EIP-7503: Zéró tudású féreglyukak privát Ethereum-tranzakciókhoz

Az EIP-7503: Zero-Knowledge Wormholes egy Ethereum fejlesztési javaslat (EIP), amely bevezet egy mechanizmust a magánélet védelmét megőrző átvitelek végrehajtására az Ethereumon. Noha sok erőfeszítést tapasztaltunk a láncon belüli átutalások priváttá tételére, beleértve a kriptovaluta keverőket, például a Tornado Cash-t, az EIP-7503 egy protokollrétegű megoldás, amely alapértelmezés szerint priváttá teszi az Ethereumot.

Ez fontos szempont: az adatvédelem alkalmazási szintű megközelítései, mint például a Tornado Cash, „opt-in” jellegűek, ami gyakran negatív hatással van a felhasználókra. Az adatvédelemre fókuszáló alkalmazások is jobban ki vannak téve a cenzúrának; Például sok felhasználó (különösen az Egyesült Államok állampolgárai) nem tudott kommunikálni a Tornado Cash-sel, miután az Office of Foreign Assets Control (OFAC) 2022-ben feketelistára tette a protokoll szerződési címeit .

Az OFAC szankciói ellenére a Tornado Cash több okból is fut:

1. A Tornado Cash eszközkeverési funkcióját megvalósító alapszerződések megváltoztathatatlanok és állandóan a láncban tárolódnak. Mivel a fő tornádó.készpénz A webhely offline állapotba került, a független projektek újra felhasználták az eredeti Tornado Cash implementációból származó szerződéskódot új változatok létrehozásához, mint pl Tornado Cash Nova .
2. A Tornado Cash protokoll többnyire „nem irányítható”. A Tornado Cash alapítócsapata ezt követően eltávolította az adminisztratív ellenőrzéseket vészhelyzeti frissítés végrehajtása egy olyan hiba kijavítására, amely lehetővé tette volna a támadók számára, hogy érvényes bizonyítékokat készítsenek a hamis betétekről, és elszívják a (legálisan elhelyezett) pénzeszközöket. Így az alapító csapat nem tudta egyoldalúan aktiválni a killswitchet, és nem lehetett rákényszeríteni, hogy „kapcsolja ki” a protokollt. letartóztatás 2023 .

A fent említett tényezők azt jelentik, hogy az emberek még ma is használhatják a Tornado Cash-t, még akkor is, ha az elemzések azt sugallják, hogy az Ethereum blokkgyártói elvetik azokat a tranzakciókat, amelyek kölcsönhatásba lépnek a protokoll szerződéseivel . Csakúgy, mint az OFAC szankció előtti napokban, nem minden, a Tornado Cash mixer protokollon keresztül irányított tranzakció volt legitim. Az Arkham Intelligence egyik cikke szerint 2023-ban legalább két nagy horderejű támadást (az Euler Finance 197 millió dolláros kizsákmányolása és az Anubis DAO 60 millió dolláros szőnyeghúzása) vagy a Tornado Cash-ből kivont pénzeszközökből finanszíroztak, vagy a keverőt használták az ellopott tárgyak tisztára mosására. pénzeszközöket és elrejteni a kimenő átutalásokat.

Tekintettel arra, hogy a Tornado Cash nem oldotta meg a rossz szereplők problémáját, akik visszaélnek a láncon belüli adatvédelemmel, miért akarnánk bevezetni egy olyan funkciót, amely protokollszintű privát transzfereket hajthat végre? Nem kockázatos ? Miért van szükség egyáltalán magánügyletekre? Az Ethereumhoz hasonló blokkláncok már nem névtelenek és „nyomon követhetetlenek”?

Ezek mind jogos kérdések, amelyeket ebben a cikkben tárgyalunk. Magas szintű áttekintést adunk a pénzügyi adatvédelem fontosságáról, és megvizsgáljuk, hogy az olyan nyilvános blokkláncok, mint az Ethereum, miért nem tudják garantálni az adatvédelmet változtatások nélkül. Ezután elemezzük az EIP-7503 megközelítését a privát fizetések Ethereumon történő engedélyezésére, és megvitatjuk az EIP-7503 alkalmazásának lehetséges előnyeit és hátrányait.

Merüljünk el!

A színpad beállítása: Miért törődjünk a láncon belüli adatvédelemmel?

Amikor „privát tranzakciókról” vagy „névtelen tranzakciókról” beszélünk az elektronikus peer-to-peer (P2P) fizetések kontextusában, akkor két tulajdonságot írunk le: a nyomon követhetőséget és az összekapcsolhatóságot . Mindkét tulajdonságot Nicolas van Saberhagen ismerteti a CryptoNote fehér könyvében :

• Nyomon követhetetlen : A tranzakció nyomon követhetetlen, ha a küldőt külső megfigyelő nem tudja megbízhatóan azonosítani. Tegyük fel, hogy Alice barátságban áll Bobbal és Carollal, és Alice két tokent kap egy átutaláson keresztül – a követhetetlenség azt jelenti, hogy senki sem tudja megmondani, ki (Bob vagy Carol) küldte a tokent Alice-nek.

• Unlinkable : A tranzakció nem kapcsolható össze, ha a címzettet külső megfigyelő nem tudja megbízhatóan azonosítani. Ha Bob és Carol külön tranzakciókban küldenek tokeneket Alice-nek, a szétválaszthatóság azt jelenti, hogy senki sem tudja megmondani, hogy Bob és Carol ugyanannak a személynek küldtek-e tokent.

  
  

A legtöbb (ha nem az összes) láncon belüli adatvédelmi megoldás kategorizálható aszerint, hogy a fent említett követelmények közül melyiknek tesznek eleget. A kriptovaluta keverők , a CoinJoin és a gyűrűs aláírások elsősorban a címek küldésével kapcsolatos információk elrejtését és a pénzeszközök nyomon követhetetlenné tételét szolgálják. A feladó személyazonosságát különböző mechanizmusok segítségével védik, de bárki láthatja, hogy ki kapta az összeget.

Összehasonlításképpen, az adatvédelmi központú protokollok, mint például a Monero , a Zcash , a Liquid Network és az Aztec v1 „védett” vagy „bizalmas” tranzakciókat kínálnak, és garantálják a tranzakciók összekapcsolhatóságát. Egy védett vagy bizalmas tranzakciót nehéz egy adott címzetthez kapcsolni, mivel a címzett címének részleteit (valamint az átadott token mennyiségét és típusát) titokban tartják. A lopakodó címek egy másik megközelítés az összekapcsolhatatlanság megőrzésére: a felhasználók egy átmeneti (rövid életű) címet generálnak a betéthez, blokkolva a két átutalás ugyanarra a címre történő összekapcsolására irányuló kísérleteket.

A tranzakciós adatvédelem javítását célzó, fent említett megközelítéseknek egyedi erősségei és gyengeségei is vannak, amelyeket később röviden megvizsgálunk. De most egy alapvető kérdésre irányítjuk figyelmünket: „Miért számít egyáltalán a pénzügyi adatvédelem?” Mivel időt és energiát áldozunk egy olyan javaslat elemzésére, amely a privát és névtelen tranzakciók Ethereumhoz való eljuttatását célozza, mi is lefektethetjük a tranzakciós adatvédelem Ethereumon történő engedélyezésének indokait.

A pénzügyi adatvédelem fontos, mert a magánélet alapvető emberi jog . A magánélethez való jog minden egyént feljogosít annak eldöntésére, hogy milyen információkat kíván nyilvánosan megosztani, és megőrzi az ellenőrzést a személyazonosításra alkalmas információk (PII) megosztása felett, hogyan, mikor és hol. A „személyazonosításra alkalmas adatok” egy tág kategória, amely magában foglal minden olyan információt, amely felhasználható az egyén kilétének feltárására – beleértve a pénzügyi tevékenységek részleteit (pl. vásárlási előzmények, elektronikus átutalások és bevételek).

Az alábbiakban néhány példa látható arra, hogyan gyakorolhatják az egyének a (pénzügyi) magánélethez való jogukat:

• Fogamzásgátló online vásárlása anélkül, hogy a család megkérdezné, miért nem szeretné növelni a létszámot a jövő évi hálaadáskor. Képzeld el, hogy a bankok információkat adtak ki az online tranzakciókról, hogy Beth nagyi tudta, Cheryl aktívan megfosztja őt az unokáktól. Mennyire kínossá válnának a dolgok?
• Adományozás jótékonysági szervezetnek anélkül, hogy nyilvánosságra hozta volna, hogy mennyit adományozott, vagy hogy egyáltalán adományozott-e. Ez akkor fontos, ha olyan jótékonysági célra adományoz, amely bizonyos körökben még mindig felvonja a szemöldökét – vagy utál előadást tartani, és (feleslegesen) felhívni a figyelmet jótékonysági tevékenységeire.
• Adományozás olyan politikai cél érdekében, amellyel nem akar nyilvános kapcsolatban lenni. Vegyük például Vitalik Buterint (eredetileg Oroszországból), aki az orosz invázió ellen harcoló ukrán erőknek adományozott – Vitalik állampolgárságára tekintettel egy nyilvános adomány valószínűleg szükségtelen PR-válságot váltott volna ki, ezért a forrásokat a Tornado Cash-en keresztül küldték el .
• Fizetés anélkül, hogy pénzügyi helyzetének részleteit rossz szereplők elé tárná. Nem akarja, hogy valaki tudja, hogy X dollár bruttó bevételt keresett tavaly, ami elegendő információt ad ahhoz, hogy tervet készítsen a pénz ellopására (pl. csalások és más szociális tervezési taktikák révén).
• Az alkalmazottak fizetése anélkül, hogy nyilvánosságra hoznák az alkalmazottak keresetére vonatkozó információkat. Lehet, hogy inkább titokban szeretné tartani a cége pénzügyi tevékenységeinek adatait, vagy az alkalmazottai ezt az információt szeretnék titokban tartani.

Ezek a példák gyakorlati példákat mutatnak be a pénzügyi adatvédelemre vonatkozóan, de rávilágítanak egy olyan részletre is, amelyet az adatvédelmi jogok kritikusai gyakran nem vesznek tudomásul: úgy gondoljuk, hogy a magánélet nem olyan dolog, amire szükségünk van, amíg már túl késő. A szokásos „mit titkolsz?” A retort nem ismer el bizonyos helyzeteket, amikor az érintett felek kevés információt akarnak kiszivárogtatni egy pénzügyi tranzakcióról. És még ha az emberek önkényes okokból el akartak is titkolni dolgokat, miért zavarná őket, feltéve, hogy titoktartási vágyuk nem veszélyezteti a közegészséget és a közbiztonságot?

Jobb, ha van, és nem kell, mint kell, és nincs. – Franz Kafka

Az Ethereum adatvédelmi problémájának megoldása az EIP-7503 segítségével

A támogatók és a kritikusok korai leírásaival ellentétben az olyan nyilvános blokkláncok, mint az Ethereum és a Bitcoin, távolról sem névtelenek vagy privátak. Ezt a két kifejezést gyakran összekeverik, de két különböző dolgot jelentenek:

• Az adatvédelem azt jelenti, hogy titkos cselekedetei visszavezethetők nyilvános személyazonosságára, de cselekedeteinek részletei rejtettek. Tegyük fel, hogy egy PGP ( Pretty Good Privacy ) eszközzel titkosított e-mailt küld: a levelezőszerverek tudják, hogy egy másik (azonosítható) félnek küldött egy e-mailt, de nem tudják elolvasni az e-mail tartalmát. Ez egy titkos művelet, mert a címzetten kívül senki más nem tudja, hogy e-mailt küldtél.

