Comments 17
Можно ли генерировать случайные числа, если мы не доверяем друг другу?Конечно можно, даже без крипто
Спасибо за разбор и пятничную КДПВ.
Год назад работал над этой проблемой в составе группы. В итоге получилась довольно аккуратная библиотека https://github.com/corestario/HERB с ней есть onchain и offchain пакеты.
Ожидал что вы будете выпускать статьи в духе: Делаем клон твитера на блокчейне Неар
Офигенно интересная тема distributed randomness. Это и игры без доверенной стороны, и масштабирование, особенно масштабирование для bft баз.
Мне кажется наоборот, очень классно, что люди пишут статьи именно про сложные технические подробности, а не очередное "запилим твиттер на платформе" без заглядывания под капот.
У нас очень разные статьи в очереди, и такие же "узконаправленные", и о разработке на NEAR, и более научно-популярные.
Есть вот такой очень простой пример гостевой книги, там можно открыть в Gitpod и прямо из браузера собрать и запустить. Не совсем твитер, но показывает как примерно выглядит разработка.
Но вообще хранить твиты или сообщения в гостевой книге на цепи дорого, для этого нужно другое решение.
NEAR разбивает состояние на несколько шардов, синхронизовать ноду, которая только подмножество шардов смотрит, быстрее (но учитывая что каждый шард потенциально ~30x быстрее чем Эфир, даже один шард синхронизовать в среднесрочной перспективе станет очень долго). Состояние каждого шарда — это подмножество всего состояния, и соответственно хранить его дешевле, чем все состояние.
За хранение данных надо не платить, а класть токены в залог (когда данные удалены, токены освобождаются). Соответственно общий размер данных ограничен сверху.
Если нет цели валидировать все с genesis, то нода может достаточно быстро проверить заголовки блоков, убедиться что с genesis до текущего момента все блоки имеют правильные подписи, и скачать состояние где-то на начало дня, которое можно проверить имея недавний заголовок. Потом можно валидировать вперед.
В среднесрочной перспективе мы будем просто выкладывать большие блобы, которые хранят состояние шарда на, допустим, начало месяца, и все транзакции в этом шарде в этом месяце, и соответственно если необходимо все-таки валидировать все с genesis, валидацию можно будет выполнить параллельно по месяцам и шардам.
А в бд как храните состояние? Плоской структурой или деревом?
Синхронизация идёт блок за блоком с полной проверкой и исполнением каждого блока? Или есть разделение на стадии обработки?
Достаточно быстро скачать и проверить заголовки — это за сколько?
В БД в текущей реализации храним как персистентное дерево, но даже в краткосрочной перспективе это не работает, потому что чтения слишком медленные.
Синхронизация идет блок за блоком, но не обязательно с genesis, и параллельная валидация планируется позже (но сейчас далеко не самая приоритетная задача).
"Достаточно быстро" — сейчас мы валидируем все заголовки, это занимает меньше часа. Но есть возможность синхнонизоваться намного быстрее скачивая только два заголовка на каждый день. Мы уже используем этот вариант для моста с Эфиром, и в скором времени полная нода тоже будет также синхронизовываться прежде чем скачивать недавнее состояние. Такая валидация занимает меньше минуты на каждый год работы протокола. Скачивание состояния в таком варианте — самая тяжелая часть. Но опять же, состояние разбито на шарды, так что скачивать все состояние тоже не надо.
Хранение в плоском виде рассматривали?
Смотря что такое "плоском". От дерева нам совсем избавиться нельзя, потому что надо быстро пересчитывать корень merkle tree.
Мы просто добавляем хеш-таблицу для чтений, и вероятно избавляемся от персистентности, там персистентность упрощает реализацию, но не необходима.
Key-value — https://youtu.be/CSpc1vZQW2Q
Очень интересная статья, спасибо. Проверку H_i не проще ли сделать, как pair(H_i, G) = pair(H, p(i)G)? Или этот протокол часто применяется не кривых, где спаривания нет?
И самое главное, где же сам код (именно этой реализации)?
Можно ли генерировать случайные числа, если мы не доверяем друг другу? Часть 2