Om anonymitet i kontobaserade blockkedjor

Vi har länge varit intresserade av anonymitet inom kryptovalutor och försöker följa utvecklingen av teknologier inom detta område. I våra artiklar har vi redan ingående behandlat principerna för konfidentiella transaktioner i Monero, samt genomfört en jämförande översyn teknologier som finns inom detta fält. Alla anonyma kryptovalutor idag bygger dock på datamodellen föreslagen av Bitcoin — Unspent Transaction Output (UTXO). För användarbaserade blockkedjor som Ethereum har de befintliga lösningarna för att implementera anonymitet och konfidentialitet (till exempel Mobius eller Aztec) försökt efterlikna UTXO-modellen i smarta kontrakt.

I februari 2019 presenterade en grupp forskare från Stanford University och Visa Research utvecklarna av musikservicen Spotify. Den modifierade Spotify Lite ser ut som den fullständiga versionen, men saknar många inställningar och tillåter inte nedladdning av låtar för lyssning utan internetanslutning. ett preprint "Zether: Mot privatliv i världen av smarta kontrakt". För första gången föreslog författarna en metod för att säkerställa anonymitet i användarbaserade blockkedjor och presenterade två varianter av smarta kontrakt: för konfidentiella (där saldon och belopp av transaktioner döljs) och anonyma (där mottagare och avsändare döljs) transaktioner. Vi finner den föreslagna teknologin intressant och skulle vilja dela dess uppbyggnad, samt diskutera varför anonymitetsproblematiken i användarbaserade blockkedjor anses vara mycket komplex och om författarna har lyckats lösa den fullt ut.

Om dessa datamodellers struktur

I UTXO-modellen består en transaktion av "insats" och "utslag". En direkt analogi till "utslagen" är sedlarna i din plånbok: varje "utslag" har ett visst värde. När du betalar någon (skapar en transaktion) använder du ett eller flera "utslag", som då blir "insatser" i transaktionen, och blockkedjan markerar dem som använda. Samtidigt får mottagaren av din betalning (eller du själv, om du behöver växel) nygenererade "utslag". Schematisk kan detta illustreras så här:

Användarbaserade blockkedjor fungerar ungefär som ditt bankkonto. De hanterar endast summan på ditt konto och summan av överföringen. När du överför ett belopp från ditt konto förbränner du inga "utslag"; nätverket behöver inte komma ihåg vilka mynt som har använts och vilka som inte har använts. I det enklaste fallet består kontrollen av transaktionen av att verifiera avsändarens signatur och beloppet på hans saldo:

Analys av teknologin

Vi kommer nu att diskutera hur Zether döljer beloppet av transaktioner, mottagaren och avsändaren. Under beskrivningen av principerna för dess funktion kommer vi att påpeka skillnaderna mellan konfidentiella och anonyma varianter. Eftersom det är mycket enklare att säkerställa konfidentialitet i kontobaserade blockkedjor, kommer vissa av begränsningarna som åläggs genom anonymisering att vara irrelevanta för den konfidentiella versionen av teknologin.

Döljande av saldon och belopp på överföringar

Zether använder ett krypteringsschema för att kryptera saldon och belopp på överföringar ElGamal. Den fungerar på följande sätt. När Alice vill skicka Bob b mynt till adressen (hans offentliga nyckel) Y, väljer hon ett slumpmässigt tal är lika med noll. och krypterar beloppet:

w C — det krypterade beloppet, D — ett hjälpvärde, nödvändigt för att dekryptera detta belopp, G — en fast punkt på den elliptiska kurvan, på vilken den publika nyckeln genereras genom att multiplicera den hemliga nyckeln.

När Bob får dessa värden lägger han enkelt till dem till sitt krypterade saldo, vilket gör att detta schema är praktiskt.

På liknande sätt drar Alice bort samma värden från sitt saldo, men använder sin offentliga nyckel som Y .

Döljande av mottagare och avsändare

