Хабрахабр

Случайные числа и децентрализованные сети: имплементации

function getAbsolutelyRandomNumer() { return 4; // returns absolutely random number!
}

в реальных сетях в чистом виде она неприменима: договариваться надо строго об одном бите, раундов должно быть много, а все сообщения должны быть идеально быстрыми и всегда доставляться. Как и в случае с концепцией абсолютно стойкого шифра из криптографии, реальные протоколы “Publicly Verifiable Random Beacon” (далее PVRB) лишь пытаются максимально приблизиться к идеальной схеме, т.к. Поэтому, при проектировании PVRB под конкретные задачи в современных блокчейнах, помимо невозможности контроля получаемого рандома и криптографической стойкости, возникает еще много чисто архитектурных и технических проблем. Разумеется, в реальных сетях это не так.

Это позволяет частично абстрагироваться от сетевых проблем, недоставки сообщений, проблем промежуточного софта — все эти риски принимает на себя децентрализованная сеть, и, главная ее ценность для PVRB — невозможность отозвать или испортить уже отправленную транзакцию — это не позволяет участникам отказаться от участия в протоколе, если только они не провели успешную атаку на консенсус. Сам блокчейн является для PVRB по сути средой для коммуникации, в которой сообщения=транзакции. Также, это намекает, что PVRB должен быть частью консенсуса, если сеть договорилась насчет основной цепочки блоков, пускай одновременно она договорится и о единственном честном результирующем рандоме. Такой уровень безопасности приемлем, поэтому PVRB должен быть устойчив к сговорам участникам ровно в той же мере, что и основная цепочка блокчейна. У обоих способов есть свои преимущества и недостатки, и выбор между ними крайне нетривиален. Либо, PVRB — это просто standalone протокол, реализованный смарт-контрактом, работающий асинхронно по отношению к блокчейну и блокам.

Два способа имплементации PVRB

Во всех случаях я буду иметь в виду популярные блокчейн-движки: Ethereum, EOS, и все, похожие на них по способу размещения и процессинга смарт-контрактов. Опишем подробнее два варианта имплементации PVRB — standalone версию, работающую с использованием независимого от блокчейна смарт-контракта, и consensus-integrated — встроенную в протокол, согласно которому сеть договаривается о цепочке блоков и включаемых транзакциях.

Standalone contract

Это значение может не храниться в контракте напрямую, а быть представлено только данными, из которых можно детерминировано получить одно и только одно значение результирующего рандома. В этом варианте PVRB представляет собой смарт-контракт, который принимает транзакции random-producer-ов (далее RP), обрабатывает их, комбинирует результаты, и, в результате, приходит к некоторому значению, которое может получить любой пользователь из этого контракта. В этой схеме RP — пользователи блокчейна, и участвовать в процессе генерации можно позволить кому угодно.

Вариант со standalone-contract хорош:

  • переносимостью (контракты можно таскать из блокчейна в блокчейн)
  • простотой в реализации и тестировании (контракты удобно писать и тестировать)
  • удобством в реализации экономических схем (легко сделать свой токен, чья логика служит целям PVRB)
  • возможностью запуска в уже работающих блокчейнах

Он же имеет и недостатки:

  • сильные ограничения на ресурсы при вычислениях, объем транзакций и storage (проще говоря cpu/mem/io)
  • ограничения на операции внутри контракта (не все инструкции доступны, сложно подключать внешние библиотеки)
  • невозможность организовать обмен сообщениями быстрее, чем транзакции включаются в блокчейн

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

Consensus-integrated

Результаты протокола записываются прямо в производимые блоки, а сообщения протокола отправляются по p2p сети между нодами. В этом варианте PVRB реализован в коде блокчейн-ноды, встроен или работает параллельно с обменом сообщений между нодами блокчейна. Значит сообщения PVRB, как и транзакции должны валидироваться нодами, и включаться в блоки, чтобы любой участник сети мог бы провалидировать соблюдение протокола PVRB. Так как протокол имеет результатом числа, которые должны быть записаны в блоках, сеть должна прийти к консенсусу относительно них. Иначе возможна ситуация, когда блок является валидным с точки зрения консенсуса, но протокол PVRB не соблюден, и с точки зрения PVRB блок не может быть принят. Это автоматически ведет нас к очевидному решению — если сеть договаривается в консенсусе насчет блока и транзакций в нем, то PVRB должен быть частью консенсуса, а не отдельно стоящим протоколом. Так что если выбран “consensus-integrated” вариант, PVRB становится важной частью консенсуса.

