Már régóta érdeklődünk a kriptovaluták anonimitása iránt, és igyekszünk nyomon követni a technológiai fejlődést ezen a területen. Cikkeinkben már részletesen elemeztük a működési elveket a Moneróban, és végeztünk a meglévő technológiákról ezen a területen. Az összes anonimitásra összpontosító kriptovaluta a mai napig a Bitcoin által javasolt adatmódellen alapul — Unspent Transaction Output (UTXO). Az account-alapú blokkláncok, mint az Ethereum, a létező anonimitást és bizalmaságot biztosító megoldások (például vagy ) próbálták megismételni az UTXO modellt okos szerződésekben.
2019 februárjában a Stanford Egyetem és a Visa Research kutatói kiadták a "Zether: Az anonimitás felé a világ okos szerződéseiben" című előtanulmányukat. Az alkotók először javasoltak megközelítést az anonymitás biztosítására az account-alapú blokkláncokban, és két okos szerződésváltozatot mutattak be: a bizalmas (a költségek és az átutalások összegeinek elrejtése) és az anonim (a címzett és az elküldvő elrejtése) tranzakciók számára. Érdekesnek találjuk a javasolt technológiát, és szeretnénk megosztani a működését, valamint beszélni arról, miért is tekintik a probléma alapú blokkláncok anonimitásának problémáját nagyon nehéznek, és hogy az alkotóknak sikerült-e teljes mértékben megoldaniuk azt.
Az adatmodellek működéséről
Az UTXO modellben a tranzakciók "bemenetekből" és "kimenetekből" állnak. A "kimenetek" közvetlen párhuzama: a pénzképek a pénztárcájában; minden "kimenet" valamilyen névértékkel bír. Amikor valakinek kifizet, (tranzakciót hoz létre) egy vagy több "kimenetet" elköltesz, és ezek "bemenetekké" válnak a tranzakcióban, és a blokklánc megjelöli őket elkölthetetlennek. Eközben a fizetésed címzettje (vagy te magad, ha visszajáróra van szükséged) újonnan generált "kimeneteket" kap. Sémásan ezt így lehet ábrázolni:
Az account-alapú blokkláncok körülbelül úgy működnek, mint a banki számlád. Csak az egyenlegeddel és az átutalás összegével foglalkoznak. Amikor egy összeget utalsz át a számládról, nem égetsz el semmilyen "kimenetet", a hálózatnak nem kell emlékeznie arra, hogy mely érme került felhasználásra, és melyik nem. A legegyszerűbb esetben a tranzakció ellenőrzése a küldő aláírásának és az egyenlegének ellenőrzésére korlátozódik:
A technológia elemzése
A következőkben arról beszélünk, hogyan rejti el a Zether a tranzakciók összegét, a címzettet és a feladót. A működési elvek leírása során megjegyezzük a titkos és anonim verzió közötti különbségeket. Mivel az account-based blokkláncokban a titkosság biztosítása sokkal egyszerűbb, néhány az anonimizálás által imposztált korlátozás nem releváns a technológia titkos verziója szempontjából.
A mérlegek és a transfer összegének elrejtése
A Zether-ben a mérlegek és a transfer összegének titkosításához az alábbi titkosítási sémát használják: . A működése a következő. Amikor Alice Bobnak szeretne küldeni b érmet a (nyilvános kulcsán található) címére Y, először választ egy véletlen számot r és titkosítja az összeget:
ahol C — titkosított összeg, D — a titkosított összeg visszafejtéséhez szükséges segédérték, G — egy fix pont az elliptikus görbén, amit a titkos kulcsra való szorzás során kapunk, így keletkezik a nyilvános kulcs.
Amikor Bob megkapja ezeket az értékeket, egyszerűen hozzáadja őket saját, hasonló módon titkosított egyenlegéhez, ami megkönnyíti a helyzetét.
Hasonló módon Alice kivonja a saját egyenlegéből az azonos értékeket, csak a Y nyilvános kulcsát használva.
A címzett és a feladó elrejtése
A kimenetek összekeverésének elve az UTXO-ban már a kriptovaluták hajnalán megjelent, és segít eltüntetni a feladót. Ehhez a küldő a tranzakció végrehajtásakor véletlen „kimeneteket” választ a blokkláncból, és összekeveri őket a sajátjaival. Ezután aláírja a kimeneteket gyűrűs aláírással — egy kriptográfiai mechanizmussal, amely bizonyítja a ellenőrnek, hogy az összekevert kimenetek között található a küldőérme. Az összekevert érmék természetesen nem használhatók fel.
A címzett elrejtésére azonban nem tudunk hamis „kimeneteket” generálni. Ezért az UTXO-ban minden „kimenetnek” egyedi címe van, amely kriptográfiai kapcsolatban áll a címzett címével. Jelenleg nincs módszer az egyedi „kimenet” cím és a címzett cím közötti kapcsolat felderítésére, hacsak nem ismerjük a titkos kulcsait.
Az account-alapú modellben nem használhatunk egyszeri címeket (mert ez már a „kilépések” modell lenne). Ezért a fogadó- és küldő fél címét más címekkel kell keverni a blokkláncon. Ezzel együtt a keverésre használt címekről titkosított 0 érmét vonunk le (vagy hozzáadunk 0-t – a fogadó keverésének esetén), a tényleges egyenlegük lényegében nem változik.
Mivel a küldő és a fogadó fél mindig állandó címmel rendelkezik, felmerül a szükség, hogy ugyanazokra a címekre történő átutalások során ugyanazokat a csoportokat használjuk a keveréshez. Ezt érdemes egy példán keresztül megvizsgálni.
Tegyük fel, hogy Alice úgy dönt, hogy adományoz egy alapítványnak Bobnak, de azt szeretné, ha ez az átutalás anonim maradna egy külső megfigyelő számára. Ezért, hogy elrejtse magát a küldő mezőben, beírja Adam és Adele címét. Bob elrejtéséhez pedig a fogadó mezőben további Ben és Bill címeket ad. Amikor Alice a következő adományt teszi, úgy dönt, hogy Alexet és Amanda-t is mellékel, Bob mellé pedig Bruce-t és Benjen-t. Ebben az esetben a blokklánc elemzése során ezekben a két tranzakcióban mindössze egy átfedő résztvevő pár található – Alice és Bob, ami deanonimizálja ezeket a tranzakciókat.
Tranzakciók versenye
Amint már említettük, az account-alapú rendszerekben a felhasználó titkosítja az egyenlegét és az átutalás összegét, hogy elrejthesse a saját egyenlegét. Ugyanakkor bizonyítania kell, hogy a számláján lévő egyenleg nem negatív. A probléma az, hogy amikor a felhasználó tranzakciót generál, bizonyítékot épít a számla aktuális állapota alapján. Mi történik azonban, ha Bob Alice-nek küld egy tranzakciót, és azt előbb fogadják el, mint Alice által küldött tranzakciót? Ebben az esetben Alice tranzakciója érvénytelen lenne, mert az egyenleg bizonyítéka azelőtt készült, hogy Bob tranzakciója elfogadásra került volna.
Az első megoldás, ami ilyenkor eszébe jut, hogy felfüggessze a fiókot a tranzakció lebonyolításáig. De ez a megközelítés nem működőképes, mert a felosztott rendszerben egy ilyen feladat megoldása bonyolult, és az anonim sémában nem világos, hogy kinek a fiókját kellene blokkolni.
A probléma megoldásához a technológia különválasztja a bejövő és kimenő tranzakciókat: a pénzfelhasználás azonnali hatással van a méretre, míg a beérkezések halasztott. Ehhez bevezetik az "epochák" fogalmát - fix méretű blokkok csoportját. A jelenlegi "epochát" a blokk magasságának és a csoport méretének osztásával határozzák meg. A tranzakció feldolgozása során a hálózat azonnal frissíti a küldő egyenlegét, míg a címzett pénze egy gyűjtőbe kerül. A felhalmozott pénz a címzett rendelkezésére csak az új "epochá" bekövetkeztekor áll rendelkezésre.
Ennek eredményeként a felhasználó tranzakciókat küldhet, függetlenül attól, hogy milyen gyakran érkeznek a források (nyilván a költségvetése engedi). Az epochák méretét az határozza meg, hogy a blokkok hány gyorsan terjednek a hálózaton, és mennyire gyorsan jut a tranzakció egy blokkba.
Ez a megoldás jól működik a titkos átutalások esetén, azonban az anonim tranzakciókkal, ahogy később látni fogjuk, súlyos problémákat okoz.
Védelem a replay-támadások ellen
Az account-based blokkláncokban minden tranzakciót a küldő magánkulcsával írnak alá, ami meggyőzi a ellenőrt arról, hogy a tranzakciót nem változtatták meg, és azt a kulcs birtokosa készítette. De mi történik, ha egy támadó, aki figyeli az átviteli csatornát, elkapja ezt az üzenetet, és pontosan ugyanezt a második üzenetet küldi el? Az ellenőr egyezteti a tranzakció aláírását, és megbizonyosodik annak szerzőjéről, és a hálózat újra levonja az ugyanakkora összeget a küldő egyenlegéből.
Ezt a támadást replay-támadásnak hívják. Az UTXO-modellekben ilyen támadások nem relevánsak, mivel a támadó a felhasználható kimeneteket próbálja felhasználni, ami önmagában nem érvényes és a hálózat elutasítja.
Annak elkerülése érdekében, hogy ilyesmi történjen, a tranzakcióba véletlenszerű adatokat tartalmazó mezőt ágyaznak be, amelyet nonce vagy egyszerűen "só"-nak hívnak. Ha a tranzakciót újra elküldik a "sóval", az ellenőr ellenőrzi, hogy ezt a nonce-t használták-e korábban, és ha nem, érvényesnek tekinti a tranzakciót. Anélkül, hogy tárolni kellene a felhasználók összes nonce-történetét a blokkláncban, általában az első tranzakcióban nullának veszik, majd eggyel növelik. A hálózaton csak annyit kell ellenőrizni, hogy az új tranzakció nonce-a eltér-e az előzőtől egyessel.
Az anonim tranzakciós sémában felmerül a nonce-ok érvényesítésének problémája. Nem kapcsolhatjuk a nonce-okat közvetlenül a küldő címéhez, mert ez nyilvánvalóan deanonimizálja a tranzakciót. Emellett nem növelhetjük a részt vevő fiókok nonce-jait, mivel ez ütközhet más, feldolgozás alatt álló tranzakciókkal.
A Zether szerzői javasolják, hogy kriptográfiai úton generáljunk nonce-okat - a 'korszak' függvényében. Például:
Itt x — a küldő titkos kulcsa, valamint Gepoch — egy további generátor a korszakhoz, amelyet a 'Zether + ' formátumú sztring hashelésével nyerünk. Most a probléma látszólag megoldódik - nem hozunk nyilvánosságra a küldő nonce-át, és nem avatkozunk be a nem érintett résztvevők nonce-aiba. De ez a megközelítés komoly korlátozást jelent: egy fiók nem küldhet több mint egy tranzakciót egy 'korszak' alatt. Ez a probléma sajnos megoldatlan marad, és jelenleg a Zether anonim verzióját, véleményünk szerint, alig teszi használhatóvá.
Nulla nyilvánosságra hozatali bizonyítékok nehézsége
Az UTXO esetében a küldőnek be kell bizonyítania a hálózatnak, hogy nem költ negatív összeget, különben lehetséges, hogy új érmeket generálunk a levegőből (miért lehetséges ez, erről korábban írtunk). Továbbá alá kell írnia a 'bemeneteket' körkörös aláírással, hogy bizonyítani tudja, hogy a keverendő érmék között vannak közvetlenül hozzá tartozó eszközök.
Az anonim account-alapú blokk lánc verzióban a bizonyítékok kifejezései sokkal bonyolultabbak. A küldőnek be kell bizonyítania, hogy:
- Az átutalt összeg pozitív;
- A mérleg nem lehet negatív;
- A küldő helyesen titkosította az átutalások összegét (beleértve a nullát is);
- A mérleg csak a küldő és a fogadó esetében változik;
- A küldő rendelkezik a fiókja titkos kulcsával, és valóban ott van a küldők listájában (a keverendők között);
- A tranzakcióban használt nonce helyesen áll össze.
Az ilyen bonyolult bizonyítékhoz a szerzők egy keveréket használnak, (a szerzők egyike mellesleg részt vett a kidolgozásában) és , amelyet Sigma-bullets néven neveznek. Egy ilyen állítás formális bizonyítása meglehetősen bonyolult feladat, és erősen korlátozza a technológia megvalósításával foglalkozni akarók számát.
Mi az összefoglaló?
Véleményünk szerint a Zether azon része, amely adatvédelmet hoz a fiókalapú blokkláncokba, már most is használható lehet. Azonban jelenleg az anonimizált változat komoly korlátozásokat jelent a használatában, és a bonyolultsága a megvalósítására is hatással van. Ne felejtsük el azonban, hogy a fejlesztők mindössze néhány hónapja adták ki, és lehetséges, hogy valaki más talál megoldást a jelenlegi problémákra. Végül is így működik a tudomány.
Forrás: habr.com
