Taproot kommer til Bitcoin: Hvordan det fungerer, historien og implikasjonene

Taproot og Schnorr-signaturer går live på Bitcoin på blokk 709,632. Dette kommer til å være en massiv grunnleggende prestasjon å fortsette å bygge videre på i fremtiden. Det har gått fire år siden Segregated Witness gikk live på nettverket, vår siste store protokolloppgradering. Det er like lang som en halveringssyklus!

Tenk på det. Fire år fra SegWit går live til Taproot går live. Sakte, metodisk tålmodighet, som det skal være. Men Taproot/Schnorrs historie går mye lenger tilbake enn det.

Historien om taproot

Noen som har vært her en stund vil kanskje finne dette ironisk, men den første omtalen av Schnorr-signaturer som jeg er klar over, var faktisk fra den tidligere Bitcoin Core-utvikleren som ble enterprise blockchain-bygger Mike Hearn. I 2012, han tok opp ideen om en ny kryptografisk kurve i forhold til batchverifisering av signaturer for å gjøre nodevalidering mindre beregningsmessig kostbar. Til syvende og sist var ordningen han foreslo avhengig av Schnorr-signaturer.

Adam Back diskuterte naivitet ordninger å gjøre en multisig-adresser som så ut som en singlesig-adresser tilbake i 2014, ved å bruke Schnorr-signaturer. Til og med Gavin Andresen inkludert Schnorr i stedet for ECDSA på ønskelisten hans over endringer han ville gjort i Bitcoin hvis han kunne vifte med en tryllestav.

Siden ganske nær begynnelsen av Bitcoin har de fleste utviklere som er aktivt involvert i Bitcoin Core ønsket Schnorr-signaturer, og det har alltid vært en ganske solid konsensus om deres overlegenhet i forhold til ECDSA-signaturer. Det kan faktisk hevdes at ECDSA ble opprettet spesifikt fordi Schnorr-signaturordningen var patentert, og det var et enormt behov for en åpen kildekode kryptografisk signaturordning som ikke var beheftet med patenter.

Schnorr er mye mer effektiv og lett manipulerbar (ting kan legges til, trekkes fra osv. fra signaturer, og hvis det gjøres riktig, kan brukerne fortsatt ha gyldige signaturer når de burde ha dem) enn ECDSA. Å bruke ECDSA var et spørsmål om nødvendighet snarere enn ønske i de fleste kryptografiske applikasjoner gjennom årene.

Merkelized Abstract Syntax Trees (MAST), Taproot-halvdelen av denne kommende Taproot-oppgraderingen, har en lignende langvarig historie. Jeg kan ikke finne sitatet, men jeg husker ganske tydelig at jeg så den frasen som ble kastet rundt av slike som Peter Todd på Bitcointalk.org tilbake rundt 2013 eller 2014.

Den opprinnelige BIP for MAST ble foreslått av Johnson Lau i 2016. Dette forslaget så også en viss aktivitet rundt 2017 da Mark Friedenbach, BTCDrak og Kalle Alm delte det opp i to separate BIP-er (116 og 117) og utvidet Laus opprinnelige forslag.

MAST satt på en måte i limbo det neste året til Greg Maxwell kom opp med den første Taproot-ideen og publisert den til bitcoin-dev-e-postlisten. Hans viktigste innsikt var at i enhver kontraktssak mellom flere deltakere han kunne tenke seg, var det et "optimalt resultat" der kontrakten kunne gjøres opp ved at alle bare signerte det riktige resultatet i stedet for å håndheve resultatet med mer avanserte skript og transaksjoner. Dette er den grunnleggende påstanden om at Taproot er basert på, det vil si å tilpasse MAST-treet til en vanlig nøkkel på toppnivå som kan brukes uten å avsløre om et Merkle-tre med andre forbruksbetingelser i det hele tatt eksisterer.

