zkDocs: Nul-viden informationsdeling PlatoBlockchain Data Intelligence. Lodret søgning. Ai.

zkDocs: Nul vidensdeling

Størstedelen af ​​blockchain-transaktioner er offentlige af design, tilgængelige for alle, der er villige til at inspicere dem. Selvom det er fremragende til auditerbarhed, gør dette dem til et mindre oplagt valg til at videresende privat information. Du ønsker ikke at forpligte dit personnummer til Ethereum blockchain, for eksempel. Vi kan dog bruge nul-viden bevis (som giver os mulighed for kryptografisk at bevise fakta om information uden at afsløre oplysningerne) for ikke kun at beskytte privatlivets fred, men også forbedre nutidens traditionelle informationsdeling og verifikationsarbejdsgange.

For eksempel, mange organisationer og institutioner er afhængige af omhyggeligt at dele private oplysninger og verificere deres ægthed for ansøgninger fra realkreditlån til universitetsoptagelser. Men i praksis involverer disse privatlivsbeskyttende arbejdsgange en række subjektive adgangsbekræftelser, når mennesker spørger andre mennesker. De er ofte fejltilbøjelige, ineffektive og utætte processer, der afslører unødvendig information og er muligvis ikke egnet til at håndtere vores mest følsomme data.

Her demonstrerer vi, hvordan adskillige kryptografiske primitiver udviklet og populariseret af web3-bevægelsen kan forbedre informationsverifikations-workflows, samtidig med at både privatlivets fred og decentralisering bevares gennem vores nyligt udgivne zkDocs repo. Det er et værktøj til at skabe "nulvidensaktiverede dokumenter", der giver forskellige parter i en given arbejdsgang mulighed for at dele og verificere information og sikre, at den opfylder visse kriterier - uden at afsløre den unødigt.

[Indlejret indhold]

Men først: hvordan det virker, nøglemekanismer og mere

Lad os starte med et hurtigt overblik over tre vigtige aktører i zkDocs-arbejdsgangen, og hvordan de kan interagere for at ansøge om og godkende et realkreditlån.

  • Verifikator: Administratoren eller skaberen af ​​et zkDoc-skema. I vores eksempel er verifikatoren realkreditinstituttet.
  • Indsender: Den eller de personer, der søger at få data verificeret af skemaet. Dette er låneansøgeren eller den potentielle boligkøber.
  • Attestor: En betroet person eller institution, der kan attestere sandheden af ​​et eller flere af afsenderens felter. Dette kan være en arbejdsgiver eller en boligvurderingsmand.

Typisk starter en realkreditansøgning en verifikationsarbejdsgang, hvor en realkreditinstitut (verifikator) engagerer andre betroede institutioner for at bekræfte, at en ansøger (indsender) opfylder deres krav. Når ansøgningen hopper fra institution til institution (attester), kan den oprindelige långiver godkende lånet.

Arkitekturen vi lægger op tillader en verifikator at specificere et skema over felter og betroede attestor, og specificer derefter nogle begrænsninger over disse felter. I tilfælde af en realkreditansøgning kan långiver angive, at summen af ​​en ansøgers sikkerhedsstillelse er større end deres udestående gæld.

zkDocs tillader også afsenderen kun at dele relevant information med hver attestor. En arbejdsgiver kan muligvis kun attestere for eksempel en ansøgers løn og ansættelsesstatus uden at se unødvendige økonomiske detaljer. 

Afsenderen kan derefter generere et nul-vidensbevis, der viser, at skemaet er udfyldt sandfærdigt - og at hvert felt er blevet korrekt attesteret - uden at afsløre nogen af ​​de underliggende data. Enhver part (inklusive verifikatoren) kan validere nulvidensbeviset via en letvægtsberegning.

Der er to primære mekanismer at bemærke: attester , nul-viden bevis.

Brug af blockchains til attesteringer

Offentlige blockchains har en række egenskaber, der gør dem ideelle til attesteringer: censurmodstand, offentlig datatilgængelighed, auditerbarhed og hemmelige signeringsnøgler. Attestorer kan bruge deres private nøgle til at underskrive alle transaktioner, der sendes til blockchain, og sikre, at attester ikke kan forfalskes eller forfalskes.

En af ulemperne ved at sende attester til en blockchain er dog, at de underliggende værdier er offentligt synlige. zkDocs løser dette ved at sende kryptografiske forpligtelser til værdierne i stedet for klartekstværdierne. Disse forpligtelser forbliver offentligt tilgængelige, men deres underliggende værdier er ikke synlige.

Hvad er en kryptografisk forpligtelse?

En kryptografisk forpligtelse giver en part mulighed for at generere en forpligtelse til nogle private data. Senere kan forpligteren åbne forpligtelsen til at afsløre de forpligtede data. 

Tilsagnsordninger skal være (1) skjule, hvilket betyder, at tilsagnet ikke afslører noget om dataene, og (2) bindende, hvilket betyder, at forpligtende ikke kan finde et tilsagn, som det kan åbne på to forskellige måder. 

Den enkleste forpligtelsesordning er bygget ud fra en kryptografisk hashfunktion - for eksempel Poseidon hash. For at forpligte sig til nogle data, beregner committeren: engagement ← poseidon(data, nuntius), hvor nuntius er en tilfældig 512-bit streng. For at åbne forpligtelsen senere, afslører committeren data og nuntius. Enhver kan verificere, at forpligtelsen blev åbnet korrekt.

