Ons het lank belanggestel in die onderwerp van anonimiteit in kripto-geldeenhede en probeer om die ontwikkeling van tegnologie op hierdie gebied te volg. In ons artikels het ons reeds die beginsels van werk in detail ontleed in Monero, en ook gehou tegnologie op hierdie gebied. Alle anonieme kripto-geldeenhede is egter vandag gebou op die datamodel wat deur Bitcoin voorgestel word - Onbestede transaksie-uitset (hierna verwys as UTXO). Vir rekeninggebaseerde blokkettings soos Ethereum, bestaande anonimiteit- en privaatheidsoplossings (byvoorbeeld, of ) het probeer om die UTXO-model in slim kontrakte te herhaal.
In Februarie 2019, 'n span navorsers van Stanford Universiteit en Visa Research vrygelaat "Zether: Op pad na privaatheid in die wêreld van slim kontrakte". Die skrywers het vir die eerste keer 'n benadering voorgestel om anonimiteit in rekeninggebaseerde blokkettings te verseker en twee opsies vir 'n slim kontrak aangebied: vir vertroulike (versteek saldo's en oordragbedrae) en anonieme (versteek die ontvanger en sender) transaksies. Ons vind die voorgestelde tegnologie interessant en wil graag die ontwerp daarvan deel, asook praat oor hoekom die probleem van anonimiteit in rekeninggebaseerde blokkettings as baie moeilik beskou word en of die skrywers daarin geslaag het om dit ten volle op te los.
Oor die struktuur van hierdie datamodelle
In die UTXO-model bestaan 'n transaksie uit "insette" en "uitsette". Die direkte analoog van "uitsette" is banknote in jou beursie: elke "uitset" het 'n denominasie. Wanneer jy iemand betaal (vorm 'n transaksie), spandeer jy een of meer "uitsette", terwyl hulle "insette" van die transaksie word, en die blokketting merk dit as bestee. In hierdie geval ontvang die ontvanger van jou betaling (of jyself, as jy verandering nodig het) die nuutgegenereerde "uitsette". Skematies kan dit soos volg voorgestel word:
Rekeninggebaseerde blokkettings word baie soos jou bankrekening opgestel. Hulle werk slegs op die bedrag in jou rekening en die bedrag van die oordrag. Wanneer jy 'n bedrag van jou rekening oorplaas, verbrand jy geen "uitsette nie", die netwerk hoef nie te onthou watter munte bestee word en watter nie. In die eenvoudigste geval kom die kontrolering van 'n transaksie neer op die kontrolering van die sender se handtekening en die bedrag op sy saldo:
Tegnologie Analise
Vervolgens sal ons praat oor hoe Zether die hoeveelheid transaksies, die ontvanger en die sender verberg. In die loop van die beskrywing van die beginsels van die werking daarvan, sal ons let op die verskille in die vertroulike en anonieme weergawe. Aangesien dit baie makliker is om privaatheid in rekeninggebaseerde blokkettings te verskaf, sal sommige van die beperkings wat deur anonimisering opgelê word nie relevant wees vir die vertroulike weergawe van die tegnologie nie.
Versteek saldo's en oordragbedrae
Zether gebruik 'n enkripsieskema om saldo's te enkripteer en bedrae oor te dra . Dit werk soos volg. Wanneer Alice vir Bob wil stuur b munte volgens adres (die publieke sleutel daarvan) Y, kies sy 'n ewekansige nommer r en enkripteer die bedrag:
waar C - geënkripteerde bedrag, D - 'n hulpwaarde wat nodig is om hierdie bedrag te ontsyfer, G - 'n vaste punt op 'n elliptiese kromme, wanneer die geheime sleutel waarmee die publieke sleutel verkry word, vermenigvuldig word.
Wanneer Bob hierdie waardes ontvang, voeg hy dit eenvoudig by sy balans geïnkripteer op dieselfde manier, wat gerieflik is vir hierdie skema.
Net so trek Alice dieselfde waardes van haar balans af, net as Y gebruik sy publieke sleutel.
Versteek die geadresseerde en sender
Die vermenging van "uitsette" in UTXO het aan die begin van kripto-geldeenhede verskyn en help om die sender weg te steek. Om dit te doen, versamel die sender self, wanneer hy 'n oordrag maak, ewekansige "uitsette" in die blokketting en meng dit met sy eie. Dan teken hy die "uitsette" met 'n ringhandtekening, 'n kriptografiese meganisme wat jou toelaat om die verifieerder te oortuig dat die sender se munte onder die betrokke "uitsette" is. Die munte self word natuurlik nie spandeer nie.
Om die ontvanger egter weg te steek, sal ons nie vals "uitsette" kan genereer nie. Daarom, in UTXO, het elke "uitset" sy eie unieke adres, en dit word kriptografies geassosieer met die adres van die ontvanger van hierdie munte. Op die oomblik is daar geen manier om die verwantskap tussen die unieke "uitgang"-adres en die adres van die ontvanger te openbaar sonder om sy geheime sleutels te ken nie.
In die rekeninggebaseerde model kan ons nie eenmalige adresse gebruik nie (anders sal dit reeds 'n "uitgange"-model wees). Daarom moet die ontvanger en sender onder ander rekeninge in die blokketting gemeng word. Terselfdertyd word geënkripteerde 0-munte van die gemengde rekeninge afgetrek (of 0 word bygevoeg as die ontvanger gemeng is), sonder om hul werklike saldo werklik te verander.
Aangesien beide die sender en die ontvanger altyd 'n permanente adres het, word dit hier nodig om dieselfde groepe vir vermenging te gebruik wanneer na dieselfde adresse oorgeplaas word. Dit is makliker om dit met 'n voorbeeld te sien.
Kom ons sê Alice besluit om 'n skenking aan Bob se liefdadigheidsstigting te maak, maar verkies dat hierdie oordrag anoniem bly vir die buite-waarnemer. Dan, om haarself in die senderveld te vermom, voer sy ook die rekeninge van Adam en Adele in. En om Bob te versteek, in die ontvangerveld, ook die rekeninge van Ben en Bill. Toe Alice die volgende aflewering gemaak het, het Alice besluit om Alex en Amanda langs haar te skryf, en Bruce en Benjen langs Bob. In hierdie geval, wanneer die blokketting in hierdie twee transaksies ontleed word, is daar net een kruisende paar deelnemers - Alice en Bob, wat hierdie transaksies deanonimiseer.
Transaksie resies
Soos ons reeds genoem het, om sy saldo in rekeninggebaseerde stelsels weg te steek, enkripteer die gebruiker sy saldo en die bedrag van die oordrag. Terselfdertyd moet hy bewys dat die saldo op sy rekening nie-negatief bly. Die probleem is dat wanneer 'n transaksie gevorm word, die gebruiker 'n bewys bou aangaande sy huidige rekeningstatus. Maar wat gebeur as Bob 'n transaksie aan Alice stuur, en dit word aanvaar voor die een wat deur Alice gestuur is? Dan sal Alice se transaksie as ongeldig beskou word, want die balansbewys is gebou voordat Bob se transaksie aanvaar is.
Die eerste oplossing wat in so 'n situasie kom, is om die rekening te vries totdat die transaksie plaasvind. Maar hierdie benadering is nie geskik nie, want benewens die kompleksiteit om so 'n probleem in 'n verspreide stelsel op te los, sal dit in 'n anonieme skema nie duidelik wees wie se rekening om te blokkeer nie.
Om hierdie probleem op te los, skei die tegnologie inkomende en uitgaande transaksies: besteding van fondse het 'n onmiddellike uitwerking op die balansstaat, terwyl ontvangste 'n vertraagde effek het. Om dit te doen, word die konsep van "epog" bekendgestel - 'n groep blokke van 'n vaste grootte. Die huidige "epog" word bepaal deur die blokhoogte deur die groepgrootte te deel. Wanneer 'n transaksie verwerk word, werk die netwerk die sender se balans onmiddellik op, en voeg die ontvanger se fondse by die akkumulator. Die opgehoopte fondse is slegs beskikbaar vir die begunstigde wanneer 'n nuwe "epog" begin.
Gevolglik kan die gebruiker transaksies stuur ongeag hoe gereeld hy fondse ontvang (sover sy saldo dit toelaat, natuurlik). Die epoggrootte word bepaal op grond van hoe vinnig blokke oor die netwerk versprei en hoe vinnig 'n transaksie in 'n blok kom.
Hierdie oplossing werk goed in die geval van vertroulike oordragte, maar met anonieme transaksies, soos ons later sal sien, skep dit ernstige probleme.
Beskerming teen herhalingsaanvalle
In rekeninggebaseerde blokkettings word elke transaksie met die sender se private sleutel onderteken, wat die verifieerder oortuig dat die transaksie nie gewysig is nie en deur die eienaar van hierdie sleutel geskep is. Maar wat as 'n aanvaller wat op die transmissiekanaal geluister het hierdie boodskap onderskep en presies dieselfde tweede een stuur? Die verifieerder sal die handtekening van die transaksie verifieer en oortuig wees van die outeurskap daarvan, en die netwerk sal dieselfde bedrag weer van die sender se balans afskryf.
Hierdie aanval word 'n herhalingsaanval genoem. In die UTXO-model is sulke aanvalle nie relevant nie, want die aanvaller sal probeer om die bestee uitsette te gebruik, wat op sigself nie geldig is nie en deur die netwerk verwerp word.
Om te voorkom dat dit gebeur, word 'n veld met ewekansige data in die transaksie ingebed, wat 'n nonce of bloot "sout" genoem word. Wanneer 'n transaksie met 'n "sout" herstuur word, kyk die verifieerder om te sien of hierdie nonce voorheen gebruik is en, indien nie, beskou hierdie transaksie as geldig. Om nie die hele geskiedenis van gebruiker-nonces in die blokketting te stoor nie, word dit gewoonlik gelyk aan nul geneem in die heel eerste transaksie, en dan met een verhoog. Die netwerk hoef net te kontroleer dat die afwesigheid van die nuwe transaksie van die vorige een vir een verskil.
In 'n anonieme oordragskema ontstaan die probleem van die validering van transaksienonsies. Ons kan die nons nie uitdruklik aan die sender se adres bind nie, want dit deanoniseer natuurlik die oordrag. Ons kan ook nie een by die nonses van alle deelnemende rekeninge voeg nie, aangesien dit kan bots met ander oordragte wat aan die gang is.
Die skrywers van Zether stel voor om 'n nonce kriptografies te genereer, afhangende van die "epog". Byvoorbeeld:
Hier x is die sender se geheime sleutel, en Gepoch — 'n bykomende kragopwekker vir die epog, verkry deur 'n string soos 'Zether + ' te hash. Nou blyk dit dat die probleem opgelos is - ons maak nie die nies van die sender bekend nie en meng nie in met die nonsies van onbetrokke deelnemers nie. Maar hierdie benadering stel 'n ernstige beperking: een rekening kan nie meer as een transaksie per "epog" stuur nie. Hierdie probleem bly ongelukkig onopgelos en maak op die oomblik die anonieme weergawe van Zether, na ons mening, beswaarlik bruikbaar.
Kompleksiteit van Zero Kennis Bewyse
In UTXO moet die sender aan die netwerk bewys dat hy nie 'n negatiewe bedrag spandeer nie, anders word dit moontlik om nuwe munte uit die lug te genereer (hoekom dit moontlik is, het ons in een van die vorige geskryf ). En ook om die "ingange" met 'n ringhandtekening te teken om te bewys dat daar tussen die munte wat geknie word, fondse is wat aan hom behoort.
In die anonieme weergawe van die rekeninggebaseerde blokketting is die bewysuitdrukkings baie meer ingewikkeld. Die sender bewys dat:
- Die bedrag wat gestuur is, is positief;
- Die balans bly nie-negatief;
- Die sender het die oordragbedrae korrek geïnkripteer (insluitend nul ene);
- Die saldo op die balans verander slegs vir die sender en ontvanger;
- Die sender besit die geheime sleutel tot sy rekening en hy is werklik teenwoordig in die lys van senders (onder die betrokkenes);
- Die nonce wat in die transaksie gebruik is, is korrek.
Vir so 'n komplekse bewys gebruik die skrywers 'n mengsel (een van die skrywers het terloops aan die skepping daarvan deelgeneem) en , wat Sigma-koeëls genoem word. Die formele bewys van so 'n stelling is 'n taamlike moeilike taak, en dit beperk grootliks die aantal mense wat bereid is om die tegnologie te implementeer.
Die resultaat?
Na ons mening kan die deel van Zether wat privaatheid na rekeninggebaseerde blokkettings bring, nou gebruik word. Maar op die oomblik stel die anonieme weergawe van die tegnologie ernstige beperkings op die gebruik daarvan, en die kompleksiteit daarvan op implementering. Dit moet egter nie uitgesluit word nie dat die skrywers dit net 'n paar maande gelede vrygestel het, en miskien sal iemand anders 'n oplossing vind vir die probleme wat vandag bestaan. Dit is immers hoe wetenskap gedoen word.
Bron: will.com