• Az anonimitás azt jelenti, hogy nyilvános tevékenységei el vannak választva nyilvános identitásától. Az előző példával élve: egy hipotetikus, peer-to-peer névtelen e-mail szolgáltatás elhomályosíthatja egy titkosított e-mail eredetét és célját, miközben nyilvános nyilvántartást vezet a hálózaton keresztül továbbított összes e-mailről. Ez egy nyilvános művelet, mivel az e-mail küldésről szóló rekordot a hálózat minden résztvevője láthatja, de az e-mail címek hash karakterláncok ( 0xdeadbeef ), nem pedig nevek ( [email protected] ).

  
  

Az Ethereum nem privát, mivel a blokklánc minden tranzakcióról nyilvántartást vezet, beleértve az átutalt összeget és a tranzakció által végrehajtott láncon belüli műveleteket. Az Ethereum sem névtelen, mert a blokkláncon tranzakciókat folytató fiókokról szóló információk ( címekkel azonosítva) nyilvánosak. Nem használhat valódi nevet, például „Alice Hopkins” az Ethereum-fiókjához, de ha minden tranzakcióhoz ugyanazt a címet használja, a blokklánc kriminalisztika lehetővé teszi, hogy a tranzakciókat az Ön valós személyazonosságával korrelálja – olyan technikák használatával, mint az IP-címek megfigyelése , a címcsoportosítás és a grafikon. elemzés .

Az Ethereumot ezért pontosan álnévként írják le, és nem garantálja az anonimitást vagy a magánélet védelmét. Ami rossz egy olyan platform számára, amely várhatóan a jövőbeli értékinternet rendezési rétegévé válik. A kontextusban a bankok bizonyos szintű adatvédelmet biztosítanak a felhasználók számára azáltal, hogy a pénzügyi adatokat központi adatbázisokban tárolják, szigorú hozzáférés-ellenőrzési mechanizmusokkal az illetéktelen hozzáférés megakadályozása érdekében.

Ez „ál-adatvédelem”, mivel a bank és az adatbázis-infrastruktúra szolgáltatója hozzáfér ezekhez az információkhoz, és bármit megtehet vele (pl. bizonyos országokba irányuló kifizetések lefagyasztása, hogy az átutalás célpontjának elemzése alapján megfeleljenek a szankcióknak). De a „válasszon az ördög és a mélykék tenger között” klasszikus esetben az átlagos egyén valószínűleg bizonyos magánéletet választ a magánélet hiánya helyett, ami kizárja, hogy Ethereum-fiókot nyisson, és minden láncon belüli művelet látható legyen a világ számára.

Sokan felismerték ezt a problémát, különösen azért, mert az olyan decentralizált technológiáktól, mint az Ethereum, a központosított megoldások felé tereli a felhasználókat, amelyek valamivel jobb adatvédelmi garanciákat kínálnak a cenzúrával szembeni ellenállás és az átláthatóság rovására (többek között). Vitalik The Three Transitions című műve például remek érvet nyújt a magánélet fontossága mellett az Ethereum tömeges elfogadása szempontjából:

A harmadik [átállás a magánélet védelmét megőrző átvitelekre] nélkül az Ethereum kudarcot vall, mert az összes tranzakció (és a POAP-ok stb.) nyilvánosan elérhetővé tétele szó szerint bárki számára túl nagy adatvédelmi áldozatot jelent sok felhasználó számára, és mindenki a központosított megoldásokra tér át, legalább valamennyire elrejti az adatait. - Vitalik Buterin

Az EIP-7503 a korábban leírt problémák némelyikének orvoslására törekszik, különösen a tranzakciók küldőinek névtelenségének hiányára. A javaslat olyan eszközt vezet be a címek számára, amelyek célja az Ether (ETH) szándékos megsemmisítése azáltal, hogy pénzt küldenek egy el nem költhető címre , és egy ZK-SNARK igazolást generálnak az el nem költhető címre történő betét hitelesítésére. Ha ez a bizonyíték átmegy az ellenőrzésen, akkor a felhasználó által választott új címre ETH token (amely megegyezik az el nem költhető cím egyenlegével) verésre kerül – megszakítva a kapcsolatot a pénzátutalással érintett küldő és fogadó címek között.

Az EIP-7503 a meglévő adatvédelmi protokollokból kölcsönöz ötleteket az Ethereum adatvédelmi tranzakcióinak biztosításához. A javaslat például megnehezíti a pénzverési tranzakció során kapott pénzeszközök nyomon követését egy adott forrásig azáltal, hogy az ETH-egyenleggel és nulla kimenő tranzakcióval rendelkező Ethereum-címek teljes készletét anonimitás-készletté alakítja. Nem lehet könnyen azonosítani az A címet, amely felelős az ETH elégetéséért, amely B címet a következő tranzakció során újra verte: A lehet egy a több millió cím közül, amelyek egyenlege nem nulla, de nem kezdeményeztek Ethereum-tranzakciót.

Ez hasonló ahhoz az ötlethez, hogy a különböző forrásokból származó pénzeszközöket egyetlen poolba keverjék össze, és lehetővé tegyék a betétesek számára, hogy egy másik cím használatával pénzeszközöket vonjanak ki a poolból. Az EIP-7503 azonban kedvezően hat a kriptovaluta-keverőkhöz, például a Tornado Cash-hez, mivel elfogadható tagadhatóságot biztosít. A valószínű tagadás egy olyan fogalom, amelyet később megvizsgálunk, de egyelőre csak annyit kell tudnia, hogy lehetővé teszi (az EIP-7503 privát átutalást végrehajtó felhasználó) letagadhatja a magántranzakció lebonyolítását.

A valószínű tagadhatóság az EIP-7503 fontos jellemzője, amely megakadályozza, hogy a külső megfigyelők anonimizálják a privát tranzakciók küldőit. Ez megakadályozhatja a Tornado Cash-fiaskó megismétlődését, amelyben bizonyos címek feketelistára kerültek, és korlátozták a hozzáférést a dappokhoz, a központokhoz és a DeFi-protokollokhoz, mivel a láncon belüli kriminalisztika feltárta a Tornado Cash-sel való történelmi interakciókat – még akkor is, ha ezek a számlák kölcsönhatásba léptek a Tornado Cash-sel. jóindulatú okokból (pl. magánadományozás).

Az EIP-7503 más adatvédelmi központú protokolloktól is kölcsönöz, mint például a Zcash és az Aztec v1, kriptográfiai bizonyítékokkal a tranzakciók érvényesítéséhez anélkül, hogy felfedné a tranzakció részleteit. A tranzakciók adatvédelmet megőrző módon történő érvényesítése biztosítja, hogy az Ethereum biztonságosan támogassa a privát átutalásokat anélkül, hogy aláásná a meglévő biztonsági modellt, amely attól függ, hogy a csomópontok elosztott hálózata újra végrehajtja az egyes tranzakciókat annak helyességének megerősítése érdekében. A következő szakaszokban (többek között) megvizsgáljuk, hogyan használja az EIP-7503 a ZK-SNARK-okat a motorháztető alatt, hogy támogassa a privát átutalások biztonságos végrehajtását az Ethereumon.

Figyelmeztetés *: Annak ellenére, hogy megkülönböztetem az adatvédelmet az anonimitástól, a „privát” és a „névtelen” szavakat felváltva használom ebben a cikkben, hogy a dolgok egyszerűek legyenek, és elkerüljük az összetévesztést az olvasók számára, akik hozzászoktak ahhoz, hogy a két fogalom egy és ugyanaz. Ezenfelül az EIP-7503 tartalmazza az anonimitás elemeit (a feladók és a címzettek közötti kapcsolatok megszakítása) és a magánélet védelmét (a jelenlegi javaslat javasolt kiterjesztése lehetővé teszi a felhasználók számára a befizetési és kifizetési összegek elrejtését).*

Az EIP-7503: Zero-Knowledge féreglyukak áttekintése

Magas szinten az EIP-7503 a következőképpen működik:

1. A felhasználók „égetik” az ETH-t egy olyan címre küldve, amelynek egyenlege elkölthetetlen

Egy cím elkölthetetlen, ha senki sem fér hozzá az egyenlegből költő (érvényes) tranzakció aláírásához szükséges privát kulcshoz. Ez hasonló ahhoz, mintha pénzeszközöket küldenénk a nulla címre : a számlának nincs privát kulcsa, így a kapott eszközök visszavonhatatlanok vagy „elégettek”.

A nulla cím a leggazdagabb számla az Ethereumban, több mint 280 millió dolláros token birtoklással. Néhány szerencsétlen felhasználó kivételével, akik véletlenül a nulla címre küldenek pénzt, a nulla címre küldött tokeneket küldő felhasználók túlnyomó többsége vagy szerződést köt (amihez a nulla címet kell beállítani címzettként), vagy szándékosan veszi ezeket a tokeneket. forgalomból.

Az eredeti ERC-20 token szabvány nem határoz meg funkciókat a tokenek készletének csökkentésére, ami azt jelenti, hogy a régebbi tokenek, például a WETH (wrapped Ether) nem tudják biztosítani, hogy a felhasználók kivonják a becsomagolt eszközöket a forgalomból az eredeti letét visszavonása előtt. A WETH tokenek nulla címre történő küldése azonban elkölthetetlenné teszi őket, és a WETH keringő készletének csökkenését szimulálja minden alkalommal, amikor az ETH visszavonásra kerül a WETH burkolószerződésből. Ha kíváncsi arra, hogy a WETH hogyan tart fenn 1:1 arányt a natív ETH-val, ott a válasz.

Az EIP-7503 hasonló mechanizmust használ annak érdekében, hogy a felhasználók egy kis csavarral ETH-t és tokeneket égessenek egy másik címre az Ethereumban. Ahelyett, hogy arra kérné a felhasználókat, hogy egyetlen írási címre küldjenek pénzt, az EIP-7503 megköveteli a felhasználóktól, hogy minden tranzakcióhoz egyedi írási címet hozzanak létre, mielőtt az ETH-t egy másik címre vernék.

2. A felhasználók privát égési igazolást vagy „égési nyugtát” hoznak létre, amely bizonyítja, hogy egy korábbi tranzakció során elégetett bizonyos mennyiségű ETH-t azáltal, hogy elküldi azt egy égési címre.

Az EIP-7503 specifikáció szerint létrehozott (az EIP-7503 specifikáció szerint létrehozott) pénzeszközök elküldése egyenértékű a készpénz féreglyukba dobásával – soha nem lehet visszaszerezni. De egy ZK-SNARK ( Z ero- K nowledge S uccinct A argument of K nowledge) segítségével bebizonyíthatja , hogy ismer valamit, amit a féreglyukba küldtek; innen ered a „zéró tudású féreglyukak” kifejezés.

Az égetés igazolása privát, mert a felhasználónak csak azt kell bizonyítania, hogy el nem költhető A címre küldte a tokeneket anélkül, hogy az A-t nyílt szövegben felfedné. Az égési igazolás generálásához be kell bizonyítani, hogy az írási cím valóban elkölthetetlen. Miért? Ha arra kérik a felhasználókat, hogy égessenek el natív ETH-t, mielőtt új ETH-tokeneket vernének a címzett címére, ez biztosítja mindkét típusú eszköz paritását (értékben és helyettesíthetőségben), ha a felhasználók később pénzt vonhatnak ki az égési címről, a natív ETH és a verett 1:1 arányú kapcsolatról. Az ETH tokenek megszűnnének.

3. A felhasználók ETH tokeneket vernek úgy, hogy privát égési igazolást küldenek be egy teljes csomóponthoz, amely az égési címre utalt letétnek megfelelő összeget ír jóvá a felhasználónak.

Az EIP-7503 egy új tranzakciótípust vezet be az EVM-ben (Ethereum Virtual Machine), amely elfogadja az égetés igazolását és a címzettet bemenetként, és új ETH tokeneket ment a küldő címre, ha a bizonyítást sikeresen ellenőrizték. Annak elkerülése érdekében, hogy ugyanazon égési tranzakció során ETH-t kétszer lehessen verni, minden égetési igazoláshoz egy speciális „semmisítő” érték kapcsolódik a cím használatának nyomon követésére.

Ha az el nem költhető címre küldött ETH-t sikeresen újból verték, a nullifikáló megakadályozza, hogy egy tisztességtelen felhasználó új érvényes égetési igazolást generáljon a korábban a címre küldött pénzeszközökre (pl. kettős pénzverés támadások). Fontos, hogy a nullifikátor azonosítja a használt címet anélkül, hogy a címről információt szivárogna ki egyszerű szövegben.

Ezzel a magas szintű bevezetéssel most belemerülhetünk az EIP-7503 megvalósításának alacsony szintű részleteibe. A következő szakaszok az EIP-7503 megvalósításának legfontosabb részleteit tárgyalják, például:

• Az el nem költhető cím generálása
• Magánégetési bizonyítékok generálása
• Magánégetési bizonyítékok ellenőrzése
• ETH pénzverése magántranszferek címzettjei számára

Elkölthetetlen cím generálása

A szokásos Ethereum-cím a fiók privát kulcsából generált nyilvános kulcs Keccak256-kivonatának első 20 bájtja (a privát kulcs egy emlékeztető vagy kezdő kifejezésből előállított egész szám). Mind a magánkulcsokat, mind a nyilvános kulcsokat az Elliptic Curve Digital Signature Algorithm (ECDSA) segítségével állítják elő. Az ECDSA egy összetett téma (a „komplex” az általam preferált eufemizmus a „sok matematikával rendelkezik”), de itt van néhány forrás – kezdőtől a téma szakértőjéig:

• Egy (Viszonylag könnyen érthető) alapozó az elliptikus görbe kriptográfiához (Cloudflare blog)
• Elliptikus görbe digitális aláírási algoritmus (Wikipédia)
• Elliptikus görbe digitális aláírási algoritmus (Bitcoin Wiki)
• ECDSA: Elliptikus görbe aláírások (Gyakorlati kriptográfia fejlesztőknek)

A nyilvános kulcsot úgy kapjuk meg, hogy a privát kulcsot (amit titkosnak vagy röviden s -nek neveznek) megszorozunk egy speciális G „generátor” értékkel, így új értéket kapunk a pubKey = privKey * G formátumban. A címet úgy állítjuk elő, hogy a nyilvános kulcsot a Keccak256 hash függvényen keresztül futtatjuk, és a hash karakterlánc első 20 bájtját veszik. Álmatematikai jelöléssel a művelet így néz ki: A = K(s * G) , ahol A a cím, s a titkos vagy privát kulcs, és G a generátorpont az elliptikus görbén.

A cím, a nyilvános kulcs és a privát kulcs nagyon különböző célokat szolgál:

• A cím nyilvánosan meg van osztva, és azonosítja azt a számlát, amelyre a tranzakció során átutalt pénzeszközök kerülnek.
• A privát kulccsal olyan üzenetet írnak alá, amely arra utasítja a hálózatot, hogy vigye át a tokeneket egy cím egyenlegéből, és ezt titokban kell tartani.
• A nyilvános kulcs lehetővé teszi annak ellenőrzését, hogy a tranzakció aláírását a megfelelő privát kulcs generálta-e.

A lista utolsó eleme egy apró részletre mutat rá: csak akkor lehet egy címre küldött pénzt elkölteni, ha Ön kezeli a privát kulcsot – vagyis ismeri azt a privát kulcsot, amelyből a nyilvános kulcsot generálták, amelyből a cím származtatott. Ha nem ismeri egy cím privát kulcsát, vagy a privát kulcsot valaki más irányítja, nem költhet pénzt erről a címről.

Honnan tudhatjuk, hogy egy A cím egyenlege elkölthetetlen? Kezdhetjük azzal, hogy véletlenszerűen választunk ki egy véletlenszerű 20 bájtos A értéket, és kihasználjuk a kriptográfiai hash** függvények egy speciális tulajdonságát, amelyet előkép-ellenállásnak nevezünk. Egyszerűen fogalmazva, az előkép ellenállása azt jelenti, hogy nem találunk olyan x értéket, hogy H(x) ( x hash-je) megegyezzen A val, ha A véletlenszerűen lett kiválasztva. Álmatematikai jelöléssel ez az állítás a következő alakú: H(x) ≠ A .

A a hash képe (a hash függvény kimenete), x pedig a hash függvény előképe (a hash függvény bemenete). Az x értékének megtalálása H(x) = A esetén nehéz, mivel (a) a lehetséges egész számok puszta száma (b) az a mód, ahogyan a bemeneteket egy hash függvény manipulálja kimenet létrehozása érdekében. Így az egyetlen módja annak, hogy „kitaláljon” egy olyan értéket x számára, amely A eredményez, az az, ha óriási számítási teljesítménnyel és elegendő idővel rendelkezik ahhoz, hogy rengeteg számításon végigfusson H(x) = A megállapításához.