Blandning av "utgångar" i UTXO uppstod redan i kryptovalutornas gryning och hjälper till att dölja avsändaren. För detta väljer avsändaren vid en överföring slumpmässiga "utgångar" i blockkedjan och blandar dem med sina egna. Därefter signerar han "utgångarna" med en ringunderskrift - en kryptografisk mekanism som möjliggör för kontrollanten att övertygas om att det blandade "utgångarna" innehåller avsändarens mynt. Själva de blandade mynten spenderas självklart inte.

För att dölja mottagaren kommer vi dock inte att kunna generera falska "utgångar". Därför har varje "utgång" i UTXO sin unika adress, och den är kryptografiskt kopplad till mottagarens adress för dessa mynt. För närvarande finns det inget sätt att avslöja kopplingen mellan den unika adressen för "utgången" och mottagarens adress utan att känna till dess hemliga nycklar.

I account-based modeller kan vi inte använda engångsadresser (annars blir det redan en "utgångsmodell"). Därför måste mottagaren och avsändaren blandas bland andra konton i blockkedjan. Samtidigt dras det krypterade 0 mynt från de blandade kontona (eller läggs 0 till – i fallet med att blanda mottagaren), utan att förändra deras verkliga saldo.

Eftersom både avsändaren och mottagaren alltid har en konstant adress, uppstår här behovet av att använda samma grupper för blandning vid överföringar till samma adresser. Det är enklare att illustrera med ett exempel.

Anta att Alice har beslutat att göra en donation till Bob's välgörenhetsfond, men föredrar att denna överföring förblir anonym för en tredje parts observatör. Då, för att dölja sig själv i avsändarfältet, skriver hon in ytterligare konton från Adam och Adele. Och för att dölja Bob – i mottagarfältet ytterligare konton från Ben och Bill. Vid nästa donation bestämde sig Alice för att skriva in Alex och Amanda bredvid sig och Bruce och Benjen bredvid Bob. I det här fallet, när man analyserar blockkedjan, kommer det endast att finnas ett överlappande par av deltagare i dessa två transaktioner – Alice och Bob, vilket deanonimiserar dessa transaktioner.

Transaktionslopp

Som vi redan har nämnt, för att dölja sitt saldo i account-based system, krypterar användaren sitt saldo och överföringsbelopp. Detta gäller att han måste bevisa att saldot på hans konto förblir icke-negativt. Problemet är att när användaren skapar en transaktion, bygger han ett bevis angående sitt nuvarande konto. Men vad händer om Bob skickar en transaktion till Alice, och den accepteras innan Alices skickade transaktion? Då kommer Alices transaktion att anses ogiltig, eftersom beviset för saldot byggdes innan Bobs transaktion accepterades.

Den första lösningen som kommer i en sådan situation är att frysa kontot tills transaktionen har genomförts. Men denna metod är inte användbar, eftersom det förutom svårigheterna med att lösa en sådan uppgift i ett distribuerat system, i en anonym schema, kommer det att vara oklart vems konto som ska blockeras.

För att lösa detta problem skiljer teknologin mellan inkommande och utgående transaktioner: utgifter påverkar kontobalansen omedelbart, medan inkomster har en fördröjd effekt. För detta introduceras begreppet "epoker" – grupper av block av fast storlek. Den aktuella "epoken" definieras av blockhöjden delad med gruppstorleken. När en transaktion behandlas uppdaterar nätverket omedelbart avsändarens balans, medan mottagarens medel samlas i en bunt. De insamlade medlen blir tillgängliga för betalningsmottagaren först vid nästa "epok".

Som ett resultat kan användaren skicka transaktioner oberoende av hur ofta han får medel (så länge hans balans tillåter det, förstås). Storleken på epoken bestäms utifrån hur snabbt block sprids genom nätverket och hur snabbt en transaktion går in i ett block.

Denna lösning fungerar bra i fall av konfidentiella överföringar, men i fallet med anonyma transaktioner, som vi senare kommer att se, skapar den allvarliga problem.

Skydd mot replay-attacker

