Увод

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

Као и код концепта апсолутно јаке шифре из криптографије, прави „Публицли Верифиабле Рандом Беацон” (у даљем тексту ПВРБ) протоколи само покушавају да се што више приближе идеалној шеми, јер у стварним мрежама није применљив у свом чистом облику: потребно је стриктно договорити један бит, мора бити много рунди, а све поруке морају бити савршено брзе и увек испоручене. Наравно, то није случај у стварним мрежама. Стога, када се пројектују ПВРБ-ови за специфичне задатке у савременим блок-чејновима, поред немогућности контроле настале насумице и криптографске снаге, јављају се још многи чисто архитектонски и технички проблеми.

За ПВРБ, сам блоцкцхаин је у суштини комуникациони медиј у којем су поруке = трансакције. Ово вам омогућава да делимично апстрахујете од проблема са мрежом, неиспоруке порука, проблема са међуверским софтвером - све ове ризике преузима децентрализована мрежа, а његова главна вредност за ПВРБ је немогућност опозива или корумпирања већ послате трансакције - ово се чини не дозвољавају учесницима да одбију учешће у протоколу, осим ако нису извршили успешан напад на консензус. Овај ниво безбедности је прихватљив, тако да ПВРБ треба да буде отпоран на дослухе учесника у потпуно истој мери као и главни ланац блок ланца. Такође, ово наговештава да ПВРБ мора бити део консензуса ако се мрежа сложи око главног блоцкцхаина, чак и ако се слаже и о једином фер резултирајућем насумичном избору. Или, ПВРБ је једноставно самостални протокол имплементиран путем паметног уговора који ради асинхроно у односу на блок ланац и блокове. Обе методе имају своје предности и мане, а избор између њих је крајње нетривијалан.

Два начина за имплементацију ПВРБ-а

Опишимо детаљније две опције за имплементацију ПВРБ-а - самосталну верзију, која ради коришћењем паметног уговора независног од блокчејна, и консензус интегрисану верзију, уграђену у протокол, према којој се мрежа слаже око блокчејна и трансакције које треба укључити. У свим случајевима, мислићу на популарне блокчејн моторе: Етхереум, ЕОС и све сличне њима по начину на који хостују и обрађују паметне уговоре.

Самостални уговор

У овој верзији, ПВРБ је паметни уговор који прихвата трансакције насумичних произвођача (у даљем тексту РП), обрађује их, комбинује резултате и, као резултат, долази до одређене вредности коју сваки корисник може добити од овог уговора. Ова вредност можда неће бити ускладиштена директно у уговору, већ је представљена само подацима из којих се може детерминистички добити једна и само једна вредност резултујућег случаја. У овој шеми, РП-ови су корисници блоцкцхаина, и свакоме може бити дозвољено да учествује у процесу генерисања.

Опција са самосталним уговором је добра:

• преносивост (уговори се могу превлачити са блоцкцхаина на блоцкцхаин)
• једноставност имплементације и тестирања (уговоре је лако написати и тестирати)
• погодност у имплементацији економских шема (лако је направити сопствени токен, чија логика служи сврси ПВРБ-а)
• могућност покретања на већ функционалним блокчејновима

Такође има недостатке:

• јака ограничења на рачунарске ресурсе, обим трансакција и складиштење (другим речима, цпу/мем/ио)
• ограничења рада у оквиру уговора (нису сва упутства доступна, тешко је повезати спољне библиотеке)
• немогућност организовања размене порука брже него што су трансакције укључене у блоцкцхаин

Ова опција је погодна за имплементацију ПВРБ-а који треба да се покрене на постојећој мрежи, не садржи сложену криптографију и не захтева велики број интеракција.

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