Финальность — это механизм, используемый в детерминированных консенсусах, фиксирующий блок (и цепочку, ведущую к нему), который является финальным, и никогда не будет выброшен, даже если появится параллельный форк. Описывая имплементации PVRB на уровне консенсуса в сети, ни в коем случае нельзя обойти вопросы финальности. А в EOS, например, финальными являются так называемые Last Irreversible Blocks, которые появляются в среднем каждые 432 блока (12*21 + 12*15, pre-vote + pre-commit). Например, в Bitcoin такого механизма нет — если опубликовать цепочку большей сложности, она заменит любую менее сложную, вне зависимости от длины цепочек. При появлении форков, которые старше чем последний LIB они просто отбрасываются. Этот процесс — по сути ожидание 2/3 подписей block-producers (далее BP). Также, финальными блоками являются блоки, подписанные 2/3 BP в Hyperledger, Tendermint и других pBFT-based консенсусах. Этот механизм позволяет гарантированно утверждать, что транзакция включена в блокчейн и никогда не будет откачена, какими бы ресурсами не обладал атакующий. Вот хорошая статья про финальность в Ethereum. Также, протокол для обеспечения финальности имеет смысл делать надстройкой над консенсусом, так как он может работать асинхронно с производством и публикацией блоков.

Если финальности нет, то опубликованный форк заменяет блок с “хорошей” транзакцией на другой, из “плохого” форка, в котором эти же средства переводятся на адрес атакующего. Финальность крайне важна для пользователей, которые без нее могут оказаться жертвами атаки “double spend”, когда BP “придерживает” блоки, и публикует их после того, как сеть “увидела” хорошую транзакцию. В случае с PVRB требования к финальности еще ужесточаются, так как построение форков для PVRB означает возможность для атакующего готовить несколько вариантов рандома с целью опубликовать наиболее выгодный ему, и ограничить время возможной атаки — хорошее решение.

Теперь игроки получат гарантированный рандом за N секунд, и могут быть уверены, что откатить его или переиграть заново невозможно. Поэтому лучший вариант — совместить PVRB и финальность в один протокол — тогда финализированный блок = финализированный рандом, а это именно то, что надо было получить.

Вариант с consensus-integrated хорош:

  • возможностью асинхронной реализации по отношению к производству блоков — блоки производятся как обычно, но параллельно с этим может работать протокол PVRB, который производит рандомы не каждый блок
  • возможностью имплементировать даже тяжелую криптографию, без ограничений, накладываемых на смарт-контракты
  • возможностью организовать обмен сообщениями быстрее, чем транзакции включаются в блокчейн, например часть протокола может работать между нодами без распространения сообщений по сети

Он же имеет и недостатки:

  • сложности при тестировании и разработке — придется эмулировать сетевые ошибки, пропадающие ноды, хардфорки сети
  • ошибки в реализации требуют хардфорка сети

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

Любой децентрализованный протокол должен учитывать возможность Sybil-атаки, любое действие можно сделать согласованными силами множества аккаунтов, поэтому при проектировании необходимо учитывать возможности атакующих по созданию произвольного числа участников протокола действующих в сговоре. Блокчейн, который обеспечивает прозрачный и надежный канал обмена сообщениями протокола, делает это не бесплатно.

PVRB и переменные блока.

Откуда тогда такое количество gambling приложений в Ethereum и EOS? Я не врал, когда говорил, что хорошего PVRB, проверенного множеством gambling приложений, в блокчейнах пока никто не имплементировал. Меня это удивляет также как и вас, ну откуда в полностью детерминированной среде достали столько “стойких” рандомов?

Хорошая статья про проблемы таких схем здесь. Любимый способ доставать рандом в блокчейне — это брать какую то “непредсказуемую” информацию из блока, и на основе нее делать рандом — просто прохешировав одно или несколько значений. Затем прохешировать их, одно или несколько, и, по идее должен получиться самый настоящий рандом. Можно взять какое нибудь из “непредсказуемых” значений в блоке, например хеш блока, количество транзакций, сложность сети, и другие, неизвестные заранее значения. Можно даже добавить в wihitepaper, что ваша схема “post-quantum secure”(так как существуют quantum-proof хеш функции :)).

