Hjem
Artikler
Forbedring af kryptogennemsigtighed med zero-knowledge proofs

Forbedring af kryptogennemsigtighed med zero-knowledge proofs

Let √łvet
Offentliggjort Feb 10, 2023Opdateret Jan 5, 2024
10m

TL;DR

Et zero-knowledge proof g√łr det muligt for en part (verifikatoren) at afg√łre gyldigheden af et udsagn fra en anden part (beviseren) uden at kende til udsagnets indhold. F.eks. kan Binance √łnske at bevise, at de har sikret deres brugeres midler fuldt ud i reserver uden at afsl√łre alle individuelle brugeres saldi.

Et "Proof of Reserves" kan konstrueres med et Merkle-tr√¶, der beskytter mod forfalskning af dets interne data, i dette tilf√¶lde dets samlede nettokundesaldoer, som er b√łrsens forpligtelser over for sine brugere. Dette kan s√• kombineres med en zk-SNARK (en zero-knowledge proof-protokol), der sikrer, at brugerne kan kontrollere, at deres saldo er en del af den samlede nettobalance for brugeraktiver uden at kende de individuelle saldi.

Introduktion

I lyset af begivenhederne p√• markedet er sikkerheden for kryptoaktiver i forvaltning blevet et kritisk emne. Blockchain-brugere s√¶tter stor pris p√• gennemsigtighed og √•benhed, men st√łtter ogs√• beskyttelse af personoplysninger og fortrolighed. Det skaber et dilemma, n√•r man skal bevise reserver af midler, der opbevares af forvaltere. Ofte er der en afvejning mellem gennemsigtighed, tillid og datafortrolighed.

Dette beh√łver dog ikke at v√¶re tilf√¶ldet. Ved at kombinere zero-knowledge proof-protokoller s√•som zk-SNARK'er med Merkle-tr√¶er kan vi finde en effektiv l√łsning for alle parter.

Hvad er zero-knowledge proof?

Et zero-knowledge proof g√łr det muligt for en part (verifikatoren) at afg√łre gyldigheden af et udsagn fra en anden part (beviseren) uden at kende til udsagnets indhold. Lad os se p√• et enkelt eksempel.

Du har et aflåst pengeskab, som kun du kender koden til. For eksemplets skyld kan pengeskabet ikke dirkes eller tvinges op eller på anden måde åbnes uden at kende kombinationen. Dette faktum er også fastslået, verificeret og kendt af din ven, der deltager i eksperimentet.

Du siger til din ven, at du kender kombinationen, men du vil ikke give den v√¶k eller √•bne pengeskabet foran vedkommende. √ėverst p√• pengeskabet er der et hul, som din ven kan f√łre en seddel igennem. For at g√łre dette til et zero-knowledge proof, b√łr din ven ikke have nogen ekstra oplysninger om processen ud over den givne erkl√¶ring.

Du kan bevise over for din ven, at du kender kombinationen, ved at √•bne pengeskabet, fort√¶lle, hvad der st√•r p√• sedlen, og lukke det igen. Du har dog p√• intet tidspunkt afsl√łret kombinationen.

For et mere avanceret eksempel kan du læse vores artikel Hvad er zero-knowledge proof, og hvordan påvirker det blockchainen?

Hvorfor bruger vi zero-knowledge proofs?

Zero-knowledge proofs er velegnede til at bevise noget uden at afsl√łre f√łlsomme oplysninger eller detaljer. Det kan v√¶re tilf√¶ldet, hvis du ikke √łnsker at udlevere dine √łkonomiske eller personlige oplysninger, som kan blive brugt p√• en uhensigtsm√¶ssig m√•de.

I krypto kan du bevise, at du ejer en private key uden at afsl√łre den eller signere noget digitalt. En kryptovalutab√łrs kan ogs√• √łnske at bevise status for sine reserver uden at afsl√łre fortrolige oplysninger om sine brugere, herunder deres individuelle kontosaldi.¬†

Til disse eksempler (og mange andre) vil et zero-knowledge proof bruge algoritmer, der tager et datainput og returnerer "sandt" eller "falsk" som output. 

Definition af zero-knowledge proofs i tekniske termer

