Ад ідэі да рэалізацыі: мадыфікуем існуючую схему лічбавага подпісу на эліптычнай крывой, каб яна была дэтэрмінаванай, і падаем на яе аснове функцыі атрымання правяраных у рамках блокчейна псеўдавыпадковых лікаў.
Ідэя
Увосень 2018 у блокчейне Waves былі , неадкладна ўзнікла пытанне аб магчымасці атрымання , якім можна давяраць.
Ламаючы галаву над гэтым пытаннем, канчаткова прыйшоў да высновы: любы блокчейн - гэта клетка, атрымаць давераную крыніцу энтрапіі ў замкнёнай сістэме немагчыма.
Але адна ідэя мне ўсё ж спадабалася: калі будзе рабіць подпіс карыстацкіх дадзеных дэтэрмінаваным алгарытмам, то карыстач заўсёды зможа і праверыць такі подпіс па адчыненым ключы, і будзе ўпэўнены, што атрыманае значэнне ўнікальна. Аракул пры ўсім жаданні не ў сілах нічога змяніць, алгарытм выдае адназначны вынік. Па сутнасці, карыстач фіксуе вынік, але не ведае яго датуль, пакуль аракул яго не апублікуе. Атрымліваецца, што можна ўвогуле не давяраць аракулу, але правяраць вынік яго працы. Тады, у выпадку паспяховай праверкі, такі подпіс можна лічыць крыніцай энтрапіі для псеўдавыпадковага ліку.
У блокчэйн-платформе Waves выкарыстоўваецца схема подпісу. варыянт . У дадзенай схеме подпіс складаецца са значэнняў R і S, дзе R залежыць ад выпадковага значэння, а S вылічаецца на аснове падпісанага паведамлення, зачыненага ключа і таго ж выпадковага ліку, што і R. Атрымліваецца, што адназначнай залежнасці няма, для аднаго і таго ж карыстацкага паведамлення існуе мноства валідных подпісаў.
Відавочна, што ў чыстым выглядзе такі подпіс немагчыма выкарыстоўваць у якасці крыніцы псеўдавыпадковых лікаў, бо яна з'яўляецца недэтэрмінаванай і, такім чынам, можа быць лёгка схільная да маніпуляцый з боку аракула.
Але, як высветлілася, зрабіць яе дэтэрмінаванай насамрэч магчыма.
Вялікія надзеі ў мяне былі на , Але вывучыўшы матч, ад гэтага варыянт прыйшлося адмовіцца. Хоць VRF і прапануе дэтэрмінаваны варыянт подпісу і яго доказы, у алгарытме прысутнічае дзіўнае месца, якое адкрывае чорную дзірку для маніпуляцый аракулам. У прыватнасці, пры разліку значэння k () выкарыстоўваецца зачынены ключ, які застаецца невядомым карыстачу, значыць карыстач не можа праверыць карэктнасць вылічэнні k, значыць аракул можа выкарыстоўваць любое патрэбнае яму значэнне k і адначасова весці базу дадзеных адпаведнікаў k і падпісваных дадзеных, каб заўсёды ўмець паўторна вылічыць карэктны з пункта гледжання VRF вынік . Убачыце розыгрыш на аснове VRF без расчынення зачыненага ключа, можаце паразумнічаць: паказаць на неабходнасць або расчыніць ключ, або выключыць яго з разліку k, тады зачынены ключ аўтаматычна сам расчыніцца пры з'яўленні першага ж подпісу. Увогуле, як ужо было сказанае, дзіўная схема для выпадковага аракула.
Трохі падумаўшы і заручыўшыся падтрымкай мясцовых аналітыкаў, нарадзілася схема працы VECRO.
VECRO – абрэвіятура ад Verifiable Elliptic Curve Random Oracle, што па-руску азначае правяраемы выпадковы аракул на эліптычных крывых.
Усё аказалася даволі проста, для дасягнення дэтэрмінаванасці патрабуецца зафіксаваць значэнне R да з'яўлення падпісанага паведамлення. Калі R зафіксавана і з'яўляецца часткай падпісанага паведамлення, што дадаткова гарантуе фіксацыю R у самім падпісваным паведамленні, значэнне S адназначна дэтэрмінуецца карыстацкім паведамленнем і, такім чынам, можа быць скарыстана ў якасці крыніцы для псеўдавыпадковых лікаў.
У такой схеме ўсё роўна якім чынам фіксуецца R, гэта застаецца ў зоне адказнасці аракула. Важна, што S адназначна вызначаецца карыстачом, але яго значэнне невядома пакуль аракул яго не апублікуе. Усё як мы хацелі!
Гаворачы аб фіксаваным R, звярніце ўвагу, што пры подпісе розных паведамленняў адназначна расчыняе зачынены ключ у схеме EdDSA. Для ўладальніка аракула становіцца вельмі важным выключыць магчымасць паўторнага выкарыстання R для подпісу розных паведамленняў карыстальніка. Гэта значыць, пры любых маніпуляцыях або змове аракул заўсёды будзе рызыкаваць стратай свайго зачыненага ключа.
Разам, аракул павінен падаваць карыстачам дзве функцыі: ініцыялізацыю, якая фіксуе значэнне R, і подпіс, якая вяртае значэнне S. Пры гэтым пара R, S з'яўляецца звычайным правяраным подпісам карыстацкага паведамлення ўтрымоўвалага фіксаванае значэнне R і адвольныя дадзеныя карыстача.
Можна запярэчыць, што дадзеная схема для блокчейна нішто іншае як звычайная . Па сутнасці, так, гэта яна. Але ёсць некалькі нюансаў. Па-першае, аракул заўсёды працуе з адным і тым жа ключом ва ўсіх аперацыях, напрыклад, гэта зручна выкарыстоўваць у кантрактах. Па-другое, існуе рызыка страты зачыненага ключа аракулам пры некарэктных паводзінах, напрыклад, аракул дазваляе рабіць спробы выніку, тады досыць зрабіць усяго дзве пробы, каб пазнаць зачынены ключ і атрымаць поўны доступ да кашалька. Па-трэцяе, натыўна правяраемы ў блокчейне подпіс, які з'яўляецца крыніцай выпадковасці - гэта прыгожа.
Паўгода ідэя рэалізацыі цеплілася ў галаве, пакуль нарэшце не з'явілася матывацыя ў выглядзе . З вялікім грантам прыходзіць вялікая адказнасць, значыць праекту быць!
Рэалізацыя
Такім чынам, у дадзеным праекце на блокчейне Waves у рэжыме запыт-адказ з дапамогай транзакцый трансферу паміж карыстальнікам і аракулам. Пры гэтым на акаўнце аракула ўсталяваны скрыпт, які кантралюе працу строга ў адпаведнасць з апісанай вышэй логікай. Транзакцыі аракула праходзяць праверку з аднаўленнем усяго ланцужка ўзаемадзеяння з карыстальнікам. У праверцы фінальнага значэння ўдзельнічаюць усе чатыры транзакцыі, смарт-кантракт нанізвае іх на строгую праверачную нітку, крок за крокам правяраючы ўсе значэння і не пакідаючы месца для якіх-небудзь маніпуляцый.
Яшчэ раз, каб адклалася і было больш зразумела. Аракул не проста працуе па прапанаванай схеме. Яго праца цалкам кантралюецца на ўзроўні блокчейна устаноўленым . Крок налева, і транзакцыя проста не пройдзе. Так што, калі транзакцыя патрапіла ў блокчейн, карыстачу нават правяраць нічога не трэба, за яго ўсё ўжо праверылі сотні вузлоў сеткі.
На бягучы момант у асноўнай сетцы Waves запушчаны адзін VECRO (вы можаце запусціць свой, гэта не складана, проста ). Бягучы код працуе на PHP (на , пра які ).
Для таго каб скарыстацца сэрвісам аракула неабходна:
- Зафіксаваць R;
- Адправіць мінімум 0.005 Waves на аліяс аракула init@vecr;
- Атрымаць R-code у поле attachment у трансферы 1 R-vecr токена ад аракула карыстачу;
- Атрымаць подпіс;
- Адправіць мінімум 0.005 Waves на аліяс аракула random@vecr, а таксама АБАВЯЗКОВА пазначыць у поле attachment атрыманы раней R-code і дадатковыя карыстацкія дадзеныя;
- Атрымаць S-code у поле attachment у трансферы 1 S-vecr токена ад аракула карыстачу;
- Выкарыстоўваць S-code у якасці крыніцы псеўдавыпадковага ліку.
Нюансы бягучай рэалізацыі:
- Адпраўленыя аракулу Waves выкарыстоўваюцца ў якасці камісіі для зваротнай транзакцыі карыстачу, аж да максімальных 1 Waves;
- R-code - гэта канкатэнацыя байта знака 'R' і 32-байт значэння R у кадоўцы base58;
- R-code у attachment павінен знаходзіцца першым, карыстацкія дадзеныя ідуць пасля R-code;
- S-code - гэта канкатэнацыя байта знака 'S' і 32-байт значэння S у кадоўцы base58;
- S з'яўляецца вынікам дзялення па модулі, таму нельга выкарыстоўваць S як паўнавартасны 256-бітны псеўдавыпадковы лік (гэты лік можа лічыцца максімум 252-бітным псеўдавыпадковым лікам);
- Найбольш просты варыянт - выкарыстоўваць у якасці псеўдавыпадковага ліку хэш ад S-code.
Прыклад атрымання S-code:
- Ініцыялізацыя:
- Атрыманне R-code:
- Запыт выніку подпісу R-code і карыстацкіх дадзеных "random":
- Атрыманне S-code:
З тэхнічнага пункта гледжання, аракул цалкам готаў да працы, можаце адважна ім карыстацца. З пункта гледжання выкарыстання радавым карыстачом, бракуе зручнага графічнага інтэрфейсу, гэтага прыйдзецца пачакаць.
Буду рады адказаць на пытанні і прыняць заўвагі, дзякуй.
Крыніца: habr.com