Увядзенне

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

Як і ў выпадку з канцэпцыяй абсалютна ўстойлівага шыфра з крыптаграфіі, рэальныя пратаколы "Publicly Verifiable Random Beacon" (далей PVRB) толькі спрабуюць максімальна наблізіцца да ідэальнай схемы, т.я. у рэальных сетках у чыстым выглядзе яна непрымяняльная: дамаўляцца трэба строга аб адным біце, раўндаў павінна быць шмат, а ўсе паведамленні павінны быць ідэальна хуткімі і заўсёды дастаўляцца. Зразумела, у рэальных сетках гэта ня так. Таму, пры праектаванні PVRB пад пэўныя задачы ў сучасных блокчейнах, акрамя немагчымасці кантролю атрымоўванага рандома і крыптаграфічнай устойлівасці, узнікае яшчэ шмат чыста архітэктурных і тэхнічных праблем.

Сам блокчейн з'яўляецца для PVRB па ісце асяроддзем для камунікацыі, у якой паведамленні=транзакцыі. Гэта дазваляе часткова абстрагавацца ад сеткавых праблем, недастаўкі паведамленняў, праблем прамежкавага софту - усе гэтыя рызыкі прымае на сябе дэцэнтралізаваная сетка, і, галоўная яе каштоўнасць для PVRB - немагчымасць адклікаць або сапсаваць ужо адпраўленую транзакцыю - гэта не дазваляе ўдзельнікам адмовіцца ад удзелу ў пратаколе, калі толькі яны не правялі паспяховую атаку на кансэнсус. Такі ўзровень бяспекі прымальны, таму PVRB павінен быць устойлівы да змоваў удзельнікам роўна ў той жа меры, што і асноўны ланцужок блокчейна. Таксама, гэта намякае, што PVRB павінен быць часткай кансэнсусу, калі сетка дамовілася наконт асноўнага ланцужка блокаў, няхай адначасова яна дамовіцца і аб адзіным сумленным выніковым рандоме. Або, PVRB – гэта проста standalone пратакол, рэалізаваны смарт-кантрактам, працуюзій асінхронна ў адносінах да блокчейну і блокам. У абодвух спосабаў ёсць свае перавагі і недахопы, і выбар паміж імі вельмі нетрывіяльны.

Два спосабу імплементацыі PVRB

Апішам падрабязней два варыянты імплементацыі PVRB – standalone версію, якая працуе з выкарыстаннем незалежнага ад блокчейна смарт-кантракту, і consensus-integrated – убудаваную ў пракалоў, паводле якога сетка дамаўляецца аб ланцужку блокаў і ўключаных транзакцыях. Ва ўсіх выпадках я буду мець на ўвазе папулярныя блокчейн-рухавічкі: Ethereum, EOS, і ўсё, падобныя на іх па спосабе размяшчэння і працэсінгу смарт-кантрактаў.

Standalone contract

У гэтым варыянце PVRB уяўляе сабой смарт-кантракт, які прымае транзакцыі random-producer-ов (далей RP), апрацоўвае іх, камбінуе вынікі, і, у выніку, прыходзіць да некаторага значэння, якое можа атрымаць любы карыстач з гэтага кантракту. Гэта значэнне можа не захоўвацца ў кантракце напрамую, а быць прадстаўлена толькі дадзенымі, з якіх можна дэтэрмінавана атрымаць адно і толькі адно значэнне выніковага рандома. У гэтай схеме RP – карыстальнікі блокчейна, і ўдзельнічаць у працэсе генерацыі можна дазволіць каму заўгодна.

Варыянт са standalone-contract добры:

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

Ён жа мае і недахопы:

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

Гэты варыянт падыходзіць для рэалізацыі PVRB, які неабходна запусціць ва ўжо існай сетцы, не ўтрымоўвальны складаную крыптаграфію і не патрабавальны вялікай колькасці ўзаемадзеянняў.

Consensus-integrated