Секрет кроется в требованиях к PVRB, напомню их из предыдущей статьи: Но даже post-quantum secure хешей недостаточно, увы.

  1. Результат должен иметь доказуемо равномерное распределение, т.е основан на доказуемо стойкой криптографии.
  2. Невозможно контролировать ни один из битов результата. Как следствие, результат не может быть заранее предсказан.
  3. Нельзя саботировать протокол генерации за счет неучастия в протоколе или путем перегрузки сети атакующими сообщениями
  4. Все вышеперечисленное должно быть стойким к сговорам допустимого числа нечестных участников протокола (например 1/3 участников).

Хешируя непредсказуемые значения из блока, мы получим равномерное распределение и хорошие рандомы. В данном случае соблюдается только требование 1, и не соблюдается 2. Таким образом BP как минимум может выбирать из ДВУХ вариантов рандома: “своего” и того, который получится, если блок сделает кто-то другой. Но у BP есть как минимум возможность “опубликовать блок, или нет”. Таким образом, играя например в “чет-нечет” или “красное/черное” в рулетке, он может публиковать блок только, если видит выигрыш. BP может заранее “подсматривать”, что получится, если он опубликует блок, и просто принимает решение делать это или нет. В этом случае говорят, что “будет использован рандом, который получается хешированием текущих данных и хеша будущего блока высотой, например, N + 42, где N — текущая высота блока. Это также делает нерабочей стратегию использования, например, хеша блока “из будущего”. Это немного усиливает схему, но все равно позволяет BP, пусть и в будущем, выбирать, придержать блок или опубликовать.

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

В ограниченном варианте, с ограничениями на размеры ставок, ограничениями количества играющих и/или KYC регистрацией (чтобы не давать одному игроку возможность использовать несколько адресов), эти схемы могут работать для небольших игр, но не более того. Так что способы с использованием информации из блока не годятся на роль универсальной имплементации PVRB.

PVRB и commit-reveal.

Если решить проблему front-running-а майнеров, должно получиться что-то более годное. Ладно, спасибо хешированию и хотя-бы относительной непредсказуемости хеша блока и других переменных. Давайте добавим в эту схему пользователей — пускай тоже влияют на рандом: любой сотрудник техподдержки скажет вам, что самое рандомное в IT системах — это действия пользователей 🙂

В этом случае последний играющий может выбирая собственный рандом контролировать какой получится результат. Наивная схема, когда пользователи просто шлют рандомные числа, а результат вычисляется как, например, хеш от их суммы, не годится. Участники сначала шлют хеши от своих рандомов (commit-ы), а затем открывают сами рандомы (reveal-ы). Поэтому используется очень широко используемый паттерн commit-reveal. Теперь слепим все это с параметрами блока, причем лучше взятого из будущего (рандом можно будет узнать только в одном из будущих блоков), и вуаля — рандом готов! Фаза “reveal” начинается лишь после того, как были собраны необходимые commit-ы, поэтому участники могут прислать ровно тот рандом, хеш от которого прислали ранее. В этом случае делать commit и не делать reveal будет невыгодно. Теперь любой игрок влияет на результирующий рандом, и может “победить” зловредного BP, перекрыв его рандом своим, неизвестным заранее, рандомом… Еще можно добавить защиту от саботирования протокола путем невскрытия на этапе reveal — просто потребовав при commit-е прикладывать к транзакции некоторую сумму — страховой депозит, который вернется только при процедуре reveal.

Теперь на результат может влиять не только майнер, но и любой участник протокола. Это была хорошая попытка, и такие схемы тоже есть в игровых DApp-ах, но увы, этого опять недостаточно. Ее простота является серьезным преимуществом — более серьезные протоколы требуют гораздо более мощных вычислений. Контролировать само значение по прежнему можно, с меньшей степенью вариативности и за деньги, но, как и в случае с майнером, если результаты розыгрыша ценнее, чем плата за участие в протоколе PVRB, то random-producer(RP) может решать, делать ли reveal и по-прежнему может выбирать из минимум двух вариантов рандома.
Зато появилась возможность наказывать тех, кто делает commit и не делает reveal, и эта схема еще пригодится.

PVRB и детерминированные подписи.

