Topic: Файловый майнинг, подтверждение владени&#1103 (Read 236 times)

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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