Verifikation af private data gennem nul-viden beviser

Nulvidensbeviser er en metode til at bevise et faktum om data uden at afsløre noget om de underliggende data. Med zkDocs kan en afsender oprette et nul-viden bevis på, at alle data er blevet forpligtet til og opfylder de påkrævede begrænsninger. Enhver tredjepart kan køre verifikationsberegningen uden kendskab til eller information om de underliggende data.

Resultatet er, at de data, der kræves for at bekræfte en zkDoc-skemaindsendelse, er offentligt tilgængelige og fuldt ud reviderbare, mens de altid forbliver private.

Specifikt genererer afsenderen et nul-viden bevis på, at den kender en række af (værdi, nuntius) par sådan, at:

  • poseidon(value[i], nonce[i]) == prior_commitment[i]og
  • value[0], …, value[n] opfylder begrænsningerne

Indsenderen kan generere et nul-vidensbevis ved hjælp af dette kredsløb og udsende det til enhver part, der er interesseret i at verificere deres data. Enhver kan køre beviset og bekræfte gyldigheden af ​​felterne i skemaet.

For at demonstrere, lad os se på to korte casestudier.

Eksempel: pantansøgning

Lad os først vende tilbage til låneansøgningen, et godt eksempel på en arbejdsgang for informationsattest, der kan forbedres med zkDocs.

Realkreditlångiveren (verifikatoren, i dette tilfælde) ville oprette et skema 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 specificerer skemaet flere felter, som långiveren er interesseret i: løn, 401(k) indkomst, checkkontosaldo, ejendomsværdi og låneværdi. 

Derefter to begrænsninger over disse felter: 

  1. Summen af ​​ejendomsværdi og bankkontosaldo er større end låneværdien
  2. Summen af ​​401(k) indkomst og løn er større end $65,000 om året

Og endelig fem institutioner, som den har tillid til at attestere disse oplysninger:

  1. Arbejdsgiver
  2. Boligvurderingsmand
  3. 401 (k) udbyder
  4. Tjekkontoudbyder
  5. kreditor

For at ansøge om et realkreditlån udfylder ansøgeren felterne i afsnittet "felter" ved hjælp af zkDocs-brugergrænsefladen og offentliggør en kryptografisk forpligtelse på kæden til hver. Ansøgeren sender derefter de relevante klartekstfelter sammen med erklæringerne for hver forpligtelse, til hver af de attesterende institutioner (fra det sæt, der er anført under trusted_institutions). zkDocs UI gør dette gennem hyperlinks.

Hver attestor verificerer den relevante klartekstinformation og attesterer forpligtelsen ved at underskrive med deres Ethereum private nøgle. Derefter kan ansøgeren indsende en transaktion til blockchainen inklusive nulvidensbeviset for gyldigheden af ​​tilsagn og begrænsninger, og dermed kvalificere sig som en gyldig pantemodtager. Det verificerende realkreditinstitut behøver ikke at udføre yderligere verifikation for at bekræfte ansøgningens integritet.

Eksempel: MakerDAO RWA-lån

MakerDAO er en udlånsprotokol, som til dato har udstedt $6 milliarder i lån denomineret i DAI (et USD-pegged token). Maker's Real World Assets (RWA)-division arbejder på at yde DAI-denominerede lån til downstream-långivere, hvilket gør DAI i stand til direkte at sætte gang i den økonomiske vækst i den virkelige verden. Men Maker er en DAO, hvis styringstoken ejes af omkring 78,000 unikke tegnebøger, hver med ret til at deltage i styringsprocessen og styre protokollens fremtid. 

De fleste store beslutningstagere, såsom en om at påtage sig en ny kilde til sikkerhed, diskuteres i offentlige fora. Men en institution eller person, der ansøger om et lån hos Maker, er måske ikke interesseret i at dele hele deres økonomi med offentligheden af ​​en række årsager, fra privatliv til forretningshemmeligheder. Maker kunne i stedet udgive et zkDoc med et skema, der ligner 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 skema ville give regeringsdeltagere mulighed for at sikre, at protokollen ikke tager urimelige risici uden at kræve, at alle RWA-lånansøgere krænker deres privatliv.

***
zkDocs, som i øjeblikket implementeret, bruger:

  • Underskrevne transaktioner (eller enhver EVM-kompatibel kæde) for at bekræfte ægtheden af ​​attester
  • Offentlig blokplads til at opbevare både forpligtelser og attester
  • Smarte kontrakter til at verificere beviser uden viden 

Ud over zkDocs' auditabilitets- og privatlivsegenskaber er der en anden interessant akse: Når verifikation af privat information er live på en offentlig blockchain, kan brugere og udviklere komponere zkDoc-verificeret information med deres egne applikationer. Man kunne forestille sig, at lånehistorik spiller ind i et DAO-omdømme, fællesskabsverificerede kvartalsvise ansøgninger for at justere protokolparametre, øjeblikkelige universitetsansøgninger, nedsatte protokolsatser for brugere, der er tillid til i et andet fællesskab, og meget mere.

Vores mål med at dele dette proof of concept er at demonstrere, hvordan disse nye computerprimitiver kan bruges i produktionen i dag, og at hjælpe med at fremskynde deres indførelse ved at bringe flere applikationer online. Hvis du planlægger at implementere zkDocs til prod eller bruge en lignende ordning, er du velkommen til at kontakte Twitter.

Tidsstempel:

Mere fra Andreessen Horowitz