We have long been interested in the topic of anonymity in cryptocurrencies and strive to keep up with the development of technologies in this area. In our articles, we have already explored the principles of operation in detail. in Monero, as well as conducted of the technologies that exist in this field. However, all anonymous cryptocurrencies today are built on the data model proposed by Bitcoin — Unspent Transaction Output (UTXO). For account-based blockchains like Ethereum, existing solutions for implementing anonymity and confidentiality (such as of ) have attempted to replicate the UTXO model in smart contracts.
In February 2019, a group of researchers from Stanford University and Visa Research uitgebracht entitled 'Zether: Towards Privacy in the World of Smart Contracts'. The authors were the first to propose an approach for ensuring anonymity in account-based blockchains and presented two variants of smart contracts: for confidential (hiding balances and amounts of transfers) and anonymous (hiding the sender and receiver) transactions. We find the proposed technology interesting and would like to share its structure, as well as discuss why the issue of anonymity in account-based blockchains is considered very complex and whether the authors have fully resolved it.
On the structure of these data models
In the UTXO model, a transaction consists of 'inputs' and 'outputs'. A direct analogy for the 'outputs' is the banknotes in your wallet: each 'output' has a certain denomination. When you pay someone (create a transaction), you spend one or more 'outputs', which become the 'inputs' of the transaction, and the blockchain marks them as spent. The recipient of your payment (or you, if you need change) receives newly generated 'outputs'. This can be schematically represented as follows:
Account-based blockchains are structured somewhat like your bank account. They operate solely on the amount in your account and the amount being transferred. When you transfer an amount from your account, you do not burn any 'outputs', and the network does not need to remember which coins have been spent and which have not. In its simplest form, transaction verification boils down to checking the sender's signature and the amount in their balance:
Analysis of the technology
Laten we nu bespreken hoe Zether het bedrag van transacties, de ontvanger en de afzender verbergt. Tijdens de beschrijving van de werking ervan zullen we de verschillen in vertrouwelijkheid en anonimiteit markeren. Aangezien het veel eenvoudiger is om vertrouwelijkheid te waarborgen in account-gebaseerde blockchains, zullen sommige van de beperkingen die door anonimiteit worden opgelegd, niet relevant zijn voor de vertrouwelijke versie van de technologie.
Verbergen van saldi en transactiebedragen
Voor het versleutelen van saldi en transactiebedragen in Zether wordt een versleutelingsschema gebruikt Het werkt als volgt. Wanneer Alice Bob b een aantal munten naar (zijn publieke sleutel) wil sturen, Ykiest ze een willekeurig getal , die de eerste regel van het verzoek, de headers en de gegevens scheidt. en versleutelt ze het bedrag:
waar C — het versleutelde bedrag, D — een hulpparameter die nodig is voor het ontsleutelen van dit bedrag, G — een vast punt op de elliptische kromme, waarbij de publieke sleutel verkregen wordt door de geheime sleutel ermee te vermenigvuldigen.
Wanneer Bob deze waarden ontvangt, voegt hij ze eenvoudigweg toe aan zijn op dezelfde manier versleutelde saldo, wat het schema handig maakt.
Op dezelfde manier trekt Alice dergelijke waarden af van haar saldo, maar gebruikt ze als Y haar publieke sleutel.
Het verbergen van de ontvanger en afzender
Het mengen van 'uitgangen' in UTXO is al ontstaan in de vroege dagen van cryptocurrency en helpt de afzender te verbergen. Hiervoor selecteert de afzender bij het uitvoeren van een transactie willekeurige 'uitgangen' in de blockchain en mengt deze met zijn eigen. Vervolgens ondertekent hij de 'uitgangen' met een ringhandtekening — een cryptografisch mechanisme dat de controleur overtuigt dat onder de gemengde 'uitgangen' munten van de afzender aanwezig zijn. De gemengde munten worden uiteraard niet uitgegeven.
Echter, om de ontvanger te verbergen, kunnen we geen valse 'uitgangen' genereren. Daarom heeft elke 'uitgang' in UTXO zijn unieke adres, dat cryptografisch is verbonden met het adres van de ontvanger van deze munten. Tot nu toe is er geen manier om de verbinding tussen het unieke adres van de 'uitgang' en het adres van de ontvanger te onthullen zonder zijn geheime sleutels te kennen.
In een account-based model kunnen we geen eenmalige adressen gebruiken (anders zou het al een 'uitgangs'-model zijn). Daarom moeten zowel de ontvanger als de afzender worden vermengd tussen andere accounts in de blockchain. Hierbij wordt van de vermengde accounts een gecodeerde 0 munt afgeschreven (of 0 toegevoegd — in het geval van het vermengen van de ontvanger), waardoor hun werkelijke balans feitelijk niet verandert.
Aangezien zowel de afzender als de ontvanger altijd een vast adres hebben, is het hier noodzakelijk om bij overboekingen naar dezelfde adressen dezelfde groepen voor het vermengen te gebruiken. Het is makkelijker om dit aan de hand van een voorbeeld te bekijken.
Stel dat Alice heeft besloten een donatie te doen aan Bob's liefdadigheidsinstelling, maar ze geeft er de voorkeur aan dat deze overdracht anoniem blijft voor een externe waarnemer. Om zichzelf in het afzenderveld te maskeren, schrijft ze ook de accounts van Adam en Adele erbij. En om Bob te verbergen — in het ontvanger veld voegt ze bovendien de accounts van Ben en Bill toe. Bij de volgende donatie besloot Alice Alex en Amanda naast zich te schrijven, en naast Bob Bruce en Benjen. In dit geval zal bij de analyse van de blockchain in deze twee transacties slechts één overlappend paar deelnemers worden gevonden — Alice en Bob, wat deze transacties de-anonimiseert.
Transactie races
Zoals we al hebben vermeld, verbergt een gebruiker in account-based systemen zijn saldo en het over te maken bedrag. Hierbij moet hij bewijzen dat het saldo op zijn rekening niet negatief blijft. Het probleem is dat wanneer de gebruiker een transactie opzet, hij een bewijs opbouwt omtrent zijn huidige rekeningstatus. Maar wat als Bob een transactie naar Alice stuurt, en deze wordt eerder geaccepteerd dan die van Alice? Dan wordt de transactie van Alice als ongeldig beschouwd, omdat het bewijs van het saldo vóór de acceptatie van Bobs transactie is opgebouwd.
De eerste oplossing die in een dergelijke situatie opkomt, is om het account te bevriezen totdat de transactie is uitgevoerd. Maar deze aanpak is niet geschikt, omdat, naast de complexiteit van het oplossen van een dergelijke taak in een gedistribueerd systeem, het in een anoniem systeem niet duidelijk is wiens account geblokkeerd moet worden.
Om dit probleem op te lossen, deelt de technologie inkomende en uitgaande transacties: het uitgeven van middelen heeft een onmiddellijke impact op de balans, terwijl inkomsten uitgesteld zijn. Hiervoor wordt het concept 'tijdperk' geïntroduceerd — een groep blokken van vaste grootte. Het huidige 'tijdperk' wordt bepaald door de hoogte van het blok te delen door de groepsgrootte. Bij het verwerken van een transactie werkt het netwerk de balans van de afzender onmiddellijk bij, terwijl de middelen van de ontvanger in een reserve worden geplaatst. De verzamelde middelen worden pas ter beschikking van de ontvanger gesteld bij het begin van een nieuw 'tijdperk'.
Hierdoor kan de gebruiker transacties verzenden, ongeacht hoe vaak hij middelen ontvangt (voor zover zijn balans dat toelaat, natuurlijk). De grootte van het tijdperk wordt bepaald aan de hand van hoe snel blokken zich door het netwerk verspreiden en hoe snel een transactie in een blok komt.
Deze oplossing werkt goed voor vertrouwelijke overmakingen, maar met anonieme transacties, zoals we later zullen zien, creëert dit serieuze problemen.
Bescherming tegen replay-aanvallen
In account-based blockchains wordt elke transactie ondertekend met de privé-sleutel van de afzender, wat de controleur verzekert dat de transactie niet is gewijzigd en is gemaakt door de eigenaar van die sleutel. Maar wat als een kwaadwillende, die de communicatie afluistert, dit bericht opvangt en een exactzelfde bericht opnieuw verzendt? De controleur controleert de handtekening van de transactie en is overtuigd van de authenticiteit, en het netwerk haalt hetzelfde bedrag opnieuw van de balans van de afzender af.
Deze aanval wordt een replay-aanval genoemd. In het UTXO-model zijn dergelijke aanvallen niet relevant, aangezien de aanvaller zal proberen gebruikte uitgangen te gebruiken, wat op zichzelf ongeldig is en door het netwerk wordt afgewezen.
Om te voorkomen dat dit gebeurt, wordt er een veld met willekeurige gegevens in de transactie ingebouwd, dat nonce of gewoon 'zout' wordt genoemd. Bij het opnieuw verzenden van de transactie met 'zout' controleert de controleur of deze nonce eerder is gebruikt en, indien niet, beschouwt hij deze transactie als geldig. Om niet de volledige geschiedenis van gebruikers' nonces in de blockchain op te slaan, wordt bij de allereerste transactie meestal aangenomen dat deze gelijk is aan nul, en daarna met één verhoogd. Het netwerk hoeft alleen maar te controleren of de nonce van de nieuwe transactie verschilt van de vorige met één.
In an anonymous transfer scheme, the problem of validating transaction nonces arises. We cannot directly bind the nonce to the sender's address, as this would obviously deanonymize the transfer. We also cannot increment the nonces of all involved accounts, as this might conflict with other transfers currently being processed.
The authors of Zether suggest generating nonces cryptographically — depending on the 'epoch'. For example:
Hier x — the sender's secret key, and Gepoch — an additional generator for the epoch obtained by hashing a string of the form 'Zether + '. Now the problem seems to be resolved — we do not reveal the sender's nonce and do not interfere with the nonces of uninvolved participants. However, this approach imposes a serious limitation: one account can send no more than one transaction in an 'epoch'. Unfortunately, this problem remains unsolved and currently makes the anonymous version of Zether hardly suitable for use, in our opinion.
Zero-Knowledge Proofs
In UTXO, the sender must prove to the network that they are not spending a negative amount, otherwise, it would be possible to generate new coins out of thin air (why this is possible has been discussed in one of the previous ). They must also sign the 'inputs' with a ring signature to prove that among the mixed coins, there are funds belonging to them.
In the anonymous version of the account-based blockchain, the expressions for proof become much more complex. The sender proves that:
- The amount sent is positive;
- The balance remains non-negative;
- The sender has correctly encrypted the amounts of transfers (including zero);
- The balance changes only for the sender and the receiver;
- The sender possesses the secret key to their account and that they are indeed on the list of senders (among the mixed);
- The nonce used in the transaction is composed correctly.
For such a complex proof, the authors use a mix (one of the authors participated in its creation) and , which is referred to as Sigma-bullets. The formal proof of such a claim is quite a complex task and greatly limits the number of those willing to implement the technology.
Wat is het resultaat?
Naar onze mening kan de Zether-component, die privacy toevoegt aan account-based blockchains, nu al gebruikt worden. Maar op dit moment legt de anonieme versie van de technologie ernstige beperkingen op aan het gebruik, en de complexiteit ervan aan de implementatie. Toch moet men niet vergeten dat de auteurs het pas een paar maanden geleden hebben uitgebracht, en misschien vindt iemand anders wel een oplossing voor de huidige problemen. Dit is tenslotte hoe wetenschap werkt.
Bron: habr.com
