Файловый майнинг, подтверждение владения

[Mitch]

В рамках разработки одного интересного проекта, я уперся в проблему:

Нужно придумать алгоритм, в рамках которого можно было бы заключать смарт контракт с подтверждением наличия файла.
Автор файла - хочет отдать файл на хранение.
Нода - принимает файл на хранение.
Автор с нодой заключают смарт контракт, оба кладут на смарт контракт монетки, нода оставляет свою подпись.
Автор полностью устраняется и более не участвует в процессе.
В контракте указана дата, когда Нода должна предъявить смарт контракту файл (или как то достоверно подтвердить владение файлом).

Если смарт контракт может получать произвольные данные, которые не сохраняются в блокчейн, а сохраняется только результат их обработки (банально на вход упал файл и его хеш был сравнен с хешем в контракте) то проблемы нет, сверил хеш и отдал монетки.
Я не достаточно хорошо понимаю смарт контранты, и не уверен что можно как то передать в контракт данные которых нет в блокчейне.
Подскажите плиз, как это можно реализовать, может уже есть проекты с такими возможностями?
PS Проекты конечно только децентрализованные, центральный сервер использовать нельзя.

Если же целиком файл нельзя отправить в смарт контракт, то есть ли какие идеи как реализовать подтверждение владениея файла?
Например, автор может до создания контракта вычислить хеш (файл+random), и как то спрятать значение random и хеша, так чтобы его не могла узнать нода, но контракт смог их узнать в нужную дату.
Не смог пока придумать как можно данные так спрятать в блокчейне, чтоб только контракт мог получить к ним доступ, код контракта то весь открыт его можно прочесть и понять где спрятаны данные.

Либо может быть еще одна сущность, созданная автором, в которой хранится random+хеш, которая шлет их в контракт в нужную дату.
Но если это еще один контракт в этом же блокчейне, то он может быть легко найден нодой, а если это что то снаружи, то это тоже должно быть что то децентрализованное, без сервера.

[bomj]

Размер файла?
Т.е. заказчик хочет создать временную метку, если я правильно понял.

[Mitch]

Размер файла?
Т.е. заказчик хочет создать временную метку, если я правильно понял.

Большой файл всегда можно разбить на части, так что какое то конкретное ограничение нет смысла обсуждать.
Но в целом поток в 1 петабайт в сутки должен нормально проходить, и это не должно быть пределом.

[Vtools]

Нужно придумать алгоритм, в рамках которого можно было бы заключать смарт контракт с подтверждением наличия файла.

Навскидку, можно попробовать сделать так:
1)Автор в смарт-контракте записывает меркл-хэш файла и закидывает монеты.
2)Нода периодически, например, раз в неделю отправляет транзакцию в виде меркл-пруфа, который доказывает что нода хранит файл и за это получает монеты со смарт-контракта. Меркл-пруф рассчитывается от случайного сегмента файла. Случайность выбирается на основании какого-либо хэша блока (важно чтобы нода не могла повлиять на эту случайность и не могла выбрать понравившуюся случайность).

[Mitch]

Навскидку, можно попробовать сделать так:
1)Автор в смарт-контракте записывает меркл-хэш файла и закидывает монеты.
..

Нода получив файл может просто рассчитать такой же меркл-хэш и удалить файл за ненадобностью.
И даже это не потребуется, ведь нода может просто посмотреть в смарт контракт и найти в нем данные меркл хеша.

Модель разумеется должна быть устойчива к злонамереным нодам с модифицированным кодом которые умеют делать всякие умные вещи.

[Vtools]

Навскидку, можно попробовать сделать так:
1)Автор в смарт-контракте записывает меркл-хэш файла и закидывает монеты.
..

Нода получив файл может просто рассчитать такой же меркл-хэш и удалить файл за ненадобностью.
И даже это не потребуется, ведь нода может просто посмотреть в смарт контракт и найти в нем данные меркл хеша.

Модель разумеется должна быть устойчива к злонамереным нодам с модифицированным кодом которые умеют делать всякие умные вещи.

Тут важен пункт 2. А в целом я ничего нового не изобретал, это базовые вещи - называется proof of capacity, погуглите...

[Mitch]

