Pælerod kommer til Bitcoin: Hvordan det virker, dets historie og implikationer

Taproot og Schnorr signaturer går live på Bitcoin på blok 709,632. Dette vil være en massiv grundlæggende præstation at fortsætte med at bygge videre på i fremtiden. Det er fire år siden, at Segregated Witness gik live på netværket, vores sidste større protokolopgradering. Det er lige så lang som en halveringscyklus!

Tænk over det. Fire år fra SegWit går live til Taproot går live. Langsom, metodisk tålmodighed, som den skal være. Men Taproot/Schnorrs historie går meget længere tilbage end det.

Pælerodens historie

Nogle, der har været her et stykke tid, vil måske finde dette ironisk, men den første omtale af Schnorr-signaturer, som jeg er klar over, var faktisk fra den tidligere Bitcoin Core-udvikler, der blev enterprise blockchain-bygger Mike Hearn. I 2012 har han opdraget ideen om en ny kryptografisk kurve i forhold til batchverifikation af signaturer for at gøre nodevalidering mindre beregningsmæssigt dyr. I sidste ende var den ordning, han foreslog, afhængig af Schnorrs underskrifter.

Adam Back diskuterede naivt ordninger at lave en multisig-adresser, der lignede en singlesig-adresser tilbage i 2014, ved at bruge Schnorr-signaturer. Selv Gavin Andresen inkluderet Schnorr i stedet for ECDSA på sin ønskeliste over ændringer, som han ville foretage på Bitcoin, hvis han kunne vifte med en tryllestav.

Siden temmelig nær begyndelsen af ​​Bitcoin har de fleste udviklere, der er aktivt involveret i Bitcoin Core, ønsket Schnorr-signaturer, og der har altid været en ret solid konsensus om deres overlegenhed i forhold til ECDSA-signaturer. Det kunne faktisk hævdes, at ECDSA blev oprettet specifikt, fordi Schnorr signaturordningen var patenteret, og der var et massivt behov for en open source kryptografisk signaturordning, der ikke var behæftet med patenter.

Schnorr er meget mere effektiv og let manipulerbar (ting kan tilføjes, trækkes fra osv. fra signaturer, og hvis det gøres korrekt, kan det stadig efterlade brugere med gyldige signaturer, når de burde have dem) end ECDSA. Brug af ECDSA var et spørgsmål om nødvendighed snarere end ønske i de fleste kryptografiske applikationer gennem årene.

Merkelized Abstract Syntax Trees (MAST), pælerods-halvdelen af ​​denne kommende pælerodsopgradering, har en lignende langvarig historie. Jeg kan ikke finde citatet, men jeg husker tydeligt, at jeg så den sætning kastet rundt af personer som Peter Todd på Bitcointalk.org tilbage omkring 2013 eller 2014.

Den oprindelige BIP for MAST blev foreslået af Johnson Lau i 2016. Dette forslag oplevede også en vis aktivitet omkring 2017, da Mark Friedenbach, BTCDrak og Kalle Alm delte det op i to separate BIP'er (116 , 117) og udvidet på Laus oprindelige forslag.

MAST sad lidt i limbo det næste år, indtil Greg Maxwell kom op med den første Pælerod-idé og offentliggjort det til bitcoin-dev-mailinglisten. Hans centrale indsigt var, at i enhver kontraktsag mellem flere deltagere, han kunne komme i tanke om, var der et "optimalt resultat", hvor kontrakten kunne afvikles ved, at alle bare underskrev det passende resultat i stedet for at håndhæve resultatet med mere avancerede scripts og transaktioner. Dette er den grundlæggende påstand om, at Taproot er baseret på, dvs. at tilpasse MAST-træet til en almindelig nøgle på øverste niveau, der kan bruges uden at afsløre, om der overhovedet eksisterer et Merkle-træ med andre forbrugsbetingelser.

