Введение

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

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

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

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

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

Standalone contract

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

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

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

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

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

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

Consensus-integrated

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PVRB и commit-reveal.

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

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

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

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

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

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

PVRB и secret sharing схемы

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

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

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

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

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

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

PVRB и threshold signatures

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

Источник: habr.com