zkDocs: Null-kunnskapsdeling

De fleste blokkjedetransaksjoner er offentlige av design, tilgjengelige for alle som er villige til å inspisere dem. Selv om det er utmerket for reviderbarhet, gjør dette dem til et mindre opplagt valg for videresending av privat informasjon. Du ønsker for eksempel ikke å binde personnummeret ditt til Ethereum-blokkjeden. Vi kan imidlertid bruke bevis på null kunnskap (som lar oss kryptografisk bevise fakta om informasjon uten å avsløre informasjonen) for ikke bare å beskytte personvernet, men også forbedre dagens tradisjonelle arbeidsflyter for informasjonsdeling og verifisering.

Eksempelvis mange organisasjoner og institusjoner er avhengige av å nøye dele privat informasjon og verifisere ektheten for søknader fra boliglån til høyskoleopptak. Men i praksis involverer disse personvernbeskyttende arbeidsflytene en rekke subjektive tilgangsbekreftelser når mennesker spør andre mennesker. De er ofte feilutsatte, ineffektive og lekke prosesser som avslører unødvendig informasjon, og som kanskje ikke er egnet for å håndtere våre mest sensitive data.

Her demonstrerer vi hvordan flere kryptografiske primitiver utviklet og popularisert av web3-bevegelsen kan forbedre arbeidsflyter for informasjonsverifisering, samtidig som både personvern og desentralisering bevares, gjennom vår nylig utgitte zkDocs repo. Det er et verktøy for å lage "nullkunnskapsaktiverte dokumenter" som lar ulike parter i en gitt arbeidsflyt dele og verifisere informasjon, og sikre at den oppfyller visse kriterier – uten å avsløre den unødvendig.

[Innebygd innhold]

Men først: hvordan det fungerer, nøkkelmekanismer og mer

La oss starte med en rask oversikt over tre viktige aktører i zkDocs arbeidsflyt, og hvordan de kan samhandle for å søke om og godkjenne et boliglån.

• Verifikator: Administratoren eller skaperen av et zkDoc-skjema. I vårt eksempel er verifikatoren pantelåner.

• Innsender: Individet eller individene som ønsker å få data verifisert av skjemaet. Dette er lånesøker eller potensiell boligkjøper.

• Attestor: En betrodd person eller institusjon som kan attestere sannheten til ett eller flere av innsenderens felt. Dette kan være en arbeidsgiver eller en boligtakstmann.

Vanligvis starter en boliglånssøknad en verifiseringsarbeidsflyt der en pantelåner (verifikator) engasjerer andre pålitelige institusjoner for å bekrefte at en søker (innsender) oppfyller kravene deres. Når søknaden spretter fra institusjon til institusjon (attester), kan den opprinnelige långiveren godkjenne lånet.

Arkitekturen vi legger ut lar en verifikator spesifisere et skjema over felt og pålitelige attestor, og spesifiser deretter noen begrensninger over disse feltene. Når det gjelder en boliglånssøknad, kan långiver spesifisere at summen av en søkers sikkerhetsverdi er større enn deres utestående gjeld.

zkDocs lar også innsenderen bare dele relevant informasjon med hver attestor. En arbeidsgiver kan for eksempel bare bekrefte en søkers lønn og arbeidsstatus uten å se unødvendige økonomiske detaljer. 

Innsenderen kan deretter generere et null-kunnskapsbevis som viser at skjemaet er fylt ut sannferdig - og at hvert felt er riktig attestert - uten å avsløre noen av de underliggende dataene. Enhver part (inkludert verifikatoren) kan validere nullkunnskapsbeviset via en lettvektsberegning.

Det er to primære mekanismer å merke seg: attester og bevis på null kunnskap.

Bruke blokkjeder for attester

Offentlige blokkjeder har en rekke egenskaper som gjør dem ideelle for attester: sensurmotstand, offentlig datatilgjengelighet, reviderbarhet og hemmelige signeringsnøkler. Attestorer kan bruke sin private nøkkel til å signere alle transaksjoner som sendes til blokkjeden, for å sikre at attester ikke kan forfalskes eller forfalskes.

