Om anonymitet i account-based blokkjeder

Vi har lenge vært interessert i anonymitet i kryptovalutaer og prøver å følge med på utviklingen av teknologier innen dette feltet. I artiklene våre har vi allerede grundig gjennomgått prinsippene for konfidensielle transaksjoner i Monero, samt gjennomført en sammenlignende oversikt over teknologier som eksisterer på dette området. Alle anonyme kryptovalutaer i dag er imidlertid bygget på datamodellen foreslått av Bitcoin – Unspent Transaction Output (UTXO). For konto-baserte blokkjeder som Ethereum har eksisterende løsninger for implementering av anonymitet og konfidensialitet (for eksempel Mobius eller Aztec) forsøkt å gjenskape UTXO-modellen i smarte kontrakter.

I februar 2019 publiserte en gruppe forskere fra Stanford University og Visa Research har gitt ut et preprint "Zether: På vei mot konfidensialitet i verden av smarte kontrakter". Forfatterne foreslo for første gang en tilnærming for å sikre anonymitet i konto-baserte blokkjeder og presenterte to typer smarte kontrakter: for konfidensielle (skjuling av saldoer og transaksjonsbeløp) og anonyme (skjuling av mottaker og avsender) transaksjoner. Vi finner den foreslåtte teknologien interessant og ønsker å dele dens oppbygning, samt diskutere hvorfor anonymitetsproblemet i konto-baserte blokkjeder anses som veldig komplekst og om forfatterne har klart å løse det fullt ut.

Om oppbygningen av disse datamodellene

I UTXO-modellen består en transaksjon av "innganger" og "utganger". Den direkte analogen til "utgangene" er sedler i lommeboken din: hver "utgang" har en viss verdi. Når du betaler noen (danner en transaksjon), bruker du en eller flere "utganger", som deretter blir "innganger" i transaksjonen, og blokkjeden markerer dem som brukt. Mottakeren av betalingen din (eller deg selv, hvis du trenger veksling) mottar deretter ny-genererte "utganger". Schematiske kan dette illustreres slik:

Konto-baserte blokkjeder fungerer omtrent som bankkontoen din. De håndterer bare beløpet på kontoen din og overføringsbeløpet. Når du overfører et beløp fra kontoen din, brenner du ikke noen "utganger"; nettverket trenger ikke å huske hvilke mynter som er brukt og hvilke som ikke er. I det enkleste tilfellet reduseres verifiseringen av transaksjonen til å kontrollere avsenderens signatur og beløpet på saldoen hans:

Analyse av teknologien

Vidare skal vi snakke om hvordan Zether skjuler beløpet for transaksjoner, mottaker og avsender. Underveis i beskrivelsen av prinsippene for hvordan det fungerer, vil vi påpeke forskjellene mellom den konfidensielle og anonyme varianten. Siden det er mye enklere å sikre konfidensialitet i konto-baserte blokkjeder, vil noen av begrensningene som pålegges anonymisering, være irrelevante for den konfidensielle versjonen av teknologien.

Skjuling av balanse og overføringsbeløp

For kryptering av balanser og overføringsbeløp i Zether brukes en krypteringsordning ElGamal. Den fungerer på følgende måte: Når Alice ønsker å sende til Bob b mynter til adressen (hans offentlige nøkkel) Y, velger hun et tilfeldig tall, r og krypterer beløpet:

der C — det krypterte beløpet, D — et hjelpeverdi som er nødvendig for å dekryptere dette beløpet, G — et fast punkt på den elliptiske kurven, når man multipliserer den hemmelige nøkkelen med, får man den offentlige nøkkelen.

Når Bob mottar disse verdiene, legger han dem enkelt til sin egen krypterte balanse på samme måte, noe som gjør ordningen praktisk.

På samme måte trekker Alice de samme verdiene fra sin balanse, men bruker Y sin offentlige nøkkel.

Skjuling av mottaker og avsender

