We zijn al heel lang geïnteresseerd in het onderwerp anonimiteit in cryptocurrencies en proberen de ontwikkeling van technologieën op dit gebied te volgen. In onze artikelen hebben we de werkingsprincipes al in detail besproken in Monero, en ook uitgevoerd technologieën die op dit gebied bestaan. Alle anonieme cryptocurrencies van vandaag zijn echter gebouwd op het datamodel voorgesteld door Bitcoin - Unspent Transaction Output (hierna UTXO). Voor accountgebaseerde blockchains zoals Ethereum kunnen bestaande oplossingen voor het implementeren van anonimiteit en vertrouwelijkheid (bijvoorbeeld of ) probeerde het UTXO-model te repliceren in slimme contracten.
In februari 2019 ontdekte een groep onderzoekers van Stanford University en Visa Research vrijgelaten "Zether: Op weg naar privacy in de wereld van slimme contracten." De auteurs waren de eersten die een aanpak voorstelden om de anonimiteit in accountgebaseerde blockchains te garanderen en presenteerden twee versies van een slim contract: voor vertrouwelijke (verbergen van saldi en overdrachtsbedragen) en anonieme (verbergen van de ontvanger en afzender) transacties. We vinden de voorgestelde technologie interessant en willen graag het ontwerp ervan delen, maar ook praten over waarom het probleem van anonimiteit in accountgebaseerde blockchains als zeer moeilijk wordt beschouwd en of de auteurs erin zijn geslaagd het volledig op te lossen.
Over de structuur van deze datamodellen
In het UTXO-model bestaat een transactie uit “inputs” en “outputs”. Een directe analogie van ‘outputs’ zijn de bankbiljetten in uw portemonnee: elke ‘output’ heeft een bepaalde waarde. Wanneer u iemand betaalt (vorm een transactie), geeft u een of meer ‘outputs’ uit, in welk geval ze ‘inputs’ van de transactie worden, en de blockchain markeert ze als uitgegeven. In dit geval ontvangt de ontvanger van uw betaling (of u zelf, als u wisselgeld nodig heeft) de nieuw gegenereerde “outputs”. Dit kan schematisch als volgt worden weergegeven:
Op accounts gebaseerde blockchains zijn net zo gestructureerd als uw bankrekening. Zij behandelen alleen het bedrag op uw rekening en het overboekingsbedrag. Wanneer u een bedrag van uw account overboekt, verbrandt u geen “outputs”, het netwerk hoeft niet te onthouden welke munten zijn uitgegeven en welke niet. In het eenvoudigste geval komt transactieverificatie neer op het controleren van de handtekening van de afzender en het bedrag op zijn saldo:
Analyse van technologie
Vervolgens zullen we het hebben over hoe Zether het transactiebedrag, de ontvanger en de afzender verbergt. Terwijl we de principes van de werking ervan beschrijven, zullen we de verschillen opmerken tussen de vertrouwelijke en anonieme versies. Omdat het veel gemakkelijker is om de vertrouwelijkheid te garanderen in accountgebaseerde blockchains, zullen sommige beperkingen die door anonimisering worden opgelegd, niet relevant zijn voor de vertrouwelijke versie van de technologie.
Saldo's en overboekingsbedragen verbergen
Er wordt een versleutelingsschema gebruikt om saldi te versleutelen en bedragen over te maken in Zether . Het werkt als volgt. Als Alice Bob wil sturen b munten op adres (de publieke sleutel) Y, kiest ze een willekeurig getal r en codeert het bedrag:
waar C - gecodeerd bedrag, D - hulpwaarde die nodig is om dit bedrag te ontcijferen, G - een vast punt op de elliptische curve, wanneer vermenigvuldigd met de geheime sleutel, wordt de publieke sleutel verkregen.
Wanneer Bob deze waarden ontvangt, voegt hij ze eenvoudigweg op dezelfde manier toe aan zijn gecodeerde saldo, en daarom is dit schema handig.
Op dezelfde manier trekt Alice dezelfde waarden van haar saldo af, alleen als Y gebruikt uw publieke sleutel.
De ontvanger en afzender verbergen
Het schudden van “uitvoer” in UTXO dateert uit de begindagen van cryptocurrencies en helpt de afzender te verbergen. Om dit te doen, verzamelt de afzender zelf, wanneer hij een overdracht uitvoert, willekeurige “outputs” in de blockchain en mengt deze met de zijne. Vervolgens ondertekent hij de ‘outputs’ met een ringhandtekening – een cryptografisch mechanisme waarmee hij de verificateur ervan kan overtuigen dat de munten van de afzender aanwezig zijn tussen de betrokken ‘outputs’. De gemengde munten zelf worden uiteraard niet uitgegeven.
We kunnen echter geen valse uitvoer genereren om de ontvanger te verbergen. Daarom heeft in UTXO elke “uitvoer” zijn eigen unieke adres, en is het cryptografisch gekoppeld aan het adres van de ontvanger van deze munten. Op dit moment is er geen manier om de relatie tussen het unieke uitvoeradres en het ontvangersadres te identificeren zonder de geheime sleutels ervan te kennen.
In het accountgebaseerde model kunnen we geen eenmalige adressen gebruiken (anders is het al een “exits” -model). Daarom moeten de ontvanger en de afzender gemengd zijn tussen andere accounts in de blockchain. In dit geval worden gecodeerde 0-munten van de gemengde rekeningen afgeschreven (of worden er 0 toegevoegd als de ontvanger gemengd is), zonder dat hun werkelijke saldo daadwerkelijk wordt gewijzigd.
Omdat zowel de afzender als de ontvanger altijd een vast adres hebben, wordt het noodzakelijk om dezelfde groepen te gebruiken voor het mixen bij het doorverbinden naar dezelfde adressen. Het is gemakkelijker om dit met een voorbeeld te bekijken.
Laten we zeggen dat Alice besluit een bijdrage te leveren aan het goede doel van Bob, maar er de voorkeur aan geeft dat de overdracht anoniem blijft voor een externe waarnemer. Om zich te vermommen in het afzenderveld voert ze vervolgens ook de rekeningen van Adam en Adele in. En om Bob te verbergen, voegt u de accounts van Ben en Bill toe in het ontvangerveld. Bij de volgende bijdrage besloot Alice Alex en Amanda naast haar te schrijven, en Bruce en Benjen naast Bob. In dit geval is er bij het analyseren van de blockchain bij deze twee transacties slechts één kruisend paar deelnemers aanwezig: Alice en Bob, die deze transacties de-anonimiseren.
Transactieraces
Zoals we al hebben vermeld, codeert de gebruiker, om uw saldo in accountgebaseerde systemen te verbergen, zijn saldo en het overboekingsbedrag. Tegelijkertijd moet hij bewijzen dat het saldo op zijn rekening niet negatief blijft. Het probleem is dat de gebruiker bij het aanmaken van een transactie een bewijs opbouwt van zijn huidige accountstatus. Wat gebeurt er als Bob een transactie naar Alice stuurt en deze wordt geaccepteerd vóór de transactie die door Alice is verzonden? Dan wordt de transactie van Alice als ongeldig beschouwd, omdat het bewijs van saldo is opgesteld voordat de transactie van Bob werd geaccepteerd.
De eerste beslissing die in een dergelijke situatie wordt genomen, is het bevriezen van de rekening totdat de transactie is uitgevoerd. Maar deze aanpak is niet geschikt, omdat naast de complexiteit van het oplossen van een dergelijk probleem in een gedistribueerd systeem, het in een anoniem schema niet duidelijk zal zijn wiens account moet worden geblokkeerd.
Om dit probleem op te lossen, scheidt de technologie inkomende en uitgaande transacties: uitgaven hebben een onmiddellijk effect op de balans, terwijl ontvangsten een vertraagd effect hebben. Om dit te doen, wordt het concept van 'tijdperk' geïntroduceerd: een groep blokken met een vaste grootte. Het huidige "tijdperk" wordt bepaald door de blokhoogte te delen door de groepsgrootte. Bij het verwerken van een transactie werkt het netwerk onmiddellijk het saldo van de afzender bij en slaat het geld van de ontvanger op in een opslagtank. Het verzamelde geld wordt pas aan de begunstigde ter beschikking gesteld wanneer een nieuw ‘tijdperk’ begint.
Als gevolg hiervan kan de gebruiker transacties verzenden, ongeacht hoe vaak er geld wordt ontvangen (voor zover zijn saldo dit uiteraard toelaat). De tijdperkgrootte wordt bepaald op basis van hoe snel blokken zich door het netwerk voortplanten en hoe snel een transactie een blok binnengaat.
Deze oplossing werkt goed voor vertrouwelijke overdrachten, maar bij anonieme transacties levert het, zoals we later zullen zien, ernstige problemen op.
Bescherming tegen replay-aanvallen
Bij accountgebaseerde blockchains wordt elke transactie ondertekend door de privésleutel van de afzender, wat de verificateur ervan overtuigt dat de transactie niet is gewijzigd en is gemaakt door de eigenaar van deze sleutel. Maar wat als een aanvaller die naar het transmissiekanaal aan het luisteren was, dit bericht onderschept en precies hetzelfde tweede bericht verzendt? De verificateur verifieert de handtekening van de transactie en is overtuigd van het auteurschap ervan, en het netwerk schrijft hetzelfde bedrag opnieuw af van het saldo van de afzender.
Deze aanval wordt een replay-aanval genoemd. In het UTXO-model zijn dergelijke aanvallen niet relevant, omdat de aanvaller zal proberen gebruikte output te gebruiken, wat op zichzelf niet geldig is en door het netwerk wordt afgewezen.
Om dit te voorkomen, is er in de transactie een veld met willekeurige gegevens ingebouwd, dat een nonce of simpelweg ‘salt’ wordt genoemd. Bij het opnieuw indienen van een transactie met een salt, kijkt de verificateur of de nonce al eerder is gebruikt en, zo niet, beschouwt hij de transactie als geldig. Om niet de hele geschiedenis van gebruikersnonces in de blockchain op te slaan, wordt deze meestal bij de allereerste transactie gelijk gesteld aan nul en vervolgens met één verhoogd. Het netwerk kan alleen controleren of de nonce van de nieuwe transactie één voor één verschilt van de vorige.
Bij het anonieme overdrachtsstelsel doet zich het probleem voor van het valideren van transactie-nonces. We kunnen de nonce niet expliciet aan het adres van de afzender koppelen, omdat hierdoor de overdracht uiteraard wordt gedeanonimiseerd. We kunnen er ook geen toevoegen aan de nonces van alle deelnemende accounts, omdat dit in conflict kan komen met andere overboekingen die worden verwerkt.
De auteurs van Zether stellen voor om de nonce cryptografisch te genereren, afhankelijk van het “tijdperk”. Bijvoorbeeld:
Hier x is de geheime sleutel van de afzender, en Gepoch — een extra generator voor het tijdperk, verkregen door een string van de vorm 'Zether +' te hashen. Nu lijkt het probleem opgelost: we maken de nonce van de afzender niet bekend en bemoeien ons niet met de nonces van niet-betrokken deelnemers. Maar deze aanpak legt een ernstige beperking op: één account kan niet meer dan één transactie per “epoch” verzenden. Dit probleem blijft helaas onopgelost en maakt de anonieme versie van Zether momenteel naar onze mening nauwelijks geschikt voor gebruik.
De complexiteit van nulkennisbewijzen
In UTXO moet de afzender aan het netwerk bewijzen dat hij geen negatief bedrag uitgeeft, anders wordt het mogelijk om uit het niets nieuwe munten te genereren (waarom dit mogelijk is, schreven we in een van de vorige ). En onderteken ook de “invoer” met een ringhandtekening om te bewijzen dat er onder de munten die worden gemengd, fondsen zitten die van hem zijn.
In de anonieme versie van de accountgebaseerde blockchain zijn de uitdrukkingen voor bewijs veel complexer. De afzender bewijst dat:
- Het verzonden bedrag is positief;
- Het saldo blijft niet-negatief;
- De afzender heeft de overboekingsbedragen correct gecodeerd (inclusief nul);
- Het saldo op het saldo verandert alleen voor de afzender en de ontvanger;
- De afzender is eigenaar van de private sleutel van zijn account en hij staat daadwerkelijk op de lijst van afzenders (onder de betrokkenen);
- De bij de transactie gebruikte Nonce is correct samengesteld.
Voor zo'n complex bewijs gebruiken de auteurs een mengsel (een van de auteurs nam trouwens deel aan de creatie ervan) en , die Sigma-kogels worden genoemd. Formeel bewijs van een dergelijke verklaring is een nogal moeilijke taak, en het beperkt het aantal mensen dat bereid is de technologie te implementeren aanzienlijk.
Het resultaat?
Naar onze mening kan het deel van Zether dat privacy brengt in accountgebaseerde blockchains nu worden gebruikt. Maar op dit moment legt de anonieme versie van de technologie ernstige beperkingen op aan het gebruik ervan, en de complexiteit ervan aan de implementatie ervan. Er mag echter niet worden uitgesloten dat de auteurs het pas een paar maanden geleden hebben uitgebracht, en misschien zal iemand anders een oplossing vinden voor de problemen die er vandaag de dag bestaan. Dit is tenslotte hoe wetenschap wordt bedreven.
Bron: www.habr.com