Az ötlettől a megvalósításig: módosítjuk a meglévő digitális aláírási rendszert elliptikus görbén, hogy az determinisztikus legyen, és ezen alapul véletlenszerű számokat generáló funkciókat kínálunk a blokklánc keretein belül.
Ötlet
2018 őszén a Waves blokkláncon azonnal felmerült a kérdés, hogy lehetséges-e Elgondolkodva ezen a kérdésen, végül arra a következtetésre jutottam, hogy bármely blokklánc egy ketrec, és a zárt rendszerben megbízható entrópiát találni lehetetlen.
De egy ötlet mégis tetszett: ha
a véletlenszám-orákulum A Waves blokklánc-platformon az aláírási struktúra
EdDSA a verziót Nyilvánvaló, hogy tiszta formájában ezt az aláírást nem lehet használni véletlenszerű számok forrásaként, mivel az nem determinisztikus, ezért könnyen manipulálható az orákulum által.
De, mint kiderült, valójában lehetséges a determinisztikus létrehozása.
Nagy reményeket fűztem a
ellenőrizhető véletlenszám-funkcióhoz (VRF) , de a műszaki anyagok áttekintése után ezt a lehetőséget el kellett vetni. Bár a VRF determinisztikus aláírási és annak bizonyítási lehetőséget kínál, a algoritmusban van egy furcsa hely, ami fekete lyukat nyit a jósló manipulációira. Nevezetesen, a k értékének kiszámításakor () egy zárt kulcsot használnak, amely a felhasználó előtt ismeretlen marad, tehát a felhasználó nem tudja ellenőrizni a k számításának helyességét, így a jósló bármilyen szükséges k értéket használhat, és egyidejűleg nyilvántartást vezethet a k és az aláírandó adatok megfelelő kapcsolatairól, hogy mindig képes legyen újra számítani a VRF szempontjából helyes eredményt. Ha látja a VRF alapú sorsolást anélkül, hogy felfedné a zárt kulcsot, elmondhatja, hogy szükséges felfedni a kulcsot, vagy kizárni azt a k számításából, ez esetben a zárt kulcs automatikusan felfedésre kerül az első aláírás megjelenésekor. Összességében, ahogy már említettem, furcsa séma egy véletlen jóslóra.
Néhány gondolkodás után és a helyi elemzők támogatásával, megszületett a VECRO működési terve.
A VECRO a Verifiable Elliptic Curve Random Oracle rövidítése, amely magyarul ellenőrizhető véletlen jóslót jelent elliptikus görbék alapján.
Mindez meglehetősen egyszerűnek bizonyult, a determináltság eléréséhez szükséges a R értékének rögzítése az aláírandó üzenet megjelenése előtt. Ha R rögzítve van, és az aláírandó üzenet részét képezi, ami további garanciát nyújt R rögzítésére magában az aláírandó üzenetben, akkor az S érték egyértelműen meghatározva van a felhasználói üzenet alapján, és ezért felhasználható ál-random számok forrásaként.
Ilyen séma esetén nem számít, hogyan rögzítik R-t, az a jósló felelősségi körébe tartozik. Fontos, hogy S-t egyértelműen a felhasználó határozza meg, de ennek értéke ismeretlen, amíg a jósló nem teszi közzé. Minden úgy van, ahogy akartuk!
A rögzített R-ről beszélve, vegye figyelembe, hogy A különböző üzenetek aláírásakor egyértelműen felfedi a zárkulcsot az EdDSA sémában. Az oracle tulajdonosa számára rendkívül fontos, hogy kizárja a R újrahasználatának lehetőségét a felhasználó különböző üzeneteinek aláírásához. Vagyis bármilyen manipuláció vagy összejátszás esetén az oracle mindig kockázatot vállal a zárkulcs elvesztésére.
Összességében az oracle-nak két funkciót kell biztosítania a felhasználók számára: az initáló funkciót, amely rögzíti az R értéket, és az aláírás funkciót, amely visszaadja az S értéket. Ezenkívül az R és S pár egy szokásos ellenőrizhető aláírása a felhasználói üzenetnek, amely tartalmazza az R rögzített értékét és a felhasználó önálló adatokat.
Ellenkezhetünk azzal, hogy ez a séma nem más, mint egy szokásos . Valójában igen, az. De van néhány árnyalat. Először is, az oracle mindig ugyanazzal a kulccsal dolgozik minden művelet során, például ez kényelmesen használható szerződésekben. Másodszor, az oracle zárkulcsának elvesztése a hibás viselkedés miatt kockázatot jelent, például, ha az oracle lehetővé teszi az eredmény mintavételezését, akkor elég csak két mintát venni ahhoz, hogy megtudjuk a zárkulcsot, és teljes hozzáférést nyerjünk a pénztárcához. Harmadszor, a blokkláncban natívan ellenőrizhető aláírás, amely a véletlenszerűség forrása - ez szépen hangzik.
Hat hónapig foglalkozott az ötlet megvalósításával, míg végül megjelent a motiváció . Nagy támogatással nagy felelősség jár, tehát a projekt megvalósulhat!
Megvalósítás
Tehát ebben a projektben a Waves blokkláncon kérés-válasz üzemmódban a felhasználó és az oracle közötti átutalási tranzakciók segítségével. Ezenkívül az oracle fiókján egy olyan szkript van telepítve, amely szigorúan ellenőrzi a fent leírt logika szerint a működést. Az oracle tranzakciói ellenőrzésen mennek keresztül, helyreállítva az összes felhasználóval való interakció láncolatát. A végső érték ellenőrzésében mind a négy tranzakció részt vesz, a smart contract szigorúan felfűzi ezeket az ellenőrzési szálra, lépésről lépésre ellenőrizve az összes értéket és nem hagyva helyet bármiféle manipulációnak.
Még egyszer, hogy rögzüljön és érthetőbb legyen. Az oracle nem csupán a javasolt séma szerint működik. A működése teljes mértékben ellenőrzött a blokklánc szintjén, amelyet beállítottak. . Egy lépés balra, és a tranzakció egyszerűen nem megy át. Tehát ha a tranzakció a blokkláncra került, a felhasználónak még csak ellenőriznie sem kell, mert már számos hálózati csomópont ellenőrizte helyette.
Jelenleg a Waves főhálózatában egy VECRO működik (indíthat sajátot is, ez nem nehéz, csak ). A jelenlegi kód PHP nyelven működik (a -ról, amiről ).
Ahhoz, hogy igénybe vegye az oracle szolgáltatást, a következőket kell tenni:
- R rögzítése;
- Küldjön minimum 0.005 Wavest az oracle aliasának, init@vecr;
- Szerezze meg az R-kódot a csatolmány mezőben az oracle-tól a felhasználóhoz történő 1 R-vecr token átutalásakor;
- Szerezze meg az aláírást;
- Küldjön minimum 0.005 Wavest az oracle aliasának, random@vecr, és KÖTELEZŐEN adja meg a korábban kapott R-kódot a csatolmány mezőben, valamint további felhasználói adatokat;
- Szerezze meg az S-kódot a csatolmány mezőben az oracle-tól a felhasználóhoz történő 1 S-vecr token átutalásakor;
- Használja az S-kódot mint félreeső véletlenszám forrást.
A jelenlegi megvalósítás részletei:
- Az oracle-nek küldött Wavese-k a felhasználóhoz való visszautalás díjaként használatosak, maximum 1 Waves-ig;
- Az R-kód a ‘R’ karakterből és a 32 bájt hosszú R értékből áll a base58 kódolásban;
- Az R-kódnak a csatolmányban elöl kell lennie, a felhasználói adatok után következnek;
- Az S-kód a ‘S’ karakterből és a 32 bájt hosszú S értékből áll a base58 kódolásban;
- Az S a modulo osztás eredménye, ezért az S-t nem lehet teljes 256 bites véletlenszámként használni (ez a szám maximum 252 bites véletlenszámnak tekinthető);
- A legegyszerűbb megoldás az S-kód hash értékét használni véletlenszámként.
S-kód beszerzésének példája:
- Inicializáció:
- R-kód beszerzése:
- Az R-kód aláírásának és a felhasználói adatoknak a 'random' értékének lekérdezése:
- S-kód beszerzése:
Technikai szempontból az oracle teljesen kész a használatra, bátran igénybe veheti. A végfelhasználó számára a könnyen használható grafikus felület hiányzik, erre még várni kell.
Örömmel válaszolok a kérdésekre és fogadom a megjegyzéseket, köszönöm.
Forrás: habr.com