Et zero-knowledge proof f√łlger teknisk set en bestemt struktur med visse kriterier. Vi har allerede d√¶kket beviser- og verifikatorrollerne, men der er ogs√• tre kriterier, som et zero-knowledge proof b√łr d√¶kke:

  1. Fuldstændighed. Hvis udsagnet er sandt, vil en verifikator blive overbevist af det fremlagte bevis uden behov for andre oplysninger eller verifikation.

  2. Soliditet. Hvis udsagnet er falsk, vil en verifikator ikke blive overbevist om et udsagns sandhed af det fremlagte bevis.

  3. Zero-knowledge. Hvis udsagnet er sandt, får verifikatoren ingen andre oplysninger, end at udsagnet er sandt.

Hvad er en zk-SNARK?

En zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) er en bevisprotokol, der f√łlger principperne for zero-knowledge, der tidligere er angivet. Med en zk-SNARK kan du bevise, at du kender den oprindelige hashede v√¶rdi (gennemg√•et l√¶ngere nede) uden at afsl√łre, hvad den er. Du kan ogs√• bevise gyldigheden af en transaktion uden at afsl√łre nogen oplysninger om de specifikke bel√łb, v√¶rdier eller adresser, der er involveret.

zk-SNARK'er er almindeligt brugt og debatteret i blockchain- og kryptovalutaverden. Men du undrer dig måske over, hvorfor nogen gider bruge en zk-SNARK, når de kan bruge en simpel metode til at parre en public og en private key til at sikre oplysningerne. Vi ville dog ikke være i stand til at implementere det matematiske bevis for at sikre, at ingen negative saldoer er inkluderet og summen af Merkle-træet. 

I tilf√¶ldet med en b√łrs' reserver √łnsker vi at bevise 1:1-opbakning af kundernes saldi, uden at identifikatorer og saldi for hver konto offentligg√łres. Derudover g√łr zk-SNARK-teknologien det endnu mere usandsynligt at forfalske data.

Hvad er et Merkle-træ?

At pr√¶sentere de summerede midler p√• Binance-brugernes konti kr√¶ver, at man arbejder med et stort datas√¶t. En m√•de at pr√¶sentere denne store m√¶ngde data kryptografisk p√• er at bruge et Merkle-tr√¶. En stor m√¶ngde oplysninger kan lagres i det p√• effektiv vis, og dets kryptografiske natur g√łr det nemt at verificere dets integritet.

Hash-funktioner

For kortfattet at kode et input afh√¶nger et Merkle-tr√¶ af brugen af hash-funktioner. Hashing refererer kort sagt til processen med at generere et output i fast st√łrrelse fra et input af variabel st√łrrelse. Med andre ord, n√•r et input af en hvilken som helst l√¶ngde hashes gennem en algoritme, vil det producere et krypteret output af fast l√¶ngde.

S√• l√¶nge inputtet forbliver det samme, vil outputtet ogs√• g√łre det. Det betyder, at vi kan tage enorme m√¶ngder transaktionsdata og hashe dem til et h√•ndterbart output. Outputtet vil v√¶re radikalt anderledes, hvis nogen oplysninger √¶ndres i inputtet.

Vi kan f.eks. tage indholdet af 100 b√łger og indtaste dem i SHA-256-hashfunktionen. Det ville dermed resultere i noget i retningen af dette som output:

801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea

Hvis vi s√• √¶ndrer et enkelt tegn i inputtet (de 100 b√łger), vil hashen v√¶re helt anderledes, s√•dan her:

abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410

Det er en vigtig egenskab ved hash-funktioner, fordi det g√łr det nemt at verificere dataenes n√łjagtighed. Hvis nogen gentager processen med at hashe de samme 100 b√łger ved hj√¶lp af SHA-256-algoritmen, vil de f√• n√łjagtig den samme hash som output. Hvis outputtet er anderledes, kan vi med sikkerhed sige, at inputtet er blevet √¶ndret. Det betyder, at der ikke er behov for individuelt eller manuelt at kontrollere forskelle mellem inputtene, hvilket kan v√¶re arbejdskr√¶vende.