I konto-baserade blockkedjor signeras varje transaktion med avsändarens privata nyckel, vilket övertygar verifieraren om att transaktionen inte har ändrats och att den har skapats av ägaren av denna nyckel. Men vad händer om en illasinnad aktör som avlyssnar överföringskanalen fångar detta meddelande och skickar exakt samma andra? Verifieraren kommer att jämföra transaktionens signatur och vara övertygad om dess äkthet, och nätverket kommer att debitera samma belopp från avsändarens balans igen.

Denna attack kallas replay-attack. I UTXO-modellen är sådana attacker inte aktuella, eftersom den illasinnade aktören kommer att försöka använda spenderade utgångar, vilket i sig är ogiltigt och avvisas av nätverket.

För att förhindra detta inkluderas ett fält med slumpdata i transaktionen, vilket kallas nonce eller helt enkelt "salt". Vid återsending av transaktionen med "salt" kontrollerar verifieraren om denna nonce har använts tidigare, och om inte, anser han att denna transaktion är giltig. För att undvika att lagra hela historiken av användarnas nonces i blockkedjan, accepteras vanligtvis den första transaktionen som noll, och sedan ökas den med en enhet. Nätverket behöver bara kontrollera att den nya transaktionens nonce skiljer sig från den tidigare med en enhet.

I den anonyma överföringsschemat uppstår problemet med validering av transaktionsnonce. Vi kan inte koppla nonce på ett tydligt sätt till avsändarens adress eftersom det uppenbarligen skulle av-anonymisera överföringen. Vi kan inte heller öka nonce för alla deltagande konton, eftersom det kan skapa konflikter med andra överföringar som är under behandling.

Författarna till Zether föreslår att generera nonce kryptografiskt – beroende på "epok". Till exempel:

Här x – avsändarens hemliga nyckel, och Gepoch – en extra generator för epoken, erhållen genom att hash av en sträng som ser ut som 'Zether + '. Nu verkar problemet vara löst – vi avslöjar inte avsändarens nonce och ingriper inte i nonce för opartiska deltagare. Men denna metod innebär ett allvarligt begränsning: ett konto kan inte skicka mer än en transaktion inom en "epok". Detta problem förblir tyvärr olöst och gör den anonyma versionen av Zether, enligt vår uppfattning, knappt användbar.

Svårigheterna med noll-läckagebevis

I UTXO måste avsändaren bevisa för nätverket att de inte spenderar ett negativt belopp, annars blir det möjligt att generera nya mynt ur intet (varför detta är möjligt har vi skrivit om i en av de tidigare artiklar). Dessutom måste de signera "ingångarna" med en ringunderteckning för att bevisa att bland de blandade mynten finns medel som tillhör dem.

I den anonyma versionen av blockkedjan baserad på konto blir uttrycken för bevis mycket mer komplexa. Avsändaren måste bevisa att:

1. Det belopp som skickas är positivt;
2. Saldo förblir icke-negativt;
3. Avsändaren har korrekt krypterat överföringsbeloppen (inklusive nollbelopp);
4. Saldo på kontot ändras endast för avsändaren och mottagaren;
5. Avsändaren äger den hemliga nyckeln till sitt konto och är verkligen med i avsändarlistan (bland de blandade);
6. Nonce som används i transaktionen är korrekt sammansatt.

För en sådan komplex bevisning använder författarna en blandning Oöverträffad (en av författarna deltog för övrigt i dess skapande) och Sigma-protokoll, som kallas Sigma-bullets. Ett formellt bevis på detta påstående är en ganska komplicerad uppgift, och det begränsar kraftigt antalet som vill implementera teknologin.

Vad blir resultatet?

Enligt vår åsikt kan Zether-delarna som bidrar till sekretess i konto-baserade blockkedjor absolut användas redan nu. Men för tillfället innebär den anonyma versionen av teknologin allvarliga begränsningar för dess användning, och dess komplexitet är en utmaning för implementeringen. Men man bör inte glömma att författarna släppte den för bara några månader sedan, och kanske kommer någon annan att hitta lösningar på de problem som finns idag. Det är ju så vetenskapen faktiskt utvecklas.

Källa: habr.com