У овој верзији, ПВРБ је имплементиран у коду блокчејн чвора, уграђен или ради паралелно са разменом порука између блокчејн чворова. Резултати протокола се уписују директно у произведене блокове, а поруке протокола се шаљу преко п2п мреже између чворова. Пошто протокол резултира бројевима који се записују у блоковима, мрежа мора постићи консензус о њима. То значи да ПВРБ поруке, као и трансакције, морају бити потврђене од стране чворова и укључене у блокове тако да сваки учесник мреже може да потврди усклађеност са ПВРБ протоколом. Ово нас аутоматски доводи до очигледног решења – ако се мрежа сложи око консензуса око блока и трансакција у њему, онда ПВРБ треба да буде део консензуса, а не самостални протокол. У супротном, могуће је да је блок валидан са становишта консензуса, али се ПВРБ протокол не поштује и са ПВРБ тачке гледишта блок не може бити прихваћен. Дакле, ако се одабере опција „интегрисана консензусом“, ПВРБ постаје важан део консензуса.

Када се описује ПВРБ имплементација на нивоу мрежног консензуса, никако се не може избећи питање коначности. Коначност је механизам који се користи у детерминистичким консензусима који закључава блок (и ланац који води до њега) који је коначан и никада неће бити одбачен, чак и ако дође до паралелног рачвања. На пример, у Битцоин-у не постоји такав механизам - ако објавите ланац веће сложености, он ће заменити било који мање сложен, без обзира на дужину ланаца. А у ЕОС-у, на пример, коначни су такозвани Последњи неповратни блокови, који се појављују у просеку на свака 432 блока (12*21 + 12*15, пре-гласање + пре-урезивање). Овај процес у суштини чека на 2/3 потписа произвођача блокова (у даљем тексту БП). Када се појаве виљушке које су старије од последњег ЛИБ-а, оне се једноставно одбацују. Овај механизам омогућава да се гарантује да је трансакција укључена у блоцкцхаин и да никада неће бити враћена, без обзира на то које ресурсе нападач има. Такође, завршни блокови су блокови потписани од стране 2/3 БП у Хиперледгер, Тендерминт и другим консензусима заснованим на пБФТ-у. Такође, има смисла направити протокол за обезбеђивање коначности као додатак консензусу, јер може да ради асинхроно са производњом и објављивањем блокова. Ево једног доброг чланак о коначности у Етхереуму.

Коначност је изузетно важна за кориснике, који без ње могу да се нађу као жртве напада „двоструке потрошње“, где БП „држи“ блокове и објављује их након што мрежа „види“ добру трансакцију. Ако нема коначности, онда објављена виљушка замењује блок са „добром“ трансакцијом другом, из „лоше“ виљушке, у којој се иста средства преносе на адресу нападача. У случају ПВРБ-а, захтеви за коначност су још строжији, јер изградња форкова за ПВРБ значи могућност за нападача да припреми неколико насумичних опција како би објавио најпрофитабилнију, а ограничавање времена могућег напада представља добро решење.

Због тога је најбоља опција да комбинујемо ПВРБ и финалност у један протокол - онда финализовани блок = финализовани случајни случај, а то је управо оно што смо требали да добијемо. Сада ће играчи добити загарантовани случајни случај за Н секунди и могу бити сигурни да га је немогуће вратити или поново одиграти.

Опција интегрисана консензусом је добра:

• могућност асинхроне имплементације у односу на производњу блокова - блокови се производе као и обично, али паралелно са овим може да ради и ПВРБ протокол, који не производи случајност за сваки блок
• могућност имплементације чак и тешке криптографије, без ограничења наметнутих паметним уговорима
• могућност организовања размене порука брже него што су трансакције укључене у блок ланац, на пример, део протокола може да ради између чворова без дистрибуције порука преко мреже

Такође има недостатке:

• Потешкоће у тестирању и развоју - мораћете да емулирате мрежне грешке, недостајуће чворове, мрежни хард форк
• Грешке у имплементацији захтевају мрежни хардфорк

Обе методе имплементације ПВРБ-а имају право на живот, али имплементација на паметне уговоре у модерним блок-чејновима је и даље прилично ограничена у рачунарским ресурсима, а сваки прелазак на озбиљну криптографију је често једноставно немогућ. И биће нам потребна озбиљна криптографија, као што ће бити показано у наставку. Иако је овај проблем очигледно привремен, за решавање многих проблема потребна је озбиљна криптографија у уговорима и постепено се појављује (на пример, системски уговори за зкСНАРК-ове у Етхереуму)

