I november 2022 udgav Binance sit Proof of Reserves-system, der bruger Merkle-trækryptografi til at give brugerne mulighed for at verificere deres beholdninger.
Binance har nu forbedret sin løsning ved at implementere zk-SNARKs, en form for zero-knowledge proof.
Brugere kan nu kontrollere, at hver kontos samlede nettosaldo ikke er negativ, og at alle brugeraktiver er en del af Binances påståede samlede nettosaldo af brugeraktiver – på en privat og sikker måde.
Tag et kig under kølerhjelmen på Binances nye proof-of-reserves-løsning. Ved at kombinere zk-SNARKs og Merkle-træoplysninger får brugerne en ny og forbedret måde at verificere tilstanden af Binances reserver på.
I løbet af de sidste par måneder har Binances udviklingsteam arbejdet hårdt på at bygge avancerede proof-of-solvency-løsninger. Disse værktøjer er blevet afgørende for centraliserede kryptobørser midt i den tillidskrise, der ramte branchen i kølvandet på FTX-kollapset. Brugernes midler på Binance er sikret i forholdet 1:1 plus reserver, og det er blevet en vigtig del af Binances plan for at genskabe tilliden til branchen at finde en metode til at bevise dette for offentligheden uden problemer.
I november 2022 udgav vi vores proof-of-reserves-system, der bruger en kryptografisk Merkle-træteknik til at give brugerne mulighed for at verificere deres beholdninger på Binance. Selvom det er et fremskridt i Binances bestræbelser på at sikre gennemsigtighed i brugernes midler, havde det oprindelige design af denne løsning to mangler:
For at beskytte brugernes privatliv repræsenterede bladnoderne i Merkle-beviset hashen af brugernes beholdninger – Merkle-roden kunne således ikke afspejle summen af bladnodernes saldooplysninger.
Den enhed, hvis reserver blev verificeret, kunne potentielt tilføje en negativ saldo under en falsk konto et eller andet sted i træet for at få de samlede krævede reserver til at se mindre ud. Følgende diagram fra Vitalik Buterins blog viser et eksempel på et sådant ondsindet Merkle-træ (selvom roden i dette tilfælde afspejler summen af alle bladnodernes balancer, hvilket kan give problemer med databeskyttelse).
Vi har nu en løsning, der kan afhjælpe disse mangler og dermed styrke Binances proof-of-reserves-system. Ved hjælp af zero-knowledge proof-protokoller – zk-SNARKs – kan vi bevise, at:
Alle bladnoder i Merkle-træet har bidraget til Binances påståede samlede brugersaldo for hvert aktiv.
Der er ikke nogen brugere med en negativ samlet nettosaldo (en samlet USD-værdi af alle aktiver, som brugeren har) inkluderet i Merkle-træet.
Da Binance tilbyder margin-, kryptolån- og futures-handelsprodukter, kan hver brugers saldo for hvert kryptoaktiv bestå af aktiver og passiver. En brugers saldo for et bestemt kryptoaktiv kan være negativ, men brugerens samlede nettosaldo på tværs af alle kryptoaktiver bør ikke være negativ (da alle lån er fuldt sikrede).
I dette hypotetiske scenarie kan vi forestille os, at Alice havde indbetalt 10.000 FDUSD til Binance og derefter brugt 4.000 FDUSD som sikkerhedsstillelse til at låne 2 BNB (til en kurs på 1 BNB = 1.000 FDUSD, hvis vi antager, at Binance altid stiller for stor sikkerhed). Følgende tabel viser Alices saldo.
Hvis Alice derefter bytter 1 BNB for 1.000 FDUSD med Bob (som også har indsat 10.000 FDUSD), vil deres saldo se således ud, efter at handlen er indgået:
I dette tilfælde vil Alices BNB-saldo være -1, hvilket ikke er en gyldig node i et Merkle-træ, og det dækker kun ét aktiv: BNB. Men hvis vi ser på de samlede nettosaldi, er Alice stadig på 10.000.
En anden udfordring kommer fra Binances store brugerbase. En brugbar løsning skal generere brugerbeviser og zk-SNARK-beviser for titusindvis af brugere, hvoraf nogle kan have mere end 300 kryptoaktiver på vores platform.
Alt i alt ønsker vi at fremlægge bevis for følgende fakta inden for en rimelig tidsperiode:
Hver Binance-brugers aktiver er en del af vores påståede samlede brugersaldo, der er vist på øjebliksbilledet. Brugerne kan verificere vores påståede samlede brugersaldo i forhold til aktiverne på Binance-kontrollerede adresser ved hjælp af en blockchain-udforsker (som f.eks. Etherscan for Ethereum-wallets eller BscScan for BNB Chain-wallets).
Hver brugers samlede nettosaldo er ikke-negativ, hvilket betyder, at Binance ikke har oprettet dummy-konti med negativ saldo for at reducere størrelsen af vores verificerede reserver kunstigt.
Før vi går i dybden med detaljerne i vores løsning, er det på sin plads med en kort oversigt over zero-knowledge proof-mekanismen. Zero-knowledge-protokoller som zk-SNARK gør det muligt for en part – beviseren – at demonstrere over for en anden part – verifikatoren – at beviseren har udført visse beregninger nøjagtigt med visse input under visse begrænsninger, alt sammen uden at afsløre inputtene. Beregningen kan være tidskrævende, men den underliggende matematiske mekanisme kan hjælpe verifikatoren med at vurdere beviset hurtigt og sikkert.
Beviseren (Binance) starter med at definere et sæt begrænsninger for den beregning, som beviseren ønsker at bevise. Begrænsningerne er defineret i kredsløb, der kan udtrykkes i et programmeringssprog på højere niveau (i vores tilfælde en fork-version af gnark).
Beviseren udfører derefter den tunge beregning, hasher alle brugeres id'er og saldi og genererer et bevis for, at beregningen opfylder de begrænsninger, der er angivet tidligere. Til det formål bruger den beregningssporet (vidnet) og offentlige eller private input.
Verifikatoren (brugeren) får beviset og verificerer det med kredsløbets offentlige input for at sikre, at beregningen er blevet udført nøjagtigt med alle begrænsninger opfyldt. Verificeringsberegningen tager ekstremt kort tid sammenlignet med bevistiden. Hvis beviseren ikke genererer beviset på de foruddefinerede kredsløb, kan beviseren ikke producere et gyldigt bevis for at bestå verificeringen.
Hvis du vil gå mere i dybden med zk-SNARKs, kan du læse denne artikelserie.
Den grundlæggende byggesten i den opgraderede proof-of-reserves-løsning er stadig et Merkle-træ. I eksemplet ovenfor ville det se således ud:
Ud over Merkle-træet opretholder vi også en global tilstand, der repræsenterer en liste over de samlede nettosaldi for hvert aktiv, som hver Binance-kunde har.
For at bevise vores reserver vil vi generere zk-SNARK-bevis for konstruktionen af Merkle-træet. For hver brugers saldosæt – en bladnode på Merkle-træet – vil vores kredsløb sikre følgende:
Hvert aktivs saldo for denne bruger er medtaget på den liste for global tilstand, der er nævnt ovenfor.
Brugerens samlede nettosaldo er ikke negativ.
Ændringen af Merkle-træets rod er gyldig efter opdatering af denne brugers oplysninger i bladnodens hash.
Se disse tekniske specifikationer og vores kildekode for kredsløbet (begrænsninger) for at få vist implementeringsdetaljerne.
I alle tilfælde, hvor vi beviser vores reserver, vil vi offentliggøre:
1. Merkle-beviset: hashes for hver bruger (for Alice er det vist med blå noder på billedet ovenfor).
2. zk-SNARK-beviser og offentligt input (en hash af listen over samlede nettosaldi for hvert aktiv og Merkle-roden) for kredsløbet for alle brugere.
Ved at verificere Merkle-beviset kan brugerne sikre, at deres saldo er inkluderet i Merkle-træets rod. Ved at verificere zk-SNARK-beviset kan brugerne sikre, at Merkle-træets konstruktion opfylder de begrænsninger, der er defineret i kredsløbet.
Sikkerheden i denne løsning afhænger i høj grad af konfigurationen af bevisnøglen og verifikationsnøglen. Vi arbejder på en decentraliseret konfiguration af nøglerne. Når det gælder eksisterende decentraliserede, betroede konfigurationsceremonier, er Ethereum-ceremonien et godt eksempel. Vi er meget tæt på at have en MPC-løsning, der gør konfigurationen trustless.
I betragtning af antallet af Binance-brugere, hvis saldi skal inkluderes, er det ikke muligt at generere et enkelt bevis for Merkle-træets konstruktion, der ville dække alle brugere på én gang. En løsning på dette er at opdele brugerne i grupper på 864 hver, så man får et mindre kredsløb og parallelle testprocedurer.
For et batch, der indeholder 864 brugere, og hvor hver bruger ejer 350 forskellige aktiver, antages det, at hver aktivsaldo ligger i intervallet [0, 2^64-1]. Med en 32-kernet 128 GB server er zk proof-genereringstiden omkring 110 sekunder, og bevisverificeringstiden er mindre end 1 millisekund.
Binance starter 1.000 bevisere på samme tid for at generere beviser til alle konti på 2 timer. Omkostningerne til denne beviserserver i en time er ca. 0,56 USD, så de samlede omkostninger ved at generere alle zk-beviser, der dækker alle brugere, ville være ca. 1.000 USD.
Vi vil levere den første iteration af beviser for brugere genereret af denne nye løsning i en efterfølgende proof-of-reserves-meddelelse. Vi har også lagt vores brugerdataprocessor, beviser, kredsløb og verifikator ud som open source, så alle centraliserede børser, der anvender samme model som os, nemt kan generere beviser for deres brugere og aktiver.
Vi håber, at det kan være med til at løfte gennemsigtigheden i branchen for digitale aktiver op på et nyt niveau. Vi arbejder også på at implementere den løsning, der er nævnt på Vitaliks blog, for at opnå bedre ydeevne, hvilket vil gøre det muligt for os at levere beviset oftere til en lavere pris.
Da dette er den første version af vores zk-SNARK, ser vi frem til at få feedback fra fællesskabet, så vi kan fortsætte med at forbedre systemet.