Такой подписью является, например, RSA, и не является ECS. Есть еще один способ заставить RP предоставить псевдослучайное число, на которое он не сможет повлиять, если ему предоставить “прообраз” — это детерминированная подпись. Это происходит из за того, что при создании ECS подписи используется рандомное число, выбираемое подписывающим, и оно может быть выбрано как угодно, давая подписывающему возможность выбирать одну из нескольких подписей. Если у RP есть пара ключей: RSA и EСС, и он подписывает своим приватным ключом некоторое значение, то в случае RSA у него получится ОДНА И ТОЛЬКО ОДНА подпись, а в случае ECS — он может сгенерировать любое число различных валидных подписей. Предсказать какая получится подпись у другого RP не получится, поэтому PVRB с детерминированными подписями может быть организован при помощи комбинирования RSA подписей нескольких участников, которые подписали одно и то же значение. В случае RSA: “одно входное значение” + “одна пара ключей” = “одна подпись”. В такой схеме экономится немало ресурсов, т.к. Например — предыдущий рандом. подписи являются одновременно и подтверждением корректности поведения по протоколу, и источником рандома.

Последний участник по прежнему может решать, публиковать ему подпись или нет, тем самым контролируя результат. Тем не менее, даже с детерминированными подписями, схема по прежнему уязвима к проблеме “last actor”. Кроме того размер ключей RSA (1024 и 2048 бит) довольно большой, а размер для блокчейн транзакций является крайне важным параметром. Можно дорабатывать схему, добавлять в нее хеши блоков, делать раунды, чтобы заранее результат нельзя было бы предсказать, но все эти приемы, даже с учетом множества доработок, все равно оставляют нерешенной проблему влияния одного участника на коллективный результат в недоверенном окружении и могут работать лишь в условиях экономических и временных ограничений. Видимо по-простому решить проблему не получится, идем дальше.

PVRB и secret sharing схемы

Один из полезных протоколов, с которыми стоит познакомиться — схема разделения секрета Шамира. В криптографии существуют схемы, которые могут позволить сети договориться об одном и только одном значении PVRB, при этом такие схемы устойчивы к любым злонамеренным действиям части участников. Секрет распределяется таким образом, что для его восстановления достаточно M частей из N, при этом это могут быть любые M частей. Она служит для того, чтобы разделить секрет (например секретный ключ) на несколько частей, и раздать эти части N участникам. Если на пальцах, то имея график неизвестной функции, участники обмениваются точками на графике, и после получения M точек, вся функция может быть восстановлена.
Хорошее объяснение приведено в wiki а поиграться с ним практически, чтобы проиграть протокол в голове полезно на demo страничке.

В простейшем варианте протокол может выглядеть так: Если бы схема FSSS(Fiat-Shamir Secret Sharing) была применима в чистом виде — это был бы неубиваемый PVRB.

  • Каждый участник генерирует собственный random и раздает shares от него остальным участникам
  • Каждый участник вскрывает свою часть секретов остальных участников
  • Если для участника набралось больше M shares, то число этого участника можно вычислить, и оно будет единственным, вне зависимости от набора вскрывшихся участников
  • Комбинация вскрытых random-ов и есть искомый PVRB

Поэтому этот протокол, при наличии необходимой доли работающих по протоколу и доступных RP работает, реализуя требования по криптографической стойкости, и являясь устойчивым к проблеме “last actor”. Здесь отдельный участник уже не влияет на результаты протокола, за исключением случаев, когда только от него зависит достижение threshold-а раскрытия рандома.

Но, как и было сказано выше, если попытаться применить ее в лоб в блокчейне, появляются уже технические ограничения. Это мог бы быть идеальный вариант, эта схема PVRB на основе secret sharing Фиата-Шамира описана, например, в этой статье. По коду видно, что валидация proof-а требует нескольких скалярных умножений, а числа используются очень большие. Вот пример тестовой реализации протокола в смарт-контракте EOS и наиболее важная его часть — проверка опубликованного share участника: код. В этом варианте вариант оказался неработоспособным, так как верификация не укладывалась в ограничение на транзакцию(0. При этом надо понимать, что в блокчейнах verify происходит в момент, когда block-producer процессит транзакцию, и вообще любой участник должен легко проверить корректность протокола, поэтому требования к скорости функции verify очень серьезные. 5 сек).