Blandingen av "utganger" i UTXO kom frem tidlig i kryptovalutaens utvikling og hjelper med å skjule avsenderen. For dette formålet velger avsenderen tilfeldige "utganger" i blokkjeden ved overføringen og blander dem med sine egne. Deretter signerer han "utgangene" med en ringegodkjenning — en kryptografisk mekanisme som gjør at kontrolløren kan overbevises om at blant de blandede "utgangene" finnes mynter fra avsenderen. De blandede myntene blir selvsagt ikke brukt.

Imidlertid vil det ikke være mulig for å skjule mottakeren å generere falske "utganger". Derfor har hver "utgang" i UTXO sin unike adresse, og den er kryptografisk knyttet til mottakerens adresse for disse myntene. Per nå finnes det ingen måte å avdekke forholdet mellom den unike adressen på "utgangen" og adressen til mottakeren uten å kjenne hans hemmelige nøkler.

I account-based modellen kan vi ikke bruke engangsadresser (ellers ville det allerede vært en «utgangs»-modell). Derfor må mottakeren og avsenderen blandes blant andre kontoer i blokkjeden. I denne prosessen trekkes det krypterte 0 mynter fra de blandede kontoene (eller legges til 0 — i tilfelle av blanding av mottakeren), uten å endre deres reelle saldo.

Siden både avsender og mottaker alltid har en fast adresse, oppstår behovet for å bruke de samme gruppene for blanding ved overføringer til de samme adressene. Det er enklest å se dette med et eksempel.

La oss si at Alice ønsker å gi et bidrag til Bob sin veldedige stiftelse, men foretrekker at denne overføringen forblir anonym for en utenforstående observatør. For å maskere seg selv i avsenderfeltet, legger hun til kontoene til Adam og Adele. For å skjule Bob i mottakerfeltet, legger hun også til kontoene til Ben og Bill. Når Alice gjør sitt neste bidrag, bestemmer hun seg for å legge til Alex og Amanda ved siden av seg selv, og Bruce og Benjen ved siden av Bob. I dette tilfellet, når man analyserer blokkjeden, vil det kun være ett kryssende par deltakere i disse to transaksjonene — Alice og Bob, som avdekker disse transaksjonene.

Transaksjonsracing

Som vi allerede har nevnt, for å skjule sin saldo i account-based systemer, krypterer brukeren sin saldo og overføringsbeløpet. I tillegg må han bevise at saldoen på kontoen hans forblir ikke-negativ. Problemet er at når brukeren lager en transaksjon, bygger han bevis rundt sin nåværende kontobalanse. Hva skjer hvis Bob sender en transaksjon til Alice, og den blir akseptert før den som Alice sendte? Da vil transaksjonen til Alice bli ansett som ugyldig, fordi beviset på saldoen ble bygget før akseptasjonen av transaksjonen til Bob.

Den første løsningen som kommer opp i en slik situasjon, er å fryse kontoen til transaksjonen er gjennomført. Men denne tilnærmingen er ikke egnet, fordi, i tillegg til kompleksiteten ved å løse en slik oppgave i et distribuert system, vil det i en anonym ordning være uklart hvis hvilken konto som skal blokkeres.

For å løse dette problemet deler teknologien inn i innkommende og utgående transaksjoner: uttak av midler har umiddelbar effekt på saldoen, mens innskudd er forsinket. Dette innfører begrepet «epoker» — grupper av blokker med fast størrelse. Den nåværende «epoken» bestemmes ved å dele blokkhøyden med størrelsen på gruppen. Når en transaksjon behandles, oppdaterer nettverket senderens saldo umiddelbart, mens midlene til mottakeren legges i en lagringskapsel. De akkumulerte midlene blir tilgjengelig for mottakeren først når en ny «epoke» inntreffer.

Som et resultat kan brukeren sende transaksjoner uavhengig av hvor ofte han mottar midler (så langt som balansen hans tillater selvsagt). Størrelsen på epoken bestemmes av hvor raskt blokkene sprer seg i nettverket og hvor raskt en transaksjon kommer inn i en blokk.

Denne løsningen fungerer godt for konfidensielle overføringer, men når det gjelder anonyme transaksjoner, som vi vil se senere, skaper den alvorlige problemer.

Beskyttelse mot replay-angrep

