zkDocs: informatie delen zonder kennis

De meeste blockchain-transacties zijn openbaar en beschikbaar voor iedereen die ze wil inspecteren. Hoewel uitstekend voor controleerbaarheid, maakt dit ze een minder voor de hand liggende keuze voor het doorgeven van privé-informatie. U wilt bijvoorbeeld uw burgerservicenummer niet vastleggen op de Ethereum-blockchain. We kunnen echter gebruik maken van nulkennisbewijzen (waardoor we feiten over informatie cryptografisch kunnen bewijzen zonder de informatie te onthullen) om niet alleen de privacy te beschermen, maar ook om de huidige traditionele workflows voor het delen en verifiëren van informatie te verbeteren.

Bijvoorbeeld, veel organisaties en instellingen vertrouwen op het zorgvuldig delen van privé-informatie en het verifiëren van de authenticiteit ervan voor aanvragen van hypotheken tot toelating tot een universiteit. Maar in de praktijk houden deze privacybeschermende workflows een reeks subjectieve toegangsbevestigingen in wanneer mensen andere mensen ondervragen. Het zijn vaak foutgevoelige, inefficiënte en lekkende processen die onnodige informatie blootleggen en mogelijk niet geschikt zijn voor het verwerken van onze meest gevoelige gegevens.

Hier laten we zien hoe verschillende cryptografische primitieven die zijn ontwikkeld en gepopulariseerd door de web3-beweging de workflows voor informatieverificatie kunnen verbeteren, met behoud van zowel privacy als decentralisatie, via onze nieuw uitgebrachte zkDocs-opslagplaats. Het is een hulpmiddel voor het maken van "zero-knowledge-enabled documenten" waarmee verschillende partijen in een bepaalde workflow informatie kunnen delen en verifiëren, en ervoor zorgen dat deze aan bepaalde criteria voldoet - zonder deze onnodig bloot te leggen.

[Ingesloten inhoud]

Maar eerst: hoe het werkt, de belangrijkste mechanismen en meer

Laten we beginnen met een kort overzicht van drie belangrijke actoren in de zkDocs-workflow en hoe ze kunnen samenwerken om een ​​hypotheek aan te vragen en goed te keuren.

• Verificateur: De beheerder of maker van een zkDoc-schema. In ons voorbeeld is de verificateur de hypotheekverstrekker.

• indiener: De persoon of personen die gegevens willen laten verifiëren door het schema. Dit is de aanvrager van een lening of potentiële koper van een huis.

• Attester: Een vertrouwde persoon of instelling die kan getuigen van de waarheid van een of meer velden van de indiener. Dit kan een werkgever zijn of een woningtaxateur.

Meestal start een hypotheekaanvraag een verificatieworkflow waarin een hypotheekverstrekker (verificateur) andere vertrouwde instellingen inschakelt om te bevestigen dat een aanvrager (indiener) aan hun vereisten voldoet. Zodra de aanvraag van instelling naar instelling (attesteurs) stuitert, kan de oorspronkelijke kredietverstrekker de lening goedkeuren.

De architectuur die we hebben opgesteld, stelt een verificateur in staat om een ​​schema van velden en vertrouwde attestors te specificeren, en specificeer vervolgens enkele beperkingen voor die velden. In het geval van een hypotheekaanvraag kan de geldschieter specificeren dat de som van de onderpandwaarde van een aanvrager groter is dan hun uitstaande schuld.

zkDocs staat de indiener ook toe om alleen relevante informatie te delen met elke attestor. Een werkgever kan bijvoorbeeld alleen het loon en de arbeidsstatus van een sollicitant bevestigen zonder onnodige financiële details te zien. 

De indiener kan dan een nulkennisbewijs genereren waaruit blijkt dat het schema naar waarheid is ingevuld - en dat elk veld naar behoren is geattesteerd - zonder de onderliggende gegevens te onthullen. Elke partij (inclusief de verificateur) kan het nulkennisbewijs valideren via een lichtgewicht berekening.

Er zijn twee primaire mechanismen om op te merken: attesten en nulkennisbewijzen.

Blockchains gebruiken voor attesten

Openbare blockchains hebben een aantal eigenschappen die ze ideaal maken voor attesten: weerstand tegen censuur, beschikbaarheid van openbare gegevens, controleerbaarheid en geheime ondertekeningssleutels. Attestors kunnen hun privésleutel gebruiken om alle transacties die naar de blockchain worden verzonden te ondertekenen, zodat attesten niet kunnen worden vervalst of vervalst.

Een van de nadelen van het plaatsen van attesten op een blockchain is echter dat de onderliggende waarden publiekelijk zichtbaar zijn. zkDocs lost dit op door uit te zenden cryptografische verplichtingen naar de waarden in plaats van naar de leesbare tekstwaarden. Deze toezeggingen blijven publiekelijk beschikbaar, maar hun onderliggende waarden zijn niet zichtbaar.

Het verifiëren van privégegevens door middel van zero-knowledge proofs

Zero-knowledge proofs zijn een methode om een ​​feit over data te bewijzen zonder iets over de onderliggende data te onthullen. Met zkDocs kan een indiener een nulkennisbewijs creëren dat alle gegevens zijn vastgelegd en voldoen aan de vereiste beperkingen. Elke derde partij kan de verificatieberekening uitvoeren zonder kennis van of informatie over de onderliggende gegevens.

Het resultaat is dat de gegevens die nodig zijn om een ​​indiening van een zkDoc-schema te verifiëren, openbaar beschikbaar zijn en volledig controleerbaar, terwijl ze altijd privé blijven.