У гэтым варыянце PVRB рэалізаваны ў кодзе блокчейн-ноды, убудаваны ці працуе раўналежна з абменам паведамленняў паміж нодамі блокчейна. Вынікі пратакола запісваюцца прама ў вырабляныя блокі, а паведамленні пратакола адпраўляюцца па p2p сеткі паміж нодамі. Так як пратакол мае вынікам ліку, якія павінны быць запісаны ў блоках, сетка павінна прыйсці да кансэнсусу адносна іх. Значыць паведамленні PVRB, як і транзакцыі, павінны валідавацца нодамі, і ўключацца ў блокі, каб любы ўдзельнік сеткі мог бы правалідаваць выкананне пратакола PVRB. Гэта аўтаматычна вядзе нас да відавочнага рашэння - калі сетка дамаўляецца ў кансэнсусе наконт блока і транзакцый у ім, то PVRB павінен быць часткай кансэнсусу, а не асобна стаіць пратаколам. Інакш магчымая сітуацыя, калі блок з'яўляецца валідным з пункта гледжання кансэнсусу, але пратакол PVRB не выкананы, і з пункта гледжання PVRB блок не можа быць прыняты. Так што калі абраны "consensus-integrated" варыянт, PVRB становіцца важнай часткай кансэнсусу.

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

Фінальнасць вельмі важная для карыстачоў, якія без яе могуць апынуцца ахвярамі нападу "double spend", калі BP "прытрымлівае" блокі, і публікуе іх пасля таго, як сетка "ўбачыла" добрую транзакцыю. Калі фінальнасці няма, то апублікаваны форк замяняе блок з "добрай" транзакцыяй на іншы, з "дрэннага" форка, у якім гэтыя ж сродкі пераводзяцца на адрас атакавалага. У выпадку з PVRB патрабаванні да фінальнасці яшчэ ўзмацняюцца жорсткасць, бо пабудова форкаў для PVRB азначае магчымасць для атакавалага рыхтаваць некалькі варыянтаў рандома з мэтай апублікаваць найболей выгодны яму, і абмежаваць час магчымай напады добрае рашэнне.

Таму лепшы варыянт - сумясціць PVRB і фінальнасць у адзін пратакол - тады фіналізаваны блок = фіналізаваны рандом, а гэта менавіта тое, што трэба было атрымаць. Цяпер гульцы атрымаюць гарантаваны рандам за N секунд, і могуць быць упэўненыя, што адкаціць яго ці перайграць нанова немагчыма.

Варыянт з consensus-integrated добры:

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

Ён жа мае і недахопы:

• складанасці пры тэставанні і распрацоўцы - прыйдзецца эмуляваць сеткавыя памылкі, знікаючыя ноды, хардфоркі сеткі
• памылкі ў рэалізацыі патрабуюць хардфорка сеткі

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

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

PVRB і зменныя блокі.

Я не хлусіў, калі казаў, што добрага PVRB, праверанага мноствам gambling прыкладанняў, у блокчейнах пакуль ніхто не імплементаваў. Адкуль тады такая колькасць gambling прыкладанняў у Ethereum і EOS? Мяне гэта дзівіць таксама як і вас, ну адкуль у цалкам дэтэрмінаваным асяроддзі дасталі гэтулькі "ўстойлівых" рандомаў?

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

Але нават post-quantum secure хэшаў недастаткова, нажаль. Сакрэт крыецца ў патрабаваннях да PVRB, нагадаю іх з папярэдняга артыкула:

1. Вынік павінен мець даказальна раўнамернае размеркаванне, г.зн. заснаваны на даказальна стойкай крыптаграфіі.
2. Немагчыма кантраляваць ніводны з бітаў выніку. Як следства, вынік не можа быць загадзя прадказаны.
3. Нельга сабатаваць пратакол генерацыі за рахунак няўдзелу ў пратаколе ці шляхам перагрузкі сеткі атакавалымі паведамленнямі
4. Усё вышэйпералічанае павінна быць устойлівым да змоваў дапушчальнай колькасці несумленных удзельнікаў пратаколу (напрыклад 1/3 удзельнікаў).

