Onderzoekers van [[alloc] init] — Clara Shikhelman, Misha Komarov en Aleksei Moskvin — hebben Shielded Bitcoin uitgebracht, een whitepaper die een nieuw privacy-metaprotocol beschrijft gebouwd op de basellaag van Bitcoin. Het ontwerp maakt afgeschermde bitcointransacties mogelijk zonder operators, soft forks of enige andere wijziging in de Bitcoin-consensus. De whitepaper en een bijbehorende blogaankondiging zijn beschikbaar, en het team deelde het nieuws op X.

Het protocol definieert een transactiestructuur en een indexeringsprotocol voor sterk privacybeschermende transacties, terwijl het vertrouwt op Bitcoin PIPEs om fondsen in en uit het systeem te pegen. Het PIPEs-mechanisme wordt aan het einde van dit artikel in detail behandeld.

Die eigenschap — geen consensuswijziging — is belangrijk: het grootboek van Bitcoin legt bedragen en adressen openbaar vast, en wijzigingen in de regels vereisten historisch gezien brede coördinatie in het hele netwerk. Een ontwerp dat volledig binnen bestaande regelset opereert, is niet afhankelijk van dat proces om verder te komen.

Een op Bitcoin lijkend ontwerp met heel andere details

De architectuur weerspiegelt bewust die van Bitcoin zelf. Er bestaat een equivalent van de UTXO, een note genaamd. Transacties consumeren notes als inputs, net zoals een gewone Bitcoin-transactie UTXO's uitgeeft. Een witness bewijst dat de gebruikte inputs correct geautoriseerd zijn, en nodes — indexers, in het geval van een metaprotocol — doorzoeken de transactiegeschiedenis en bouwen een doorlopende staat van welke munten uitgegeven en onuitgegeven zijn.

Alle onderliggende details zijn echter behoorlijk verschillend.

Transacties die Bitcoin zelf negeert

Een Shielded Bitcoin-transactie is simpelweg een data-blob met een prefix — zoiets als "shbtc:" — ingebed in een Bitcoin-transactie via OP_RETURN, het witness-veld of een andere methode om data mee te dragen. Dit is het metaprotocolpatroon: de regels van het protocol worden afgedwongen door zijn eigen indexers en niet door Bitcoin, dus de basischain ziet niets anders dan gewone data. De blob heeft geen betekenis voor Bitcoin: het netwerk doet niets om deze te verifiëren en dwingt er keinerlei regels tegen af.

Het is daardoor heel goed mogelijk dat ongeldige Shielded Bitcoin-transacties op de chain belanden. Het is de taak van een Shielded Bitcoin Indexer, die passief de blockchain volgt, om transacties die de validatie niet doorstaan te negeren en ze niet toe te passen bij het bijwerken van de staat van de netwerksaldi.

Nullifiers in plaats van een uitgegeven-set

Een indexer verwijdert notes niet uit een set onuitgegeven notes zoals Bitcoin uitgegeven UTXO's verwijdert. In plaats daarvan beheert het een nullifier-set. Dit mechanisme stelt een gebruiker in staat openbaar een versleuteld bewijs en een nullifier te publiceren die aantoont dat een note is uitgegeven, zonder te onthullen welke note is uitgegeven. In plaats van te controleren of een note in de "set onuitgegeven notes" zit, controleren deelnemers of een bepaalde nullifier al eerder is gebruikt.

Indexers bouwen een merkle-boom die oneindig groeit en alleen kan worden uitgebreid, met daarin elke ooit gecreëerde note-output, naast de nullifier-set.

Het protocol draaien vereist slechts een node

Het gebruik van het protocol vereist niets meer dan een Bitcoin-node en een Shielded Bitcoin-indexer. Er is dienst, coördinator of off-chain status nodig om fondsen te herstellen. Het werkt net als on-chain Bitcoin: alles wat een gebruiker nodig heeft, is zijn node/indexer en zijn sleutels.

Elke gebruikerswallet leidt een hoofdsleutel (master secret key) af, waaruit elke andere betrokken set sleutels wordt gecreëerd — een ontwerp dat sterk lijkt op een HD-wallet in Bitcoin, waarmee veel adressets kunnen worden gegenereerd. sk_spend dient als de privésleutel voor uitgeven, sk_nf wordt gebruikt om note-outputs te nullify-en, vk_in ontsleutelt en bekijkt inkomende notes, vk_out bekijkt uitgaande transacties, en sk_view genereert een ontvangstadres.

Wanneer een gebruiker iemand een adres wil geven om fondsen te ontvangen, genereert deze een diversifier-waarde d, vergelijkbaar met een afleidingswaarde, en vermenigvuldigt die met zijn sk_view-sleutel. De resulterende publieke sleutel pk_d vormt samen met d het adres van de gebruiker.

De verzender genereert vervolgens een willekeurige waarde, de r_seed, die zowel nodig is voor de versleuteling van de note-output als voor de nullificatie (daar komen we zo op terug). Transactie-outputs bevatten slechts drie versleutelde items: de waarde van de output, de d-waarde die de ontvanger aan de verzender gaf, en de r_seed-waarde van de verzender. Om te versleutelen gebruikt de verzender een geheim efemeer sleutelpaar en de publieke sleutel van de ontvanger om een gedeeld geheim te creëren — beide partijen kunnen hetzelfde geheim berekenen door hun privésleutel te vermenigvuldigen met de publieke sleutel van de ander. De note-output wordt versleuteld met dit gedeelde geheim, en de efeemere sk_eph wordt onversleuteld bijgevoegd zodat de ontvanger het gedeelde geheim zelf kan genereren.

Zero-knowledge-bewijzen garanderen geldigheid

Aan de inputkant zijn twee dingen nodig voor een geldige transactie: een publieke nullifier voor elke geconsumeerde note-output, en een zero-knowledge-bewijs dat aantoont dat (1) de note-output is opgenomen in de merkle-boom van notes, (2) de transactie is geautoriseerd door de juiste sk_spend-sleutel, (3) de nullifier correct is afgeleid, en (4) er geen inflatie heeft plaatsgevonden.

De nullifier omvat de sk_nf-sleutel, een ρ-waarde afgeleid van de_seed, en de positie van de note in de merkle-boom van note-outputs. Hoewel niemand kan zien bij welke note-output een nullifier hoort, garanderen de zero-knowledge-bewijzen in elke transactie dat elke nullifier die aan de set wordt toegevoegd afkomstig is van een geldige note-output. Indexers kunnen daarom simpelweg herhaalde nullifiers afwijzen in plaats van uitgegeven notes te verwijderen, en zolang er geen herhalingen zijn, biedt het systeem dezelfde garantie tegen double-spending.

Het netto-effect is dat versleutelde metaprotocol-transacties kunnen worden ingebed op de Bitcoin-blockchain, met nog steeds de garantie dat niets dubbel wordt uitgegeven en dat munten niet uit het niets worden geïnflateerd.

Privacy-eigenschappen

Volgens de analyse is het systeem qua privacy-eigenschappen goed ontworpen en vergelijkbaar met bijvoorbeeld de shielded pools van Zcash. De vergelijking schetst het bredere landschap: Zcash levert afgeschermde transacties via regels die in zijn eigen protocol zijn ingebouwd, terwijl dit ontwerp vergelijkbare eigenschappen nastreeft op de basellaag van Bitcoin zonder de consensus aan te raken. Privacy-overwegingen die ontstaan bij het betreden en verlaten van het metaprotocol worden in een aanstaande paper nader toegelicht, waardoor de entry- en exitpunten van het systeem tot de details behoren om in de gaten te houden naarmate het werk vordert. Anders dan bij coinjoins is er geen zorg over het meten van privacy of de behoefte aan periodiek remixen.

Fondsen pegen met PIPEs v2

De beoogde peg is gebaseerd op PIPEs v2, een witness-encryption-schema. PIPEs maken het mogelijk een privésleutel te versleutelen met een programma of mechanisme dat de sleutel niet prijsgeeft, tenzij een ZK-bewijs wordt geleverd dat aan een bepaalde voorwaarde is voldaan — bijvoorbeeld de status van een bepaalde UTXO, of dat een transactie is bevestigd. Dit zou een peg laten functioneren zonder operator, federatie of enige derde partij die fondsen in bewaring houdt — een opmerkelijke eigenschap, aangezien peg-ontwerpen die Bitcoin uitbreiden doorgaans op zulke custodians leunen. Het vereist geen soft forks of protocolwijzigingen aan Bitcoin en speelt zich volledig off-chain af.

De volgende fase van het werk van het team is een pegmechanisme dat gebruikers zou toestaan fondsen in te storten in Shielded Bitcoin via cryptografisch gecontroleerde PIPEs-sleutels, die vervolgens zouden "ontgrendeld" door het genereren van een ZK-bewijs van legitieme peg-out-transacties die on-chain zijn bevestigd. Er wordt momenteel gewerkt aan de paper die dit aspect van het systeem definieert, die in de nabije toekomst zou moeten verschijnen; samen met de paper over entry/exit-privacy vult deze de openstaande punten aan die de whitepaper achterlaat.

---

Dit artikel, geschreven door Shinobi, verscheen eerst op Bitcoin Magazine.