En av ulempene med å legge ut attester til en blokkjede er imidlertid at de underliggende verdiene er offentlig synlige. zkDocs løser dette ved å kringkaste kryptografiske forpliktelser til verdiene i stedet for klartekstverdiene. Disse forpliktelsene forblir offentlig tilgjengelige, men deres underliggende verdier er ikke synlige.

Verifisering av private data gjennom null-kunnskapsbevis

Nullkunnskapsbevis er en metode for å bevise et faktum om data uten å avsløre noe om de underliggende dataene. Med zkDocs kan en innsender lage et nullkunnskapsbevis på at alle data har blitt forpliktet til og tilfredsstiller de nødvendige begrensningene. Enhver tredjepart kan kjøre verifikasjonsberegningen uten kunnskap om eller informasjon om de underliggende dataene.

Resultatet er at dataene som kreves for å verifisere en zkDoc-skjemainnsending er offentlig tilgjengelige og fullt ut reviderbare, mens de alltid forblir private.

Nærmere bestemt genererer avsenderen et nullkunnskapsbevis på at den kjenner en rekke (verdi, nuncio) par slik at:

• poseidon(value[i], nonce[i]) == prior_commitment[i]og
• value[0], …, value[n] tilfredsstille begrensningene

Innsenderen kan generere et nullkunnskapsbevis ved å bruke denne kretsen og kringkaste den til enhver part som er interessert i å verifisere dataene deres. Hvem som helst kan kjøre beviset og bekrefte gyldigheten av feltene i skjemaet.

For å demonstrere, la oss se på to korte casestudier.

Eksempel: boliglånsøknad

La oss først gå tilbake til boliglånsapplikasjonen, et godt eksempel på en arbeidsflyt for informasjonsattest som kan forbedres med zkDocs.

Boliglånsutlåneren (bekrefteren, i dette tilfellet) vil lage et skjema for en zkDoc som følger:


{
  "fields": [
    {
      "field_name": "salary"
    },
    {
      "field_name": "401k_income"
    },
    {
      "field_name": "bank_account_balance"
    },
    {
      "field_name": "property_value"
    },
    {
      "field_name": "loan_value"
    }
  ],
  "constraints": [
    {
      "fieldA": "bank_account_balance",
      "fieldB": "property_value",
      "op": "ADD",
      "constraint": "GT",
      "fieldCompare": "loan_value"
    },
    {
      "fieldA": "salary",
      "fieldB": "401k_income",
      "op": "ADD",
      "constraint": "GT",
      "constant": 65000
    }
  ],
  "trusted_institutions": [
    {
      "human_name": "Employer",
      "address": "0xabcd..."
    },
    {
      "human_name": "Home Appraiser",
      "address": "0xabcd..."
    },
    {
      "human_name": "401k Provider",
      "address": "0xabcd..."
    },
    {
      "human_name": "Checking Account Provider",
      "address": "0xabcd..."
    },
    {
      "human_name": "Creditor",
      "address": "0xabcd..."
    }
  ]
}


Først spesifiserer skjemaet flere felt som utlåner er interessert i: lønn, 401(k) inntekt, kontosaldo, eiendomsverdi og låneverdi. 

Deretter to begrensninger over disse feltene: 

1. Summen av eiendomsverdi og bankkontosaldo er større enn låneverdien
2. Summen av 401 (k) inntekt og lønn er større enn $65,000 XNUMX per år

Og til slutt, fem institusjoner den stoler på å bekrefte denne informasjonen:

1. Arbeidsgiver
2. Boligtakstmann
3. 401(k)-leverandør
4. Kontoleverandør
5. kreditor

For å søke om et boliglån fyller søkeren ut feltene som er oppført i "felt"-delen ved å bruke zkDocs-grensesnittet og publiserer en kryptografisk forpliktelse på kjeden til hver. Søkeren sender deretter de relevante klartekstfeltene, sammen med påmeldingene for hver forpliktelse, til hver av de attesterende institusjonene (fra settet oppført under trusted_institutions). zkDocs-grensesnittet gjør dette gjennom hyperkoblinger.

Hver attestor verifiserer relevant klartekstinformasjon og attesterer forpliktelsen ved å signere med deres Ethereum private nøkkel. Deretter kan søkeren sende inn en transaksjon til blokkjeden inkludert null-kunnskapsbeviset på gyldigheten av forpliktelsene og begrensningene, og dermed kvalifisere som en gyldig boliglånmottaker. Den bekreftende boliglånsinstitusjonen trenger ikke å utføre ytterligere verifisering for å bekrefte integriteten til søknaden.

Eksempel: MakerDAO RWA-lån

MakerDAO er en utlånsprotokoll som til dags dato har utstedt 6 milliarder dollar i lån denominert i DAI (et USD-festet token). Maker's Real World Assets (RWA)-divisjon jobber med å gi DAI-denominerte lån til nedstrøms långivere, noe som gjør det mulig for DAI å gi direkte drivstoff til økonomisk vekst i den virkelige verden. Men Maker er en DAO, hvis styringstoken eies av rundt 78,000 XNUMX unike lommebøker, hver med rett til å delta i styringsprosessen og styre fremtiden til protokollen. 

De fleste store Maker-beslutninger, for eksempel om å ta på seg en ny kilde til sikkerhet, diskuteres i offentlige fora. Men en institusjon eller enkeltperson som søker om lån fra Maker er kanskje ikke interessert i å dele hele økonomien sin med offentligheten av en rekke årsaker, fra personvern til forretningshemmeligheter. Maker kan i stedet publisere et zkDoc med et skjema som ligner på følgende:


{
  "fields": [
    {
      "field_name": "custodian_name"
    }, 
    {
      "field_name": "total_loan"
    },
    {
      "field_name": "total_collateral_value"
    },
    {
      "field_name": "amount_repaid"
    }
  ],
  "constraints": [
    {
      "fieldA": "total_loan",
      "fieldB": "amount_repaid",
      "op": "SUB",
      "constraint": "LT",
      "fieldCompare": "total_collateral_value"
    }
  ],
  "trusted_institutions": [
    {
      "address": "0xabcd…",
      "human_name": "Bob the Custodian"
    }
  ]
}


Dette skjemaet vil tillate styringsdeltakere å sikre at protokollen ikke tar urimelig risiko, uten at alle RWA-lånsøkere må krenke personvernet deres.

***
zkDocs, som for øyeblikket er implementert, bruker:

• Signerte transaksjoner (eller en hvilken som helst EVM-kompatibel kjede) for å bekrefte autentisiteten til attester
• Offentlig blokkplass for å lagre både forpliktelser og attester
• Smarte kontrakter for å verifisere bevis uten kunnskap 

Utover reviderbarheten og personvernegenskapene til zkDocs, er det en annen interessant akse: Når verifisering av privat informasjon er live på en offentlig blokkjede, kan brukere og utviklere komponere zkDoc-verifisert informasjon med sine egne applikasjoner. Man kan forestille seg lånehistorikk som spiller inn i et DAO-rykte, fellesskapsverifiserte kvartalsvise innleveringer for å justere protokollparametere, øyeblikkelige høyskolesøknader, rabatterte protokollpriser for brukere som er pålitelig i et annet fellesskap, og mye mer.

Målet vårt med å dele dette proof of concept er å demonstrere hvordan disse nye dataprimitivene kan brukes i produksjon i dag, og å hjelpe til med å akselerere bruken av dem ved å bringe flere applikasjoner online. Hvis du planlegger å distribuere zkDocs for å produsere eller bruke et lignende opplegg, kan du gjerne kontakte Twitter.