Merkle-træer i kryptovalutaens verden

Når man opbevarer transaktionsdata på en blockchain, indsendes hver ny transaktion gennem en hashfunktion, som genererer unikke hashværdier. Forestil dig, at vi har otte transaktioner (A til H), som vi hasher individuelt for at få deres hashede output. Det er dem, vi kalder Merkle Leaf-noderne. På billedet nedenfor kan du se den unikke hashværdi for hvert bogstav: hA for A, hB for B, hC for C osv.

Vi kan s√• tage par af hashede outputs, kombinere dem og f√• et nyt hashet output. Hashes af hA og hB hashet sammen vil f.eks. give os et nyt hashet output af hAB kendt som en Merkle-gren. Bem√¶rk, at hver gang et nyt output genereres, har det en fast l√¶ngde og st√łrrelse i henhold til den anvendte hashfunktion.

Nu har vi data fra to transaktioner (f.eks. A og B) kombineret i én hash (hAB). Bemærk, at hvis vi ændrer nogen oplysninger fra A eller B og gentager processen, vil vores hashede output hAB være helt anderledes.

Processen forts√¶tter, n√•r vi kombinerer nye par af hashes for at hashe dem igen (se billedet nedenfor). Vi hasher hAB med hCD for at f√• en unik hash hABCD og g√łr det samme med hEF og hGH for at f√• hEFGH. I sidste ende modtager vi en enkelt hash, der repr√¶senterer de hashede output af alle tidligere transaktioners hash. Med andre ord repr√¶senterer det hashede output hABCDEFGH alle de oplysninger, der kom f√łr det.

Grafen, der vises ovenfor, kaldes et Merkle-tr√¶, og det hashede output hABCDEFGH er Merkle-roden. Vi bruger Merkle-r√łdder i block headers, da de kryptografisk opsummerer alle transaktionsdata i en blok p√• en kortfattet m√•de. Vi kan ogs√• hurtigt verificere, om der er blevet manipuleret med eller √¶ndret data i blokken.

Begrænsningerne ved Merkle-træer

Lad os vende tilbage til vores eksempel med CEX-reserver. En CEX √łnsker at bevise 1:1-opbakning af alle sine kunders aktiver og bygger et Merkle-tr√¶, der hasher sine kunders UID'er sammen med deres nettoaktivbeholdninger (modregning af aktiver og passiver) p√• tokenniveau. N√•r det er frigivet (og signeret for at bevise ejerskab over Merkle-roden), vil en individuel bruger ikke have nogen mulighed for at kontrollere, om Merkle-tr√¶et er gyldigt uden at f√• adgang til alle dets inputs.

En b√łrs kan have overset at inkludere nogle inputs. Den kan ogs√• oprette falske konti med negative saldi for at √¶ndre det samlede ansvar. Selvom kundernes aktiver f.eks. kan v√¶re p√• 1.000.000 USD, kan der tilf√łjes en falsk konto med en saldo p√• -500.000 USD. Det ville skabe et reservem√•l p√• blot 500.000 USD.

Beviset for reserver er forskelligt fra en bloks Merkle-rod, da brugere kan se alle de transaktioner, en blok indeholder, p√• en blockchain-udforsker. En CEX √łnsker dog ikke at afsl√łre hver enkelt kontosaldo af hensyn til sikkerhed og databeskyttelse. Kunderne ville heller ikke v√¶re glade for, at deres kontosaldi blev offentliggjort. I dette tilf√¶lde kan CEX'en ikke bevise, at brugersaldi summerer til den korrekte sum uden at g√łre andre brugersaldi synlige.

En l√łsning, som b√łrser kan overveje at anvende, er at bruge en betroet tredjepartsrevisor. Revisoren kan kontrollere de enkelte konti og reserver, f√łr denne endeligt attesterer gyldigheden af den leverede Merkle-rod. Men for brugerne kr√¶ver denne metode tillid til revisoren og de data, der bruges til revisionen. Du beh√łver ikke at forlade dig p√• en tredjepart, n√•r du kan stole p√• dataene.

Kombination af zk-SNARK'er med Merkle-træer

