Vi har vært interessert i temaet anonymitet i kryptovalutaer i lang tid og prøver å følge utviklingen av teknologier på dette området. I artiklene våre har vi allerede diskutert i detalj prinsippene for drift i Monero, og også gjennomført teknologier som eksisterer på dette feltet. Imidlertid er alle anonyme kryptovalutaer i dag bygget på datamodellen foreslått av Bitcoin – Unspent Transaction Output (heretter kalt UTXO). For kontobaserte blokkjeder som Ethereum, eksisterende løsninger for implementering av anonymitet og konfidensialitet (f.eks. eller ) prøvde å gjenskape UTXO-modellen i smarte kontrakter.
I februar 2019, en gruppe forskere fra Stanford University og Visa Research løslatt "Zether: Mot personvern i en verden av smarte kontrakter." Forfatterne var de første som foreslo en tilnærming for å sikre anonymitet i kontobaserte blokkjeder og presenterte to versjoner av en smart kontrakt: for konfidensielle (skjule saldo og overføringsbeløp) og anonyme (skjule mottaker og avsender) transaksjoner. Vi finner den foreslåtte teknologien interessant og vil gjerne dele designet, samt snakke om hvorfor problemet med anonymitet i kontobaserte blokkjeder anses som svært vanskelig og om forfatterne klarte å løse det fullt ut.
Om strukturen til disse datamodellene
I UTXO-modellen består en transaksjon av "inputs" og "outputs". En direkte analog av "utganger" er regningene i lommeboken din: hver "utgang" har en pålydende verdi. Når du betaler noen (danner en transaksjon) bruker du en eller flere "utganger", i så fall blir de "innganger" for transaksjonen, og blokkjeden merker dem som brukt. I dette tilfellet mottar mottakeren av betalingen din (eller du selv, hvis du trenger endring) de nylig genererte "utgangene". Dette kan representeres skjematisk slik:
Kontobaserte blokkjeder er strukturert omtrent som bankkontoen din. De tar kun for seg beløpet på kontoen din og overføringsbeløpet. Når du overfører et beløp fra kontoen din, brenner du ingen "utganger", nettverket trenger ikke å huske hvilke mynter som er brukt og hvilke som ikke har brukt det. I det enkleste tilfellet handler transaksjonsbekreftelse om å sjekke avsenderens signatur og beløpet på saldoen hans:
Analyse av teknologi
Deretter skal vi snakke om hvordan Zether skjuler transaksjonsbeløpet, mottakeren og avsenderen. Når vi beskriver prinsippene for driften, vil vi legge merke til forskjellene i de konfidensielle og anonyme versjonene. Siden det er mye lettere å sikre konfidensialitet i kontobaserte blokkjeder, vil noen av begrensningene som legges ved anonymisering ikke være relevante for den konfidensielle versjonen av teknologien.
Skjul saldo og overføre beløp
Et krypteringsskjema brukes til å kryptere saldoer og overføre beløp i Zether . Det fungerer som følger. Når Alice vil sende Bob b mynter etter adresse (den offentlige nøkkelen) Y, velger hun et tilfeldig tall r og krypterer beløpet:
der C - kryptert beløp, D - hjelpeverdi som er nødvendig for å tyde dette beløpet, G - et fast punkt på den elliptiske kurven, når multiplisert med den hemmelige nøkkelen, oppnås den offentlige nøkkelen.
Når Bob mottar disse verdiene, legger han dem ganske enkelt til den krypterte saldoen sin på samme måte, og det er derfor denne ordningen er praktisk.
På samme måte trekker Alice de samme verdiene fra balansen hennes, bare som Y bruker den offentlige nøkkelen din.
Skjuler mottaker og avsender
Blanding av "utganger" i UTXO dateres tilbake til de tidlige dagene med kryptovalutaer og hjelper til med å skjule avsenderen. For å gjøre dette, samler avsenderen selv, når han foretar en overføring, tilfeldige "utganger" i blokkjeden og blander dem med sine egne. Deretter signerer han "utgangene" med en ringsignatur - en kryptografisk mekanisme som lar ham overbevise verifikatoren om at avsenderens mynter er tilstede blant de involverte "utgangene". Selve de blandede myntene blir selvfølgelig ikke brukt.
Vi vil imidlertid ikke kunne generere falske utdata for å skjule mottakeren. Derfor, i UTXO, har hver "utgang" sin egen unike adresse, og den er kryptografisk knyttet til adressen til mottakeren av disse myntene. For øyeblikket er det ingen måte å identifisere forholdet mellom den unike utdataadressen og mottakeradressen uten å kjenne dens hemmelige nøkler.
I den kontobaserte modellen kan vi ikke bruke engangsadresser (ellers vil det allerede være en "exits"-modell). Derfor må mottaker og avsender blandes blant andre kontoer i blokkjeden. I dette tilfellet debiteres en kryptert 0-mynter fra de blandede kontoene (eller 0 legges til hvis mottakeren er blandet), uten faktisk å endre deres reelle saldo.
Siden både avsender og mottaker alltid har fast adresse, blir det nødvendig å bruke samme grupper for blanding ved overføring til samme adresser. Det er lettere å se på dette med et eksempel.
La oss si at Alice bestemmer seg for å gi et bidrag til Bobs veldedighet, men foretrekker at overføringen forblir anonym for en ekstern observatør. Så, for å forkle seg i avsenderfeltet, går hun også inn på kontoene til Adam og Adele. Og for å skjule Bob, legg til kontoene til Ben og Bill i mottakerfeltet. I det neste bidraget bestemte Alice seg for å skrive Alex og Amanda ved siden av henne, og Bruce og Benjen ved siden av Bob. I dette tilfellet, når man analyserer blokkjeden, er det i disse to transaksjonene bare ett kryssende par deltakere - Alice og Bob, som avanonymiserer disse transaksjonene.
Transaksjonsløp
Som vi allerede har nevnt, for å skjule saldoen din i kontobaserte systemer, krypterer brukeren sin saldo og overføringsbeløpet. Samtidig må han bevise at saldoen på kontoen hans forblir ikke-negativ. Problemet er at når du oppretter en transaksjon, bygger brukeren et bevis angående hans nåværende kontostatus. Hva skjer hvis Bob sender en transaksjon til Alice, og den blir akseptert før den som er sendt av Alice? Da vil Alices transaksjon anses som ugyldig, siden balansebeviset ble bygget før Bobs transaksjon ble akseptert.
Den første avgjørelsen som kommer 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 et slikt problem i et distribuert system, vil det i en anonym ordning ikke være klart hvem kontoen skal blokkeres.
For å løse dette problemet skiller teknologien inngående og utgående transaksjoner: utgifter har en umiddelbar effekt på balansen, mens kvitteringer har en forsinket effekt. For å gjøre dette introduseres konseptet "epoke" - en gruppe blokker med fast størrelse. Den nåværende "epoken" bestemmes ved å dele blokkhøyden med gruppestørrelsen. Ved behandling av en transaksjon oppdaterer nettverket umiddelbart avsenderens saldo og lagrer mottakerens midler i en lagertank. De akkumulerte midlene gjøres tilgjengelig for betalingsmottakeren først når en ny "æra" begynner.
Som et resultat kan brukeren sende transaksjoner uavhengig av hvor ofte midler mottas (så langt som saldoen hans tillater, selvfølgelig). Epokestørrelsen bestemmes basert på hvor raskt blokker forplanter seg gjennom nettverket og hvor raskt en transaksjon kommer inn i en blokk.
Denne løsningen fungerer bra for konfidensielle overføringer, men med anonyme transaksjoner, som vi skal se senere, skaper den alvorlige problemer.
Beskyttelse mot replay-angrep
I kontobaserte blokkjeder er hver transaksjon signert av avsenderens private nøkkel, noe som overbeviser verifikatoren om at transaksjonen ikke er endret og ble opprettet av eieren av denne nøkkelen. Men hva om en angriper som lyttet til overføringskanalen fanger opp denne meldingen og sender nøyaktig den samme andre? Verifikatoren vil verifisere signaturen til transaksjonen og vil være overbevist om forfatterskapet, og nettverket vil avskrive det samme beløpet fra avsenderens saldo igjen.
Dette angrepet kalles et replay-angrep. I UTXO-modellen er slike angrep ikke relevante, siden angriperen vil prøve å bruke brukte utganger, som i seg selv ikke er gyldige og avvises av nettverket.
For å forhindre at dette skjer, bygges et felt med tilfeldige data inn i transaksjonen, som kalles en nonce eller ganske enkelt "salt". Når du sender inn en transaksjon med et salt på nytt, ser verifikatoren for å se om nonce har blitt brukt før og, hvis ikke, anser transaksjonen som gyldig. For ikke å lagre hele historikken til brukernonces i blokkjeden, settes den vanligvis i den aller første transaksjonen lik null, og økes deretter med én. Nettverket kan bare kontrollere at den nye transaksjonen ikke er forskjellig fra den forrige.
I den anonyme overføringsordningen oppstår problemet med å validere transaksjonsavbrudd. Vi kan ikke eksplisitt binde nonce til avsenderens adresse, siden dette åpenbart de-anonymiserer overføringen. Vi kan heller ikke legge til en til nonsene til alle deltakende kontoer, da dette kan komme i konflikt med andre overføringer som behandles.
Forfatterne av Zether foreslår å generere nonce kryptografisk, avhengig av "epoken". For eksempel:
Her x er avsenderens hemmelige nøkkel, og Gepoch — en ekstra generator for epoken, oppnådd ved å hashe en streng med formen 'Zether + '. Nå ser det ut til at problemet er løst - vi avslører ikke avsenderens nonce og forstyrrer ikke uinvolverte deltakere. Men denne tilnærmingen pålegger en alvorlig begrensning: én konto kan ikke sende mer enn én transaksjon per "epoke". Dette problemet forblir dessverre uløst, og gjør den anonyme versjonen av Zether, etter vår mening, neppe egnet for bruk.
Kompleksiteten til null kunnskapsbevis
I UTXO må avsenderen bevise overfor nettverket at han ikke bruker et negativt beløp, ellers blir det mulig å generere nye mynter ut av løse luften (hvorfor dette er mulig, skrev vi i en av de forrige ). Og signer også "inngangene" med en ringsignatur for å bevise at blant myntene som blandes er det midler som tilhører ham.
I den anonyme versjonen av den kontobaserte blokkjeden er uttrykkene for bevis mye mer komplekse. Avsenderen beviser at:
- Sendt beløp er positivt;
- Balansen forblir ikke-negativ;
- Avsenderen krypterte overføringsbeløpene riktig (inkludert null);
- Saldoen på saldoen endres kun for avsender og mottaker;
- Avsenderen eier den private nøkkelen til kontoen sin, og han er faktisk på listen over avsendere (blant de involverte);
- Nonce brukt i transaksjonen er riktig sammensatt.
For et så komplekst bevis bruker forfatterne en blanding (en av forfatterne deltok forresten i opprettelsen) og , som kalles Sigma-kuler. Formelt bevis på en slik uttalelse er en ganske vanskelig oppgave, og det begrenser i stor grad antallet personer som er villige til å implementere teknologien.
Resultatet?
Etter vår mening kan den delen av Zether som bringer personvern til kontobaserte blokkjeder brukes akkurat nå. Men for øyeblikket legger den anonyme versjonen av teknologien alvorlige begrensninger på bruken og kompleksiteten på implementeringen. Det skal imidlertid ikke utelukkes at forfatterne ga den ut for bare noen måneder siden, og kanskje vil noen andre finne en løsning på problemene som eksisterer i dag. Tross alt er det slik vitenskap gjøres.
Kilde: www.habr.com