Опишу процесс по шагам:
1. Я отправляю вывод стратегии на соревнование 8 ого июля
2. Платформа генерирует хеши от всех выводов, потом генерирует один хеш из всех хешей, назовем это ROOT HASH, и сохраняет данный ROOT HASH в блокчейне (в контракте).
3. Прошел месяц, я хочу проверить, что мой вывод был отправлен корректно и не был скорректирован.
4. Я получаю с платформы свой вывод и хеши других выводов на 8-е июля
5. Я хеширую свой вывод и хеширую все хеши выводов в один хеш (все то же самое, что и в 2-ом пункте) и получаю свой локальный ROOT HASH
6. Потом сравниваю мой ROOT HASH с ROOT HASH-ом блокчейна, который был отправлен 8 ого числа
Все это пользователь может сделать автоматическим образом, с помощью open source инструмента, оно берет все данные и проверяет на валидность.
Основной блокчейн у нас блокчейн Эфира. Код контракта верифицирован, поменять или удалить что то невозможно.
Контракт принимает один хеш в сутки, и ничего другое делать не умеет (взаимодействие с внешними данными нету).
Предоставить все выводы одному пользователю на проверку мы не можем, так как это конфиденциально. Но каждый пользователь может проверять свои все выводы на все даты на валидность.
Суть интеграции PoE не в том, что мы хотим предоставить выграшние или не выигрышные хеши 3-им лицам.
Суть состоит в том, что наши пользователи, которые участвуют в конкурсе, смогли легко проверить, что их выводы не были скорректированы с нашей стороны. Имея в руках изначальный документ, и хеши соседних документов, пользователи могут легко проверять валидность, и сравнить локально сгенерированный хеш с хешем который в блокчейне.
конечно можно использовать любой блокчейн и обойтись без контрактов,
но хранение хешей в контракте имеет свои преимущества:
Все хеши и даты хранятся в одном месте, где их можно быстро достать и читать
Возможно интегрировать с другим контрактам в будущем
Все очень чисто и аккуратно
Документы хранятся у нас на серверах, где они и должны находится (они не публичные). Наша цель предоставляет доказательство отдельным пользователей платформы, что документы, которые они создали, не были скорректированы с нашей стороны, а их хеш был включен в процесс генерации главного хеша, который в блокчейне.
При желания пользователя мы предоставляем его документ на конкретную дату с соседними хешами документов того дня. Этого достаточно чтоб пользователь был уверен, что его документ не был скорректирован.
Насчет оракулов не уверена, что их тут вообще нужно использовать. Хранить хеш каждого документа в блокчейне будет стоит очень дорого, для этого мы реализовали трюк с одним хешом.
Хеширование нужно для участников, чтоб у них был неоспоримое доказательство, что хеш который доступен в блокчейне был сгенерирован (в том числе) из хеша вывода стратегии участника
Суть состоит в том, что участники могут быть полностью уверены, что вывод стратегии не подвергался корректировке
1. Я отправляю вывод стратегии на соревнование 8 ого июля
2. Платформа генерирует хеши от всех выводов, потом генерирует один хеш из всех хешей, назовем это ROOT HASH, и сохраняет данный ROOT HASH в блокчейне (в контракте).
3. Прошел месяц, я хочу проверить, что мой вывод был отправлен корректно и не был скорректирован.
4. Я получаю с платформы свой вывод и хеши других выводов на 8-е июля
5. Я хеширую свой вывод и хеширую все хеши выводов в один хеш (все то же самое, что и в 2-ом пункте) и получаю свой локальный ROOT HASH
6. Потом сравниваю мой ROOT HASH с ROOT HASH-ом блокчейна, который был отправлен 8 ого числа
Все это пользователь может сделать автоматическим образом, с помощью open source инструмента, оно берет все данные и проверяет на валидность.
Контракт принимает один хеш в сутки, и ничего другое делать не умеет (взаимодействие с внешними данными нету).
Предоставить все выводы одному пользователю на проверку мы не можем, так как это конфиденциально. Но каждый пользователь может проверять свои все выводы на все даты на валидность.
Суть состоит в том, что наши пользователи, которые участвуют в конкурсе, смогли легко проверить, что их выводы не были скорректированы с нашей стороны. Имея в руках изначальный документ, и хеши соседних документов, пользователи могут легко проверять валидность, и сравнить локально сгенерированный хеш с хешем который в блокчейне.
Для валидации мы создали среду разработки, который вы можете посмотреть тут:
github.com/qntnet/strategy-verification/blob/master/strategy.ipynb
конечно можно использовать любой блокчейн и обойтись без контрактов,
но хранение хешей в контракте имеет свои преимущества:
Все хеши и даты хранятся в одном месте, где их можно быстро достать и читать
Возможно интегрировать с другим контрактам в будущем
Все очень чисто и аккуратно
Документы хранятся у нас на серверах, где они и должны находится (они не публичные). Наша цель предоставляет доказательство отдельным пользователей платформы, что документы, которые они создали, не были скорректированы с нашей стороны, а их хеш был включен в процесс генерации главного хеша, который в блокчейне.
При желания пользователя мы предоставляем его документ на конкретную дату с соседними хешами документов того дня. Этого достаточно чтоб пользователь был уверен, что его документ не был скорректирован.
Насчет оракулов не уверена, что их тут вообще нужно использовать. Хранить хеш каждого документа в блокчейне будет стоит очень дорого, для этого мы реализовали трюк с одним хешом.
Хеширование нужно для участников, чтоб у них был неоспоримое доказательство, что хеш который доступен в блокчейне был сгенерирован (в том числе) из хеша вывода стратегии участника
Суть состоит в том, что участники могут быть полностью уверены, что вывод стратегии не подвергался корректировке