Det sidste lille stykke af denne historielektion starter med at Pieter Wiulle annoncerer udkast til BIP'er for Schnorr og Taproot i tandem til mailinglisten den 6. maj 2019. I januar 2020 blev dette formelt afsluttet til BIPs 340, 341 og 342. Fra dette tidspunkt var det bare en masse små detaljeforfining på implementeringsniveau, en vis gennemgangsperiode og så den langvarige kamp om aktiveringsmekanismer. Det fører os til nu, bare genert af aktivering.

Vigtigheden af ​​Schnorr-signaturer

Så hvad er den store sag med Schnorr-signaturer? Nå, til at starte med gør de transaktioner mindre. En ECDSA-signatur er normalt omkring 72 bytes stor for en enkelt signatur i en transaktion. Schnorr-signaturer klokkes ind med maksimalt 64 bytes pr. signatur. Det er en besparelse på omkring 12 % i størrelse sammenlignet med ECDSA for hver Schnorr-signatur. Dette er både en direkte fordel for den person, der bruger Schnorr, som vil betale mindre i gebyrer end en ECDSA-bruger, men det er også en direkte fordel for folk, der ikke bruger Schnorr ved at kræve, at lidt mindre data gemmes i blockchainen for at behandle og validere en andens Schnorr underskrifter.

Det er altid godt at gemme mindre data, men hvad der er endnu bedre er at øge effektiviteten af ​​valideringen af ​​de data, du skal gemme. En af Schnorrs gode egenskaber, lineariteten af ​​matematikken bag den, giver også mulighed for en god egenskab, du ønsker i Bitcoin-data: batchvalidering. Når din node modtager en blok fra netværket, analyserer den hver enkelt transaktion og validerer hver signatur én efter én.

Dette er en stor del af, hvorfor validering af blokke bruger meget CPU-strøm. Schnorr-signaturer kan alle samles sammen og valideres matematisk på én gang, ligesom at smadre dem sammen og udføre en matematisk operation i stedet for en masse individuelle. Så jo flere Schnorr-signaturer der er, jo større er beregningsmæssige besparelser. Dette er en massiv skaleringsgevinst for netværket.

En anden massiv forbedring Schnorr bringer er multisignatur-scripts. Hver multisig-adresse skal eksplicit afsløre alle de individuelle offentlige nøgler, der er involveret i et multisig-script, når det bruges, og der skal angives en signatur for hver nøgle, der er involveret i forbrugsprocessen. Med Schnorrs matematiske egenskaber åbner døren sig for MuSig, en multisignaturstandard. Du kan bare tilføje nøgler sammen og afslutte med en enkelt offentlig nøgle, som alles private nøgledelinger kan signere for ved hjælp af nye signaturprotokoller. Jonas Nick fra Blockstream benchmarkes MuSig2 ved at tage to minutter til en million deltagere i en multisig-adresse at underskrive. Skaleringsforbedringen til multisignaturscripts kan ikke undervurderes.

Dette enorme spring fremad for multisignatur-scripts har også en enorm betydning for privatlivsprofilen og omkostningerne ved adskillige applikationer bygget oven på Bitcoin. MuSig-baserede Lightning-kanaler kan nu blandes ind i hele anonymitetssættet af Schnorr/Taproot UTXO'er på kæden, fordi ingen længere vil være i stand til at skelne det faktum, at de er en to-af-to multisig-output.

De vil smelte sammen og ligne et enkelt signaturscript. Det samme gælder for enhver multisig UTXO generelt. Dette vil have mange konsekvenser for folk, der bruger multisignaturscripts til bedre at beskytte deres kølelager med en mere robust sikkerheds- og gendannelsesmodel end et enkelt signaturscript.

For det første vil det ikke være indlysende, at de bruger et multisig-setup ved at se blockchain, så dette vil, ligesom i tilfældet med Lightning, få dem til at smelte sammen med alt andet. En vigtig gevinst er dog med hensyn til økonomien: Brug af multisignatur lige nu kræver at give en separat signatur for hver nøgle, der er involveret i til sidst at bruge en UTXO. Med Schnorr/MuSig vil tingene blive komprimeret til en enkelt signatur for den enkelte kombinerede offentlige nøgle, hvilket betyder, at det at bruge multisig UTXO'er ved hjælp af MuSig bliver meget billigere, da det skubber mindre data til blockchainen.