Bár ez nem az Ön Cryptography 101 osztálya, az előző magyarázat a modern kriptográfiai rendszerek egyik kulcsfontosságú tulajdonságát ragadja meg. A hash függvények előkép-ellenállási tulajdonsága szintén kulcsszerepet játszik az EIP-7503-ban: ha A véletlenszerű 20 bájtos érték, akkor ésszerűen biztosak lehetünk abban, hogy a felhasználó nem tudja levezetni a privát kulcsot , s nem tud pénzt költeni a címből. Azaz lehetetlen kiszámítani A = H(h(s * G) , ahol A az égési cím, s a privát kulcs vagy titkos kulcs, és G a generátor pont (kis megjegyzés: k(s * G) egyenértékű az előző bekezdés x jével).

Ez a stratégia azonban nem teljesen bolondbiztos. Például hogyan állapíthatjuk meg, hogy A valóban véletlenszerű, és nem s * G kiszámításának eredménye? Ha egy felhasználó önállóan választja A , akkor vagy megbíznunk kell a felhasználóban, vagy összetett eljárásokat kell kidolgoznunk annak ellenőrzésére, hogy A véletlenszerűen lett-e kiválasztva; Ha A választjuk, nem kell megbíznunk egy felhasználóban – de nem elhanyagolható a valószínűsége annak, hogy valaki szerencsét hoz és helyesen kitalálja x . Mivel x = s * G , ez a tudás lehetővé teheti a felhasználó számára, hogy az s privát kulcsot származtassa és költse el a feltételezetten el nem költhető címből.

Ez nyilvánvalóan szuboptimális, és rávilágít arra, hogy biztonságosabb mechanizmusra van szükség az el nem költhető címek generálására. Szerencsére a kriptográfiai hash függvényeknek van egy másik tulajdonsága, amelyet kihasználhatunk: ütközésállóság . Egyszerűen fogalmazva, az ütközésállóság azt jelenti, hogy nem találja H(x) = H(y) , ahol x és y különböző bemenetek – vagyis a különböző bemeneti értékekhez tartozó hash-ek kiszámítása nem „ütközhet”, és ugyanazt az eredményt eredményezheti.

Az ütközésállóság fontos a hamisítás megelőzése érdekében (többek között): két embernek, aki két különböző bemenetet hashel, mindig eltérő hash karakterlánca lesz, és nem lehet azt állítani, hogy a csak a másik személy által ismert bemenet birtokában van. Az ütközésállóság másik változata az, hogy nem található H1(x) = H2(x) , ahol H1 és H2 különböző hash függvénycsaládokból származik. Más szavakkal, az x kivonatának kiszámítása különböző kivonatolási algoritmusokkal nem „ütközhet”, és nem juthat ugyanarra a kimenetre.

Hogy megértsük, miért lehetséges ez, egy kitalált példát készítünk, amely elmagyarázza a hash függvények működését.

Közjáték: Kriptográfiai hash függvények noobokhoz

Egy kitalált példával elmagyarázzuk, hogyan működnek a kriptográfiai hash-függvények, és milyen fontos tulajdonságok garantáltak, mint például az ütközésállóság és a kép előtti támadásokkal szembeni ellenállás. Ez a magyarázat azonban a rövidség és a hozzáférhetőség kedvéért túlságosan leegyszerűsít bizonyos fogalmakat (ha törekvő kriptográfus vagy, olvass el egy cikket a hash függvényekről):

Alice, Bob, Cheryl és Max a rivális politikai pártokhoz tartoznak: Alice és Bob a Kék Párt tagjai, míg Cheryl és Max a Vörös Párthoz tartoznak. A Blue Party és a Red Party munkatársai meg akarják osztani egymással az információkat anélkül, hogy érzékeny részleteket szivárogtassanak ki a rivális párt tagjainak, és egymástól függetlenül különböző kódokat dolgoznak ki az üzenetek titkosításához.

A Blue Party kódja Double Letter algoritmus néven ismert, míg a Red Party a Triple Letter Algorithm nevű változatát használja. A kód nagyon egyszerű: az ábécét számokra cseréljük az üzenetek írásakor – az üzenetfüzérben minden szám az ábécé egy adott helyén lévő betűre utal. A „titkosító” bit abból adódik, ahogyan számokat választunk az ábécé ábrázolására:

• A Blue Party „Double Letter” kódban minden számot elosztunk kettővel, és a kapott szám (n) segítségével megkeressük az ábécé n-edik helyén lévő betűt. Például titkosíthatjuk a „BOY”-t 4-30-50 : 4/2 = 2-ként (a „B” az ábécé 2. betűje); 30/2 = 15 (az „O” az ábécé 15. betűje); Az 50/2 a 25 (az „Y” az ábécé 25. betűje).
• A Red Party „Triple Letter” kódjában minden számot elosztunk hárommal, és a kapott szám (n) segítségével megtaláljuk az ábécé n-edik helyén lévő betűt. Például titkosíthatjuk a „BOY”-t a következőképpen: 6-45-=75 : 6/3 = 2 (a „B” az ábécé 2. betűje); 45/3 = 15 (az „O” az ábécé 15. betűje); 75/3 = 25 (az „Y” az ábécé 25. betűje).

Ez a példa ugyanahhoz az üzenethez titkosítást használ, de arra számíthatunk, hogy a Blue Party és a Red Party emberek a gyakorlatban eltérő üzeneteket fognak váltani (pl. „Max egy bunkó” (Alice → Bob) és „A Blue Party tagjai vesztesek” ( Cheryl → Max) stb.). Mindazonáltal, ugyanazon üzenet titkosítása különböző kódokkal hasznos lehet a kriptográfiai hash függvények ütközésállóságának magyarázatában:

Ha a „BOY”-t a Blue Party „Double Letter” algoritmusával és a Red Party „Triple Letter” algoritmusával titkosítják, az eredmények nagyon eltérőek ( 4-30-50 és 6-45-75 ). A Blue Party tagja nem generálhat 6-45-75 , kivéve, ha a Red Party titkosítási algoritmust használja; a Red Party tagja sem tud 4-30-50 előállítani üzenetsorként, kivéve, ha a Blue Party titkosítási algoritmust használja. Mivel mindegyik fél őrzi a titkosítási algoritmus részleteit, tudjuk, hogy egy rivális párttag nem tud visszafejteni egy olyan üzenetet, amelyet nem nekik szántak.

A kriptográfiai hash függvények eltérnek a titkosítási algoritmusoktól: a kivonatoló függvények egyirányúak , és nem tudnak bemeneteket származtatni a kimenetből, míg a példában szereplő titkosítási algoritmusoknak van egy kulcsa a titkosítási funkció bemeneteinek visszafejtéséhez. De a hash függvényeknek és a titkosítási algoritmusoknak van hasonlósága, különösen az ütközésállóság területén. Ahogyan nem találtuk ugyanazt a kimenetet (titkosított üzenetet) egyetlen bemenethez különböző titkosítási algoritmusok használatával, úgy nem találjuk ugyanazt a kimenetet (kivonatot) egyetlen bemenethez különböző hash-függvények használatával.

A hash függvények ütközésállóságát kihasználva bizonyíthatóan el nem költhető címeket generálhatunk az eszközök elégetéséhez, ahogy azt az EIP-7503 megköveteli. Először is megkérjük a felhasználókat, hogy válasszanak egy titkos s értéket (az Ethereum-fiók privát kulcsát), számítsák ki az s * G Keccak256 hash értékét a nyilvános kulcs származtatásához, és a nyilvános kulcs kivonatolását az A cím származtatásához. Ezután megkérjük a felhasználót, hogy állítson elő egy új B címet úgy, hogy az s titkos értéket kivonatolja egy másik, H- ként jelölő hash-függvénnyel, és a kimenet első 20 bájtját veszi címnek.

A mi célunk? Azt akarjuk elérni, hogy K(x) ≠ H(x) , ahol K a Keccak256 hash függvényt, H pedig egy másik hash függvénycsaládból származó hash függvényt jelöl. Teljesítmény okokból azt akarjuk, hogy H „ZK-barát” legyen (azaz a H(x) eredményének ellenőrzése egy áramkörön belül olcsó és gyors legyen).

Nem tudhatjuk B nyilvános kulcsát, mert a címet véletlenszerűen generálták az s * G Keccak256 hash kiszámítása helyett (magánkulcs szorozva a generátorral), ami azt jelenti, hogy a B privát kulcsa is megismerhetetlen. Ha nem ismerjük B privát kulcsát, akkor nem tudunk érvényes aláírásokat létrehozni egy olyan üzenethez, amely elkölti B egyenlegét. Az el nem költhető címek generálására szolgáló bizonyíthatóan véletlenszerű folyamat révén most lehetőségünk van a felhasználók számára az ETH-t égetni, mielőtt újravertené az eszközöket.

A privát égésigazolás generálása

Hogyan bizonyíthatjuk, hogy egy adott felhasználó elküldte az ETH-t egy el nem költhető címre , és a nem elkölthető címet ez a felhasználó hozta létre? Az első ellenőrzésre azért van szükség, hogy elkerüljük az ETH csalárd verését (nem verünk új ETH tokeneket, hacsak nincs bizonyítékunk arra, hogy a felhasználó korábban égetett ETH-t), de a második ellenőrzés is fontos: tudnunk kell, hogy a címet a felhasználó – ellenkező esetben szükségünk lenne egy információra (pl. a beégési tranzakció hash-ére), hogy megbizonyosodjunk arról, hogy a felhasználó nem próbálja-e követelni egy másik személy letétjét.

Mivel el akarjuk kerülni, hogy egy felhasználó adatvédelmi protokollban való részvételével kapcsolatos információk kiszivárogjanak, lehetővé tesszük a felhasználók számára, hogy ehelyett nulla tudásalapú bizonyítékot hozzanak létre, amely igazolja az s (az írási cím levezetéséhez kivonatolt titkos érték) ismeretét anélkül, hogy nyilvánosan kiadnák az s-t . A zéró tudás bizonyítása azt állítja, hogy a felhasználó ismeri a B címet, amely a H(s) eredményéből származik: mivel az s-t titokban választották ki, egy másik személy nem számíthat ki eltérő H(x) értéket úgy, hogy H(s) = H(s) . Ez a korábban leírt hash függvények ütközésállósági tulajdonságának köszönhető.

Az s elrejtése megakadályozza, hogy a rosszindulatú szereplők beváltsák a felhasználó letétjét azáltal, hogy az EIP-7503 ellenőrzőnek benyújtanak egy bizonyítékot, amely megerősíti az s (el nem költhető cím generálására használt) titkos ismeretét. Ez a rész elmagyarázza, miért tudunk olyan nulla tudású bizonyítást létrehozni, amely bizonyítja, hogy H(s) = A anélkül, hogy az ellenőrzőnek meg kellene számítania H(s) függetlenül. De elolvashatja Vitalik másodfokú aritmetikai programjait: Zero To Hero és a ZK-EVM-ekről szóló cikkemet, hogy megismerje a ZK-SNARK-ok használatát a számítások érvényességének bizonyítására a bemenetek felfedése nélkül.

A nulla tudásalapú igazolást, amely érvényesíti a felhasználó pénzátutalását egy el nem költhető címre (más néven égési cím ), „égés igazolásként” vagy „égési bizonylatként” írjuk le. Az égés bizonyítéka a következő állításokat bizonyítja:

• A felhasználó ismeri az A címet és az s titkos értéket, amelyet kivonatolt az A származtatásához (azaz H(s) = A ). Ez ellenőrzi, hogy a cím el nem költhető-e azáltal, hogy megerősíti, hogy A az s kivonatolás eredménye egy (ZK-barát) hash-függvénnyel, amely különbözik a költhető Ethereum-címek generálására használt Keccak256 hash függvénytől.

• Az A cím pozitív ETH egyenlege egyenlő vagy nagyobb, mint b ( b ≥ b' ). Ez azt ellenőrzi, hogy a felhasználó által a fogadó címre befizetni próbált összeg megegyezik-e az el nem költhető címen elhelyezett összeggel.

  
  

Míg az 1. bizonyítása viszonylag egyszerű, a 2. bizonyításhoz bizonyos dolgokat kell állítani az Ethereum állapotáról. Különösen azt kell bizonyítanunk, hogy (a) a fel nem költhető cím létezik a kanonikus Ethereum trie állapotban , és (b) a fel nem költhető cím követelt egyenlege megegyezik a trie állapotú címhez társított egyenleggel. Ehhez az A címhez Merkle-bizonyítékot kell átadni az égésigazolást generáló áramkör bemeneteként.

A Merkle-bizonyíték a Merkle Patricia Trie (MPT) leveleiből áll, amelyek a bizonyítani kívánt levéltől ( A cím) a Merkle trie gyökeréig vezető útvonal kiszámításához szükségesek (a trie gyökér szintén része a Merkle bizonyíték). Bizonyítékra van szükségünk, hogy az állapotgyökér – amely a Merkle-bizonyítás ellenőrzésére szolgál – szintén kanonikus, ezért megköveteljük a felhasználótól, hogy adjon át egy B blokkfejlécet kiegészítő bemenetként az áramkörbe. Ez az információkészlet lehetővé teszi az erőforrás-korlátozott ellenőrző számára, hogy hatékonyan ellenőrizze, hogy az A cím felvétele az állapotba megpróbálja-e érvényesíteni A b egyenlegét.

Megjegyzés *: Az EIP-7503 specifikáció azt javasolja, hogy származtassa le a Merkle-bizonyítékot, amely szükséges ahhoz, hogy igazolja, hogy az írási cím szerepel az állapotban, és ellenőrizze a cím egyensúlyát az EIP-1186 -ban bevezetett * eth_getProof JSON-RPC módszerrel .

Nullifikátorok generálása címekhez

A ZK-SNARK áramkör másik bemenete, amely egy el nem költhető címre történő letétbe helyezés igazolását állítja elő, egy nullifikátor . A nullifikátor egy olyan érték, amely megakadályozza, hogy a felhasználó ugyanazt az égési bizonyítékot használja az ETH kétszeri mentéséhez. A nullázó nélkül semmi sem akadályozza meg a hozzáértő felhasználót abban, hogy az égetés igazolását többször felhasználja az ETH visszavonására: az EIP-7503 privát átutalásokat feldolgozó csomópont szemszögéből ezek a visszavonások érvényesek, mert az el nem költhető cím egyenlege soha nem csökken ( csak növekedhet).

A nullázó bemenetként kerül átadásra a ZK-SNARK bizonyítási áramkörbe, így az égésigazolás a sikeres ellenőrzés után érvénytelenné válik. Ezt a tulajdonságot úgy érjük el, hogy a (használt) nullifikátort kinyerjük egy bizonyításból, és egy ritka Merkle-fában (SMT) tároljuk. Ellentétben a hagyományos Merkle fákkal, amelyek hatékonyan tudják bizonyítani az elemek beépülését, a ritka Merkle fák hatékonyan bizonyítják az elemek nem tartalmazását . Az SMT-k tárgyalása nem terjed ki, de a korábban linkelt cikk nagyszerű áttekintést nyújt az érdeklődő olvasók számára.

Az SMT ebben az esetben hasznos, mert a ZK-SNARK ellenőrzési eljárásnak csak azt kell ellenőriznie, hogy az SMT kizárja-e az újonnan benyújtott bizonyítékhoz csatolt nullifikátort. Ha a nullázó hiányzik a Sparse Merkle Tree-ből, akkor tudjuk, hogy a felhasználó korábban nem használta ezt az égésigazolást, és egy bizonyíthatóan friss betétet von ki. Hozzáadjuk a használt nullítót az SMT-hez, hogy nyomon kövessük az ETH újraveréséhez használt írási címet anélkül, hogy nyilvánosan felfednénk az égési címet.

Mi történne, ha egyszerűen tárolnánk az égési címeket egy Merkle-fában, és ellenőriznénk, hogy az új beégésigazolásból származó cím nem része a fának, amikor egy új visszavonást feldolgozunk?

A sima írási cím nullifikátorként való használata lehetővé teszi a külső megfigyelők számára, hogy felfedjék a beégetett tranzakció feladóját azáltal, hogy összevetik a cím tranzakciós előzményeit a láncon tárolt égési címek listájával. Miután az égetési cím (elkerülhetetlenül) címzettként megjelenik a küldő által kezdeményezett tranzakciók egyikében, bárki igazolhatja, hogy a számlavezető személy elégette és újraverte az ETH-t.

Az égési (el nem költhető) cím hash-jének használata megnehezíti, de nem kivitelezhetetlen az átutalt pénzeszközök privát módon történő megismerését. Ehhez egy brute-forcing támadásra van szükség, amely kiszámolja az összes jelenleg létező Ethereum-cím kivonatát, amíg az egyik kivonat nem egyezik az SMT-ben tárolt nullifikátorral. Amint a nullifikáló hash előképe (azaz az el nem költhető cím) felfedezésre került, a korábban leírt lépések végrehajthatók annak a számlának a nyomon követésére, amelyről pénzt küldtek a kérdéses, el nem költhető címre.

Ezt a problémát úgy oldhatjuk meg, ha találunk egy biztonságosabb mechanizmust a nullifikátorok generálására. A jelenlegi EIP-7503 specifikációban alkalmazott stratégia ugyanazt a (ZK-barát) hash függvényt használja az N nullifikátor létrehozásához az égési cím kivonatolása révén az s titkos értékkel. Álmatematikai jelöléssel ez így néz ki: N = H(A,s) , ahol A az el nem költhető cím, s pedig az A-t eredetileg generáló titkos érték.

Az s titkos értéket ebben az esetben sóként írjuk le. Ez a sóérték alapvetően megnöveli az égési címekkel kapcsolatos információk nullifikátorokból való kinyerésének nehézségét: ha s ismert, akkor a megfigyelő brute-force támadást hajthat végre, és futtathatná hash(burnaddress,secret) összes lehetséges kombinációját, amelyek egy N nullifikátort eredményeznek lánc. Az s-t azonban a felhasználó titokban tartja, gyakorlatilag kiküszöböli annak lehetőségét, hogy megtalálja a megfelelő égési címet a használt nullifikátorhoz.

A privát égésigazolás ellenőrzése

Most, hogy tudjuk, hogy az égésigazolás milyen állításokat próbál bizonyítani, van egy tisztességes elképzelésünk a bizonyítékellenőrzés működéséről. Az első utasításhoz ( h(s) = A ) az ellenőrzőnek meg kell „értenie” az A cím generálásához használt hash függvény logikáját – így tudja, hogy H(s) valóban egyenlő A-val . A hash függvény logikájának kódolása az ellenőrző áramkörben azt a követelményt is érvényre juttatja, hogy A nem generálható a Keccak256 hash függvényével.

A második állításnál ( A pozitív b ETH egyenlege) a hitelesítőnek ellenőriznie kell egy Merkle-bizonyítékot, amely igazolja A szerepeltetését az Ethereum állapotában, és érvényesíti a számla adatait. Az áramkör-ellenőrző azt is ellenőrzi, hogy a B blokkfejléc a kanonikus láncból származik-e – az állapotgyökér kibontása előtt – a BLOCKHASH műveleti kód meghívásával a block.blockHash(blockNumber) bemenettel, ahol blockNumber a B blokkfejlécre utal. Ha B a kanonikus Ethereum lánc része, akkor a BLOCKHASH műveleti kód által visszaadott hash meg kell egyeznie a B blokkfejléc hashével.

Ezenkívül az ellenőrző áramkör hitelesíti a felhasználó ZK-SNARK bizonyítványában szereplő nullifikátort, és megerősíti, hogy a nullítót korábban nem használták. A kivonatoló függvények ütközésállósága itt támogató szerepet játszik azáltal, hogy megakadályozza, hogy két különböző N1 és N2 nullifikáló hash generáljon ugyanazt az burn address <> secret value kombinációját. Ha egy felhasználó különböző nullifikátorokat generálhat ugyanahhoz a címhez, akkor duplán mentheti az ETH-t – függetlenül attól, hogy a Sparse Merkle Tree tárol-e nullifikátort az adott címhez vagy sem.

Annak biztosítására, hogy a blokkjavaslatot benyújtók ellenőrizhessék az égési bizonyítékokat, az EIP-7503 az EVM módosítását javasolja a ZK-SNARK igazolások támogatási ellenőrzésének megvalósítása érdekében. Az EIP-7503 szerzői tesztelték az égési bizonyítékok EVM-en belüli ellenőrzésének megvalósíthatóságát az EVM EIP7503-kompatibilis verziójának létrehozásával a Polaris EVM keretrendszer használatával. A protokoll kialakításának további részleteiért látogassa meg a projektnek szentelt GitHub-tárat .

ETH pénzverése a címzett címére

Az EIP-7503 egy új tranzakciótípust vezet be, amely ETH-t készít egy olyan felhasználó számára, amely sikeresen bizonyítja, hogy egy meghatározott összeget egy el nem költhető címre helyezett el. A tranzakció feladója benyújt egy ZK-SNARK igazolást (egy nullifikáló mellett), és a hálózat állapotátmenetet hajt végre, amely frissíti a kivonási cím egyenlegét (az égésigazolás ellenőrzése után).

Bár az EIP-7503 elfogadható tagadhatóságot biztosít, a felhasználókat arra biztatjuk, hogy ne fizessenek olyan tranzakciókért, amelyek ugyanarról a címről származnak, amelyről az ETH-t az égési címre küldték. Ha Alice elküldi az ETH-t egy el nem költhető 0xm00la címre, és később beküld egy tranzakciót, amely ugyanannyi ETH-ért fizet, hogy egy külön számlára kerüljön, akkor Bobnak nem kell Jimmy Neutronnak lennie ahhoz, hogy Alice-t az eredeti égési tranzakcióhoz kapcsolja.

Az előző szakaszok nem említik, de a felhasználóknak fel kell tüntetniük a második B címet (amely megkapja az ETH-t a pénzverési tranzakcióból) nyilvános bemenetként a ZK-SNARK prover áramkörbe. Ez megakadályozza, hogy a potenciális szélsőséges esetek a becsületes felhasználók előrébb kerüljenek, miközben a pénzverési tranzakciók a mempoolban várakoznak.

Emlékezzünk vissza, hogy a hitelesítő nem ellenőrzi a küldő cím azonosságát, és szándékosan elkerüli annak a követelményét, hogy megtudja, hogy ugyanaz a cím, amely az ETH-t égette, beváltja-e az ETH-t egy pénzverési tranzakció során. Ez nagyszerű adatvédelmi szempontból, mivel ez azt jelenti, hogy a felhasználók újból létrehozhatják az ETH-t egy frissen generált címmel, de ez növeli az előretörő támadások kockázatát. Mivel a bizonyítvány kódolja az összes szükséges információt az ellenőrzés átadásához (beleértve a titkos érték s ismeretét is), bárki küldhet másolatot verési tranzakciót, amely ugyanazzal az igazolással, de eltérő címmel rendelkezik a vert ETH átvételéhez.

Szerencsére megkövetelhetjük az égésigazoláson a B kivonási cím feltüntetését, és érvényesíthetjük a formai szabályt: „verési ügylet csak az égésigazolásból kivont címre verhet ETH-t”. A ZK-SNARK áramkör nyilvános bemeneteként átadott cím és a pénzverési tranzakcióban megadott cím közötti egyenértékűséget a hitelesítő ellenőrzi. Így minden felhasználó biztos abban, hogy senki sem tudja felvenni a bizonylathordozó tranzakcióját a mempoolból és ellopni a pénzfelvételét.

Miért az EIP-7503? Privát átutalások esete az Ethereumon

Privát átutalások és fizetések

Az EIP-7503 egyszerű módot biztosít az Ethereum-felhasználók számára az alapok mozgatására anélkül, hogy (véletlenül) kapcsolatot hoznának létre a küldő és fogadó címek között. Elküldheti az ETH-t az egyik pénztárcából egy újonnan generált, el nem költhető címre, és kiveheti egy másik pénztárcába, ha ellenőrzés céljából megadja az égésigazolást és a nullítót. Egy külső szemlélő szerint pontosan nulla korreláció van a fiókégető ETH és a számlaverés ETH között.

Ha a felhasználó egy tranzakció során ETH-t éget el, és azonnal új címre menti az ETH-t, egy éles eset jelenhet meg. Az EIP-7503 azonban rendelkezik egy hatékony funkcióval a deanonimizálás megakadályozására: a plausible deniability . Íme a valószínű tagadhatóság meghatározása a Politikai szótárból :

A valószínű tagadás az a képesség, hogy megtagadjuk az illegális vagy etikátlan tevékenységekben való részvételt, mivel nincs egyértelmű bizonyíték az érintettség bizonyítására. A bizonyítékok hiánya hitelessé vagy hihetővé teszi a tagadást. — Politikai szótár

A vélhető tagadás a CIA-műveletek homályos világából ered, ahol a tisztviselők tagadták, hogy előre tudtak volna beosztottak cselekedeteiről. A papírnyom – az események nyilvánosan elérhető feljegyzése – hiánya azt jelentette, hogy a magas rangú tisztviselők megtagadhatták a helyszíni tisztviselőket, és elkerülhették a felelősséget a tisztviselők tevékenységének kimeneteléért (elkerülve a hatalmas PR-katasztrófákat).

A valószínű tagadás hasonló jelentéssel bír az EIP-7503 használatával végzett magánjellegű átutalások kontextusában. Tegyük fel, hogy a „főtárcád” 1,365 ETH-t éget el, a „másodlagos pénztárcád” pedig nem sokkal ezután 1,365 ETH-t. Ha az Ön művelete felkelti a túlbuzgó láncszemek figyelmét, csak azt állíthatja, hogy valaki más vert 1,365 ETH-t, hogy úgy tűnjön, mintha egy privát átutalást hajtana végre.

És mi van, ha olyan kérdést tesznek fel, mint például: „Miért küldenél ETH-t égési címre anélkül, hogy titokban pénzt utalnának át?” Állíthatja, hogy a tranzakció tévedésből történt – elvégre senki sem tagadhatja, hogy isteni iszonyatos mennyiségű ETH-t veszítettek el az emberek, akik elgépelték a címzettek címét (még én is elkövettem ezt a hibát). Ez az egész beszélgetést a feje tetejére állítja, mert ki más, ha nem egy hidegszívű egyén ne érezné át a nagy mennyiségű ETH elvesztését?

Ez egy kissé triviális példa, amely megragadja az EIP-7503 fontosságát: a valószínű tagadhatóság biztosítja, hogy a rendszeres Ethereum-felhasználók magánjellegű átutalásokat hajtsanak végre anélkül, hogy felfednének bármilyen konkrét információt, amely az adatvédelmi protokollban való részvételre utalhatna. Az alkalmazásrétegű adatvédelmi protokolloktól eltérően az EIP-7503 elkerüli a tranzakciós nyomok láncon belüli tárolását, és megnehezíti a beégetett és mentett tranzakciók valós identitásokhoz való társítását.

Az EIP-7503 nem biztosít teljes névtelenséget és adatvédelmet, mivel az égési címre történő pénzátutalással kapcsolatos információkat – beleértve az átutalt összegeket is – rögzítik a láncon. De a kapcsolat megszakítása a címek küldése és fogadása között egy tranzakció során meglehetősen hatékony, és csökkenti a címek újrafelhasználásával kapcsolatos aggodalmakat.

Ahelyett, hogy ugyanazt a címet használná a kifizetések fogadására, a felhasználó létrehozhat egy új címet, és pénzt kérhet erre a címre. Mivel a felhasználó ismeri az s titkos értéket, érvényes beégési igazolást tud generálni, amely bizonyítja az égési cím létrehozásának irányítását a láncon belüli ellenőrző számára, és „kiveheti” a letétet úgy, hogy ETH-t más címre ment. . Ez nagyon hasonlít az átutalások fogadására szolgáló rejtett cím generálására, és csökkenti annak az esélyét, hogy a különböző tranzakciókat ugyanahhoz az entitáshoz korrelálják.

Láthatjuk, hogy az EIP7503-stílusú privát átutalások hogyan lehetnek előnyösek más forgatókönyvekben:

• Kereskedők : Az égetési címeken történő kifizetések elfogadásával, és később az ETH-t nem összekapcsolható kivonási címekre verve, a kereskedők elkerülhetik a pénzügyi információk felfedését. Az EIP-7503 privát tranzakciós funkciója továbbá megakadályozza, hogy a külső megfigyelők olyan részleteket lássanak, mint például, hogy mennyit kap a kereskedő a termékekért, vagy mekkora a kereskedő ügyfélköre.
• Vevők : Ha a kereskedő által megadott égési címre fizetnek (a kereskedő nyilvánosan azonosítható címére történő küldés helyett), a vásárlók elkerülik a vásárlási előzményekhez kapcsolódó információk kiszivárgását. Az égési cím nem hozható összefüggésbe a kereskedő „valódi” számlájával, ami akadályozza annak megtudását, hogy mit vásárolt és kitől.
• Jótékonyság : Jótékonysági és politikai szervezetek anélkül fogadhatnak pénzeszközöket, hogy a küldő személyazonosságát állandóan rögzítenék a láncon. Az egyének adományozhatnak bizonyos célokra anélkül, hogy veszélyeztetnék nyilvános hírnevüket.

Az EIP-7503 nem adatvédelmi okokból is használható:

1. Jelenleg a központosított központoknak (CEX-eknek) egyedi címet kell létrehozniuk ahhoz, hogy befizetést kapjanak a felhasználótól, és olyan tranzakciókat kell küldeniük, amelyek az egyes címek egyenlegét egy vagy több hidegpénztárcába továbbítják a működési biztonsági folyamatok részeként. Az EIP-7503 segítségével a CEX üzemeltető létrehozhat egyetlen égési címet, amely fogadja a betéteket egy sor felhasználótól, és létrehozhat egy leégési igazolást, amely egyetlen tranzakcióval visszavonja az égési címen felhalmozott összes betétet a hideg pénztárcába. A CEX-betétek hidegtárcában történő konszolidálásához szükséges tranzakciók számának csökkentése előnyös a CEX-üzemeltetőnek (csökkentett működési költségek) és a hálózatnak (kevesebb a láncon belüli tranzakciók száma).
2. Bármely entitás, amely jelentős mennyiségű fizetést dolgoz fel a láncon, kihasználhatja az EIP-7503-at a működési hatékonyság javítása érdekében – így nem a CEX-ek az egyedüli kedvezményezettek. A kereskedők, a jótékonysági szervezetek és a kripto-natív fizetési sínek néhány példája azoknak a szervezeteknek, amelyek az EIP-7503-at használják a működési költségek csökkentésére azáltal, hogy a betéteket égetési címeken összesítik, és a tranzakciós költségeket több betétre osztják fel. Az EIP-7503 ezen aspektusa azzal a kívánt mellékhatással jár, hogy pénzügyi ösztönzőket hoz létre az anonimitási csoporthoz való csatlakozáshoz, és növeli a magán átutalásokat végző fiókok általános adatvédelmét.

Az adatvédelem egyensúlya a közüzemi szolgáltatásokkal és a szabályozási megfeleléssel

Az EIP-7503 egyszerű utat biztosít a tranzakciós adatvédelem Ethereumon történő rögzítéséhez anélkül, hogy a protokollon alaposan módosítani kellene. Az EIP-7503 különösen lehetővé teszi az Ethereum számára, hogy tranzakciós adatvédelmet biztosítson anélkül, hogy problémákkal kellene szembenéznie más, az adatvédelemre fókuszáló blokkláncokkal, mint például a Zcash és a Monero.

Bár korábban írtam az adatvédelmi érmék védelmében , nem kell sok ahhoz, hogy belássuk, az olyan adatvédelmi érmék, mint a ZEC (Zcash) és az MNR (Monero), nem tudják elérni azt a célt, hogy decentralizált, magánjellegű és használható pénzt vezessenek be a globális gazdaságba. . Mivel a szabályozási nyomás arra kényszeríti a tőzsdéket, hogy távolítsák el az adatvédelmi érméket, a tulajdonosok egyre nehezebben tudják kihasználni a Zcash, a Monero és más, kifejezetten a tranzakciós információk valós környezetben való elrejtésére tervezett protokollok által kínált adatvédelmi előnyöket. Ez a részlet Haseeb QureshiMiért nem vették fel az adatvédelmi érméket című könyvéből, jó bevezetőt ad a „kemény” adatvédelmi projektek mai kihívásaiba:

Az adatvédelmi érmék mindig is a szabályozási inkvizíciók első célpontjai voltak. Amikor a szabályozóknak azt a feladatot kapják, hogy „ne csak álljanak ott, tegyenek valamit”, a legegyszerűbb bók az árnyékos adatvédelmi érmék. Ami a szabályozást illeti, számos adatvédelmi érmét láttunk Dél-Koreában , Japánban és az Egyesült Királyságban. és az USA . A kormányok folyamatosan próbálják megfeszíteni az adatvédelmi érméken a hurkot (lásd itt , itt és itt ).

A kriptolobbik nagyobbra nőttek; hatalmas kiskereskedelmi sávok és sok intézmény ma már birtokolja a BTC-t és az ETH-t. De nagyon kevés intézmény hajlandó a magánélet védelmét szolgáló érmék védelmére kelni. Ahelyett, hogy hagynák, hogy az egész iparág beszennyeződjön, sokan megelégszenek azzal, hogy a magánélet védelmét szolgáló pénzérmék áldozati bárányká váljanak. - Haseeb Qureshi ( Miért nem emelkedtek ki az adatvédelmi érmék )

Az EIP-7503 úgy érzi, hogy éppen a megfelelő pillanatban érkezett az Ethereum fejlődéséhez: több felhasználóval, mint bármely blokklánc, és sok intézményi befektetéssel, az Ethereum kevésbé valószínű, hogy ugyanarra a sorsra jut, mint más projektek, amelyek megpróbálták biztosítani a privát fizetési funkciókat. a múltban. Néhány tőzsde korlátozza-e az Ether kereskedelmét, ha magánkézből verett ETH tokenek kezdenek keringeni? Talán. De egy tucat másik központ túlságosan is szívesen vállalná ezt a felelősséget – így néz ki az erős hálózati hatás .

Miért mondom, hogy az EIP-7503 a megfelelő időben érkezett? Volt idő az Ethereum történetében, amikor mindenki úgy érezte, azonnal meg kell tenni a magánélet védelmét az alaprétegen. De mások a közösségben (jogosan) rámutattak az Ethereum mint „adatvédelmi technológia” népszerűsítésével kapcsolatos lehetséges szélsőséges esetekre. Itt vannak részletek az Ethereum Magicians fórumának egy régi szálából, amely az Ethereum fokozottabb adatvédelmének szükségességét tárgyalja:

Griffith megérzései többnyire helytállóak voltak a következő években, és sok alapértelmezett adatvédelmi kriptovaluta szembesült azzal a lehetőséggel, hogy csak a keményvonalas cypherpunkok (a világ népességének kevesebb, mint 0,00001%-át kitevő csoport) által használt perempénzzé válik. Összehasonlításképpen, az Ether (ETH) értéke és mindenütt jelenléte csak odáig nőtt, hogy az EIP-7503 elfogadásával „az adatvédelmi technológia felé bökdösni” kevésbé kockázatos, mint öt évvel ezelőtt.

Ha frissítést hajt végre a privát átutalások támogatására – talán a fordított szabályozási rögzítés elkerülése vagy az alapréteg bonyolultságának minimalizálása érdekében. Megfelelő alternatíva az EIP-7503 megvalósításának felelősségének áthárítása az Ethereum L2-ekre és L3-okra. Tekintettel az Ethereum összesítés-központú ütemtervére , az EIP-7503 összesítésben való megvalósítása ésszerű, és továbbra is megőrzi az adatvédelem Ethereumban való rögzítésének célját (például hasonlóan az ERC-4337-et a natív fiókabsztrakcióhoz megvalósító összesítéshez).

Az EIP-7503 megvalósításának ez a megközelítése egyszerűbb, mivel minden L2 lánc már rendelkezik hídszerződéssel , amely ETH-t készít az L2 felhasználók számára. Az ETH tokenek verésére szolgáló mechanizmussal a rollupokhoz csak olyan összetevőket kell hozzáadniuk, amelyek a nullifikátorok láncon belüli tárolására és az égési bizonyítékok generálására/ellenőrzésére szolgálnak, hogy támogassák az EIP7503-stílusú privát átvitelt. Példa a 2. rétegű (L2) láncra, amely az EIP-7503-at az infrastruktúrájába integrálni tervezi, a Taiko , amint az ebben a megjegyzéskérésben (RFC) szerepel.

Itt azt látjuk, hogy egy olyan protokoll, mint a Taiko, az EIP-7503 elfogadásával tranzakciós adatvédelmet kínál – anélkül, hogy kiterjedt cseréket végezne az infrastruktúrájában. Ennek kulcsfontosságú előnye van azon protokollcsapatok számára, amelyek nem akarnak teljes körű, adatvédelemre összpontosító L2-t (a là Aztec v2 ) kiépíteni, hanem alapvető nyomon követhetőséget és összekapcsolhatóságot kívánnak biztosítani a felhasználók számára. Érdemes elolvasni a Nethermind csapat javaslatát az EIP-7503 bevezetésére a Taiko rendszeren, hogy képet kapjunk arról, hogyan valósítható meg az EIP-7503 Ethereum L2-vel.

Az EIP-7503 egyensúlyt teremt az adatvédelem és a szabályozási megfelelés között, ami összhangban van az Ethereum „privacy 2.0” mozgalmának céljával: a felhasználók adatainak védelme, miközben biztosítja, hogy a rossz szereplők ne tudják kihasználni az adatvédelmi infrastruktúrát aljas célokra. Az EIP-7503 Ethereum Researchnél ismertetett megvalósítása szerint az EIP-7503-at alkalmazó összesítés megakadályozhatja a Tornado Cash probléma megismétlődését azáltal, hogy szelektíven megtiltja az ismert hackereket és csalókat abban, hogy magán átutalással pénzmosást hajtsanak végre.

Ennek a tulajdonságnak az eléréséhez megköveteljük a felhasználóktól, hogy adják át a tiltólistán szereplő címek listáját ( blacklist[] ) bemenetként annak az áramkörnek, amely ZK-SNARK bizonyítékokat generál az égési tranzakciókról. Az áramkör ellenőrzi, hogy az ETH-t fogadó felhasználó címe nem része-e a feketelistán tárolt címeknek, amikor beégés-igazolást generál – a feketelistán szereplő címre történő átvitel automatikusan meghiúsul, mivel az áramkör nem tud bizonyítékot generálni, ha a bemenet nem tesz eleget minden érvényességi feltételnek.

A feketelistán szereplő címek nyilvántartásának fenntartása bizonyos fokú centralizációt és potenciális cenzúravektorokat vezet be. De ha elfogadjuk, hogy a közösség által vezérelt, alapokon nyugvó önszabályozás jobb, mint a központosított, felülről lefelé irányuló szabályozás, akkor szükség lehet az előírásoknak való megfelelést biztosító eszközökre.

Privát bérszámfejtés a láncon belüli szervezetek számára

Az átláthatóság a DAO-k (Decentralizált Autonóm Szervezetek) egyik sarokköve: a hagyományos szervezetekkel ellentétben, ahol a pénzügyi javadalmazás részleteit eltitkolják a befektetők és az érdekelt felek elől, a DAO-k befizetéseit nyilvánosan rögzítik a láncon. Ez a láncon belüli ellenőrzési nyomvonal jelentős elszámoltathatóságot biztosít, és nagymértékben csökkenti az információs aszimmetriát, amely a DAO-adminisztrátorok rossz pénzügyi gazdálkodását eredményezheti.

A DAO-k azonban elkerülhetetlenül fel fognak érni, és úgy kezdenek el működni, mint a vállalatok (jóban-rosszban) – ilyenkor kívánatossá válhatnak olyan dolgok, mint például a közreműködők kompenzációjának részleteinek titokban tartása. Az EIP-7503 biztosítja azt az infrastruktúrát, amelyre a DAO-knak szükségük van ahhoz, hogy magánkifizetéseket hajtsanak végre a fő közreműködőknek, fejlesztőknek és független vállalkozóknak. A címzettnek minden esetben csak egy írási címet kell generálnia a kifizetések fogadásához és a választott címre történő visszavonáshoz.

Hogyan tartják elszámoltathatóvá a DAO-tagok az adminisztrátorokat, ha magán-közreműködői/vállalkozói kifizetéseket hajtanak végre? Ez attól függ, hogy a DAO milyen szintű titkosságot keres, és hogy a DAO-tagok milyen szintű elrejtést tudnak elviselni. Például annak bizonyítására, hogy AliceDAO valóban kifizetett 20 ETH-t Alice-nek a DAO-munkáért, és hogy a pénzt nem használták fel alternatív célokra, Alice bizonyíthat, hogy ő hozta létre az el nem költhető címet.

Például Alice felfedheti az el nem költhető cím létrehozásához használt privát kulcsokat . Mivel az el nem költhető cím a pénzverés után semmissé válik, Alice kockázatvállalás nélkül felfedheti s-t . Egy harmadik féltől származó ellenőrző az el nem költhető címet az s kivonatolása révén fogja kivonni ugyanazt a kriptográfiai kivonatoló függvényt, amelyet Alice kezdetben használt, és összehasonlítja a két címet. Ha megegyeznek, az ellenőr tudja, hogy Alice hozzáfért az írási címhez a tranzakció elküldésekor. Azt azonban nem tudja, hogy Alice milyen címen kapta meg a vert ETH tokeneket (bizonyos mértékig megőrzi Alice magánéletét).

A kriptovaluta keverőktől való függőség csökkentése

A Tornado Cash-hez hasonló keverő használata a pénztárca-címek közötti kapcsolatok megszakítására problémás, mert egyfajta bűnösséget hoz létre. Ne feledje, hogy a keverők anonimitást biztosítanak azáltal, hogy a különböző felhasználók által elhelyezett pénzeszközöket egyetlen alapba keverik össze, amelyből bárki kivonhat anélkül, hogy bármilyen más információt kellene megadnia, mint bizonyítékot egy korábbi betét hitelesítéséhez.

Minél több forrást helyeznek el egy adatvédelmi készletbe, annál nehezebb egy külső megfigyelőnek kikövetkeztetni, kinek mi a tulajdona; Ha rossz szereplők csatlakoznak a poolhoz, a becsületes résztvevők akaratlanul is segítik a bűnözőket a pénzmosásban azáltal, hogy hozzájárulnak a protokoll névtelenségéhez. Valószínűleg ez az oka annak, hogy az OFAC szankcióit kiterjesztették (és még mindig) azokra a címekre, amelyek kapcsolatba kerültek a Tornado Cash-sel, még akkor is, ha ezek a címek nem kapcsolódnak ismert rossz szereplőkhöz (pl. adathalász bandák, nemzetállamok által támogatott hackerek és feketekalap-kizsákmányolók).

Az olyan keverők, mint a Tornado Cash, szintén problémát okoznak a helyettesíthetőségben: a keverőkészletből kivont tokenek „beszennyeződhetnek”, és lehetetlenné válhatnak a használatuk, vagy 1:1 arányban kicserélhető olyan „tiszta” tokenekkel, amelyek nem mentek át a keverőn. Van egy nagyszerű szál a Redditen , amely részletesebben tárgyalja a szennyezett alapok problémáját, és ajánlom, hogy olvassa el. Íme néhány tanulságosabb megjegyzés a szálból:

Ennek valós következményei lehetnek: például az Ethereum közösségben sok kiemelkedő személy képtelen kommunikálni néhány dapp frontenddel, miután pénztárcájába kéretlen mennyiségű ETH került a Tornado Cash poolból. Az EIP-7503-at „szerződés nélküli keverőként” írják le, és kikerüli a fent említett problémákat azáltal, hogy rendszeres EOA-tól EOA-ig történő átvitelt használ az ETH elégetésére, és bevezeti a közvetlen pénzverést, hogy megkönnyítse az anonimitási készletből való kivonást (szemben az intelligens szerződés használatával).

A szerződés nélküli keverő másik előnye a névtelenségi készlet mérete. A Tornado Cash-nél (és a hasonló protokolloknál, mint a Railgun ) az anonimitás halmaza kisebb – korrelál a résztvevők számával – és idővel csökken. Ezzel szemben az EIP-7503 az Ethereumon található elkölthető és el nem költhető címek teljes készletét anonimitás-készletté változtatja. Tekintettel a nagy címtérre, nyugodtan mondhatjuk, hogy a láncon belüli nyomozókra, akik tudni akarják, honnan származik a privát átutalás címzettjének küldött ETH, kemény munka vár rájuk.

Vannak-e hátrányai az EIP-7503 megvalósításának?

Az alábbiakban az EIP-7503 megvalósításának néhány lehetséges hátránya található:

Szabályozási megfelelési problémák

Míg a korábbi elemzések azt sugallják, hogy az Ethereum valószínűleg nem jut ugyanarra a sorsra, mint a Monero és a Zcash, ha elkezdi támogatni a privát átutalásokat, lehetetlen megjósolni , hogy mi fog történni, ha az EIP-7503 aktiválásra kerül. Íme egy megjegyzés az Ethereum Magicians szál egyik résztvevőjétől, amely a szabályozókra gyakorolt következményeket tárgyalja:

Noha az Ethereum natív adatvédelmi megoldása, a közösség kezdi felismerni annak fontosságát, hogy a Tornado Cash elleni szankciók következményei után a magánélet/anonimitás és a szabályozási megfelelés közötti kötélen járjanak. Ez az ötlet különösen befolyásolja az adatvédelmi protokollok, például a Privacy Pools és a Nocturne új generációjának tervezését:

• A Privacy Pools lehetővé teszi a felhasználók számára, hogy „ártatlanságuk bizonyítékát” állítsák elő, amely igazolja, hogy letétjüket kizárták a rossz szereplők betéteit tároló poolból. Más szavakkal, a felhasználó kapcsolatba léphet egy keverővel, és azt mondhatja: „Nem segítek bűnözőknek és terroristáknak pénzmosásban”.

• A Nocturne azt tervezi, hogy áttér az ártatlanság bizonyítási protokolljára, de jelenleg több védőkorlátot is bevezet a megfelelőség garantálása érdekében . Ez magában foglalja a betétek szűrését, a betétfeldolgozási késéseket, a címenkénti kamatkorlátokat és egy globális kamatkorlátot, amely korlátozza a protokoll által egy nap alatt feldolgozható betétek teljes értékét.

  
  

Az intelligens, szerződésen alapuló adatvédelmi megoldások, mint például a Nocturne és a Privacy Pools, képesek finom vezérléseket végrehajtani, és szelektíven kizárni azokat a felhasználókat, akikről feltételezhető, hogy jogellenes tevékenységet folytatnak. A protokollon belüli adatvédelmi megoldások, mint például az EIP-7503 megkülönböztetésmentesek – ez egy kívánatos funkció, amely azonban problémákat okozhat, és megnyithatja az ajtót a rossz szereplők előtt, hogy visszaéljenek a magántranzakciók funkciójával.

(Elméletileg) javítható az EIP-7503 a korábban leírt feketelista modul hozzáadásával, de ez valószínűleg Pandora szelencéjét nyitja meg:

• Ki kezelheti a tiltólistán szereplő címek listáját? Megkérjük az OFAC-ot, hogy adjon meg egy listát a feketelistán szereplő címekről, és kockáztatjuk, hogy a kormány döntse el, ki köthet magánügyleteket az Ethereumon? Megkockáztatjuk-e a vitás elágazást, ha egy ellenőrző csoport megtagadja a blacklistedAddresses címjegyzékben szereplő egy vagy több fiókból származó átutalások cenzúrázását?
• Ha az EIP-7503 összesítővel van megvalósítva, a DAO felelős a blacklistedAddresses nyilvántartás karbantartásáért? Vagy az alapító csapat szerződést köt olyan kriminalisztikai társaságokkal, mint a Chainalysis, az Elliptic és a TRM Labs, hogy tájékoztatást adjanak arról, hogy mely címekre kell korlátozni a privát átutalások fogadását? Milyen problémák merülhetnek fel, ha egy profitorientált vállalat dönti el, hogy mi történik a rollup alaprétegében?
• Ha az összesítő úgy dönt, hogy eltávolítja az adminisztrátori jogosultságokat, és nem frissíthetővé teszi az ellenőrző/mintaszerződéseket, hogyan biztosítja, hogy a rossz szereplők ne kezdjenek pénzeszközöket a protokollon keresztül mozgatni? Megoldható-e az ismert kihasználóktól származó tranzakciók szelektív szűrése a verem felső rétegeiben (pl. szekvenszer vagy érvényesítő szinten)? Mit jelent a logisztika?

Ez csak néhány kérdés, amelyeket meg kell válaszolni, mielőtt az Ethereum (vagy az Ethereum L2s) elfogadja az EIP-7503-at. A kriptográfia még mindig feltérképezetlen vizeken van, de segít a Murphyjitsu végrehajtásában, előre gondolva a lehetséges szélsőséges esetekre, amikor olyan döntéseket hoznak, amelyek jelentős hatással vannak a protokoll hosszú távú fennmaradására.

A szerencsétlenség leginkább azokat nehezíti, akik csak jó szerencsére számítanak. – Seneca

Az ERC-20 tokenekkel társított lehetséges központosítás

Az EIP-7503 megvalósításához frissíteni kell az EVM-et, hogy támogassa az új tranzakciótípust, amely elfogadja az égetési nyugtát, és jóváírja a címzett egyenlegét az előző tranzakcióban égetett ETH-val. A végrehajtási klienseknek frissíteniük kell a Sparse Merkle Tree (SMT) támogatására a nullifikátorok tárolására, és láncon kívüli áramköröket kell megvalósítaniuk az égési bizonyítékok generálására és ellenőrzésére a felhasználók nevében.

Felismerve, hogy a frissítés nem kivitelezhető, az EIP-7503 szerzőinek van egy alternatív javaslatuk az EIP-7503 megvalósítására egy ERC-20 token szerződés segítségével . A felhasználók megtartják ugyanazt a munkafolyamatot, amelyet az előző szakaszokban leírtak (pénzek küldése el nem költhető címre és nullifikátor létrehozása), de az ETH-tokenek fogadása helyett ERC-20 tokeneket készítenek az égésigazolás benyújtása után. Az ERC-20 szerződés integrálódik egy speciális EIP-7503 hitelesítő szerződéssel, amely láncon belül ellenőrzi az égési bizonyítékokat (az ERC-20 szerződés képes megvalósítani az ellenőrző áramkört is).

Míg az ERC-20 szerződés egyszerűsíti az EIP-7503 végrehajtását, ez a megközelítés újra bevezeti a központosítás és a cenzúra problémáját. Az ERC-20 tokent nem frissíthetővé és irányíthatatlanná tehetjük, mint például a Wrapped Ether (WETH) , hogy kiküszöböljük a központosítási vektorokat, de ez nem segíthet az olyan problémákon, mint például a token listáról való eltávolítása.

Azt is meg kell jegyeznünk, hogy a láncon belüli kriminalisztika könnyebben azonosítja az ERC-20 szerződéssel kölcsönhatásba lépő fiókokat, és ezeket a címeket egy feketelistára helyezi – ha a szabályozók úgy döntenek, hogy az Ethereumon keringő kriptovaluták után kutatnak a magánélet védelmét jobban szem előtt tartva. Mivel ez az a probléma, amelyre az EIP-7503-at tervezték, nehéz lehet belátni, hogy a „privát ERC-20 token” létrehozására irányuló javaslat miként jelent előrelépést.

A másik oldalon az ERC-20 token megkönnyíti az átvitel-szűrő funkció megvalósítását, amely blokkolja a tiltólistán szereplő címekre történő átvitelt. A fejlesztő egyszerűen eltárolhatja a blacklist[] a szerződésben, és módosíthatja az transfer() úgy, hogy a tranzakcióban ellenőrizni tudja a tokeneket fogadó cím azonosságát. Ez azonban egy olyan funkció, amelyet nem tudunk protokoll szinten megvalósítani néhány nagyon erős bizalmi feltételezés bevezetése nélkül.

Megnövekedett K+F rezsi

Az EIP-7503 megköveteli az anonim és privát tranzakciók támogatásához szükséges komplex, élvonalbeli kriptográfiai infrastruktúra létrehozását, tesztelését, auditálását és karbantartását. Legalábbis a Nethermind leírása az EIP-7503 L2 implementációjáról és a Nobitex Labs EIP-7503 Chain proof of concept egyaránt azt sugallja, hogy tisztességes mérnöki erőfeszítésekre lesz szükség az EIP-7503 igazolások generálására és ellenőrzésére szolgáló ZK-SNARK áramkörök létrehozására. .

Azt is fontos megjegyezni, hogy az olyan kriptográfiai primitíveket, mint a ZK-SNARK-ok, még nem kellőképpen tesztelték ahhoz, hogy a protokollfejlesztők teljes bizalommal implementálhassák őket. Szemléltetésképpen, Zcash kijavított egy hibát, amely lehetővé tette volna egy tisztességtelen felhasználó számára, hogy hamis bizonyítékokat mutasson be az eszköz tulajdonjogáról, és végtelen mennyiségű tokent vertessen 2018-ban. Beszéltem arról is, hogy a Tornado Cash csapata 2019-ben menekülni tudott egy esetleges kizsákmányolás elől .

Az EIP-7503 Ethereumon való megvalósításában bekövetkezett hiba nem triviális hatással lesz. Például egy felhasználó, aki véletlenül olyan hibát fedez fel, amely lehetővé teszi az égésigazolást igazoló áramkör által végzett kritikus ellenőrzések megkerülését (pl. az égési címek egyensúlya és a nullifikátorok használata), kihasználhatja a tudást végtelen mennyiségű éter és összeomlik az ETH piaci értéke.

Egy másik bonyolult terület abból a követelményből ered, hogy az EIP-7503 ellenőrzőnek ellenőriznie kell a B blokkfejlécet, amely a felhasználó által generált igazolásban szerepel. Az EVM az utolsó 128-256 blokk hash-jét tárolja, így a láncon belüli ellenőrző nem tudja megbízhatóan ellenőrizni a blokkfejléceket hosszabb tartományból.

A régebbi blokkok állapotgyökérének ellenőrzéséhez az EIP-210-et kell megvalósítani. Az EIP-210 egy olyan rendszerszintű intelligens szerződés létrehozását javasolja, amely tárolja a történelmi blokkkivonatokat, és átdolgozza a BLOCKHASH műveleti kódot, hogy az ügyfelek elolvashassák a szerződést.

Az EIP-210 nem feltétlenül szükséges, mivel a felhasználóknak legalább egy órájuk ( 14 seconds * 256 blocks ) van az EVM-mel ellenőrizhető igazolás létrehozására és benyújtására. Mégis, ha szabadságot adunk a felhasználóknak arra, hogy késleltessenek az égési címre küldött betétek beváltását, ez javítja az UX-t, és ellenállóbbá teszi a kifizetési folyamatot a címcsoportosítással és hasonló elemzési technikákkal szemben.

Alternatív megoldás egy orákulum-szerződés integrálása, amely előírja a (ösztönzött) szereplőknek, hogy történeti blokkfejléceket küldjenek be egy láncon belüli szerződésbe. Ez könnyebben megvalósítható, mint egy rendszerszintű intelligens szerződés létrehozása és egy műveleti kód átalakítása, de megköveteli, hogy a megbízható oracle operátorok (a) közzétegyék a helyes blokkfejlécet (b) azonnal küldjék be a blokkfejléceket. Ha mindkét feltételezés nem állja meg a helyét, előfordulhat, hogy a becsületes felhasználók nem tudják beváltani a betéteket, és a rossz szereplők helytelen blokkfejléceket tehetnek közzé, hogy ellenőrizzék a Merkle-bizonyítékokat a nem létező égési tranzakciókra vonatkozóan.

Az anonimitáskészletek csökkentése

Az EIP-7503 aktiválásakor a 11000-es számú ETH-t gyűjtő felhasználó anonimitása magában foglalja az összes pozitív ETH-egyenleggel és nulla kimenő tranzakcióval rendelkező Ethereum EOA-t. Ez kulcsfontosságú az anonim tranzakciók nyomon követhetősége szempontjából: ha egy tranzakció ETH-t éget el, lehetetlen felismerni égetett tranzakcióként, mert egy el nem költhető cím úgy néz ki, mint egy normál Ethereum-cím.

Mindazonáltal azon címek száma, ahol a számlaegyenleg statikus marad, és nem küldenek tranzakciókat, olyan szintre csökken, ahol csak az égetett címek alkotják az anonimitáskészletet. Így az anonimitáskészlet a szerződéses keverők, például a Tornado Cash és az új generációs adatvédelmi eszközök, például a Privacy Pools és a Railgun névtelenségi készleteihez kezd hasonlítani (ami az EIP-7503 adatvédelmi garanciáinak fokozatos csökkentését jelenti).

Az egyetlen kivételt azok a számlák jelentik, amelyek ETH-t kapnak, mert a feladó véletlenül nem létező címre utalt át pénzt, ezek a számlák örökre az EIP-7503 névtelenségben maradnak. Érdemes megfontolni azokat a címeket, ahol a tulajdonos elveszíti a privát kulcsot az anonimitási készlet részeként, de ez (szerencsére és sajnos) ritkán fordul elő, és ezeken a fiókokon általában legalább egy vagy több kimenő tranzakció van. (Nehéz elképzelni, hogy a legnoobibb felhasználó elveszítse privát kulcsait, mielőtt bármilyen tranzakciót végrehajtana.)

Az anonimitás csökkentése ellenére az EIP-7503 továbbra is hasznos az általa kínált valószínű tagadhatóság miatt. Tegyük fel, hogy valaki vihart kelt a kripto-Twitteren, és azzal vádolja Alice-t, hogy szándékosan égette el az ETH-t (egy el nem költhető címre küldve) azzal a szándékkal, hogy később pénzt vonjon ki egy új címre. Alice hihetően tagadható, és a következő állítással tudja ellensúlyozni az állítást:

• „Véletlenül küldtem az ETH-t a címre. Be tudod bizonyítani, hogy nem hibáztam, amikor beírtam a címet a MetaMaskba?”
• „Megvan a cím privát kulcsa, de nem tudom megosztani. Ugye most nem a privát kulcsomat kérnéd?
• „Megvan a privát kulcs a címhez, de elvesztettem. Be tudod bizonyítani, hogy nem vesztettem el a privát kulcsomat?”

Lehet, hogy ezek az állítások nem győznek meg, de így néz ki a valószínű tagadás a való világban. A Jogi szótár így fogalmaz:

„A hihető nem azt jelenti, hogy megbízható, lehetséges vagy akár valószínű. A valószínű azt jelenti, hogy arra a következtetésre juthat, hogy valami lehetséges vagy nem. De általában elméletileg, felületesen vagy gyanúsan. Ennek sem kell feltétlenül „ésszerű” következtetésnek lennie. Tágabb értelmében a kifejezés általában a bizonyíték hiányára utal. Hiszen az ártatlan, amíg be nem bizonyítják bűnösségét, jogrendszerünk gerince.

Tehát ha nincs bizonyíték, valószínű, hogy cáfolhatják. Lényegében minden illegális vagy etikátlan, amit ártatlan és valószínű álcával meg lehet magyarázni – igaz vagy nem – elfogadható tagadás alá esik. Még akkor is, ha a tagadás valószerűsége gyanús.”

Az egyetlen alkalom, amikor a felhasználó véglegesen kapcsolódhat egy EIP-7503 privát átutaláshoz, az a címzett címére irányuló átvitel feldolgozása. A felhasználók azonban lépéseket tehetnek annak érdekében, hogy csökkentsék vagy teljesen kiküszöböljék annak lehetőségét, hogy külső megfigyelők összekapcsolják a pénzfelvételi tranzakciót az égési tranzakcióval:

• Ahelyett, hogy egy elkölthető címre vonulna vissza, Alice ETH-t pénzel egy másik égetési címre, hogy a pénzeszközöket a névtelenségben tartsa. Az éget → menta → éget → menta → folyamat többszöri megismétlése megnehezíti annak észlelését, hogy a végső cím egy Alice által felügyelt fiók-e.
• A teljes összeg kifizetése helyett Alice a kifizetést két vagy több tranzakcióra osztja. A kifizetések késleltetése vagy véletlenszerű besorolása „zajt” generál, amely megnehezíti a tranzakciós tevékenység elemzését, és megnehezíti az égetési és pénzverési tranzakciók ugyanahhoz a felhasználóhoz való kapcsolását.

Megjegyzés : A második technika az EIP-7503 javasolt kiterjesztése, és a jelenlegi kialakítással nem tűnik megvalósíthatónak. Ahhoz, hogy a felhasználók feloszthassák a pénzfelvételeket, egy olyan funkcióra van szükség a nullifikátorok felosztására, hogy nullifier 1 az égési cím egyenlegének töredékét, nullifier 2 az egyenleg további töredékét stb.

Következtetés

Az EIP-7503 megoldást kínál az Ethereum egyik legalulértékeltebb problémájára: a pénzügyi adatvédelem hiányára. Ha az Ethereum egy napon felváltja a bankokat, akkor a felhasználóknak a jelenlegi állapottal megegyező szintű adatvédelmet kell biztosítania. Minden kevesebb, és az Ethereum nem éri el a tömeges elfogadást, mert a magánélet feladása – még a cenzúra elkerülése érdekében is – olyan áldozat, amelyet a legtöbb egyén nem tud meghozni.

Az EIP-7503 még felülvizsgálati szakaszban van, és valószínűleg változásokon és teljesítményjavuláson megy keresztül. A részösszegek kifizetésének jövőbeni támogatása mellett egy hasznos funkció lehetővé teszi a felhasználók számára, hogy több égési igazolást rekurzív módon kombináljanak egyetlen SNARK-ba, amely egy ellenőrzési tranzakció során ellenőrzi a különböző égési címekre történő befizetéseket. Ez a funkció tovább fokozza az EIP-7503 vonzerejét a CEX-ek és a kereskedők számára, akik egyetlen címet szeretnének fenntartani felhasználói letétenként anélkül, hogy külön-külön be kell nyújtaniuk az égési igazolást (esetleg több száz vagy több ezer) égetési címhez.

A rendszeres felhasználók is profitálhatnak abból, ha több írási címre küldenek tokeneket (ahelyett, hogy egyetlen el nem költhető címre küldenék), és az összesített bizonyítékot és a semmisítő készletet elküldik a privát átvitel befejezéséhez. Egynél több írási cím használatával a feladók tovább randomizálhatják a tranzakciós tevékenységet, és leállíthatják a tranzakciók egy személyre való visszaírására irányuló kísérleteket. Ez kiegészíti az EIP-7503 által már kínált főbb előnyöket, mint például a privát átutalások, a magánszemélyek közötti adományozás/kifizetések és a láncon belüli DAO-k privát bérszámfejtése.

Ha szívesen olvasta ezt a cikket, fontolja meg megoszthatja valakivel, aki informatívnak találja, és iratkozzon fel a 2077 Research hírlevélre, hogy mélyebben megismerje az EIP ökoszisztémából érkező javaslatokat. Továbbra is az Ethereum adatvédelmi megoldásaira fogunk összpontosítani, és azt tervezzük, hogy kiadjuk az ERC-5564 (a lopakodó címek generálására és az Ethereum rejtett címtranzakcióinak küldésére szolgáló szabvány) való mélyreható merülést.

Maradj velünk!

A szerző megjegyzése: Ez a cikk itt is megjelent.