Создание proof-ов, подготовка сообщений — эти процедуры можно вынести off-chain и выполнять на высокопроизводительных компьютерах, но верификацию обойти не удастся — это еще одно важное требование к PVRB. Эффективность верификации — одно из важнейших требований к использованию в общем-то любых продвинутых криптографических схем в блокчейне.

PVRB и threshold signatures

Когда для раскрытия некоторой информации требуется участие M честных участников из N, и набор честных участников может быть произвольным подмножеством N, говорят о “threshold” схемах. Познакомившись со схемой secret sharing, мы открыли целый класс протоколов, объединенных ключевым словом “threshold”. Эти схемы позволяют договориться об одном и только одном значении, даже при саботировании протокола частью участников. Именно они позволяют разобраться с проблемой “last actor”, теперь если атакующий не открывает свою часть секрета, за него это сделает другой, честный участник.

Вот статья о различных применениях threshold-подписей, а вот еще один хороший longread от Dash. Совмещение детерминированных подписей и threshold-схем позволило разработать очень удобную и многообещающую схему для реализации PVRB — это детерминированные threshold-подписи.

Они обладают также детерминистичностью и на одних и тех же входных данных выдают один и тот же результат. В последней статье описываются BLS подписи (BLS расшифровывается как Boneh-Lynn-Shacham, вот статья ), которые имеют очень важное и крайне удобное для программистов качество — публичные, секретные, публичные ключи и подписи BLS могут комбинироваться друг с другом при помощи простых математических операций, при этом их комбинации остаются валидными ключами и подписями, позволяя легко агрегировать много подписей в одну и много публичных ключей в один. Благодаря этому качеству, комбинации BLS подписей сами являются валидными ключами, что позволяет реализовать вариант, при котором M из N участников производят одну и только одну подпись, которая детерминирована, publicly verifiable, и непредсказуема до тех пор, пока не будет вскрыта M-тым участником.

Криптографические свойства подписей BLS удовлетворяют требованиям к качеству рандома, threshold-часть защищает от “last-actor”, а уникальная комбинируемость ключей позволяет реализовать еще много интересных алгоритмов, которые позволяют, например, эффективно агрегировать сообщения протокола. В схеме с threshold BLS signatures каждый участник подписывает с помощью BLS что-то (например предыдущий рандом), а общая threshold-подпись и есть искомый рандом.

Например, DFinity (здесь бенчмарк, реализующий схему, а тут пример реализации verifiable secret sharing), или Keep.network (вот их random beacon yellowpaper, а вот пример смарт-контракта, обслуживающего протокол). Так что, если вы строите PVRB в своем блокчейне, вы с большой вероятностью придете к схеме BLS threshold signatures, ее уже используют несколько проектов.

Имплементация PVRB

Несмотря на то, что сами протоколы готовы, технически применить их к существующим решениям непросто. К сожалению, до сих пор мы не видим готового, реализованного в блокчейнах PVRB протокола, доказавшего свою безопасность и устойчивость. Проектирование PVRB — это комбинирование разных протоколов, чтобы все таки слепить то, что подойдет по всем требованиям хотя бы к какому нибудь жизнеспособному блокчейну. Для централизованных систем PVRB не имеет смысла, а децентрализованные строго ограничены во всех вычислительных ресурсах: CPU, memory, storage, I/O. Один протокол эффективней вычисляет, но требует больше сообщений между RP, а другой требует крайне мало сообщений, но создание proof-а может быть задачей на десятки минут, а то и часов.

Я перечислю факторы, которые вам придется учитывать при выборе качественного PVRB:

  • Криптографическая стойкость. Ваш PVRB должен быть строго unbiasable, без возможности контроля единственного бита. В некоторых схемах это не так, поэтому зовите криптографа
  • Проблема “last actor”. Ваш PVRB должен быть устойчив к атакам, когда атакующий, контролирующий одного или нескольких RP может выбирать один из двух вариантов результата.
  • Проблема саботажа протокола. Ваш PVRB должен быть устойчив к атакам, когда атакующий, контролирующий одного или нескольких RP решает, быть ли рандому или нет и может гарантированно, либо с заданной вероятностью влиять на это
  • Проблема количества сообщений. Ваши RP должны посылать в блокчейн минимум сообщений и максимально избегать синхронных действий типа ситуаций “я отправил некоторую информацию, жду ответа от конкретного участника”. В p2p сетях, особенно разнесенных географически, не стоит расчитывать на быстрый ответ
  • Проблема вычислительной сложности. Верификация любого этапа PVRB on-chain должна быть крайне легкой, так как ее выполняют все полные клиенты сети. Если реализация делается с помощью смарт-контракта, то требования к скорости очень жесткие
  • Проблема доступности и liveness. Ваш PVRB должен стремиться быть устойчивым к ситуациям, когда часть сети стала недоступной на некоторое время и часть RP просто перестала работать
  • Проблема trusted setup и первоначального распределения ключей. Если ваш PVRB использует первичный setup протокола, то это отдельная большая и серьезная история. Вот пример. Если участники должны перед начало протокола сообщить друг-другу свои ключи — это тоже проблема, если состав участников меняется
  • Проблемы разработки. Наличие библиотек на нужных языках, их безопасность и производительность, публичность, сложные тесты и т.п.

