Blokplads er begrænset: Bitcoin-blockchain kan højst kun behandle omkring 10 transaktioner pr. Sekund. For at løse dette udvikler Bitcoins tekniske samfund protokoller i andet lag, der behandler transaktioner “off-chain”, såsom Lightning Network og sidekæder. Ved hjælp af kloge kryptografiske tricks batches disse transaktioner for periodisk at afregne på Bitcoin-blockchain som en enkelt transaktion.
Nu er en ny protokol til andet lag ved at komme ind i kampen. Statekæder, først foreslået af Seoul Bitcoin Meetup arrangør og Unhashed Podcast co-vært Ruben Somsen, vender konceptet med en Bitcoin-transaktion på hovedet. I stedet for at sende mønter fra adresse til adresse, sender statekædebrugere bare den private nøgle, der kan bruges til at bruge mønterne.
Her er hvorfor det ikke er så vildt som det lyder.
Hvorfor statechains er sikre (mere eller mindre)
Forenklet er en Bitcoin-transaktion kun en besked, der siger, hvilke mønter (“UTXOs”) flytter fra hvilke adresser (“input”) til hvilke adresser (“output”). Denne meddelelse er kryptografisk underskrevet med de private nøgler, der svarer til afsendelsesadresserne, hvilket beviser, at ejeren af disse mønter oprettede transaktionen. Bundtet (transaktionen plus underskrifter) sendes derefter over Bitcoin-netværket for til sidst at blive inkluderet i en Bitcoin-blok af en minearbejder.
Det er teknisk muligt bare at sende private nøgler som betaling i stedet: Dette gør det muligt for modtageren af den private nøgle at bruge de tilknyttede mønter. Men det er ikke sikkert. Hvis afsenderen – lad os være original og kalde hende “Alice” – sender en privat nøgle til modtageren – hvorfor så ikke kalde ham “Bob”? – der er ingen måde for Bob at være sikker på, at Alice ikke opbevarede en kopi af nøglen. Hvis hun opbevarede en kopi af nøglen, som vi i denne sammenhæng kalder den “forbigående nøgle”, kan Alice stadig bruge mønten på blockchain, så mønten er slet ikke udelukkende Bob.
Statechains ‘første løsning på dette problem er at tilføje en anden nøgle til mixet. Ved at låse mønten i en to-af-to multi-signatur (multisig) opsætning, kan den kun flyttes på blockchain, hvis begge nøgler underskriver enighed.
Denne anden nøgle genereres af en neutral part, Victor, der bliver facilitator for statskæden. Victor har en meget vigtig opgave. Victor skal underskrive en transaktion, hvis og kun hvis den sidste modtager af den midlertidige nøgle beder ham om det.
Lad os sige, at Alice opretter en statskæde med Victor som facilitator. Alice genererer en midlertidig nøgle, Victor genererer Victor’s nøgle, og de bruger deres to nøgler til at oprette en multisig-adresse. Alice sender derefter en bitcoin til denne adresse, “låser den op” mellem Alice og Victor. Hvis Alice nu vil sende mønten til Bob, kunne hun oprette en transaktion, underskrive den med den midlertidige nøgle og bede Victor om at underskrive den også. Med begge underskrifter kan Alice sende transaktionen og sende mønten til Bob som en almindelig blockchain-transaktion.
Men det savner naturligvis statskædens pointe. Alice har en bedre idé. Alice sender i stedet den midlertidige nøgle til Bob og fortæller Victor, at hun gjorde det. Dette gør Bob til den sidste modtager af den midlertidige nøgle. Bob kan nu kontakte Victor og bede ham om en underskrift for at hjælpe med at flytte mønten.
Alice har også stadig den midlertidige nøgle. Men nu, hvis hun skulle bede Victor om at hjælpe med at underskrive en transaktion for at flytte mønten, ville Victor nægte. Alice ejer ikke længere mønten, hvad Victor angår. Og da hun kun har den midlertidige nøgle, er hun faktisk ikke i stand til at flytte den alene.
Skulle Bob nogensinde ønske at flytte mønterne til en anden – siger Carol – kunne han selvfølgelig gentage statekædetricket. Når han sender den midlertidige nøgle til Carol og fortæller Victor, vil Victor kun arbejde sammen med Carol fra da af og effektivt fremstille mønten Carol’s. Denne proces kan gentages et vilkårligt antal gange, videresende den midlertidige nøgle til Dan, Erin, Frank og så videre uden nogensinde at kræve en blockchain-transaktion.
Ikke tillid til Victor
Scenariet som beskrevet ovenfor fjerner faktisk ikke al tillid fra systemet. Snarere er der en stor tillid til Victor.
For det første, hvis Victor ikke underskriver en blockchain-transaktion efter anmodning, kan mønten slet ikke flyttes. (Måske styrtede Victor’s computer, eller han blev ramt af en bus, eller måske Victor – klar over sin magt – afpresser den sidste modtager af den midlertidige nøgle for at betale ham en del af mønten til gengæld for signaturen.)
Dette problem kan løses – men det er her statekædedesignet bliver lidt mere komplekst.
Da hun oprindeligt opretter statskæden, tager Alice et forsigtigt skridt. Selv før hun sender mønten til multisig-adressen, opretter hun en “backup-transaktion”, der sender mønten fra denne multisig-adresse til en ny adresse.
Mønten kan bruges fra denne nye adresse under to betingelser. Enten både Victor og ejeren af den midlertidige nøgle underskriver transaktionen som normalt, eller Alice kan bruge mønterne alene efter for eksempel en uge.
Alice udsender ikke denne backup-transaktion til Bitcoin-netværket. I stedet giver hun det til Victor, beder ham om at underskrive transaktionen og får ham til at give den tilbage til hende.
Først efter Alice har modtaget denne underskrevne (men endnu ikke udsendte) backuptransaktion fra Victor sender hun sin mønt til multisig-adressen. På denne måde, selvom Victor forsvinder, kan hun sende backup-transaktionen og kræve mønterne tilbage efter en uge.
Når Alice nu vil sende den midlertidige nøgle til Bob, kontakter hun først Victor og beder ham om at underskrive en ny backup-transaktion for Bob og give den til ham. Så når Bob får den midlertidige nøgle fra Alice, har han allerede en ikke-udsendt, men underskrevet backup-transaktion fra Victor, så han kan kræve mønten, hvis Victor forsvinder.
Som et sidste greb bruger Alice og Bob (og alle efterfølgende ejere af den midlertidige nøgle) et trick designet til Lightning Network kaldet Eltoo. Eltoo tillod Bob at “tilsidesætte” Alice’s backup-transaktion med sin egen backup-transaktion. Så hvis Alice nogensinde prøver at snyde ved at udsende sin gamle backup-transaktion, kan Bob enten bruge den uge, som Alice har brug for at vente på at samarbejde med Victor og kræve mønten, eller han kan simpelthen tilsidesætte Alice’s opdateringstransaktion med sin egen for at få pengene.
Første problem løst.
Stol på Victor (lidt)
Mens problemet med at Victor forsvinder er løst, er der et andet problem: Victor kunne snyde. Han kunne samarbejde med en tidligere ejer af den private nøgle, som Alice, for at stjæle mønten fra Bob, Carol, Dan, Erin, Frank eller den, der var den sidste modtager af den midlertidige nøgle. (Han kunne senere også samarbejde med Bob for at stjæle fra Carol, Dan, Erin, Frank … og så videre.)
Dette problem kan faktisk ikke løses fuldstændigt – og dette er måske den største ulempe ved statskæder. Men risikoen kan minimeres.
Et skridt i retning af at minimere denne risiko er at “opdele” Victor og erstatte ham med flere enheder. “Victor’s key” er delt. Det bliver således et eget multisig-setup, hvor f.eks. Otte deltagere ud af f.eks. 12 skal samarbejde med den midlertidige nøgleholder for at flytte mønten. At samarbejde med otte “sejre” burde være sværere end at samarbejde med kun en Victor.
For det andet kan det gøres indlysende for omverdenen, hvis disse “Victors” snyder. Dette gøres ved i det væsentlige at oprette en ny miniature blockchain – faktisk “statskæden” – hvor Alice, Bob, Carol og de andre underskriver en besked, der bekræfter, at de har videresendt mønten og til hvem. Hvis sejrerne samarbejder med Alice om at bruge mønten, efter at hun underskrev den på Bob på statskæden, ser alle. (Detaljerne om, hvordan denne miniatureblockchain i sig selv ville se ud, er endnu ikke udarbejdet, men dette er ikke et meget vanskeligt problem at løse.)
For det tredje kunne disse “sejre” være velkendte enheder; for eksempel en gruppe Bitcoin-virksomheder. Disse virksomheder ville have deres omdømme på banen og har derfor noget at tabe ved at snyde – selvom de kunne tjene en mønt ved at gøre det. Selvom det ikke er kryptografisk perfekt, gør dette sikkerhedsantagelsen for statskæder svarende til fødererede sidekæder, som Blockstreams Liquid eller den aktuelle implementering af RSK Labs ‘RSK.
Og det er det!
Statechains giver dig mulighed for at sende private nøgler off-chain i stedet for at sende mønter til nye adresser.
Begrænsninger for Statechains (og potentielle løsninger)
Ud over den krævede tillid til “Victors” for ikke at samarbejde med en tidligere statkædedeltager, har statskæder nogle begrænsninger.
Begrænsninger
Den første ting at bemærke er, at statekæder, som de forklares i denne artikel, kræver to protokolopgraderinger: Schnorr-signaturer og Sighash_Anyprevout (eller noget lignende). Begge disse opgraderinger er igangværende arbejder, men synes usandsynligt at være omstridte.
En anden begrænsning er, at statekæder kun tillader overførsel af hele UTXO’er; Alice’s mønt i forbindelse med denne artikel. Da Alice oprindeligt låste nøjagtigt en bitcoin, og hun sender den midlertidige nøgle, der svarer til denne bitcoin, skal hun videregive hele mønten, og det samme skal Bob, Carol og de andre. Dette er en temmelig stor begrænsning sammenlignet med en normal Bitcoin-transaktion, hvor enhver brøkdel af en mønt kan bruges, mens resten returneres til afsenderen som ændring..
Løsninger
Stadig, dette er ikke nødvendigvis en showstopper. For det første kan statskæder kombineres med et andet trick kaldet “atomombytninger”. Dette træk ville gøre det muligt for Alice at udveksle hele sin mønt med Zach, der har to halve mønter, på en sådan måde, at ingen af dem har brug for at stole på den anden for ikke at komme ud af handelen halvvejs. Alt dette kan ske uden at kræve en on-chain-transaktion. Dette øger fleksibiliteten.
For det andet kan selv overførsel af hele UTXO’er være meget nyttige i nogle sammenhænge. Måske mest interessant ville det give deltagerne mulighed for at overføre hele lynkanaler. Ved at afbalancere en Lightning-kanal til det nøjagtige rigtige beløb (for eksempel ved først at betale sig selv i en anden kanal), kan Alice stadig betale Bob en brøkdel af mønten. Som en bonus kunne dette lade Bob åbne lynkanaler med det samme uden at kræve en on-chain finansieringstransaktion (hvilket tager tid og gebyrer).
Plus, da Lightning-transaktioner har det modsatte problem – overførsler af store værdier er sværere at gennemføre end mindre – statekæder og Lightning Network kunne komplementere hinanden ganske pænt.
Privatlivsspørgsmål
Det er heller ikke klart, hvor meget privatlivsstatskæder kunne tilbyde nøjagtigt. I værste fald ville sejrerne og andre deltagere i statskæden vide nøjagtigt, hvem der betalte hvem. (Selvom disse i virkeligheden stadig ville være offentlige nøgler, ikke rigtige navne.) Der er måder at forbedre dette, når det kommer til sejrerne. Brug af blinde signaturer (et kryptografisk trick, der først blev foreslået af eCash-opfinderen David Chaum i 1980’erne), har for eksempel den ekstra fordel, at det er i stand til at aflade ansvaret for transaktioner fra Victors til brugerne selv. (Sejrerne ville ideelt set ikke engang vide, hvad de ville underskrive.)
Privatliv fra andre deltagere kunne igen også løses med atomswaps, hvilket ville hjælpe med at tilsløre ejerskabskæden. Der er sandsynligvis flere løsninger til forbedring af privatlivets fred, som CoinJoin-tilpasninger. (Dette er for eksempel også, hvad den fortrolighedsbeskyttende Wasabi Wallet bruger.) Men detaljer er endnu ikke udarbejdet.
Der er også nogle bekymringer over tidligere deltagere i kæden, der forsøger at snyde ved at forsøge at kræve mønter gennem backup-transaktionen. Selvom dette sandsynligvis ikke vil lykkes, vil det kun koste et (on-chain) transaktionsgebyr at prøve, så opportunistisk snydeadfærd kan begrænse statskædernes potentiale.
Endelig er statskæder naturligvis et relativt nyt koncept; peer review er i gang.
Tak til Ruben Somsen for information og feedback. For mere information om statekæder, se hans forklarer på Medium eller hans præsentation på Breaking Bitcoin i Amsterdam.