Блоцкцхаин, који пружа транспарентан и поуздан канал за размену порука, не ради то бесплатно. Сваки децентрализовани протокол мора да узме у обзир могућност напада на Сибил; било коју акцију могу да ураде усаглашене снаге више налога, стога је при пројектовању неопходно узети у обзир способност нападача да креира произвољан број протокола. учесници који делују у дослуху.

ПВРБ и блок променљиве.

Нисам лагао када сам рекао да још нико није имплементирао добар ПВРБ, тестиран у многим апликацијама за коцкање, у блок ланца. Одакле онда толико апликација за коцкање на Етхереум-у и ЕОС-у? Ово ме изненађује колико и вас, одакле им толико „упорних“ случајних избора у потпуно детерминистичком окружењу?

Омиљени начин да се добије случајност у блокчејну је да се из блока узме нека врста „непредвидивих“ информација и на основу њих се направи насумична – једноставним хеширањем једне или више вредности. Добар чланак о проблемима таквих шема овде. Можете узети било коју од „непредвидивих“ вредности у блоку, на пример, хеш блока, број трансакција, сложеност мреже и друге унапред непознате вредности. Затим их хеширајте, један или више, и, теоретски, требало би да добијете прави случајни случај. Можете чак и додати на вихитепапер да је ваша шема „пост-квантно сигурна“ (пошто постоје квантно-доказне хеш функције :)).

Али чак ни пост-квантно безбедни хешеви нису довољни, авај. Тајна је у захтевима за ПВРБ, да вас подсетим на њих из претходног чланка:

1. Резултат мора да има доказиво уједначену дистрибуцију, тј. да буде заснован на доказиво јакој криптографији.
2. Није могуће контролисати било који од битова резултата. Као последица тога, исход се не може унапред предвидети.
3. Не можете саботирати протокол генерисања тако што ћете не учествовати у протоколу или преоптеретити мрежу порукама о нападу
4. Све наведено мора бити отпорно на договарање дозвољеног броја непоштених учесника у протоколу (нпр. 1/3 учесника).

У овом случају је испуњен само захтев 1, а није испуњен захтев 2. Хеширањем непредвидивих вредности из блока добићемо уједначену дистрибуцију и добре случајне случајеве. Али БП барем има опцију да „објави блок или не“. Дакле, БП може да бира најмање између ДВЕ насумичне опције: „своју“ и ону која ће испасти ако неко други блокира. БП може унапред да „њушка“ шта ће се десити ако објави блок, и једноставно одлучи да то уради или не. Тако, када игра, на пример, „пар-непар“ или „црвено/црно“ у рулету, он може да објави блок само ако види победу. Ово такође чини нефункционалном стратегију коришћења, на пример, хеш блока „из будућности“. У овом случају кажу да ће се „користити случајни одабир, који се добија хеширањем тренутних података и хешом будућег блока висине, на пример, Н + 42, где је Н тренутна висина блока. Ово мало појачава шему, али и даље омогућава БП-у, иако у будућности, да изабере да ли ће задржати блокаду или објавити.

БП софтвер у овом случају постаје компликованији, али не много. Једноставно, приликом валидације и укључивања трансакције у блок, постоји брза провера да ли ће бити добитка и, евентуално, одабир параметара једне трансакције да би се добила велика вероватноћа добитка. У исто време, готово је немогуће ухватити паметног БП за такве манипулације, сваки пут можете користити нове адресе и мало по мало освојити без изазивања сумње.

Дакле, методе које користе информације из блока нису прикладне као универзална имплементација ПВРБ-а. У ограниченој верзији, са ограничењима величине опклада, ограничењима броја играча и/или КИЦ регистрацијом (да би се спречило да један играч користи више адреса), ове шеме могу да раде за мале игре, али ништа више.

ПВРБ и урезивање-откривање.

