Въведение

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

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

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

Два начина за имплементация на PVRB

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

Standalone contract

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

Вариантът със standalone-contract е добър:

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

Но също така има и недостатъци:

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

Този вариант е подходящ за реализиране на PVRB, който трябва да бъде стартиран в съществуваща мрежа, не съдържа сложна криптография и не изисква голямо количество взаимодействия.

Consensus-integrated

В този вариант PVRB е реализиран в кода на блокчейн нода, интегриран или работещ паралелно с обмена на съобщения между нодовете на блокчейна. Резултатите от протокола се записват директно в произведените блокове, а съобщенията на протокола се изпращат по p2p мрежата между нодовете. Тъй като протоколът има за резултат числа, които трябва да бъдат записани в блоковете, мрежата трябва да постигне консенсус относно тях. Значи съобщенията на PVRB, както и транзакциите, трябва да бъдат валидирани от нодовете и включвани в блоковете, за да може всеки участник в мрежата да потвърди спазването на протокола PVRB. Това ни води автоматично до очевидното решение - ако мрежата се договаря в консенсус относно блока и транзакциите в него, то PVRB трябва да бъде част от консенсуса, а не отделен протокол. В противен случай е възможна ситуация, при която блокът е валиден от гледна точка на консенсуса, но протоколът PVRB не е спазен, и от гледна точка на PVRB блокът не може да бъде приет. Така че, ако е избран вариант с "интегриран в консенсуса", PVRB става важна част от него.

Описвайки имплементации на PVRB на ниво консенсус в мрежата, не бива по никакъв начин да се заобикалят въпросите относно финалността. Финалността е механизъм, използван в детерминирани консенсуси, който фиксира блок (и веригата, водеща към него), който е финален и никога няма да бъде отменен, дори ако се появи паралелен форк. Например, в Bitcoin такъв механизъм няма - ако се публикува верига с по-голяма сложност, тя ще замени всяка по-малко сложна, независимо от дължината на веригите. А в EOS, например, финалните блокове са т.н. Last Irreversible Blocks, които се появяват средно на всеки 432 блока (12*21 + 12*15, пред-готвене + пред-комитване). Този процес - по същество изчакване на 2/3 от подписите на производителите на блокове (наричани BP). Когато се появят форкове, които са по-стари от последния LIB, те просто се отхвърлят. Този механизъм позволява да се гарантира, че транзакцията е включена в блокчейна и никога няма да бъде отменена, независимо от ресурсите на атакуващия. Финалните блокове също така са блоковете, подписани от 2/3 от BP в Hyperledger, Tendermint и други pBFT-базирани консенсуси. Също така, протоколът за осигуряване на финалност има смисъл да бъде надстройка над консенсуса, тъй като той може да работи асинхронно с производството и публикуването на блокове. Ето едно добро статия за финалността в Ethereum.

Финалността е изключително важна за потребителите, тъй като без нея те могат да станат жертви на атака „двойно харчене“, при която BP „задържа“ блокове и ги публикува след като мрежата е „видяла“ добра транзакция. Ако финалността липсва, публикуваният forк заменя блока с „добрата“ транзакция с друг, от „лошия“ forк, в който същите средства се прехвърлят на адреса на атакуващия. В случая с PVRB изискванията към финалността са още по-строги, тъй като построяването на forкове за PVRB предоставя на атакуващия възможност да подготви няколко варианта на рандома с цел да публикува този, който му носи най-голяма полза, и да ограничи времето за възможна атака — добро решение.

Поради това, най-добрият вариант е да се комбинират PVRB и финалността в един протокол — тогава финализираният блок = финализиран рандом, а това е именно това, което трябваше да получим. Сега играчите ще получат гарантиран рандом за N секунди и могат да бъдат сигурни, че не може да бъде отменен или пренареден.

Вариантът с интегриран консенсус е добър:

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

Но също така има и недостатъци:

• сложност при тестването и разработката — ще се наложи да се емулират мрежови грешки, изчезнали възли, хардфоркове на мрежата
• грешките в реализацията изискват хардфорк на мрежата

И двата начина на имплементиране на PVRB имат право на живот, но реализацията на смарт-контракти в съвременните блокчейни е все пак значително ограничена в изчислителните ресурси, и всякакъв преход към сериозна криптография често е просто невъзможен. А сериозната криптография ще ни е нужна, както ще бъде демонстрирано по-долу. Въпреки това, този проблем явно е временного характер, сериозната криптография в контрактите е необходима за решаването на множество задачи и постепенно се появява (например, системни контракти за zkSNARKs в Ethereum)

Блокчейн, който осигурява прозрачен и надежден канал за обмен на съобщения на протокола, не е безплатен. Всеки децентрализиран протокол трябва да вземе предвид възможността за Sybil атака; действията могат да бъдат извършени с координираните сили на множество акаунти, поради което при проектирането трябва да се вземат предвид възможностите на атакуващите по създаването на произволен брой участници в протокола, действащи в съгласие.

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