Ovenst√•ende problem er et perfekt eksempel p√• brug af zk-SNARK'er. Vi √łnsker at bevise, at reserverne fuldt ud d√¶kker brugernes forpligtelser og ikke er forfalskede. Men af hensyn til beskyttelse af personoplysninger og sikkerhed √łnsker vi ikke at vise verifikatoren den n√łjagtige sammens√¶tning af brugernes saldi og reserver.¬†

Ved at bruge en zk-SNARK kan en kryptob√łrs bevise, at alle Merkle-tr√¶ets blad-noders saldos√¶t (dvs. brugerkontosaldi) bidrager til b√łrsens p√•st√•ede samlede brugeraktivsaldo. Hver bruger kan nemt f√• adgang til sin blad-node, som har v√¶ret inkluderet i processen. zk-SNARK'en sikrer ogs√•, at ethvert Merkle-tr√¶, der genereres, ikke indeholder brugere med en negativ samlet nettoaktivsaldo (hvilket ville betyde forfalskning af data, da alle l√•n er oversikkerhedsstillede). Der bruges ogs√• en beregning af Binances globale tilstand, dvs. en liste over den samlede nettosaldo for hvert aktiv, som hver Binance-kunde har.

Lad os tage et kig p√•, hvordan Binance griber situationen an. Til at begynde med definerer Binance begr√¶nsningerne for den beregning, den √łnsker at bevise, og definerer dem som et programmerbart kredsl√łb. Nedenfor er de tre begr√¶nsninger, som Binance bruger i sin model.¬†

For hver brugers saldos√¶t (Merkle-tr√¶ets blad-node) sikrer vores kredsl√łb, at:

  1. En brugers aktivsaldi er inkluderet i beregningen af summen af en brugers samlede nettosaldo hos Binance.

  2. Brugerens samlede nettosaldo er st√łrre end eller lig med nul.

  3. Ændringen af Merkle-træets rod er gyldig (dvs. bruger ikke forfalskede oplysninger) efter opdatering af en brugers oplysninger til blad-nodens hash.

Binance kan derefter generere et zk-SNARK-bevis for Merkle-tr√¶ets konstruktion i henhold til kredsl√łbet. Dette indeb√¶rer, at b√łrsen udf√łrer den tunge beregning af hashing af brugernes id'er og saldi, samtidig med at den sikrer, at beviset best√•r begr√¶nsningerne.

En verifikator vil unders√łge beviset (og dets offentligt frigivne open source-kode) for at blive overbevist om, at beregningen udf√łres med alle begr√¶nsninger opfyldt. Verifikationsberegningen tager ekstremt kort tid sammenlignet med bevistiden.

Ved hver udgivelse af Proof of Reserves vil b√łrsen offentligg√łre:

1. Merkle-beviset for hver bruger.

2. zk-SNARK-beviset og det offentlige input (en hash af listen over den samlede nettosaldo for hvert aktiv og Merkle-roden) for kredsl√łbet for alle brugere.

Interesserede parter kan verificere Merkle-beviset og sikre, at deres individuelle saldi har bidraget til Merkle-tr√¶ets rod. De kan ogs√• verificere zk-SNARK-beviset for at sikre, at konstruktionen af Merkle-tr√¶et opfylder de begr√¶nsninger, der er defineret i kredsl√łbet. For en mere detaljeret forklaring af zk-SNARK-l√łsningen og dens ydeevne henvises der til vores blog S√•dan forbedrer zk-SNARK'er Binances Proof of Reserves-system.

Sammenfatning

zk-SNARK'er leverer den teknologi, der er n√łdvendig for at sikre b√•de dataintegritet og beskyttelse af personoplysninger p√• samme tid. Dens anvendelse til at bevise reserver og √łge CEX-transparens b√łr hj√¶lpe med at opbygge tillid til blockchain-branchen. For mange har en udvikling som denne v√¶ret l√¶nge ventet og kommer p√• et afg√łrende tidspunkt for CEX'er.

Dette er den f√łrste version af vores zk-SNARK, og vi ser frem til at modtage feedback fra f√¶llesskabet, s√• vi kan forts√¶tte med at forbedre systemet.

Yderligere læsning