У реду, захваљујући хеширању и барем релативној непредвидивости хеша блока и других варијабли. Ако решите проблем напредних рудара, требало би да набавите нешто прикладније. Хајде да додамо кориснике у ову шему - нека и они утичу на случајност: сваки службеник техничке подршке ће вам рећи да је најсумичнија ствар у ИТ системима акције корисника :)

Наивна шема, када корисници једноставно шаљу насумичне бројеве, а резултат се рачуна као, на пример, хеш њиховог збира, није прикладна. У овом случају, последњи играч може, бирајући сопствени случајни одабир, да контролише какав ће бити резултат. Због тога се користи веома широко коришћен образац урезивања-откривања. Учесници прво шаљу хешове из својих насумичних (урезивања), а затим сами отварају насумичне (откривање). Фаза „откривања“ почиње тек након што се прикупе неопходна урезивања, тако да учесници могу да пошаљу тачно насумични хеш са којег су послали раније. Хајде да све ово спојимо са параметрима блока, и то боље од оног преузетог из будућности (случајност се може наћи само у једном од будућих блокова), и воила - случајност је спремна! Сада било који играч утиче на резултујућу случајност и може „поразити“ злонамерни БП тако што ће га надјачати својом, унапред непознатом, случајношћу... Такође можете додати заштиту од саботирања протокола тако што га не отварате у фази откривања – једноставно захтевајући да се трансакцији приложи одређени износ приликом извршења — депозит који ће бити враћен само током поступка откривања. У овом случају, обавезивање и неоткривање ће бити непрофитабилно.

Био је то добар покушај, а такве шеме постоје и у играчким ДАпп-овима, али ово опет није довољно. Сада не само рудар, већ и било који учесник у протоколу може утицати на резултат. И даље је могуће контролисати саму вредност, са мање варијабилности и по цени, али, као у случају рудара, ако су резултати извлачења вреднији од накнаде за учешће у ПВРБ протоколу, онда ће се случајни -произвођач (РП) може одлучити да ли ће открити и још увек може да бира између најмање две насумичне опције.
Али постало је могуће казнити оне који почине и не откривају, а ова шема ће добро доћи. Његова једноставност је озбиљна предност - озбиљнији протоколи захтевају много моћније прорачуне.

ПВРБ и детерминистички потписи.

Постоји још један начин да се примора РП да обезбеди псеудо-случајни број на који не може да утиче ако му је обезбеђена „преслика“ - ово је детерминистички потпис. Такав потпис је, на пример, РСА, а није ЕЦС. Ако РП има пар кључева: РСА и ЕЦЦ, и он потписује одређену вредност својим приватним кључем, онда ће у случају РСА добити ЈЕДАН И САМО ЈЕДАН потпис, ау случају ЕЦС може да генерише било који број различити важећи потписи. То је зато што се приликом креирања ЕЦС потписа користи случајни број, који бира потписник, а може се изабрати на било који начин, дајући потписнику могућност да изабере један од неколико потписа. У случају РСА: „једна улазна вредност“ + „један пар кључева“ = „један потпис“. Немогуће је предвидети какав ће потпис добити други РП, па се ПВРБ са детерминистичким потписима може организовати комбиновањем РСА потписа више учесника који су потписали исту вредност. На пример, претходни случајни случај. Ова шема штеди много средстава, јер потписи су и потврда исправног понашања према протоколу и извор случајности.

Међутим, чак и са детерминистичким потписима, шема је и даље рањива на проблем „последњег актера“. Последњи учесник још увек може да одлучи да ли ће објавити потпис или не, контролишући исход. Можете модификовати шему, додати јој хеш блокова, правити кругове тако да се резултат не може унапред предвидети, али све ове технике, чак и узимајући у обзир многе модификације, и даље остављају нерешеним проблем утицаја једног учесника на колектив. резултирају неповерљивим окружењем и могу да раде само под економским и временским ограничењима. Поред тога, величина РСА кључева (1024 и 2048 бита) је прилично велика, а величина за блоцкцхаин трансакције је изузетно важан параметар. Очигледно не постоји једноставан начин да се реши проблем, идемо даље.

ПВРБ и шеме тајне дељења

