Vi har varit intresserade av ämnet anonymitet i kryptovalutor under lång tid och försöker följa utvecklingen av teknologier inom detta område. I våra artiklar har vi redan diskuterat principerna för drift i detalj i Monero, och även genomförts teknik som finns på detta område. Alla anonyma kryptovalutor bygger dock idag på datamodellen som föreslås av Bitcoin – Unspent Transaction Output (nedan kallat UTXO). För kontobaserade blockkedjor som Ethereum, befintliga lösningar för implementering av anonymitet och konfidentialitet (till exempel, eller ) försökte replikera UTXO-modellen i smarta kontrakt.
I februari 2019, en grupp forskare från Stanford University och Visa Research släppte "Zether: Mot integritet i en värld av smarta kontrakt." Författarna var de första som föreslog ett tillvägagångssätt för att säkerställa anonymitet i kontobaserade blockkedjor och presenterade två versioner av ett smart kontrakt: för konfidentiella (dölja saldon och överföringsbelopp) och anonyma (dölja mottagaren och avsändaren) transaktioner. Vi tycker att den föreslagna tekniken är intressant och vill gärna dela dess design, samt prata om varför problemet med anonymitet i kontobaserade blockkedjor anses vara mycket svårt och om författarna lyckats lösa det fullt ut.
Om strukturen för dessa datamodeller
I UTXO-modellen består en transaktion av "inputs" och "outputs". Den direkta analogen till "utgångar" är räkningarna i din plånbok: varje "utgång" har en valör. När du betalar någon (bildar en transaktion) spenderar du en eller flera "outputs", i vilket fall de blir "inputs" för transaktionen, och blockkedjan markerar dem som spenderade. I det här fallet får mottagaren av din betalning (eller du själv, om du behöver ändring) de nygenererade "outputs". Detta kan representeras schematiskt så här:
Kontobaserade blockkedjor är strukturerade ungefär som ditt bankkonto. De hanterar bara beloppet på ditt konto och överföringsbeloppet. När du överför något belopp från ditt konto bränner du inga "outputs", nätverket behöver inte komma ihåg vilka mynt som har spenderats och vilka som inte har gjort det. I det enklaste fallet handlar transaktionsverifiering om att kontrollera avsändarens signatur och beloppet på hans saldo:
Analys av teknik
Därefter kommer vi att prata om hur Zether döljer transaktionsbeloppet, mottagaren och avsändaren. När vi beskriver principerna för dess funktion kommer vi att notera skillnaderna i de konfidentiella och anonyma versionerna. Eftersom det är mycket enklare att säkerställa konfidentialitet i kontobaserade blockkedjor, kommer vissa av de restriktioner som införs genom anonymisering inte att vara relevanta för den konfidentiella versionen av tekniken.
Dölja saldon och överföra belopp
Ett krypteringsschema används för att kryptera saldon och överföra belopp i Zether . Det fungerar enligt följande. När Alice vill skicka Bob b mynt efter adress (dess offentliga nyckel) Y, väljer hon ett slumpmässigt tal r och krypterar beloppet:
där C - krypterad mängd, D - hjälpvärde som krävs för att dechiffrera detta belopp, G - en fast punkt på den elliptiska kurvan, när den multipliceras med den hemliga nyckeln erhålls den publika nyckeln.
När Bob får dessa värden lägger han helt enkelt till dem till sitt krypterade saldo på samma sätt, vilket är anledningen till att detta schema är bekvämt.
På samma sätt subtraherar Alice samma värden från sin balans, bara som Y använder din publika nyckel.
Döljer mottagare och avsändare
Blandning av "utgångar" i UTXO går tillbaka till de tidiga dagarna av kryptovalutor och hjälper till att dölja avsändaren. För att göra detta samlar avsändaren själv, när han gör en överföring, slumpmässiga "utgångar" i blockkedjan och blandar dem med sina egna. Därefter signerar han "utgångarna" med en ringsignatur - en kryptografisk mekanism som gör att han kan övertyga verifieraren om att avsändarens mynt finns bland de inblandade "utgångarna". De blandade mynten i sig spenderas naturligtvis inte.
Vi kommer dock inte att kunna generera falska utdata för att dölja mottagaren. Därför, i UTXO, har varje "utgång" sin egen unika adress, och den är kryptografiskt länkad till adressen till mottagaren av dessa mynt. För tillfället finns det inget sätt att identifiera förhållandet mellan den unika utgående adressen och mottagaradressen utan att känna till dess hemliga nycklar.
I den kontobaserade modellen kan vi inte använda engångsadresser (annars blir det redan en "exits"-modell). Därför måste mottagaren och avsändaren blandas bland andra konton i blockkedjan. I det här fallet debiteras ett krypterat 0-mynt från de blandade kontona (eller 0 läggs till om mottagaren är blandad), utan att deras verkliga saldo faktiskt ändras.
Eftersom både avsändaren och mottagaren alltid har en fast adress blir det nödvändigt att använda samma grupper för blandning vid överföring till samma adresser. Det är lättare att se på detta med ett exempel.
Låt oss säga att Alice bestämmer sig för att ge ett bidrag till Bobs välgörenhet, men föredrar att överföringen förblir anonym för en extern observatör. Sedan, för att maskera sig i avsändarfältet, går hon också in på Adams och Adeles konton. Och för att dölja Bob lägger du till Ben och Bills konton i mottagarfältet. När hon gjorde nästa bidrag, bestämde sig Alice för att skriva Alex och Amanda bredvid henne, och Bruce och Benjen bredvid Bob. I det här fallet, när man analyserar blockkedjan, finns det i dessa två transaktioner bara ett korsande par av deltagare - Alice och Bob, som avanonymiserar dessa transaktioner.
Transaktionslopp
Som vi redan har nämnt, för att dölja ditt saldo i kontobaserade system, krypterar användaren sitt saldo och överföringsbeloppet. Samtidigt måste han bevisa att saldot på hans konto förblir icke-negativt. Problemet är att när användaren skapar en transaktion bygger användaren ett bevis angående hans nuvarande kontostatus. Vad händer om Bob skickar en transaktion till Alice och den accepteras före den som skickats av Alice? Då kommer Alices transaktion att betraktas som ogiltig, eftersom balansbeviset byggdes innan Bobs transaktion accepterades.
Det första beslutet som kommer i en sådan situation är att frysa kontot tills transaktionen är genomförd. Men detta tillvägagångssätt är inte lämpligt, eftersom det förutom komplexiteten att lösa ett sådant problem i ett distribuerat system, i ett anonymt system inte kommer att vara klart vems konto som ska blockeras.
För att lösa detta problem separerar tekniken inkommande och utgående transaktioner: utgifterna har en omedelbar effekt på balansräkningen, medan kvitton har en fördröjd effekt. För att göra detta introduceras begreppet "epok" - en grupp block av en fast storlek. Den aktuella "epok" bestäms genom att dividera blockhöjden med gruppstorleken. Vid bearbetning av en transaktion uppdaterar nätverket omedelbart avsändarens saldo och lagrar mottagarens pengar i en lagringstank. De ackumulerade medlen görs tillgängliga för betalningsmottagaren först när en ny "era" börjar.
Som ett resultat kan användaren skicka transaktioner oavsett hur ofta pengar tas emot (så långt som hans saldo tillåter, naturligtvis). Epokstorleken bestäms utifrån hur snabbt block sprider sig genom nätverket och hur snabbt en transaktion går in i ett block.
Denna lösning fungerar bra för konfidentiella överföringar, men med anonyma transaktioner, som vi kommer att se senare, skapar den allvarliga problem.
Skydd mot reprisattacker
I kontobaserade blockkedjor signeras varje transaktion av avsändarens privata nyckel, vilket övertygar verifieraren om att transaktionen inte har modifierats och skapades av ägaren till denna nyckel. Men vad händer om en angripare som lyssnade på överföringskanalen fångar upp detta meddelande och skickar exakt samma andra? Verifieraren kommer att verifiera transaktionens signatur och kommer att vara övertygad om dess författare, och nätverket kommer att skriva av samma belopp från avsändarens saldo igen.
Denna attack kallas en replay attack. I UTXO-modellen är sådana attacker inte relevanta, eftersom angriparen kommer att försöka använda förbrukade utdata, vilket i sig inte är giltigt och avvisas av nätverket.
För att förhindra att detta händer byggs ett fält med slumpmässiga data in i transaktionen, vilket kallas en nonce eller helt enkelt "salt". När du skickar om en transaktion med ett salt, ser verifieraren efter om nonce har använts tidigare och, om inte, anser att transaktionen är giltig. För att inte lagra hela historiken för användarnaser i blockkedjan, vanligtvis i den allra första transaktionen sätts den lika med noll och ökas sedan med en. Nätverket kan bara kontrollera att den nya transaktionen avviker från den föregående.
I det anonyma överföringsschemat uppstår problemet med att validera transaktionsavvisanden. Vi kan inte uttryckligen binda nonce till avsändarens adress, eftersom detta uppenbarligen avanonymiserar överföringen. Vi kan inte heller lägga till en till nonces för alla deltagande konton, eftersom detta kan komma i konflikt med andra överföringar som bearbetas.
Författarna till Zether föreslår att generera nonce kryptografiskt, beroende på "epoken". Till exempel:
Här x är avsändarens hemliga nyckel, och Gepoch — en extra generator för epoken, erhållen genom att hasha en sträng av formen 'Zether +'. Nu verkar problemet vara löst - vi avslöjar inte avsändarens nonce och stör inte oinvolverade deltagares nonces. Men detta tillvägagångssätt innebär en allvarlig begränsning: ett konto kan inte skicka mer än en transaktion per "epok". Detta problem förblir tyvärr olöst och för närvarande gör den anonyma versionen av Zether, enligt vår mening, knappast lämplig att använda.
Komplexiteten med noll kunskapsbevis
I UTXO måste avsändaren bevisa för nätverket att han inte spenderar ett negativt belopp, annars blir det möjligt att generera nya mynt ur tomma intet (varför detta är möjligt, skrev vi i en av de tidigare ). Och signera också "ingångarna" med en ringsignatur för att bevisa att bland mynten som blandas finns det fonder som tillhör honom.
I den anonyma versionen av den kontobaserade blockkedjan är uttrycken för bevis mycket mer komplexa. Avsändaren bevisar att:
- Det skickade beloppet är positivt;
- Balansen förblir icke-negativ;
- Avsändaren krypterade överföringsbeloppen korrekt (inklusive noll);
- Saldot på saldot ändras endast för avsändaren och mottagaren;
- Avsändaren äger den privata nyckeln till sitt konto och han finns faktiskt på listan över avsändare (bland de inblandade);
- Den nonce som används i transaktionen är korrekt sammansatt.
För ett så komplext bevis använder författarna en blandning (en av författarna deltog förresten i dess tillkomst) och , som kallas Sigma-kulor. Formella bevis för ett sådant uttalande är en ganska svår uppgift, och det begränsar i hög grad antalet personer som är villiga att implementera tekniken.
Resultatet?
Enligt vår åsikt kan den del av Zether som ger integritet till kontobaserade blockkedjor användas just nu. Men för tillfället sätter den anonyma versionen av tekniken allvarliga begränsningar för dess användning och dess komplexitet för dess implementering. Det ska dock inte bortses från att författarna släppte den för bara några månader sedan, och kanske hittar någon annan en lösning på de problem som finns idag. Det är trots allt så vetenskap görs.
Källa: will.com