Régóta érdekel bennünket a kriptovaluták anonimitása, és igyekszünk követni a technológiák fejlődését ezen a területen. Cikkeinkben már részletesen tárgyaltuk a működési elveket
2019 februárjában a Stanford Egyetem és a Visa Research kutatóinak egy csoportja
Ezen adatmodellek szerkezetéről
Az UTXO modellben egy tranzakció „bemenetekből” és „kimenetekből” áll. A „kimenetek” közvetlen analógja a pénztárcájában lévő számlák: minden „kimenetnek” van valamilyen címlete. Amikor fizetsz valakinek (tranzakciót formálsz), egy vagy több „outputot” költesz el, ebben az esetben ezek a tranzakció „bemenetei” lesznek, és a blokklánc elköltöttként jelöli meg. Ebben az esetben az Ön kifizetésének címzettje (vagy Ön maga, ha változtatásra van szüksége) megkapja az újonnan generált „kimeneteket”. Ezt sematikusan így ábrázolhatjuk:
A számlaalapú blokkláncok felépítése hasonló az Ön bankszámlájához. Csak a számláján lévő összeggel és az átutalás összegével foglalkoznak. Amikor átutal egy bizonyos összeget a számlájáról, nem éget el semmilyen „kimenetet”, a hálózatnak nem kell emlékeznie arra, hogy melyik érmét költötte el és melyiket nem. A tranzakció ellenőrzése a legegyszerűbb esetben a feladó aláírásának és az egyenlegén lévő összeg ellenőrzéséből áll:
A technológia elemzése
Ezután arról fogunk beszélni, hogy a Zether hogyan rejti el a tranzakció összegét, címzettjét és feladóját. A működési elvek ismertetése során észrevesszük a bizalmas és névtelen változat eltéréseit. Mivel a fiókalapú blokkláncokban sokkal könnyebb a titoktartást biztosítani, az anonimizálás által támasztott korlátozások egy része nem lesz releváns a technológia bizalmas verziója szempontjából.
Egyenlegek és átutalási összegek elrejtése
Egy titkosítási sémát használnak az egyenlegek titkosítására és az összegek átutalására a Zetherben
ahol C - titkosított mennyiség, D - az összeg megfejtéséhez szükséges segédérték, G - egy fix pont az elliptikus görbén, ha megszorozzuk a titkos kulccsal, a nyilvános kulcsot kapjuk.
Amikor Bob megkapja ezeket az értékeket, egyszerűen hozzáadja őket a titkosított egyenlegéhez ugyanúgy, ezért ez a séma kényelmes.
Hasonlóképpen, Alice ugyanazokat az értékeket vonja le az egyenlegéből, csak mint Y nyilvános kulcsát használja.
A címzett és a feladó elrejtése
A „kimenetek” keverése az UTXO-ban a kriptovaluták korai napjaira nyúlik vissza, és segít elrejteni a küldőt. Ehhez maga a küldő az átutalás során véletlenszerű „kimeneteket” gyűjt össze a blokkláncban, és összekeveri azokat a sajátjával. Ezután aláírja a „kimeneteket” egy gyűrűs aláírással – egy kriptográfiai mechanizmussal, amely lehetővé teszi számára, hogy meggyőzze a hitelesítőt arról, hogy a küldő érméi jelen vannak az érintett „kimenetek” között. Magukat a kevert érméket természetesen nem költik el.
Nem tudunk azonban hamis kimeneteket generálni a címzett elrejtésére. Ezért az UTXO-ban minden „kimenet” egyedi címmel rendelkezik, és kriptográfiailag kapcsolódik ezen érmék címzettjének címéhez. Jelenleg nincs mód az egyedi kimeneti cím és a fogadó cím közötti kapcsolat azonosítására a titkos kulcsok ismerete nélkül.
A fiók alapú modellben nem használhatunk egyszeri címeket (különben már „kilépési” modell lesz). Ezért a címzettet és a feladót össze kell keverni a blokklánc többi fiókjával. Ebben az esetben egy titkosított 0 érmét vonnak le a vegyes számlákról (vagy 0-t adnak hozzá, ha a címzett vegyes), anélkül, hogy ténylegesen megváltoztatná a valós egyenlegüket.
Mivel mind a feladónak, mind a címzettnek mindig van állandó címe, szükségessé válik ugyanazon csoportok keverése az azonos címekre történő átvitelnél. Könnyebb ezt egy példán keresztül szemlélni.
Tegyük fel, hogy Alice úgy dönt, hogy hozzájárul Bob jótékonysági szervezetéhez, de inkább azt szeretné, ha az átutalás névtelen maradna egy külső szemlélő számára. Aztán, hogy a küldő mezőbe álcázza magát, Ádám és Adél fiókjába is belép. Bob elrejtéséhez pedig adja hozzá Ben és Bill fiókját a címzett mezőbe. A következő közreműködéssel Alice úgy döntött, hogy Alex és Amanda mellé ír, Bruce és Benjen pedig Bob mellé. Ebben az esetben, amikor a blokkláncot elemezzük, ebben a két tranzakcióban csak egy egymást metsző résztvevőpár van - Alice és Bob, amely anonimizálja ezeket a tranzakciókat.
Tranzakciós versenyek
Ahogy már említettük, a felhasználó egyenlegének elrejtéséhez a számlaalapú rendszerekben titkosítja egyenlegét és az átutalás összegét. Ugyanakkor bizonyítania kell, hogy a számláján lévő egyenleg nem negatív. A probléma az, hogy a tranzakció létrehozásakor a felhasználó igazolást készít az aktuális számla állapotáról. Mi történik, ha Bob egy tranzakciót küld Alice-nek, és azt elfogadják, mielőtt Alice küldte volna? Ekkor Alice tranzakciója érvénytelennek minősül, mivel az egyensúlyi igazolás Bob tranzakciójának elfogadása előtt készült.
Ilyen helyzetben az első döntés a számla lefagyasztása a tranzakció végrehajtásáig. De ez a megközelítés nem megfelelő, mert amellett, hogy egy ilyen probléma elosztott rendszerben történő megoldása bonyolult, egy névtelen sémában nem lesz egyértelmű, hogy kinek a fiókját kell blokkolni.
A probléma megoldására a technológia szétválasztja a bejövő és kimenő tranzakciókat: a kiadások azonnali hatást gyakorolnak a mérlegre, míg a bevételek késleltetett hatást fejtenek ki. Ehhez bevezetik a „korszak” fogalmát - egy rögzített méretű blokkok csoportját. Az aktuális "korszakot" úgy határozzuk meg, hogy a blokk magasságát elosztjuk a csoport méretével. A tranzakció feldolgozása során a hálózat azonnal frissíti a küldő egyenlegét, és a címzett pénzeszközeit egy tárolótartályban tárolja. A felhalmozott pénzeszközök csak akkor állnak a kedvezményezett rendelkezésére, ha egy új „korszak” kezdődik.
Ennek eredményeként a felhasználó küldhet tranzakciókat, függetlenül attól, hogy milyen gyakran érkezik pénz (természetesen amennyire egyenlege megengedi). A korszak méretét az határozza meg, hogy milyen gyorsan terjednek a blokkok a hálózaton, és milyen gyorsan lép be egy tranzakció a blokkba.
Ez a megoldás jól működik a bizalmas átutalásoknál, de az anonim tranzakcióknál, mint később látni fogjuk, komoly problémákat vet fel.
Replay támadások elleni védelem
A számlaalapú blokkláncokban minden tranzakciót a küldő privát kulcsa ír alá, amely meggyőzi az ellenőrzőt arról, hogy a tranzakciót nem módosították, és a kulcs tulajdonosa hozta létre. De mi van akkor, ha egy támadó, aki az átviteli csatornát hallgatta, elkapja ezt az üzenetet, és pontosan ugyanazt a másodikat küldi? A hitelesítő ellenőrzi a tranzakció aláírását és megbizonyosodik annak szerzőjéről, és a hálózat ismét leírja a feladó egyenlegéről ugyanazt az összeget.
Ezt a támadást replay támadásnak nevezik. Az UTXO modellben az ilyen támadások nem relevánsak, mivel a támadó megpróbálja felhasználni az elhasznált kimeneteket, ami önmagában nem érvényes, és a hálózat elutasítja.
Ennek megakadályozására egy véletlenszerű adatokat tartalmazó mezőt építenek be a tranzakcióba, amelyet nonce-nek vagy egyszerűen „sónak” neveznek. A sót tartalmazó tranzakció újbóli benyújtásakor az ellenőrző megvizsgálja, hogy a nonce-t korábban használták-e, és ha nem, akkor érvényesnek tekinti a tranzakciót. Annak érdekében, hogy ne tárolja a felhasználói nonces teljes előzményét a blokkláncban, általában a legelső tranzakcióban nullára állítják, majd eggyel növelik. A hálózat csak azt tudja ellenőrizni, hogy az új tranzakció nonce-je egyenként eltér-e az előzőtől.
Az anonim átviteli sémában felmerül a tranzakciós nonces érvényesítésének problémája. Nem köthetjük kifejezetten a nonce-t a feladó címéhez, mivel ez nyilvánvalóan anonimizálja az átvitelt. Nem adhatunk hozzá egyet az összes részt vevő fiók nonces-eihez, mivel ez ütközhet más feldolgozott átutalással.
A Zether szerzői azt javasolják, hogy a nonce-t kriptográfiailag állítsák elő, a „korszaktól függően”. Például:
Itt x a küldő titkos kulcsa, és Gepoch — egy további generátor az epochához, amelyet egy „Zether +” formátumú karakterlánc kivonatolása révén kapunk. Most a probléma megoldódni látszik - nem fedjük fel a küldő nonce-jét, és nem avatkozunk bele a nem érintett résztvevők non-segélyeibe. Ez a megközelítés azonban komoly korlátot támaszt: egy számla legfeljebb egy tranzakciót küldhet „korszakonként”. Ez a probléma sajnos továbbra is megoldatlan, és jelenleg a Zether névtelen verziója véleményünk szerint aligha alkalmas a használatra.
A nulla tudás bizonyításának összetettsége
Az UTXO-ban a küldőnek bizonyítania kell a hálózat felé, hogy nem költ el negatív összeget, különben levegőből lehet új érméket generálni (miért lehetséges, azt írtuk az egyik korábbi
A fiókalapú blokklánc névtelen változatában a bizonyítás kifejezései sokkal összetettebbek. A feladó bizonyítja, hogy:
- A küldött összeg pozitív;
- Az egyenleg nem negatív;
- A feladó helyesen titkosította az átutalási összegeket (beleértve a nullát);
- Az egyenleg egyenlege csak a feladó és a címzett esetében változik;
- A küldő birtokolja a fiókjához tartozó privát kulcsot, és ténylegesen szerepel a feladók listáján (az érintettek között);
- A tranzakcióban használt Nonce helyesen van összeállítva.
Egy ilyen összetett bizonyításhoz a szerzők keveréket használnak
Az eredmény?
Véleményünk szerint a Zethernek az a része, amely az adatvédelmet hozza a fiókalapú blokkláncokhoz, már most használható. Jelenleg azonban a technológia névtelen verziója komoly korlátozásokat támaszt a használatára, és a megvalósítás bonyolultságára. Nem szabad azonban figyelmen kívül hagyni, hogy a szerzők csak néhány hónapja adták ki, és talán valaki más talál megoldást a ma fennálló problémákra. Hiszen így készül a tudomány.
Forrás: will.com