У криптографији постоје шеме које могу омогућити мрежи да се договори око једне и само једне ПВРБ вредности, док су такве шеме отпорне на било какве злонамерне радње неких учесника. Један користан протокол са којим се вреди упознати је Шамирова тајна шема дељења. Служи да се тајна (на пример, тајни кључ) подели на неколико делова, и да се ти делови дистрибуирају Н учесника. Тајна је распоређена на начин да је М делова од Н довољно да се она поврати, а то може бити било који М делова. Ако на прстима, онда имајући график непознате функције, учесници размењују поене на графикону, а након што добију М поена, цела функција се може вратити.
Дато је добро објашњење вики али играње са њим практично да би се играо протокол у својој глави је корисно за демо страна.

Када би ФССС (Фиат-Схамир Сецрет Схаринг) шема била применљива у свом чистом облику, то би била неуништива ПВРБ. У свом најједноставнијем облику, протокол би могао изгледати овако:

• Сваки учесник генерише сопствени случајни случај и дистрибуира удео од њега другим учесницима
• Сваки учесник открива свој део тајни осталих учесника
• Ако учесник има више од М акција, онда се број овог учесника може израчунати и биће јединствен, без обзира на скуп откривених учесника
• Комбинација откривених случајних избора је жељени ПВРБ

Овде појединачни учесник више не утиче на резултате протокола, осим у случајевима када постизање прага откривања случајности зависи само од њега. Стога, овај протокол, ако постоји потребан проценат РП-ова који раде на протоколу и који су доступни, функционише, имплементирајући захтеве за криптографску снагу и отпоран је на проблем „последњег актера“.

Ово би могла бити идеална опција, ова ПВРБ шема заснована на Фиат-Схамир-овом тајном дијељењу је описана на примјер у ово чланак. Али, као што је горе поменуто, ако покушате да га примените директно у блок ланцу, појављују се техничка ограничења. Ево примера пробне имплементације протокола у ЕОС паметном уговору и његовог најважнијег дела – провере објављеног учесника дељења: код. Из кода можете видети да валидација доказа захтева неколико скаларних множења, а бројеви који се користе су веома велики. Треба имати на уму да се у блокчејновима верификација дешава у тренутку када произвођач блокова обрађује трансакцију, и генерално, сваки учесник мора лако да провери исправност протокола, тако да су захтеви за брзину функције верификације веома озбиљни . У овој опцији, опција се показала неефикасном, јер се верификација није уклапала у ограничење трансакције (0.5 секунди).

Ефикасност верификације је један од најважнијих захтева за коришћење, уопште, било које напредне криптографске шеме у блокчејну. Креирање доказа, припрема порука – ове процедуре се могу скинути са ланца и извршити на рачунарима високих перформанси, али верификација се не може заобићи – ово је још један важан захтев за ПВРБ.

ПВРБ и гранични потписи

Након што смо се упознали са шемом за дељење тајне, открили смо читаву класу протокола уједињених кључном речју „праг“. Када обелодањивање неке информације захтева учешће М поштених учесника од Н, а скуп поштених учесника може бити произвољан подскуп од Н, говоримо о „граничним“ шемама. Они су ти који нам дозвољавају да се позабавимо проблемом „последњег актера“, сада ако нападач не открије свој део тајне, други, поштени учесник ће то учинити уместо њега. Ове шеме дозвољавају договор о једном и само једном значењу, чак и ако неки од учесника саботира протокол.

Комбинација детерминистичких потписа и шема прага омогућила је да се развије веома згодна и обећавајућа шема за имплементацију ПВРБ - ово су детерминистички гранични потписи. Ево чланак о различитим употребама граничних потписа, а ево још једног доброг лонгреад од Дасх.