Нода то отправит, а как смарт контракт проверит что это верный данные, если у него нет файла?

[Vtools]

Нода то отправит, а как смарт контракт проверит что это верный данные, если у него нет файла?

Повторюсь - см. алгоритм пункта 2. Я все же настаиваю чтобы вы погуглили...

[Coin-1]

Нода то отправит, а как смарт контракт проверит что это верный данные, если у него нет файла?

Судя по всему, при такой схеме смарт-контракт никак не сможет проверить подлинность данных. Полагаю, что файл должен храниться минимум в двух экземлярах, к тому же, в языке Solidity (который используется в Ethereum) предусмотрена специальная функция, дающая возможность обращения к внешним интернет-ресурсам (хотя, надо сказать, доступность этого ресурса с ноды майнера в момент добавления нового блока в блокчейн не гарантируется).

Vtools предложил интересное решение, однако алгоритм "Proof of Capacity", по-моему, подразумевает множество майнеров, и там решается немного другая задача, нежели чем у топикстартера.


Могу навскидку предложить такой вариант. Смарт-контракт заключается между владельцем файла и двумя (или более) неафиллированными (независящими друг от друга) хостерами. Их ноды поочерёдно отправляют в смартконтракт, к примеру, 32-байтный сегмент файла, причём шагом, допустим, 16 байт. То есть сначала первая нода шлёт 256-битную бинарную строку с отступом 0 от начала файла, потом вторая нода через заданное контрактом время шлёт бинарную строку с отступом 16, после этого первая нода отсылает строку с отступом 32, и так далее. Через более длительные интервалы времени отступ может меняться в зависимости от хеша одного из текущих блоков Ethereum, порядковый номер которого вычисляется по некой формуле, что реализует рандомность алгоритма. Смарт-контракт сможет сравнить одинаковость начальных и конечных 16 байтов, присланных разными нодами, и, в случае несовпадения, разорвать заключённое соглашение со всеми хостерами. Тогда вопрос должен решаться через разбирательство, кто из них нарушил взятое на себя обязательство по хранению файла.

[Mitch]

Могу навскидку предложить такой вариант. Смарт-контракт заключается между владельцем файла и двумя (или более) неафиллированными (независящими друг от друга) хостерами. Их ноды поочерёдно отправляют в смартконтракт, к примеру, 32-байтный сегмент файла, причём шагом, допустим, 16 байт. То есть сначала первая нода шлёт 256-битную бинарную строку с отступом 0 от начала файла, потом вторая нода через заданное контрактом время шлёт бинарную строку с отступом 16, после этого первая нода отсылает строку с отступом 32, и так далее. Через более длительные интервалы времени отступ может меняться в зависимости от хеша одного из текущих блоков Ethereum, порядковый номер которого вычисляется по некой формуле, что реализует рандомность алгоритма. Смарт-контракт сможет сравнить одинаковость начальных и конечных 16 байтов, присланных разными нодами, и, в случае несовпадения, разорвать заключённое соглашение со всеми хостерами. Тогда вопрос должен решаться через разбирательство, кто из них нарушил взятое на себя обязательство по хранению файла.

Интересная идея!
Ноды у нас == хостеры.
Допустим контракт заключен с 1000-й нод, у всех у них должен быть файл.
В момент "сверки" смарт контракт по текущему nonce вычисляет сдвиг от начала файла и все ноды поочередно присылают свои куски файла, каждая со сдвигом относительно предидущей.
Тк эти кусуки файла не одинаковые, но сильно пересекающиеся, то данные от каждой ноды перепроверяются данными от других нод, и тут действительно скрипт может с определеной надежностью быть уверен у кого есть файл, а кто "пытался угадать достроив данные от нод которые постили инфу первыми".

Если атакующий владеет большинством нод - то он конечно сможет убедить смарт контракт что именно у него есть файл, а остальные что то мутят, аналог атаки 51%.
Соответственно для недопушения этого, при выборе нод с которыми заключается контракт нужно чтобы контракт выбирал рандомные N нод среди всех открытых к заключению таких контрактов.

Сам алгоритм будет работать лучше, если скрипт сразу в реалтайме производит проверку целостности,
сам давая нодам команды, кто с каким смещением сейчас должен дать файл.
Пока нет коллизий то просто последовательно просит
Нода1 - давай 1-й кусок
Нода2 - давай 2-й кусок
Нода3 - давай 3-й кусок
..
Нода55 - давай 3-й кусок
И тут например, коллизия возникает, данные Ноды55 конфликтуют с данными Ноды53
В этот момент контрак меняет схему опроса, ему надо принять решение,  Нода53 или Нода55 врет.
Соответтсвенно у следующих например 10 нод контракт просит - дайте мне оба куска, соответствующие спонрым, щас мы сравним и решим кто прав.
Каких вариантов больше прилетело тот считаем верным.
Все ноды что дали неверный ответ - исключаем из дальнейшей сверки и выплаты вознаграждения.
Продолжаем опрос.

[Coin-1]

И тут например, коллизия возникает, данные Ноды55 конфликтуют с данными Ноды53
В этот момент контрак меняет схему опроса, ему надо принять решение,  Нода53 или Нода55 врет.
Соответтсвенно у следующих например 10 нод контракт просит - дайте мне оба куска, соответствующие спонрым, щас мы сравним и решим кто прав.
Каких вариантов больше прилетело тот считаем верным.
Все ноды что дали неверный ответ - исключаем из дальнейшей сверки и выплаты вознаграждения.
Продолжаем опрос.

Предложенную мной схему можно ещё упростить. На самом деле, задача сводится к тому, чтобы создать условия, при которых хостеры конкурировали бы между собой. То есть у честных хостеров должна быть заинтересованность в исключении недобросовестных хостеров, которые не хранят файл, не присылают ответы в требуемый срок или намеренно отправляют фейковые данные.

Суть упрощения схемы заключается в следующем. Все хостеры по очереди отсылают в смарт-контракт транзакции, содержащие 32-байтные сегменты файла с определённым отступом, который вычисляется из хеша одного из текущих блоков Ethereum. После этого другие хостеры, автоматизированно читая блокчейн, просто сверяют эту 256-битную строку с хранимыми у себя бинарными данными и, в случае несовпадения, отправляют в смарт-контракт специальную транзакцию, которая сигнализирует о том, что тот хостер прислал неверные данные.

Теоретически, можно обязать всех хостеров вносить на смарт-контракт депозит, который распределяется между всеми добросовестными хостерами в таких конфликтных случаях.

[Mitch]

При сигнализировании, получается надо еще указать верные данные, чтоб нельзя было просто так жаловаться непонятно что утверждая.
Чтобы на саму жалобу также можно было жаловаться, если это жалоба от атакующего.

[Coin-1]

При сигнализировании, получается надо еще указать верные данные, чтоб нельзя было просто так жаловаться непонятно что утверждая.
Чтобы на саму жалобу также можно было жаловаться, если это жалоба от атакующего.

Думаю, что хостер, который отправил заведомо ложную жалобу в смарт-контракт, должен терять свой депозит, так как это очевидное злоупотребление системой. В такой ситуации встаёт вопрос о проведении разбирательства: действительно ли хостер, на которого поступила жалоба, удалил файл со своего носителя информации и прислал фейковую 256-битную строку с целью получить регулярную оплату за услугу по мнимому хранению данных, или же он добросовестно выполняет взятые на себя обязательства.

Идеальный вариант, конечно, когда сам владелец файла является одним из хостеров. Тогда в конфликтных ситуациях он может проверить данные, присылаемые другими хостерами, и для смарт-контракта решение владельца файла будет всегда истинным.

Если же владелец файла не хранит свой файл, точнее говоря, не является хостером в данной системе, то, полагаю, вопрос может решаться простым голосованием среди всех хостеров, которые внесли депозит на смарт-контракт.

[Mitch]

Систему важно сконструировать так, чтобы владелец\автор файла мог не быть хостером, а если и был, то не имел никаких дополнительных прав.
Нужно иммутабельное хранилище данных, так чтобы автор тоже не мог изменять файл после его заливки в сеть.

Получается да, если коллизия то голосуют все кто заключал контракт и те кого меньшинство теряют свой депозит и статус хостера.
Похоже что как минимум одно решение этой задачи найдено, отлично!