Это означает, что как минимум один раунд обмена в децентрализованной сети придется выждать, а, учитывая, что генерируемый рандом, к примеру, необходим в играх, практически в realtime, это означает, что саботаж протокола возможен на этом этапе, и преимущества threshold схемы теряются. К примеру у threshold BLS подписей есть существенная проблема — перед тем как начать работать, участникам обязательно надо раздать друг другу ключи, организовав группу, в рамках которой будет работать threshold. Также, верификация BLS с приемлемым уровнем безопасности попросту не помещается, например, в стандартную транзакцию EOS или Ethereum — просто не хватает времени на верификацию. Эта проблема уже проще предыдущих, но все равно требует разработки отдельной процедуры формирования threshold-групп, которую придется защищать экономически, за счет депозитов и отъема средств(slashing) у участников, не следующих протоколу. Криптографические функции не реализованы нативно(пока), и работают в десятки раз медленнее обычных криптографических библиотек. Код контрактов — это WebAssembly или EVM, исполняется виртуальной машиной. Многие протоколы не подходят по требованиям просто исходя из объема ключей, например это 1024 и 2048 bit для RSA, в 4-8 раз больше, чем стандартная подпись транзакции в Bitcoin и Ethereum.

Вариант с интеграцией в консенсус требует писать протокол на языке платформы, поэтому придется искать код на Go для geth, на Rust для Parity, на C++ для EOS. Играет роль и наличие реализаций на разных языках программирования — которых немного, особенно для новых протоколов. Код на JavaScript придется искать всем, а так как JavaScript и криптография не особо близкие друзья, поможет WebAssembly, который теперь уже точно претендует на роль следующего важного интернет-стандарта.

Заключение

Вообще, окончательный дизайн протокола возможен лишь после проведения массивных тестов, учитывающих все аспекты от setup-а до эмуляции сбоев, поэтому вы вряд ли найдете готовые рецепты в whitepaper-ах команд и в статьях, да и мы в ближайший год-два точно не решимся писать “делайте так, так точно правильно”. Надеюсь, в предыдущей статье я сумел убедить вас, что генерация случайных чисел на блокчейне критически важна для множества аспектов жизни децентрализованных сетей, а этой статьей показал, что задача эта крайне амбициозная и непростая, но хорошие решения уже существуют.

Возможно, что мы используем сразу две схемы: сначала дорогую secret sharing для создания долгосрочного random_seed, а его используем далее в качестве основы для высокочастотной генерации рандома с помощью детерминированных threshold BLS подписей, возможно ограничимся лишь одной из схем. Пока, для нашего PVRB в разрабатываемом блокчейне Haya, мы остановились на применении threshold BLS signatures, планируем реализовывать PVRB на уровне консенсуса, так как верификация в смарт-контрактах с приемлемым уровнем безопасности пока невозможна. Для обеспечения требований со стороны бизнеса мы решаем конкретную практическую задачу — обеспечение игровых приложений надежным источником энтропии, поэтому нам приходится уделять внимание также самому блокчейну, в частности вопросам финальности цепочки и governance сети. Сказать заранее, каким будет протокол, увы, невозможно, радует лишь то, что как и в науке, в инженерных задачах отрицательный результат — это тоже результат, и каждая новая попытка решить задачу является очередной ступенькой для изысканий всех, занимающихся проблемой.

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

Так что, встретив программиста, проектирующего децентрализованный рандом, будьте внимательны и заботливы, при необходимости окажите психологическую помощь 🙂

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть