Blockutrymmet är begränsat: Bitcoin-blockkedjan kan endast behandla cirka tio transaktioner per sekund. För att lösa detta utvecklar Bitcoins tekniska grupp andra protokoll som hanterar transaktioner “off-chain”, såsom Lightning Network och sidokedjor. Med hjälp av smarta kryptografiska tricks grupperas dessa transaktioner för att regelbundet lösa Bitcoin-kedjan som en enda transaktion.

Nu går ett nytt protokoll av andra lagret in i striden. Statechains, först föreslogs av Seoul Bitcoin Meetup arrangör och Unhashed Podcast co-värd Ruben Somsen, vänder konceptet med en Bitcoin-transaktion på huvudet. I stället för att skicka mynt från adress till adress skickar statkedjeanvändare bara den privata nyckeln som kan användas för att spendera mynt.

Här är varför det inte är så galet som det låter.

Varför statechains är säkra (mer eller mindre)

Förenklat är en Bitcoin-transaktion bara ett meddelande som säger vilka mynt (“UTXOs”) som flyttar från vilka adresser (“ingångar”) till vilka adresser (“utgångar”). Detta meddelande är kryptografiskt signerat med de privata nycklarna som motsvarar de sändande adresserna, vilket bevisar att ägaren av dessa mynt skapade transaktionen. Paketet (transaktionen plus signaturer) skickas sedan över Bitcoin-nätverket för att så småningom inkluderas i ett Bitcoin-block av en gruvarbetare.

Det är tekniskt möjligt att bara skicka privata nycklar som betalning istället: Detta gör det möjligt för mottagaren av den privata nyckeln att spendera tillhörande mynt. Men det är inte säkert. Om avsändaren – låt oss vara original och kalla henne “Alice” – skickar en privat nyckel till mottagaren – varför inte kalla honom “Bob”? – det finns inget sätt för Bob att vara säker på att Alice inte behöll en kopia av nyckeln. Om hon behöll en kopia av nyckeln, som vi i det här sammanhanget kommer att kalla “övergående nyckel”, kan Alice fortfarande spendera myntet på blockkedjan, så myntet är inte uteslutande Bobs alls.

Statechains första lösning på detta problem är att lägga till en andra nyckel till mixen. Genom att låsa myntet i en två-av-två-inställning för multisignatur (multisig) kan det bara flyttas i blockkedjan om båda nycklarna loggar in.

Denna andra nyckel genereras av ett neutralt parti, Victor, som blir statskedjans facilitator. Victor har en mycket viktig uppgift. Victor måste underteckna en transaktion om, och endast om den sista mottagaren av den övergående nyckeln ber honom att göra det.

Så, låt oss säga att Alice sätter upp en statkedja, med Victor som facilitator. Alice genererar en övergångsnyckel, Victor genererar Victorns nyckel och de använder sina två nycklar för att skapa en multisig-adress. Alice skickar sedan en bitcoin till den här adressen, “låser upp den” mellan Alice och Victor. Om Alice nu vill skicka myntet till Bob kan hon skapa en transaktion, underteckna det med den övergående nyckeln och be Victor att också underteckna det. Med båda signaturerna kan Alice sända transaktionen och skicka myntet till Bob som en vanlig blockchain-transaktion.

Men det missar naturligtvis statskedjans poäng. Alice har en bättre idé. Alice skickar istället den övergående nyckeln till Bob och berättar för Victor att hon gjorde det. Detta gör Bob till den sista mottagaren av den övergående nyckeln. Bob kan nu kontakta Victor och be honom om en signatur för att flytta myntet.

Alice har fortfarande den övergående nyckeln också. Men om hon skulle be Victor hjälpa till att underteckna en transaktion för att flytta myntet skulle Victor dock vägra. Alice äger inte längre myntet när det gäller Victor. Och eftersom hon bara har den övergående nyckeln kan hon verkligen inte flytta den på egen hand.

Skulle Bob någonsin vilja flytta mynten till någon annan – säg Carol – skulle han naturligtvis kunna upprepa statekedjesticket. När han skickar övergångsnyckeln till Carol och berättar för Victor, kommer Victor bara att samarbeta med Carol från och med då och effektivt göra myntet Carol’s. Denna process kan upprepas ett godtyckligt antal gånger, vidarebefordra den övergående nyckeln till Dan, Erin, Frank och så vidare, utan att någonsin kräva en blockchain-transaktion.

Inte litar på Victor

Scenariot som beskrivs ovan tar faktiskt inte bort allt förtroende från systemet. Snarare är Victor en hel del förtroende.

För det första, om Victor inte undertecknar en blockchain-transaktion på begäran, kan myntet inte flyttas alls. (Kanske Victor’s dator kraschade, eller han träffades av en buss, eller kanske Victor – medveten om sin makt – utpressar den sista mottagaren av den övergående nyckeln för att betala en del av myntet i utbyte mot signaturen.)

Detta problem kan lösas – men det är här statkedjedesignen blir lite mer komplex.

När hon initialt sätter upp statykedjan tar Alice ett försiktighetssteg. Redan innan hon skickar myntet till multisig-adressen skapar hon en “backup-transaktion” som skickar myntet från denna multisig-adress till en ny adress.

Myntet kan spenderas från denna nya adress under två förhållanden. Antingen både Victor och ägaren av den övergående nyckeln undertecknar transaktionen, som normalt, eller så kan Alice spendera mynten på egen hand, till exempel en vecka.

Alice sänder inte denna reservtransaktion till Bitcoin-nätverket. Istället ger hon det till Victor, ber honom att underteckna transaktionen och låter honom ge tillbaka till henne.

Först efter att Alice har fått den signerade (men ännu inte sända) reservtransaktionen från Victor skickar hon sitt mynt till multisig-adressen. På detta sätt, även om Victor försvinner, kan hon sända reservtransaktionen och kräva tillbaka mynt efter en vecka.

När Alice nu vill skicka den övergående nyckeln till Bob, kontaktar hon först Victor och ber honom att underteckna en ny reservtransaktion för Bob och ge den till honom. Så när Bob får den övergående nyckeln från Alice, har han redan en icke-utsänd men undertecknad reservtransaktion från Victor, så att han kan göra anspråk på myntet om Victor försvinner..

Som en sista touch använder Alice och Bob (och alla efterföljande ägare av den övergående nyckeln) ett trick som är utformat för Lightning Network som heter Eltoo. Eltoo skulle tillåta Bob att “åsidosätta” Alice’s backup-transaktion med sin egen backup-transaktion. Så om Alice någonsin försöker fuska genom att sända sin gamla reservtransaktion kan Bob antingen använda veckan som Alice behöver vänta på att samarbeta med Victor och göra anspråk på myntet, eller så kan han helt enkelt åsidosätta Alices uppdateringstransaktion med sin egen för att få pengarna.

Första problemet löst.

Lita på Victor (lite)

Medan problemet med att Victor försvinner är löst finns det ett annat problem: Victor kan fuska. Han kunde samarbeta med en tidigare ägare av den privata nyckeln, som Alice, för att stjäla myntet från Bob, Carol, Dan, Erin, Frank eller den som var den sista mottagaren av den övergående nyckeln. (Han kunde senare också samarbeta med Bob för att stjäla från Carol, Dan, Erin, Frank … och så vidare.)

Detta problem kan faktiskt inte lösas helt – och detta är kanske den största nackdelen med statliga kedjor. Men risken kan minimeras.

Ett steg mot att minimera denna risk är att “dela upp” Victor och ersätta honom med flera enheter. “Victor’s key” är uppdelad. Det blir således en egen multisig-inställning där, säg åtta deltagare av, säg 12, måste samarbeta med den övergående nyckelhållaren för att flytta myntet. Att samarbeta med åtta ”Victors” borde vara svårare än att samarbeta med bara en Victor.

För det andra kan det göras uppenbart för omvärlden om dessa “Victors” fuskar. Detta görs genom att i huvudsak skapa en ny, miniatyr blockchain – faktiskt “statskedjan” – där Alice, Bob, Carol och de andra undertecknar ett meddelande som bekräftar att de har vidarebefordrat myntet och till vem. Om Victors samarbetar med Alice för att spendera myntet efter att hon undertecknat det till Bob på statskedjan, ser alla. (Detaljerna om hur denna miniatyrblockchain i sig skulle se ut exakt är ännu inte utarbetad, men det här är inte ett särskilt svårt problem att lösa.)

För det tredje kan dessa “Victors” vara välkända enheter; till exempel en grupp Bitcoin-företag. Dessa företag skulle ha sitt rykte på linjen och skulle därför ha något att förlora genom att fuska – även om de kunde tjäna ett mynt genom att göra det. Även om det inte är kryptografiskt perfekt, gör detta säkerhetsantagandet för statkedjor som liknar federerade sidokedjor, som Blockstreams Liquid eller den nuvarande implementeringen av RSK Labs RSK.

Och det är allt!

Med statechains kan du skicka privata nycklar utanför kedjan istället för att skicka mynt till nya adresser. Men du kan fortfarande använda nycklarna för att spendera mynten i kedjan.Med statechains kan du skicka privata nycklar utanför kedjan istället för att skicka mynt till nya adresser.

Begränsningar av statechains (och potentiella lösningar)

Utöver det nödvändiga förtroendet för “Victors” att inte samarbeta med en tidigare statkedjedeltagare har statkedjor vissa begränsningar.

Begränsningar

Det första att notera är att, som de förklaras i den här artikeln, kräver statechains två protokolluppgraderingar: Schnorr-signaturer och Sighash_Anyprevout (eller något liknande). Båda dessa uppgraderingar är pågående verk men verkar osannolikt omstridda.

En annan begränsning är att statskedjor endast tillåter överföring av hela UTXO: er; Alice mynt i samband med denna artikel. Eftersom Alice ursprungligen låste in exakt en bitcoin, och hon skickar den övergående nyckeln som motsvarar denna bitcoin, måste hon skicka hela myntet, och så även Bob, Carol och de andra. Detta är en ganska stor begränsning jämfört med en normal Bitcoin-transaktion, där någon bråkdel av ett mynt kan spenderas, medan resten återförs till avsändaren som förändring.

Lösningar

Ändå är detta inte nödvändigtvis en showstopper. För det första kan statkedjor kombineras med ett annat trick som kallas “atombyten”. Denna åtgärd skulle göra det möjligt för Alice att byta hela sitt mynt med Zach, som har två halvmynt, på ett sådant sätt att ingen av dem behöver lita på att den andra inte kommer tillbaka ur handeln halvvägs. Allt detta kan hända utan att det krävs en on-chain-transaktion. Detta ökar flexibiliteten.

För det andra kan även överföring av hela UTXOs vara mycket användbart i vissa sammanhang. Kanske mest intressant skulle det tillåta deltagare att överföra hela blixtkanaler. Genom att balansera en blixtkanal till exakt rätt belopp (till exempel genom att först betala sig själv i en annan kanal) kan Alice fortfarande betala Bob en bråkdel av myntet. Som en bonus kan detta låta Bob öppna Lightning-kanaler omedelbart utan att kräva en on-chain finansieringstransaktion (vilket tar tid och avgifter).

Plus, eftersom Lightning-transaktioner har det motsatta problemet – stora värdeöverföringar är svårare att genomföra än mindre – statekedjor och Lightning Network kan komplettera varandra ganska snyggt.

Sekretessfrågor

Det är inte heller klart hur mycket sekretessstatuskedjor kan erbjuda exakt. I värsta fall skulle Victors och andra deltagare i statskedjan veta exakt vem som betalade vem. (Även om det i verkligheten fortfarande skulle vara offentliga nycklar, inte riktiga namn.) Det finns sätt att förbättra detta när det gäller Victors. Att använda blinda signaturer (ett kryptografiskt knep som först föreslogs av eCash-uppfinnaren David Chaum på 1980-talet) har till exempel den extra fördelen att kunna avlasta ansvaret för transaktioner från Victors till användarna själva. (Victors skulle helst inte ens veta vad de skulle skriva på.)

Sekretess från andra deltagare kan i sin tur också lösas med atombyten, vilket skulle hjälpa till att fördunkla ägarkedjan. Det finns förmodligen fler lösningar för att förbättra integriteten, som anpassningar av CoinJoin. (Detta är till exempel också vad den sekretessbevarande Wasabi Wallet använder.) Men detaljer har ännu inte utarbetats.

Det finns också några farhågor om tidigare deltagare i kedjan som försöker fuska genom att försöka hämta mynt genom reservtransaktionen. Även om detta sannolikt inte kommer att lyckas, skulle det bara kosta en (on-chain) transaktionsavgift att försöka, så opportunistiskt fuskbeteende kan begränsa statens.

Slutligen är statkedjor naturligtvis ett relativt nytt koncept; peer review pågår.

Tack till Ruben Somsen för information och feedback. För mer information om statechains, se hans förklaring på Medium eller hans presentation på Breaking Bitcoin i Amsterdam.