У дадзеным выпадку выконваецца толькі патрабаванне 1, і не выконваецца 2. Хэшуючы непрадказальныя значэнні з блока, мы атрымаем раўнамернае размеркаванне і добрыя рандомы. Але ў BP ёсць як мінімум магчымасць "апублікаваць блок, ці не". Такім чынам BP як мінімум можа выбіраць з ДВУХ варыянтаў рандома: "свайго" і таго, які атрымаецца, калі блок зробіць хтосьці іншы. BP можа загадзя "падглядаць", што атрымаецца, калі ён апублікуе блок, і проста прымае рашэнне рабіць гэта ці не. Такім чынам, гуляючы напрыклад у "цот-непарот" ці "чырвонае/чорнае" у рулетцы, ён можа публікаваць блок толькі, калі бачыць выйгрыш. Гэта таксама робіць непрацоўнай стратэгію выкарыстання, напрыклад, хеша блока "з будучыні". У гэтым выпадку кажуць, што “будзе выкарыстаны рандом, які атрымліваецца хэшаваннем бягучых дадзеных і хеша будучага блока вышынёй, напрыклад, N + 42, дзе N – бягучая вышыня блока. Гэта крыху ўзмацняе схему, але ўсё роўна дазваляе BP, хай і ў будучыні, выбіраць, прытрымаць блок або апублікаваць.

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

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

PVRB і commit-reveal.

Добра, дзякуй хэшаванню і хоць бы адноснай непрадказальнасці хеша блока і іншых зменных. Калі вырашыць праблему front-running-а майнераў, павінна атрымацца нешта больш прыдатнае. Давайце дадамо ў гэтую схему карыстальнікаў - няхай таксама ўплываюць на рандом: любы супрацоўнік тэхпадтрымкі скажа вам, што самае рандомнае ў IT сістэмах - гэта дзеянні карыстальнікаў 🙂

Наіўная схема, калі карыстачы проста шлюць рандомныя лікі, а вынік вылічаецца як, напрыклад, хэш ад іх сумы, не падыходзіць. У гэтым выпадку апошні гуляючы можа выбіраючы свой рандом кантраляваць які атрымаецца вынік. Таму выкарыстоўваецца вельмі шырока выкарыстоўваны патэрн commit-reveal. Удзельнікі спачатку шлюць хэшы ад сваіх рандомаў (commit-ы), а затым адчыняюць самі рандомы (reveal-ы). Фаза "reveal" пачынаецца толькі пасля таго, як былі сабраны неабходныя commit-ы, таму ўдзельнікі могуць даслаць роўна той рандом, хэш ад якога даслалі раней. Зараз сляпім усё гэта з параметрамі блока, прычым лепш узятага з будучыні (рандом можна будзе пазнаць толькі ў адным з будучых блокаў), і вуаля — рандом готаў! Зараз любы гулец уплывае на выніковы рандом, і можа "перамагчы" шкоднага BP, перакрыўшы яго рандом сваім, невядомым загадзя, рандомам… Яшчэ можна дадаць абарону ад сабатавання пратаколу шляхам неадкрыцця на этапе reveal - проста запатрабаваўшы пры commit-е прыкладаць да транзакцыі некаторую суму - страхавы дэпазіт, які вернецца толькі пры працэдуры reveal. У гэтым выпадку рабіць commit і не рабіць reveal будзе невыгодна.

Гэта была добрая спроба, і такія схемы таксама ёсць у гульнявых DApp-ах, але нажаль, гэтага зноў нядосыць. Цяпер на вынік можа ўплываць не толькі майнер, але і любы ўдзельнік пратакола. Кантраляваць само значэнне па-ранейшаму можна, з меншай ступенню варыятыўнасці і за грошы, але, як і ў выпадку з майнерам, калі вынікі розыгрышу больш каштоўныя, чым плата за ўдзел у пратаколе PVRB, то random-producer(RP) можа вырашаць, ці рабіць reveal і па-ранейшаму можа выбіраць з мінімум двух варыянтаў рандома.
Затое з'явілася магчымасць караць тых, хто робіць commit і не робіць reveal, і гэтая схема яшчэ спатрэбіцца. Яе прастата з'яўляецца сур'ёзнай перавагай - больш сур'ёзныя пратаколы патрабуюць значна больш магутных вылічэнняў.

PVRB і дэтэрмінаваныя подпісы.

Ёсць яшчэ адзін спосаб прымусіць RP падаць псеўдавыпадковы лік, на якое ён не зможа паўплываць, калі яму падаць "правобраз" – гэта дэтэрмінаваны подпіс. Такі подпіс з'яўляецца, напрыклад, RSA, і не з'яўляецца ECS. Калі ў RP ёсць пара ключоў: RSA і EСС, і ён падпісвае сваім прыватным ключом некаторае значэнне, то ў выпадку RSA у яго атрымаецца ОДНЫ І ТОЛЬКІ ОДНЫ подпіс, а ў выпадку ECS – ён можа згенераваць любы лік розных валідных подпісаў. Гэта адбываецца з-за таго, што пры стварэнні ECS подпісы выкарыстоўваецца рандомны лік, які выбіраецца падпісантам, і ён можа быць абраны як заўгодна, даючы падпісанту магчымасць выбіраць адзін з некалькіх подпісаў. У выпадку RSA: "адно ўваходнае значэнне" + "адна пара ключоў" = "адзін подпіс". Прадказаць які атрымаецца подпіс у іншага RP не атрымаецца, таму PVRB з дэтэрмінаванымі подпісамі можа быць арганізаваны пры дапамозе камбінавання RSA подпісаў некалькіх удзельнікаў, якія падпісалі адно і тое ж значэнне. Напрыклад - папярэдні рандом. У такой схеме эканоміцца ​​нямала рэсурсаў, т.я. подпісы з'яўляюцца адначасова і пацвярджэннем карэктнасці паводзін па пратаколе, і крыніцай рандома.

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

PVRB і secret sharing схемы

У крыптаграфіі існуюць схемы, якія могуць дазволіць сеткі дамовіцца аб адным і толькі адным значэнні PVRB, пры гэтым такія схемы ўстойлівыя да любых зламысных дзеянняў часткі ўдзельнікаў. Адзін з карысных пратаколаў, з якімі варта пазнаёміцца ​​- схема падзелу сакрэту Шаміра. Яна служыць для таго, каб падзяліць сакрэт (напрыклад сакрэтны ключ) на некалькі частак, і раздаць гэтыя часткі N удзельнікам. Сакрэт размяркоўваецца такім чынам, што для яго аднаўлення дастаткова M частак з N, пры гэтым гэта могуць быць любыя M частак. Калі на пальцах, то маючы графік невядомай функцыі, удзельнікі абменьваюцца кропкамі на графіцы, і пасля атрымання M кропак, уся функцыя можа быць адноўлена.
Добрае тлумачэнне прыведзена ў вікі а пагуляць з ім практычна, каб прайграць пратакол у галаве карысна на дэманстрацыя старонцы.

Калі б схема FSSS (Fiat-Shamir Secret Sharing) была дастасавальная ў чыстым выглядзе – гэта быў бы незабівальны PVRB. У найпростым варыянце пратакол можа выглядаць так:

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

Тут асобны ўдзельнік ужо не ўплывае на вынікі пратакола, за выключэннем выпадкаў, калі толькі ад яго залежыць дасягненне threshold-а расчыненні рандома. Таму гэты пратакол, пры наяўнасці неабходнай дзелі якія працуюць па пратаколе і даступных RP працуе, рэалізуючы патрабаванні па крыптаграфічнай устойлівасці, і з'яўляючыся ўстойлівым да праблемы "last actor".

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

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

PVRB і threshold signatures

Пазнаёміўшыся са схемай secret sharing, мы адкрылі цэлы клас пратаколаў, аб'яднаных ключавым словам "threshold". Калі для расчынення некаторай інфармацыі патрабуецца ўдзел M сумленных удзельнікаў з N, і набор сумленных удзельнікаў можа быць адвольным падмноствам N, кажуць аб "threshold" схемах. Менавіта яны дазваляюць разабрацца з праблемай "last actor", зараз калі атакавалы не адчыняе сваю частку сакрэту, за яго гэта зробіць іншы, сумленны ўдзельнік. Гэтыя схемы дазваляюць дамовіцца аб адным і толькі адным значэнні, нават пры сабатаванні пратакола часткай удзельнікаў.

Сумяшчэнне дэтэрмінаваных подпісаў і threshold-схем дазволіла распрацаваць вельмі зручную і шматабяцальную схему для рэалізацыі PVRB – гэта дэтэрмінаваныя threshold-подпісы. Вось артыкул аб розных ужываннях threshold-подпісаў, а вось яшчэ адзін добры longread ад Dash.

У апошнім артыкуле апісваюцца BLS подпісы (BLS расшыфроўваецца як Boneh-Lynn-Shacham, вось артыкул ), якія маюць вельмі важную і вельмі зручную для праграмістаў якасць — публічныя, сакрэтныя, публічныя ключы і подпісы BLS могуць камбінавацца адзін з адным пры дапамозе простых матэматычных аперацый, пры гэтым іх камбінацыі застаюцца валіднымі ключамі і подпісамі, дазваляючы лёгка агрэгаваць шмат подпісаў у адну і шмат публічных ключоў у адзін. Яны валодаюць таксама дэтэрміністычнасцю і на адных і тых жа ўваходных дадзеных выдаюць адзін і той жа вынік. Дзякуючы гэтай якасці, камбінацыі BLS подпісаў самі з'яўляюцца валіднымі ключамі, што дазваляе рэалізаваць варыянт, пры якім M з N удзельнікаў вырабляюць адзін і толькі адзін подпіс, які дэтэрмінаваны, publicly verifiable, і непрадказальны датуль, пакуль не будзе выкрыта M-тым удзельнікам. .

У схеме з threshold BLS signatures кожны ўдзельнік падпісвае з дапамогай BLS нешта (напрыклад папярэдні рандам), а агульны threshold-подпіс і ёсць шуканы рандам. Крыптаграфічныя ўласцівасці подпісаў BLS задавальняюць патрабаванням да якасці рандома, threshold-частка абараняе ад "last-actor", а ўнікальная камбінаванасць ключоў дазваляе рэалізаваць яшчэ шмат цікавых алгарытмаў, якія дазваляюць, напрыклад, эфектыўна агрэгаваць паведамленні пратаколу.

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

Імплементацыя PVRB

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

Я пералічу фактары, якія вам давядзецца ўлічваць пры выбары якаснага PVRB:

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

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

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

Заключэнне

Спадзяюся, у папярэдняй артыкуле я здолеў пераканаць вас, што генерацыя выпадковых лікаў на блокчейне крытычна важная для мноства аспектаў жыцця дэцэнтралізаваных сетак, а гэтым артыкулам паказаў, што задача гэтая вельмі амбіцыйная і няпростая, але добрыя рашэнні ўжо існуюць. Наогул, канчатковы дызайн пратаколу магчымы толькі пасля правядзення масіўных тэстаў, якія ўлічваюць усе аспекты ад setup-а да эмуляцыі збояў, таму вы ці наўрад знойдзеце гатовыя рэцэпты ў whitepaper-ах каманд і ў артыкулах, ды і мы ў найблізкі год-два сапраўды не вырашымся пісаць "рабіце так, так дакладна правільна".

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

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

Так што, сустрэўшы праграміста, які праектуе дэцэнтралізаваны рандом, будзьце ўважлівыя і клапатлівыя, пры неабходнасці акажыце псіхалагічную дапамогу 🙂

Крыніца: habr.com