Comments 17
Кажется есть проблема. Каждый день делаем два предсказания — цена пойдёт вверх, цена пойдёт вниз. Затем даём клиентам хеши сбывшихся предсказаний. Профит.
Имхо хеш дают вместе с предсказанием.
Привет! andreyverbin savostin
Хеширование нужно для участников, чтоб у них был неоспоримое доказательство, что хеш который доступен в блокчейне был сгенерирован (в том числе) из хеша вывода стратегии участника
Суть состоит в том, что участники могут быть полностью уверены, что вывод стратегии не подвергался корректировке
Хеширование нужно для участников, чтоб у них был неоспоримое доказательство, что хеш который доступен в блокчейне был сгенерирован (в том числе) из хеша вывода стратегии участника
Суть состоит в том, что участники могут быть полностью уверены, что вывод стратегии не подвергался корректировке
Андрей, имхо, говорит о том, что можно не подделать хеш, а сгенерировать 2 хеша, оба положить в блокчейн и затем выдать тот, который оказался правильным. Я говорю о том, что сгенерированный хеш выкладывается вместе с предсказанием, т.е. этот хеш известен до наступления события и провернуть такую схему будет невозможно.
Суть интеграции PoE не в том, что мы хотим предоставить выграшние или не выигрышные хеши 3-им лицам.
Суть состоит в том, что наши пользователи, которые участвуют в конкурсе, смогли легко проверить, что их выводы не были скорректированы с нашей стороны. Имея в руках изначальный документ, и хеши соседних документов, пользователи могут легко проверять валидность, и сравнить локально сгенерированный хеш с хешем который в блокчейне.
Для валидации мы создали среду разработки, который вы можете посмотреть тут:
github.com/qntnet/strategy-verification/blob/master/strategy.ipynb
Суть состоит в том, что наши пользователи, которые участвуют в конкурсе, смогли легко проверить, что их выводы не были скорректированы с нашей стороны. Имея в руках изначальный документ, и хеши соседних документов, пользователи могут легко проверять валидность, и сравнить локально сгенерированный хеш с хешем который в блокчейне.
Для валидации мы создали среду разработки, который вы можете посмотреть тут:
github.com/qntnet/strategy-verification/blob/master/strategy.ipynb
Способ да, известный и применяеться не только в финансах — вернее это частный случай применения. Мы тут разрабатываем именно решения для финансов и пошли чуть дальше ) у нас добавляються еще и пруфы всех используемых котировок и алгоритмов (и истории их изменения, но это чуть в сторону уже к говернансу ближе)
Вот все говорят «отправляем в блокчейн» и как бы всё.
Поправьте, если ошибаюсь — это же не бесплатно?
Дочитал статью :|
Зачем вы делали контракт? Так как стороннее приложение (оракул) все равно требуется, необходимость заворачиваться что либо в особую логику на стороне блокчейна абсолютно бессмысленно, тем более у вас там абстрактный документ (в pdf O_o!) а не машиночитаемый формат, чтобы можно было ваши стратегии программно проверять.
Достаточно в блокчейне сохранять только хеши ваших документов (подойдут любые транзакции в любом блокчейне), а рядом хранить эти же документы в том же порядке что отправляете транзакции в блокчейн (для скорости можно хранить ссылку на эту транзакцию рядом с документом).
Собственно вся работа — сохранение этих документов, добавение и проверка на консистентность (что все документы сохранены и на каждый есть верный хеш блокчейне)
Достаточно в блокчейне сохранять только хеши ваших документов (подойдут любые транзакции в любом блокчейне), а рядом хранить эти же документы в том же порядке что отправляете транзакции в блокчейн (для скорости можно хранить ссылку на эту транзакцию рядом с документом).
Собственно вся работа — сохранение этих документов, добавение и проверка на консистентность (что все документы сохранены и на каждый есть верный хеш блокчейне)
А рассылки хешей клиентам емайлом задачу не решает?
Боюсь не достаточно, если вам нужно доказательство неподдельности данных, необходимо дать возможность получить весь список документов, правильно хранить их в блокчейне, в виде цепочки, чтобы нельзя было ни исключить документ ни подсунуть новый, если мы храним в блокчейне только хеши, значит для документов нужно реализовать аналог блокчейне, минимальный
как под хеш документа отправленного клиенту по емайлу можно «подсунуть» что либо иное кроме документа?
Вы не понимаете или специально?
Мы говорим о механизме, который позволит клиенту, в т.ч. новому, проверить, 'действительно ли сигналы у этого перца такие прибыльные как он пишет?' причем единственный откуда мы можем получить список истории сигналов — это сам заинтересованный смухлевать. Соответственно в данном случае необходимо использовать стороннюю базу данных, в которой подмена данных исключена или значительно дороже, чем выгода обмана, — какой то блокчейн, куда запихиваем хеши документов.
Вы как клиент, должны загрузить все хеши из этого блокчейна и запросить все документы (сигналы) которые были выданы. Благодаря стороннему блокчейну мы можем проверить дату появления сигнала (дата транзакции с хешем) и главное можем проверить что никакие документы не были пропущены (мы видим все хеши а на почту новичку можно отправить только 'выигрышные' сигналы).
Мы говорим о механизме, который позволит клиенту, в т.ч. новому, проверить, 'действительно ли сигналы у этого перца такие прибыльные как он пишет?' причем единственный откуда мы можем получить список истории сигналов — это сам заинтересованный смухлевать. Соответственно в данном случае необходимо использовать стороннюю базу данных, в которой подмена данных исключена или значительно дороже, чем выгода обмана, — какой то блокчейн, куда запихиваем хеши документов.
Вы как клиент, должны загрузить все хеши из этого блокчейна и запросить все документы (сигналы) которые были выданы. Благодаря стороннему блокчейну мы можем проверить дату появления сигнала (дата транзакции с хешем) и главное можем проверить что никакие документы не были пропущены (мы видим все хеши а на почту новичку можно отправить только 'выигрышные' сигналы).
rPman
конечно можно использовать любой блокчейн и обойтись без контрактов,
но хранение хешей в контракте имеет свои преимущества:
Все хеши и даты хранятся в одном месте, где их можно быстро достать и читать
Возможно интегрировать с другим контрактам в будущем
Все очень чисто и аккуратно
Документы хранятся у нас на серверах, где они и должны находится (они не публичные). Наша цель предоставляет доказательство отдельным пользователей платформы, что документы, которые они создали, не были скорректированы с нашей стороны, а их хеш был включен в процесс генерации главного хеша, который в блокчейне.
При желания пользователя мы предоставляем его документ на конкретную дату с соседними хешами документов того дня. Этого достаточно чтоб пользователь был уверен, что его документ не был скорректирован.
Насчет оракулов не уверена, что их тут вообще нужно использовать. Хранить хеш каждого документа в блокчейне будет стоит очень дорого, для этого мы реализовали трюк с одним хешом.
конечно можно использовать любой блокчейн и обойтись без контрактов,
но хранение хешей в контракте имеет свои преимущества:
Все хеши и даты хранятся в одном месте, где их можно быстро достать и читать
Возможно интегрировать с другим контрактам в будущем
Все очень чисто и аккуратно
Документы хранятся у нас на серверах, где они и должны находится (они не публичные). Наша цель предоставляет доказательство отдельным пользователей платформы, что документы, которые они создали, не были скорректированы с нашей стороны, а их хеш был включен в процесс генерации главного хеша, который в блокчейне.
При желания пользователя мы предоставляем его документ на конкретную дату с соседними хешами документов того дня. Этого достаточно чтоб пользователь был уверен, что его документ не был скорректирован.
Насчет оракулов не уверена, что их тут вообще нужно использовать. Хранить хеш каждого документа в блокчейне будет стоит очень дорого, для этого мы реализовали трюк с одним хешом.
Я говорю о переусложнении, кстати какой блокчейн у вас базовый? Контракты в нем изменяемые? Если да, то городить все это тем более бессмысленно, так как вы можете полностью переписать контракт с данными.
Оракул — это и есть ваше приложение, которо рулит внешними данными и выступает шлюзом для них в блокчейн
Оракул — это и есть ваше приложение, которо рулит внешними данными и выступает шлюзом для них в блокчейн
Основной блокчейн у нас блокчейн Эфира. Код контракта верифицирован, поменять или удалить что то невозможно.
Контракт принимает один хеш в сутки, и ничего другое делать не умеет (взаимодействие с внешними данными нету).
Предоставить все выводы одному пользователю на проверку мы не можем, так как это конфиденциально. Но каждый пользователь может проверять свои все выводы на все даты на валидность.
Контракт принимает один хеш в сутки, и ничего другое делать не умеет (взаимодействие с внешними данными нету).
Предоставить все выводы одному пользователю на проверку мы не можем, так как это конфиденциально. Но каждый пользователь может проверять свои все выводы на все даты на валидность.
Опишу процесс по шагам:
1. Я отправляю вывод стратегии на соревнование 8 ого июля
2. Платформа генерирует хеши от всех выводов, потом генерирует один хеш из всех хешей, назовем это ROOT HASH, и сохраняет данный ROOT HASH в блокчейне (в контракте).
3. Прошел месяц, я хочу проверить, что мой вывод был отправлен корректно и не был скорректирован.
4. Я получаю с платформы свой вывод и хеши других выводов на 8-е июля
5. Я хеширую свой вывод и хеширую все хеши выводов в один хеш (все то же самое, что и в 2-ом пункте) и получаю свой локальный ROOT HASH
6. Потом сравниваю мой ROOT HASH с ROOT HASH-ом блокчейна, который был отправлен 8 ого числа
Все это пользователь может сделать автоматическим образом, с помощью open source инструмента, оно берет все данные и проверяет на валидность.
1. Я отправляю вывод стратегии на соревнование 8 ого июля
2. Платформа генерирует хеши от всех выводов, потом генерирует один хеш из всех хешей, назовем это ROOT HASH, и сохраняет данный ROOT HASH в блокчейне (в контракте).
3. Прошел месяц, я хочу проверить, что мой вывод был отправлен корректно и не был скорректирован.
4. Я получаю с платформы свой вывод и хеши других выводов на 8-е июля
5. Я хеширую свой вывод и хеширую все хеши выводов в один хеш (все то же самое, что и в 2-ом пункте) и получаю свой локальный ROOT HASH
6. Потом сравниваю мой ROOT HASH с ROOT HASH-ом блокчейна, который был отправлен 8 ого числа
Все это пользователь может сделать автоматическим образом, с помощью open source инструмента, оно берет все данные и проверяет на валидность.
Sign up to leave a comment.
Как самостоятельно имплементировать (Proof of Existence) за 2 шага