Запровадження
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/3 учасників).
В даному випадку дотримується лише вимога 1, і не дотримується 2. Хешируючи непередбачувані значення блоку, ми отримаємо рівномірний розподіл і хороші рандоми. Але BP має як мінімум можливість “опублікувати блок, чи ні”. Таким чином BP як мінімум може вибирати з ДВУ варіантів рандому: "свого" і того, який вийде, якщо блок зробить хтось інший. BP може заздалегідь "підглядати", що вийде, якщо він опублікує блок і просто приймає рішення робити це чи ні. Таким чином, граючи, наприклад, у “чет-нечет” або “червоне/чорне” в рулетці, він може публікувати блок тільки, якщо бачить виграш. Це також робить неробочою стратегію використання, наприклад, хеша блоку "з майбутнього". У цьому випадку кажуть, що “буде використаний рандом, який виходить хешуванням поточних даних та хешу майбутнього блоку заввишки, наприклад, N + 42, де N – поточна висота блоку. Це трохи посилює схему, але все одно дозволяє 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 точок, вся функція може бути відновлена.
Хороше пояснення наведено в а погратися з ним практично, щоб програти протокол у голові корисно на сторінці.
Якби схема 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-підписів, а ось ще один хороший від 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 , А ось смарт-контракту, який обслуговує протокол).
Імплементація 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. Це означає, що щонайменше один раунд обміну в децентралізованій мережі доведеться почекати, а, враховуючи, що генерований рандом, наприклад, необхідний в іграх, практично в реальномучасі, це означає, що саботаж протоколу можливий на цьому етапі, і переваги 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 у блокчейні, що розробляється. Ми зупинилися на застосуванні threshold BLS signatures, плануємо реалізовувати PVRB на рівні консенсусу, оскільки верифікація в смарт-контрактах з прийнятним рівнем безпеки поки що неможлива. Можливо, що ми використовуємо відразу дві схеми: спочатку дорогу secret sharing для створення довгострокового random_seed, а його використовуємо далі як основу для високочастотної генерації рандому за допомогою детермінованих threshold BLS підписів, можливо обмежимося лише однією зі схем. Сказати заздалегідь, яким буде протокол, на жаль, неможливо, тішить лише те, що як і в науці, в інженерних завданнях негативний результат — це теж результат, і кожна нова спроба вирішити завдання є черговою сходинкою для пошуків усіх, хто займається проблемою. Для забезпечення вимог з боку бізнесу ми вирішуємо конкретне практичне завдання — забезпечення ігрових додатків надійним джерелом ентропії, тому нам доводиться приділяти увагу також блокчейну, зокрема питанням фінальності ланцюжка і governance мережі.
І нехай ми поки не бачимо в блокчейнах доведено стійкого PVRB, який використовувався б уже достатньо часу, щоб пройти випробування справжніми додатками, множинними аудитами, навантаженнями, і, звичайно ж, реальними атаками, але кількість можливих шляхів підтверджує, що рішення існує, і який з цих алгоритмів зрештою вирішить проблему. Ми із задоволенням будемо ділитися результатами і дякуємо іншим командам, які теж займаються цим питанням за статті та код, які дозволяють інженерам не наступати двічі на одні й ті самі граблі.
Так що, зустрівши програміста, який проектує децентралізований рандом, будьте уважні та дбайливі, за необхідності надайте психологічну допомогу 🙂
Джерело: habr.com