Den siste delen av denne historietimen starter med at Pieter Wiulle kunngjør utkast til BIP for Schnorr og Taproot i takt med e-postlisten 6. mai 2019. Innen januar 2020 ble dette formelt ferdigstilt til BIP-er 340, 341 og 342. Fra dette tidspunktet var det bare en masse små detaljraffinering på implementeringsnivå, en viss gjennomgangsperiode, og så den langvarige kamp om aktiveringsmekanismer. Det fører oss til nå, bare sjenert for aktivering.

Viktigheten av Schnorr-signaturer

Så, hva er problemet med Schnorr-signaturer? Vel, til å begynne med gjør de transaksjoner mindre. En ECDSA-signatur er vanligvis omtrent 72 byte stor for en enkelt signatur i en transaksjon. Schnorr-signaturer klokkes inn med maksimalt 64 byte per signatur. Det er en besparelse på omtrent 12 % i størrelse sammenlignet med ECDSA for hver Schnorr-signatur. Dette er både en direkte fordel for personen som bruker Schnorr som vil betale mindre i avgifter enn en ECDSA-bruker, men det er også en direkte fordel for folk som ikke bruker Schnorr ved å kreve at litt mindre data lagres i blokkjeden for å behandle og validere noen andres Schnorr signaturer.

Å lagre mindre data er alltid bra, men det som er enda bedre er å øke effektiviteten av å validere dataene du må lagre. En av de fine egenskapene til Schnorr, lineariteten til matematikken bak, gir også mulighet for en fin egenskap du vil ha i Bitcoin-data: batchvalidering. Når noden din mottar en blokk fra nettverket, analyserer den hver enkelt transaksjon og validerer hver signatur en etter en.

Dette er en stor del av hvorfor validering av blokker bruker mye CPU-kraft. Schnorr-signaturer kan alle settes sammen og valideres matematisk på en gang, på en måte som å knuse dem sammen og utføre en matematisk operasjon i stedet for en haug med individuelle. Så jo flere Schnorr-signaturer det er, jo større er beregningsmessige besparelser. Dette er en massiv skaleringsgevinst for nettverket.

En annen massiv forbedring Schnorr bringer er multisignatur-skript. Hver multisig-adresse må eksplisitt avsløre alle de individuelle offentlige nøklene som er involvert i et multisig-skript ved brukstid, og en signatur må gis for hver nøkkel som er involvert i utgiftsprosessen. Med Schnorrs matematiske egenskaper åpnes døren for MuSig, en multisignaturstandard. Du kan bare legge til nøkler og avslutte med en enkelt offentlig nøkkel som alles private nøkkeldelinger kan signere for ved hjelp av nye signaturprotokoller. Jonas Nick fra Blockstream benchmarked MuSig2 på å ta to minutter for en million deltakere i en multisig-adresse å signere. Skaleringsforbedringen til multisignaturskript kan ikke undervurderes.

Dette enorme spranget fremover for multisignaturskript har også en enorm implikasjon for personvernprofilen og kostnadene for en rekke applikasjoner bygget på toppen av Bitcoin. MuSig-baserte Lightning-kanaler kan nå blandes inn i hele anonymitetssettet med Schnorr/Taproot UTXO-er på kjede fordi ingen lenger vil kunne skille det faktum at de er en to-av-to multisig-utgang.

De vil gli inn og se ut akkurat som et enkelt signaturskript. Det samme gjelder for enhver multisig UTXO generelt. Dette vil ha mange implikasjoner for folk som bruker multisignaturskript for å bedre beskytte kjølelageret sitt med en mer robust sikkerhets- og gjenopprettingsmodell enn et enkelt signaturskript.

For det første vil det ikke være åpenbart at de bruker et multisig-oppsett ved å se på blokkjeden, så dette vil, som i tilfellet med Lightning, få dem til å smelte sammen med alt annet. En nøkkelgevinst er imidlertid med hensyn til økonomien: bruk av multisignatur akkurat nå krever å gi en separat signatur for hver nøkkel som er involvert i til slutt å bruke en UTXO. Med Schnorr/MuSig vil ting bli komprimert til en enkelt signatur for den enkelt kombinerte offentlige nøkkelen, noe som betyr å bruke multisig UTXO-er ved å bruke MuSig vil bli mye billigere ettersom det skyver mindre data til blokkjeden.