In het bijzonder genereert de indiener een nulkennisbewijs dat hij een array kent van (waarde, nuntius) paren zodanig dat:

• poseidon(value[i], nonce[i]) == prior_commitment[i] en
• value[0], …, value[n] voldoen aan de beperkingen

De indiener kan met behulp van dit circuit een nulkennisbewijs genereren en dit uitzenden naar elke partij die geïnteresseerd is in het verifiëren van hun gegevens. Iedereen kan het bewijs uitvoeren en de geldigheid van de velden binnen het schema bevestigen.

Laten we om dit te demonstreren eens kijken naar twee korte casestudies.

Voorbeeld: hypotheekaanvraag

Laten we eerst teruggaan naar de hypotheekaanvraag, een goed voorbeeld van een workflow voor informatieattesten die met zkDocs kan worden verbeterd.

De hypotheekverstrekker (in dit geval de verificateur) zou als volgt een schema voor een zkDoc maken:


{
  "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..."
    }
  ]
}


Eerst specificeert het schema verschillende velden waarin de geldschieter geïnteresseerd is: salaris, 401 (k) inkomen, saldo op de rekening, waarde van onroerend goed en leningwaarde. 

Dan twee beperkingen voor die velden: 

1. De som van de waarde van het onroerend goed en het saldo op de bankrekening is groter dan de waarde van de lening
2. De som van 401 (k) inkomen en salaris is groter dan $ 65,000 per jaar

En tot slot, vijf instellingen die het vertrouwt om deze informatie te bevestigen:

1. Werkgever
2. Woning taxateur
3. 401 (k) aanbieder
4. Betaalrekening provider
5. Schuldeiser

Om een ​​hypotheek aan te vragen, vult de aanvrager de velden in de sectie "velden" in met behulp van de zkDocs-gebruikersinterface en publiceert voor elk een on-chain cryptografische verbintenis. De aanvrager stuurt vervolgens de relevante leesbare tekstvelden, samen met de nonces voor elke toezegging, aan elk van de attesterende instellingen (uit de reeks vermeld onder trusted_institutions). De gebruikersinterface van zkDocs doet dit door middel van hyperlinks.

Elke attestor verifieert de relevante duidelijke tekstinformatie en bevestigt de verbintenis door te ondertekenen met hun Ethereum-privésleutel. Vervolgens kan de aanvrager een transactie indienen bij de blockchain inclusief het zero-knowledge proof over de geldigheid van de toezeggingen en beperkingen, en zo kwalificeren als een geldige hypotheekontvanger. De verifiërende hypotheekinstelling hoeft geen aanvullende verificatie uit te voeren om de integriteit van de aanvraag te bevestigen.

Voorbeeld: MakerDAO RWA-leningen

MakerDAO is een uitleenprotocol dat tot op heden is uitgegeven: $ 6 miljard aan leningen uitgedrukt in DAI (een aan USD gekoppeld token). De divisie Real World Assets (RWA) van Maker werkt aan het verstrekken van in DAI luidende leningen aan stroomafwaartse kredietverstrekkers, waardoor DAI rechtstreeks de reële economische groei kan stimuleren. Maar Maker is een DAO, wiens governance-token eigendom is van ongeveer 78,000 unieke wallets, elk met het recht om deel te nemen aan het governanceproces en de toekomst van het protocol te sturen. 

De meeste grote Maker-beslissingen, zoals het nemen van een nieuwe bron van onderpand, worden besproken in openbare forums. Maar een instelling of persoon die een lening bij Maker aanvraagt, is om een ​​aantal redenen misschien niet geïnteresseerd in het delen van al hun financiële gegevens met het publiek, van privacy tot handelsgeheimen. Maker zou in plaats daarvan een zkDoc kunnen publiceren met een schema dat lijkt op het volgende:


{
  "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"
    }
  ]
}


Met dit schema kunnen governance-deelnemers ervoor zorgen dat het protocol geen onredelijk risico neemt, zonder dat alle aanvragers van een RWA-lening hun privacy hoeven te schenden.

***
zkDocs, zoals momenteel geïmplementeerd, gebruikt:

• Ondertekende transacties (of een EVM-compatibele keten) om de authenticiteit van attesten te verifiëren
• Openbare blokruimte om zowel de toezeggingen als attesten op te slaan
• Slimme contracten om nulkennisbewijzen te verifiëren 

Naast de controleerbaarheid en privacy-eigenschappen van zkDocs, is er nog een andere interessante as: zodra de verificatie van privé-informatie live is op een openbare blockchain, kunnen gebruikers en ontwikkelaars zkDoc-geverifieerde informatie samenstellen met hun eigen applicaties. Je kunt je voorstellen dat de leengeschiedenis een rol speelt bij een DAO-reputatie, door de gemeenschap geverifieerde driemaandelijkse deponeringen om protocolparameters aan te passen, onmiddellijke college-applicaties, gereduceerde protocoltarieven voor gebruikers die vertrouwd zijn binnen een andere gemeenschap, en nog veel meer.

Ons doel bij het delen van dit proof-of-concept is om te demonstreren hoe deze nieuwe computerprimitieven tegenwoordig in productie kunnen worden gebruikt, en om de acceptatie ervan te versnellen door meer applicaties online te brengen. Als je van plan bent om zkDocs in te zetten om te proppen of een soortgelijk schema te gebruiken, neem dan gerust contact op via Twitter.