Последњи чланак описује БЛС потписе (БЛС је скраћеница од Бонех-Линн-Схацхам, овде чланак), који имају веома важан и изузетно погодан квалитет за програмере – јавни, тајни, јавни кључеви и БЛС потписи могу се комбиновати једни са другима коришћењем једноставних математичких операција, док њихове комбинације остају валидни кључеви и потписи, што вам омогућава да лако агрегирате многе потписа у један и више јавних кључева у један. Они су такође детерминистички и дају исти резултат за исте улазне податке. Захваљујући овом квалитету, комбинације БЛС потписа су саме по себи валидни кључеви, што омогућава имплементацију опције у којој М од Н учесника производи један и само један потпис који је детерминистички, јавно проверљив и непредвидив док га не отвори Мтх. учесник .

У шеми са граничним БЛС потписима, сваки учесник нешто потписује користећи БЛС (на пример, претходни насумични), а заједнички гранични потпис је жељени насумични. Криптографска својства БЛС потписа задовољавају захтеве за насумични квалитет, део прага штити од „последњег актера“, а јединствена комбинованост кључева омогућава имплементацију много занимљивијих алгоритама који омогућавају, на пример, ефикасно агрегирање протоколарних порука .

Дакле, ако градите ПВРБ на свом блокчејну, највероватније ћете завршити са БЛС шемом граничних потписа, неколико пројеката је већ користи. На пример, ДФинити (овде бенцхмарк који имплементира коло, и овде пример имплементације проверљиве тајне дељења), или Кееп.нетворк (овде је њихов насумични светионик жути папир, Али пример паметни уговор који опслужује протокол).

Имплементација ПВРБ

Нажалост, још увек не видимо готов протокол имплементиран у ПВРБ блоцкцхаинс који је доказао своју сигурност и стабилност. Иако су сами протоколи спремни, технички их применити на постојећа решења није лако. За централизоване системе, ПВРБ нема смисла, а децентрализовани су строго ограничени у свим рачунарским ресурсима: ЦПУ, меморија, складиште, И/О. Дизајнирање ПВРБ-а је комбинација различитих протокола како би се створило нешто што испуњава све захтеве за барем неки одрживи блок ланац. Један протокол израчунава ефикасније, али захтева више порука између РП-ова, док други захтева врло мало порука, али креирање доказа може бити задатак који траје десетине минута, или чак сати.

Навешћу факторе које ћете морати да узмете у обзир када бирате квалитетан ПВРБ:

• Криптографска снага. Ваш ПВРБ мора бити строго непристрасан, без могућности контроле ни једног бита. У неким шемама то није случај, па позовите криптографа
• Проблем "последњег актера".. Ваш ПВРБ мора бити отпоран на нападе у којима нападач који контролише један или више РП-ова може изабрати један од два исхода.
• Проблем саботаже протокола. Ваш ПВРБ мора бити отпоран на нападе у којима нападач који контролише један или више РП-ова одлучује да ли ће бити насумичан или не и може бити загарантован или са датом вероватноћом да утиче на то
• Проблем са бројем порука. Ваши РП би требало да шаљу минимум порука блокчејну и избегавају синхроне радње колико год је то могуће, као што су ситуације попут „Послао сам неке информације, чекам одговор од одређеног учесника“. У п2п мрежама, посебно географски дисперзованим, не треба рачунати на брз одговор
• Проблем рачунске сложености. Верификација било које фазе ПВРБ он-ланца треба да буде изузетно лака, пошто је обављају сви пуни клијенти мреже. Ако се имплементација врши помоћу паметног уговора, онда су захтеви за брзину веома строги
• Проблем приступачности и животности. Ваш ПВРБ треба да тежи да буде отпоран на ситуације у којима део мреже постане недоступан на одређено време, а део РП једноставно престане да ради
• Проблем поузданог подешавања и почетне дистрибуције кључа. Ако ваш ПВРБ користи примарно подешавање протокола, онда је ово посебна велика и озбиљна прича. Ево пример. Ако учесници морају да кажу једни другима своје кључеве пре покретања протокола, то је такође проблем ако се промени састав учесника
• Питања развоја. Доступност библиотека на потребним језицима, њихова безбедност и перформансе, публицитет, сложени тестови итд.