I konto-baserte blokkjeder signeres hver transaksjon med senderens private nøkkel, noe som bekrefter for kontrolløren at transaksjonen ikke har blitt endret og at den ble laget av eieren av denne nøkkelen. Men hva hvis en angriper som overvåker overføringskanalen, fanger opp denne meldingen og sender nøyaktig den samme andre? Kontrolløren vil verifisere transaksjonens signatur og være overbevist om dens eierskap, og nettverket vil trekke det samme beløpet fra senderens saldo igjen.

Dette angrepet kalles et replay-angrep. I UTXO-modellen er slike angrep ikke relevante, ettersom angriperen vil forsøke å bruke allerede brukte utganger, noe som i seg selv ikke er gyldig og blir avvist av nettverket.

For å forhindre dette, integreres et felt med tilfeldige data i transaksjonen, kjent som nonce eller bare «salt». Ved en gjentatt sending av transaksjonen med «salt», kontrollerer verifisereren om denne nonce tidligere har vært brukt, og hvis ikke, anser denne transaksjonen som gyldig. For å unngå å måtte lagre hele historien med brukernes noncer i blokkjeden, aksepteres vanligvis nonce som lik null i den første transaksjonen, og deretter økes det med én. Nettverket må bare sjekke at nonce for den nye transaksjonen er forskjellig fra den forrige med én.

I den anonyme overføringsordning oppstår problemet med validering av nonce for transaksjoner. Vi kan ikke knytte nonce eksplisitt til avsenders adresse, da dette åpenbart ville de-anonymisere overføringen. Vi kan heller ikke legge til en enhet til nonce for alle involverte kontoer, ettersom dette kan komme i konflikt med andre overføringer som er under behandling.

Forfatterne av Zether foreslår å generere nonce kryptografisk — avhengig av "æra". For eksempel:

Her x — den hemmelige nøkkelen til avsenderen, og Gepoch — en ekstra generator for æraen, oppnådd ved å hashe en streng av typen 'Zether + '. Nå ser problemet ut til å bli løst — vi avslører ikke avsenderens nonce og blander oss ikke inn i nonce for ikke-involverte deltakere. Men denne tilnærmingen medfører en alvorlig begrensning: en konto kan sende ikke mer enn én transaksjon per "æra". Dette problemet forblir dessverre uløst, og for øyeblikket gjør det den anonyme versjonen av Zether, etter vår mening, knapt brukbar.

Vanskeligheten med null-oppløsningsbevis

I UTXO må avsenderen bevise for nettverket at de ikke bruker en negativ sum, ellers blir det mulig å generere nye mynter ut av intet (hvorfor dette er mulig, har vi skrevet om i en av de tidligere artiklene). Og de må også signere "innganger" med en ring signatur for å bevise at det er midler som tilhører dem blant de blandede myntene.

I den anonyme versjonen av account-based blokkjeden blir uttrykkene for bevisene mye mer kompliserte. Avsenderen må bevise at:

1. Den sendte summen er positiv;
2. Salden forblir ikke-negativ;
3. Avsenderen har korrekt kryptert overføringsbeløpene (inkludert null);
4. Saldoen endres kun hos avsenderen og mottakeren;
5. Avsenderen eier den hemmelige nøkkelen til kontoen sin, og den er faktisk på listen over sendere (blant de blandede);
6. Nonce brukt i transaksjonen er korrekt sammensatt.

For så komplekse bevis bruker forfatterne en blanding Kulepunkter (en av forfatterne har forresten deltatt i utviklingen av dette) og Sigma-protokollen, som de kaller Sigma-bullets. Det formelle beviset for et slikt utsagn er en ganske komplisert oppgave, og det begrenser sterkt antall som ønsker å implementere teknologien.

Hva ble resultatet?

Etter vårt syn kan delen av Zether som bringer personvern til konto-baserte blokkjeder, absolutt brukes allerede nå. Men for øyeblikket pålegger den anonyme versjonen av teknologien betydelige begrensninger på bruken, og dens kompleksitet påvirker implementeringen. Det er imidlertid verdt å huske på at forfatterne kun har lansert den for noen måneder siden, og kanskje noen andre vil finne løsninger på de utfordringene som eksisterer i dag. Tross alt er det nettopp slik vitenskap fungerer.

Kilde: habr.com