En sidste cool ting, som Schnorr-signaturer gør, er at forenkle implementeringen af ​​adaptersignaturer drastisk. Tænk på en adaptersignatur, der er "krypteret" med en værdi, der er blevet tilføjet eller trukket fra en gyldig signatur. Det er ikke gyldigt, før du vender den matematiske operation om, eller "dekrypterer den" med "nøglen", som blev brugt til at manipulere den. Dette er muligt med ECDSA, men på grund af at matematikken er ikke-lineær sammenlignet med Schnorr, er det relativt kompliceret, og der er mange sikkerhedsproblemer at overveje ved implementeringen.

På grund af Schnorrs lineære egenskaber er en adaptersignatur dog så simpel som at tage en enkelt (f.eks. tallet 9,300,030) og trække en værdi fra den (f.eks. 30). Når den part, der har adaptersignaturen, lærer den subtraherede værdi, kan de blot tilføje den tilbage og voila, har de en gyldig signatur igen.

Konsekvenserne af pælerod

Som diskuteret lidt ovenfor, er Taproot i virkeligheden i bund og grund bare MAST, bortset fra at i stedet for at det fungerer som P2SH (hvor du hash scriptet, eller i MASTs tilfælde, Merkle-roden i toppen af ​​scripttræet), "tweaker" du en Schnorr offentlige nøgle ved roden af ​​Merkle træet.

Tweaking fungerer på grund af Schnorrs lineære egenskaber - når du "tweaker" en offentlig nøgle med en Merkle-rod (tilføje den Merkle-rod til den offentlige nøgle), så kan du blot tilføje Merkle-roden til den originale private nøgle og generere forbrugsnøglen for den nye tweakede offentlige nøgle. Dvs., du tilføjer det samme til både offentlige og private nøgler, og de er stadig et gyldigt nøglepar. Dette skjuler eksistensen af ​​et MAST-træ, medmindre der bruges en gren af ​​det, men grundlæggende er det stadig kun et MAST-træ, bare et der er forpligtet til på en mere effektiv og privat måde.

Evnen til at forpligte sig til forskellige forbrugsscripts i et Merkle-træ og kun afsløre det brugte script er en massiv skalerbarhedsgevinst i form af smart kontraktkompleksitet, der er mulig at bygge på Bitcoin.

Ligesom hvordan blokstørrelsen begrænser antallet af transaktioner pr. blok, er der en grænse for transaktionsstørrelse på 100 kilobyte. Den eneste forskel er, at i stedet for at være en konsensusregel, er det en politisk regel. Det betyder, at en minearbejder kan mine en transaktion større end 100 kilobyte, men som standard vil ingens node på netværket videresende en transaktion, der er større end den, til minearbejderen i første omgang.

Dette begrænser i sagens natur størrelsen af ​​det script, der bruges til at låse en Bitcoin UTXO. Selv med P2SH, hvor UTXO er låst til en hash af scriptet, som ikke afsløres, før du bruger det, er du stadig nødt til at afsløre hele scriptet, når du bruger det. Taproot øger denne skalerbarhedsgrænse for script ved ikke at kræve, at du afslører hele scriptet, når du bruger det. I stedet for at den samlede størrelse af alle de måder, du kan bruge UTXO på, er begrænset til grænsen for transaktionsstørrelsen, skal du kun sørge for, at enhver enkelt måde, du kan bruge en Taproot UTXO på, respekterer denne begrænsning.

Der er også masser af privatlivsfordele, der følger med Taproot. En af de store fordele ved et MAST-træ er evnen til at skabe alle slags betingede situationer, hvor mønter kan bruges af andre parter.

Forestil dig ting som arveordninger, hvor dine børn efter et år eller deromkring kan bruge dine mønter, eller i tilfælde af at du nægter at underskrive, har din kone og en advokat en potentiel vej til at inddrive mønter. Intet om disse udgiftsbetingelser afsløres for offentligheden, medmindre de rent faktisk bliver brugt. Denne to-delte proces giver plausibel benægtelse for andre parter, der er involveret i forskellige forbrugsgrene, du konstruerer med hensyn til deres involvering i den UTXO, samt beskytter dem mod en tyv eller angriber, der forebyggende målretter dem, vel vidende, at de har en vis grad af kontrol over deres målets UTXO'er.

På et teknisk plan er Taproot også blevet relativt godt konstrueret. Enhver, der læser, og som er bekendt med Segregated Witness på et hvilket som helst dybt niveau, bør være bekendt med vidneversionen.

Da Segregated Witness blev implementeret, oprettede det den nye "vidne"-sektion af en transaktion, hvor signaturdata blev flyttet til. Vidnedata havde et versionsflag, så det kunne opgraderes til ny funktionalitet uden at skulle bruge udefinerede OP_CODEs på basislaget til nye funktioner.

Det er faktisk sådan, Taproot/Schnorr er blevet implementeret. Segregerede vidnetransaktioner bruger vidneversion nul. Når Taproot/Schnorr snart går live, vil de bruge den nye vidneversion XNUMX til at skelne dem fra ældre Segregated Witness-transaktioner. På samme måde som SegWit introducerede vidneversioner, introducerer Taproot "tapleaf version" for tapscripts, der bruges i MAST-træerne til UTXO'er, der bruger Taproot. Dette gør det ikke kun muligt for de scripts, der er begravet i MAST, at opgradere uden at bruge nye OP_CODEs på basislaget, men også uden at skulle opgradere vidneversioner! Så Taproot blev designet til at være så effektiv som muligt at opgradere i fremtiden uden at begrænse andre ikke-relaterede opgraderinger til protokollen.

Pælerod vil bringe mange forskellige anvendelsesmuligheder. Til at starte med kan alle de ikke-samarbejdsvillige klausuler i en Lightning-kanal, såsom strafnøgler eller tidslåse for at tillade dem at blive brugt, begraves under en MAST med Taproot. Ingen vil nogensinde vide, at de eksisterer, medmindre de skal bruges, hvilket yderligere slører, hvilke UTXO'er der faktisk er Lightning-kanaler eller ej.

Arveordninger er en anden brugssag. Forestil dig et pælerodstræ struktureret, så efter seks måneder, hvor du ikke har flyttet dine penge, kan hele din familie samles og bruge UTXO, som de vil. Så, seks måneder senere, kan alle minus én person bruge det (så forestil dig, hvis du havde din kone, to børn og forældre som nøgleholdere, så forestil dig, at efter de ekstra seks måneder kan din kone, et barn og forældre skrive under , eller dine to børn og forældre kan skrive under uden din kone, og så videre).

Så, seks måneder efter det, kan alle minus to personer bruge det. Til sidst kunne det koge ned til, at kun én person med hjælp fra en advokat (for at sikre, at der ikke opstod noget skænderi) kunne bruge UTXO.

Eller hvad nu hvis du bruger multisig til at sikre dit kølerum, men du kun har ét sted, som du anser for sikkert og forudsigeligt på lang sigt? Du kan oprette en MAST, hvor nøglen på det sikre sted til sidst, efter et par år, kan bruge disse mønter alene, bare hvis andre nøgler skulle gå tabt eller ødelægges, men uden at sætte dine mønter i fare for tyveri i nutiden, hvis det en nøgle blev kompromitteret.

Dette er en fantastisk og omfattende opgradering til Bitcoin, der uden tvivl har været undervejs siden næsten selve Bitcoins fødsel, ikke kun de sidste par år, hvor de faktiske implementeringsdetaljer er blevet udarbejdet og implementeret.

Det er virkelig en gevinst på så mange måder for skalerbarheden og anvendeligheden af ​​Bitcoin-protokollen, at det er svært at formidle på grund af hvor subtile og "usexede" nogle af dem er. Men det forringer ikke sejren. Så alle bliver spændt fast og klar til at lege med det nye legetøj, som vi snart skal bruge, for pælerod kommer!

Dette er et gæsteindlæg af Shinobi. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc Bitcoin Magazine.

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