На пример, гранични БЛС потписи имају значајан проблем - пре него што почну да раде, учесници морају међусобно поделити кључеве, организујући групу унутар које ће праг радити. То значи да ће бар један круг размене у децентрализованој мрежи морати да сачека, а с обзиром да је генерисани ранд, на пример, неопходан у игрицама, скоро у реалном времену, то значи да је саботажа протокола могућа у овој фази , а предности шеме прагова се губе . Овај проблем је већ једноставнији од претходних, али и даље захтева развој посебне процедуре за формирање граничних група, које ће морати да се заштите економски, кроз депозите и повлачење средстава (сласхинг) од учесника који не прате протокола. Такође, БЛС верификација са прихватљивим нивоом сигурности једноставно се не уклапа, на пример, у стандардну ЕОС или Етхереум трансакцију - једноставно нема довољно времена за верификацију. Шифра уговора је ВебАссембли или ЕВМ, коју извршава виртуелна машина. Криптографске функције (још увек) нису примењене нативно и раде десетине пута спорије од конвенционалних криптографских библиотека. Многи протоколи не испуњавају захтеве једноставно на основу обима кључа, на пример 1024 и 2048 бита за РСА, 4-8 пута већи од стандардног потписа трансакције у Битцоин и Етхереум.

Присуство имплементација у различитим програмским језицима такође игра улогу - којих је мало, посебно за нове протоколе. Опција са интеграцијом у консензус захтева писање протокола на језику платформе, тако да ћете морати да тражите код у Го за гетх, у Руст за Парити, у Ц++ за ЕОС. Сви ће морати да траже ЈаваСцрипт код, а пошто ЈаваСцрипт и криптографија нису нарочито блиски пријатељи, помоћи ће вам ВебАссембли, који сада дефинитивно тврди да је следећи важан Интернет стандард.

Закључак

Надам се у претходном Чланак Успео сам да вас убедим да је генерисање насумичних бројева на блокчејну кључно за многе аспекте живота децентрализованих мрежа, а овим чланком сам показао да је овај задатак изузетно амбициозан и тежак, али добра решења већ постоје. Генерално, коначни дизајн протокола је могућ тек након спровођења масивних тестова који узимају у обзир све аспекте од подешавања до емулације грешке, тако да је мало вероватно да ћете наћи готове рецепте у тимским белим папирима и чланцима, а ми сигурно нећемо одлучите у наредних годину-две напишите „урадите на овај начин, тачно како треба“.

Збогом, за наш ПВРБ у блокчејну који се развија хаиа, одлучили смо се на коришћењу граничних БЛС потписа, планирамо да имплементирамо ПВРБ на нивоу консензуса, пошто верификација у паметним уговорима са прихватљивим нивоом безбедности још није могућа. Могуће је да користимо две шеме одједном: прво, скупо дељење тајне за креирање дугорочног рандом_сеед, а затим га користимо као основу за високофреквентно насумично генерисање користећи БЛС потписе детерминистичког прага, можда ћемо се ограничити само на једна од шема. Нажалост, немогуће је унапред рећи какав ће бити протокол, једино добро је то што је, као у науци, и у инжењерским проблемима негативан резултат такође резултат, а сваки нови покушај решавања проблема је још један корак за истраживање свих укључених у проблем. Да бисмо испунили пословне захтеве, решавамо специфичан практичан проблем - обезбеђивање апликација за игре са поузданим извором ентропије, тако да такође морамо да обратимо пажњу на сам блоцкцхаин, посебно на питања коначности ланца и управљања мрежом.

И иако још не видимо доказано отпоран ПВРБ у блок-чејновима, који би се користио довољно времена да га тестирају стварне апликације, вишеструке ревизије, оптерећења и, наравно, стварни напади, али број могућих путева то потврђује решење постоји и који од ових алгоритама ће на крају решити проблем. Бићемо срећни да поделимо резултате и захвалимо другим тимовима који такође раде на овом питању за чланке и код који омогућавају инжењерима да не стану на исте грабље два пута.

Дакле, када сретнете програмера који дизајнира децентрализовано насумично, будите пажљиви и брижни и пружите психолошку помоћ ако је потребно :)

Извор: ввв.хабр.цом