въведение

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

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

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

Два начина за внедряване на PVRB

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

Самостоятелен договор

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

Вариантът със самостоятелен договор е добър:

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

Има и недостатъци:

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

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

Интегриран с консенсус

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

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

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

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

Интегрираният с консенсус вариант е добър:

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

Има и недостатъци:

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

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

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

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

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

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

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

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

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

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

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

PVRB и ангажиране-разкриване.

Добре, благодарение на хеширането и поне относителната непредсказуемост на блоковия хеш и други променливи. Ако решите проблема с водещите миньори, трябва да вземете нещо по-подходящо. Нека добавим потребители към тази схема - нека те също влияят на случайността: всеки служител на техническата поддръжка ще ви каже, че най-случайното нещо в ИТ системите са действията на потребителите :)

Наивна схема, когато потребителите просто изпращат произволни числа и резултатът се изчислява като например хеш на тяхната сума, не е подходяща. В този случай последният играч може, като избере свой произволен избор, да контролира какъв ще бъде резултатът. Ето защо се използва много широко използваният модел за разкриване на ангажименти. Участниците първо изпращат хешове от своите произволни позиции (комити), а след това отварят самите произволности (разкривания). Фазата на „разкриване“ започва едва след като са събрани необходимите ангажименти, така че участниците могат да изпратят точно произволния хеш, от който са изпратили по-рано. Сега нека съберем всичко това заедно с параметрите на блок и то по-добре от един, взет от бъдещето (случайността може да бъде намерена само в един от бъдещите блокове) и готово - случайността е готова! Сега всеки играч влияе на произтичащата случайност и може да „победи“ злонамерения BP, като го замени със собствената си, неизвестна предварително, случайност... Можете също така да добавите защита срещу саботиране на протокола, като не го отваряте на етапа на разкриване - просто като се изисква определена сума да бъде прикрепена към транзакцията при извършване — гаранционен депозит, който ще бъде върнат само по време на процедурата за разкриване. В този случай обвързването и неразкриването ще бъде нерентабилно.

Това беше добър опит и такива схеми съществуват и в DApps за игри, но уви, това отново не е достатъчно. Сега не само миньорът, но и всеки участник в протокола може да повлияе на резултата. Все още е възможно да се контролира самата стойност, с по-малко променливост и на цена, но, както в случая с миньора, ако резултатите от тегленето са по-ценни от таксата за участие в протокола PVRB, тогава произволният -продуцентът (RP) може да реши дали да разкрие и пак може да избира от поне две произволни опции.
Но стана възможно да се наказват тези, които се ангажират и не разкриват, и тази схема ще бъде полезна. Неговата простота е сериозно предимство - по-сериозните протоколи изискват много по-мощни изчисления.

PVRB и детерминистични сигнатури.

Има друг начин да принудите RP да предостави псевдослучайно число, на което не може да повлияе, ако му бъде предоставено „предобраз“ - това е детерминистичен подпис. Такъв подпис е например RSA, а не ECS. Ако RP има двойка ключове: RSA и ECC и той подписва определена стойност с частния си ключ, тогава в случай на RSA той ще получи ЕДИН И САМО ЕДИН подпис, а в случая на ECS той може да генерира произволен брой различни валидни подписи. Това е така, защото при създаването на ECS подпис се използва произволен номер, избран от подписващия, като той може да бъде избран по всякакъв начин, давайки възможност на подписващия да избере един от няколко подписа. В случай на RSA: „една входна стойност“ + „една двойка ключове“ = „един подпис“. Невъзможно е да се предвиди какъв подпис ще получи друг RP, така че PVRB с детерминистични подписи може да бъде организиран чрез комбиниране на RSA подписите на няколко участници, подписали една и съща стойност. Например предишното произволно. Тази схема спестява много ресурси, т.к подписите са както потвърждение за правилното поведение според протокола, така и източник на случайност.

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

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

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

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

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

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

Това може да бъде идеален вариант, тази PVRB схема, базирана на споделяне на тайни на Fiat-Shamir, е описана например в това статия. Но, както бе споменато по-горе, ако се опитате да го приложите директно в блокчейна, се появяват технически ограничения. Ето пример за тестова реализация на протокола в интелигентния договор на EOS и най-важната му част - проверка на публикувания участник в споделянето: код. Можете да видите от кода, че проверката на доказателството изисква няколко скаларни умножения и използваните числа са много големи. Трябва да се разбере, че в блокчейните проверката се извършва в момента, когато блок-производителят обработва транзакцията и като цяло всеки участник трябва лесно да провери правилността на протокола, така че изискванията за скоростта на функцията за проверка са много сериозни. . В тази опция опцията се оказа неефективна, тъй като проверката не се вписва в лимита на транзакцията (0.5 секунди).

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

PVRB и прагови подписи

След като се запознахме със схемата за споделяне на тайна, открихме цял клас протоколи, обединени от ключовата дума „праг“. Когато разкриването на някаква информация изисква участието на M честни участници от N, а наборът от честни участници може да бъде произволно подмножество от N, говорим за „прагови“ схеми. Именно те ни позволяват да се справим с проблема с „последния актьор“, сега, ако нападателят не разкрие своята част от тайната, друг, честен участник ще го направи вместо него. Тези схеми позволяват споразумение за едно и само едно значение, дори ако протоколът е саботиран от някои от участниците.

Комбинацията от детерминистични сигнатури и прагови схеми направи възможно разработването на много удобна и обещаваща схема за внедряване на PVRB - това са детерминистични прагови сигнатури. Тук статия за различните употреби на прагови подписи и ето още един добър longread от Dash.

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

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

Така че, ако изграждате PVRB на вашия блокчейн, най-вероятно ще се окажете със схемата за прагови подписи BLS, няколко проекта вече я използват. Например DFinity (тук бенчмарк, който изпълнява веригата, и тук примерна реализация на проверимо споделяне на тайна), или Keep.network (ето техния произволен маяк жълта хартия, Но пример интелигентен договор, обслужващ протокола).

Внедряване на PVRB

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

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

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

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

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

Заключение

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

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

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

Така че, когато срещнете програмист, който проектира децентрализирано произволно, бъдете внимателни и грижовни и осигурете психологическа помощ, ако е необходимо :)

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