En siste kul ting som Schnorr-signaturer gjør er å drastisk forenkle implementeringen av adaptersignaturer. Tenk på en adaptersignatur som er "kryptert" med en verdi som er lagt til eller trukket fra en gyldig signatur. Den er ikke gyldig før du reverserer den matematiske operasjonen, eller "dekrypterer den" med "nøkkelen" som ble brukt til å manipulere den. Dette er mulig med ECDSA, men på grunn av at regnestykket er ikke-lineært sammenlignet med Schnorr, er det relativt komplisert og det er mange sikkerhetsproblemer å vurdere ved implementeringen.

På grunn av Schnorrs lineære egenskaper er imidlertid en adaptersignatur så enkel som å ta en singel (si tallet 9,300,030 30 XNUMX) og trekke en verdi fra den (si XNUMX). Når parten som har adaptersignaturen lærer den subtraherte verdien, kan de ganske enkelt legge den tilbake og voila, de har en gyldig signatur igjen.

Implikasjonene av taproot

Som diskutert litt ovenfor, er Taproot i virkeligheten i hovedsak bare MAST, bortsett fra at i stedet for at det fungerer som P2SH (hvor du hash skriptet, eller i MASTs tilfelle, Merkle-roten til toppen av skripttreet), "tweaker" du en Schnorr offentlig nøkkel ved roten av Merkle-treet.

Tweaking fungerer på grunn av Schnorrs lineære egenskaper - når du "tweaker" en offentlig nøkkel med en Merkle-rot (legger den Merkle-roten til den offentlige nøkkelen), så kan du ganske enkelt legge til Merkle-roten til den originale private nøkkelen og generere forbruksnøkkelen for den nye finjusterte offentlige nøkkelen. Det vil si at du legger til det samme til både offentlig og privat nøkkel, og de er fortsatt et gyldig nøkkelpar. Dette skjuler eksistensen av et MAST-tre, med mindre en gren av det brukes, men i bunn og grunn er det fortsatt bare et MAST-tre, bare ett som er forpliktet til på en mer effektiv og privat måte.

Evnen til å forplikte seg til forskjellige forbruksskript i et Merkle-tre og bare avsløre det brukte skriptet er en massiv skalerbarhetsgevinst når det gjelder smart kontraktskompleksitet som er mulig å bygge på Bitcoin.

Akkurat som hvordan blokkstørrelsen begrenser antall transaksjoner per blokk, er det en grense for transaksjonsstørrelse på 100 kilobyte. Den eneste forskjellen er at i stedet for å være en konsensusregel, er det en policyregel. Det betyr at en gruvearbeider kan utvinne en transaksjon som er større enn 100 kilobyte, men som standard vil ingens node på nettverket videresende en transaksjon som er større enn det til gruvearbeideren i utgangspunktet.

Dette begrenser iboende størrelsen på skriptet som brukes til å låse opp en Bitcoin UTXO. Selv med P2SH, hvor UTXO er låst til en hash av skriptet som ikke avsløres før du bruker det, må du likevel til slutt avsløre hele skriptet når du bruker det. Taproot øker denne skalerbarhetsgrensen for skript ved ikke å kreve at du avslører hele skriptet når du bruker det. I stedet for at den totale størrelsen på alle måtene du kan bruke UTXO på er begrenset til grensen for transaksjonsstørrelse, må du bare sørge for at en enkelt måte du kan bruke en Taproot UTXO på respekterer denne begrensningen.

Det er også mange personvernfordeler som følger med Taproot. En av de store fordelene med et MAST-tre er muligheten til å skape alle slags betingede situasjoner der mynter kan brukes av andre parter.