Не лъгах, когато казах, че добрият PVRB, проверен от множество хазартни приложения, досега не е имплементиран в блокчейните. Откъде тогава идва толкова много хазартни приложения в Ethereum и EOS? Това ме учуди толкова, колкото и вас, но откъде в напълно детерминирана среда се появиха толкова "устойчиви" произволности?

Любимият начин да се извлече произволност в блокчейна е да се вземе някаква "непредсказуема" информация от блока и на нейна основа да се направи произволност — просто като хеширате едно или няколко стойности. Добра статия относно проблемите на такива схеми. тук.. Може да се вземе някоя от "непредсказуемите" стойности в блока, например хешът на блока, броят на транзакциите, сложността на мрежата и други, предварително неизвестни стойности. След това да се хешират, едно или няколко, и по идея би трябвало да се получи истинска произволност. Може дори да добавите в whitepaper, че вашата схема е "пост-квантово защитена" (тъй като съществуват квантово устойчиви хеш функции :)).

Но дори и пост-квантовите защитени хешове не са достатъчни, за съжаление. Тайна е в изискванията към PVRB, да си напомням за тях от предишната статия:

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

В този случай се спазва само изискването 1, а изискване 2 не се спазва. Хеширайки непредсказуеми стойности от блока, ние получаваме равномерно разпределение и добри рандоми. Но BP има поне възможността "да публикува блока или не". По този начин BP може да избира между ДВЕ варианта за рандом: "своят" и този, който ще бъде, ако блока бъде поставен от друг. BP може предварително "да надникне", какво ще се случи, ако публикува блока, и просто да вземе решение дали да го направи или не. Следователно, играейки например в "чет-нечет" или "червено/черно" на рулетка, той може да публикува блока само ако вижда печалба. Това също прави неработеща стратегията за използване на, например, хеша на блока "от бъдещето". В този случай се говори, че "ще бъде използван рандом, който се получава от хеширането на текущите данни и хеша на бъдещия блок на височина, например, N + 42, където N е текущата височина на блока. Това малко усилва схемата, но все пак позволява на BP, макар и в бъдеще, да избира дали да задържи блока или да го публикува.

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

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

PVRB и commit-reveal.

Добре, благодаря на хеширането и поне на относителната непредсказуемост на хеша на блока и другите променливи. Ако решим проблема с фронт-ранването от майнери, трябва да се получи нещо по-добро. Нека добавим в тази схема потребителите — нека също влияят на рандома: всеки служител на техническата поддръжка ще ви каже, че най-рандомното в 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 подписи на няколко участника, които са подписали същата стойност. Например — предишно случайно число. В такава схема се спестяват значителни ресурси, тъй като подписите представляват едновременно и потвърждение за коректността на поведението според протокола, и източник на случайност.

Въпреки това, дори с детерминирани подписи, схемата все още е уязвима на проблема "последен участник". Последният участник все пак може да реши да публикува подписа си или не, контролирайки резултата. Може да се доработи схемата, като се добавят хешове на блокове, да се правят рундове, така че предварителният резултат да не може да бъде предсказан, но всички тези техники, дори и със стотици подобрения, все още оставят нерешен проблема с влиянието на един участник върху колективния резултат в ненадеждни среди и могат да работят само при условия на икономически и времеви ограничения. Освен това размерът на ключовете RSA (1024 и 2048 бита) е доста голям, а размерът за блокчейн транзакции е изключително важен параметър. Очевидно е, че просто решение на проблема не може да бъде намерено, така че продължаваме напред.

PVRB и схеми за споделяне на тайни

В криптографията съществуват схеми, които могат да позволят на мрежата да се споразумее за едно единствено значение PVRB, при което тези схеми са устойчиви на всякакви злонамерени действия от страна на участниците. Един от полезните протоколи, с които си струва да се запознаете, е схемата за разделяне на тайна на Шамир. Тя служи за разделяне на тайна (например секретен ключ) на няколко части и раздаване на тези части на N участници. Тайната се разпределя по такъв начин, че за нейното възстановяване са достатъчни M части от N, и те могат да бъдат всякакви M части. Ако го илюстрираме, участниците обменят точки на график на неизвестна функция, и след получаване на M точки, цялата функция може да бъде възстановена.
Добро обяснение е дадено в wiki и за да се поиграете с него практически, е полезно да проиграете протокола в главата си на демо страницата.

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

• Всеки участник генерира собствен random и раздава shares от него на останалите участници.
• Всеки участник разкрива своята част от тайните на останалите участници.
• Ако за участника има повече от M shares, то числото на този участник може да бъде изчислено и то ще бъде единствено, независимо от набора от разкрили участници.
• Комбинацията от разкритите random-ове е исканият PVRB.

Тук отделен участник вече не влияе на резултатите от протокола, освен в случаите, когато само от него зависи достигането на threshold-а за разкритие на random. Следователно, този протокол, при наличие на необходимия процент работещи по протокола и налични RP, работи, реализирайки изискванията за криптографска устойчивост и е устойчив на проблема "последен играч".

Това би могло да бъде идеалният вариант, схемата PVRB на базата на secret sharing на Фиат-Шамир е описана, например, в тази статия. Но, както беше споменато по-горе, ако се опитате да я приложите директно в блокчейна, се появяват вече технически ограничения. Ето пример за тестова реализация на протокола в смарт-контракт на EOS и най-важната му част — проверка на публикувания share на участника: код. От кода е видно, че валидацията на proof изисква няколко скаларни умножения, а числата са много големи. Важно е да се разбере, че в блокчейните проверката става в момента, когато block-producer обработва транзакцията, а всеки участник трябва лесно да може да провери коректността на протокола, затова изискванията към скоростта на функцията за проверка са много сериозни. В този вариант алгоритъмът се оказа неработоспособен, тъй като верификацията не успя да се впише в ограниченията за транзакцията (0.5 сек).

Ефективността на верификацията е едно от най-важните изисквания при използването на практически всички съвременни криптографски схеми в блокчейна. Създаването на proofs, подготовката на съобщения – тези процедури могат да се извършват off-chain и на високопроизводителни компютри, но верификацията не може да бъде избегната – това е още едно важно изискване към PVRB.

PVRB и threshold подписи

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

Комбинирането на детерминирани подписи и threshold-схеми позволи разработването на много удобна и обещаваща схема за реализиране на PVRB — детерминирани threshold-подписи. Ето статия за различни приложения на threshold-подписите, а ето и още един добър дългочетиво от Dash.

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

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

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

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

За съжаление, все още не виждаме готов, реализиран в блокчейните PVRB протокол, който да е доказал своята сигурност и устойчивост. Въпреки че самите протоколи са готови, технически е трудно да се приложат към съществуващите решения. За централизираните системи PVRB няма смисъл, а децентрализираните са строго ограничени във всички изчислителни ресурси: CPU, памет, хранилище, I/O. Проектирането на PVRB е комбиниране на различни протоколи, за да се създаде нещо, което да отговаря на всички изисквания поне за някакъв жизнеспособен блокчейн. Един протокол изчислява по-ефективно, но изисква повече съобщения между RP, докато друг изисква изключително малко съобщения, но създаването на proof може да бъде задача, отнемаща десетки минути или дори часове.

Ще изброя факторите, които трябва да имате предвид при избора на качествен PVRB:

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

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

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

Заключение

Надявам се в предходния статии Успях да ви убедя, че генерирането на произволни числа в блокчейна е критично важно за много аспекти от живота на децентрализираните мрежи, а с тази статия показа, че задачата е изключително амбициозна и сложна, но добрите решения вече съществуват. По принцип окончателният дизайн на протокола е възможен само след провеждане на масивни тестове, отразяващи всички аспекти от настройката до емилирането на сбои, така че е малко вероятно да намерите готови рецепти в whitepaper-ите на екипите и в статиите, а и ние в следващата година-две със сигурност няма да се наемем да пишем "правете така, така определено е правилно".

Докато, за нашия PVRB в разработвания блокчейн Хая, решихме да приложим threshold BLS подписи, планираме да реализираме PVRB на ниво консенсус, тъй като верификацията в смарт контрактите с приемливо ниво на сигурност все още е невъзможна. Възможно е да използваме наведнъж две схеми: първо скъпа секретна споделеност за създаване на дългосрочен random_seed, а след това да я използваме като основа за високо честотно генериране на рандом с помощта на детерминирани threshold BLS подписи, може би ще се ограничим само с една от схемите. Да се каже предварително какъв ще е протоколът, за съжаление, е невъзможно, радва само това, че както в науката, така и в инженерните задачи отрицателният резултат също е резултат, и всяка нова опит да се реши задачата е нова стъпка за изследванията на всички, занимаващи се с проблема. За да отговорим на изискванията от страна на бизнеса, решаваме конкретна практическа задача - осигуряване на игрални приложения с надежден източник на ентропия, затова трябва да обърнем внимание и на самия блокчейн, по-специално на въпросите за финалността на веригата и управлението на мрежата.

И нека все още не виждаме в блокчейните доказано устойчив PVRB, който да е бил използван достатъчно дълго време, за да премине изпитанията на истински приложения, множество одити, натоварвания и, разбира се, реални атаки, но числото на възможните пътища потвърджава, че решение съществува, и някой от тези алгоритми в крайна сметка ще реши проблема. С удоволствие ще споделим резултатите и благодарим на другите екипи, които също се занимават с този въпрос за статиите и кода, които позволяват на инженерите да не стъпват два пъти на едни и същи грабли.

Когато срещнете програмист, който проектира децентрализирано произволно число, бъдете внимателни и любезни, ако е необходимо, предоставете психологическа помощ 🙂

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