Se for deg ting som arveordninger der barna dine etter et år eller så kan bruke myntene dine, eller i tilfelle du nekter å signere, har din kone og en advokat en potensiell vei for å gjenopprette mynter. Ingenting om disse forbruksbetingelsene blir avslørt for offentligheten med mindre de faktisk brukes. Denne todelte prosessen gir plausibel benektelse for andre parter som er involvert i forskjellige pengebruksgrener du konstruerer med hensyn til deres involvering i den UTXO-en, samt beskytter dem mot en tyv eller angriper som forebyggende målretter mot dem, vel vitende om at de har en viss grad av kontroll over deres målets UTXOer.

På et teknisk nivå har Taproot vært relativt godt konstruert også. Alle som leser som er kjent med Segregated Witness på et hvilket som helst dypt nivå, bør være kjent med vitneversjonen.

Da Segregated Witness ble implementert, opprettet det den nye "vitne"-delen av en transaksjon der signaturdata ble flyttet til. Vitnedata hadde et versjonsflagg slik at de kunne oppgraderes til ny funksjonalitet uten å måtte bruke opp udefinerte OP_CODEs på basislaget for nye funksjoner.

Dette er faktisk hvordan Taproot/Schnorr har blitt implementert. Segregerte vitnetransaksjoner bruker vitneversjon null. Når Taproot/Schnorr snart går live, vil de bruke den nye vitneversjonen en for å skille dem fra eldre Segregated Witness-transaksjoner. På samme måte som SegWit introduserte vitneversjoner, introduserer Taproot "tapleaf-versjon" for tapscriptene som brukes i MAST-trærne for UTXO-er som bruker Taproot. Dette lar ikke bare skriptene som er begravd i MAST oppgradere uten å bruke nye OP_CODEs på basislaget, men også uten å måtte oppgradere vitneversjoner heller! Så Taproot ble designet for å være så effektiv som mulig å oppgradere i fremtiden uten å begrense andre urelaterte oppgraderinger til protokollen.

Taproot vil gi mange forskjellige brukstilfeller. Til å begynne med kan alle de ikke-samarbeidende klausulene i en Lightning-kanal, for eksempel straffenøkler, eller tidslåser for å tillate dem å brukes, begraves under en MAST med Taproot. Ingen vil noen gang vite at de eksisterer med mindre de må brukes, noe som ytterligere skjuler hvilke UTXO-er som faktisk er Lightning-kanaler eller ikke.

Arveordninger er en annen brukssak. Se for deg et taprottre strukturert slik at etter seks måneder uten at du har flyttet pengene dine, kan hele familien komme sammen og bruke UTXO slik de vil. Så, seks måneder senere, kan alle minus én person bruke det (så tenk om du hadde din kone, to barn og foreldre som nøkkelinnehavere, så forestill deg at etter de ekstra seks månedene kan din kone, ett barn og foreldre signere , eller dine to barn og foreldre kan signere uten din kone, og så videre).

Så, seks måneder etter det, kan alle minus to personer bruke den. Til slutt kunne det koke ned til at bare én person ved hjelp av en advokat (for å sikre at det ikke oppstod noen grusomheter) kunne bruke UTXO.

Eller hva om du bruker multisig for å sikre kjølelageret ditt, men du bare har ett sted du anser som sikkert og forutsigbart på lang sikt? Du kan lage en MAST der nøkkelen på det sikre stedet til slutt, etter noen år, kan bruke disse myntene alene, i tilfelle andre nøkler ble tapt eller ødelagt, men uten å sette myntene dine umiddelbart i fare for tyveri i nåtiden hvis det én nøkkel ble kompromittert.

Dette er en fantastisk og omfattende oppgradering til Bitcoin som uten tvil har vært i arbeid siden nesten fødselen til selve Bitcoin, ikke bare de siste årene der de faktiske implementeringsdetaljene har blitt utarbeidet og implementert.

Det er virkelig en seier på så mange måter for skalerbarheten og nytten av Bitcoin-protokollen at det er vanskelig å formidle på grunn av hvor subtile og "usexy" noen av dem er. Men det forringer ikke seieren. Så, alle fester seg og er klare til å leke med de nye lekene som vi snart må bruke, for Taproot kommer!

Dette er et gjesteinnlegg av Shinobi. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc Bitcoin Magazine.

Kilde: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer