Blokkplassen er begrenset: Bitcoin-blokkjeden kan bare behandle omtrent 10 transaksjoner per sekund, på det meste. For å løse dette utvikler Bitcoins tekniske samfunn protokoller i andre lag som behandler transaksjoner “off-chain”, som Lightning Network og sidekjeder. Ved hjelp av smarte kryptografiske triks blir disse transaksjonene gruppert for å jevnlig bosette seg i Bitcoin blockchain som en enkelt transaksjon.

Nå kommer en ny protokoll fra andre lag inn i kampen. Statekjeder, først foreslått av Seoul Bitcoin Meetup arrangør og Unhashed Podcast medvert Ruben Somsen, snur konseptet med en Bitcoin-transaksjon på hodet. I stedet for å sende mynter fra adresse til adresse, sender statain-brukere bare den private nøkkelen som kan brukes til å bruke myntene.

Her er hvorfor det ikke er så gal som det høres ut.

Hvorfor statechains er sikre (mer eller mindre)

Forenklet er en Bitcoin-transaksjon bare en melding som sier hvilke mynter (“UTXOs”) som flytter fra hvilke adresser (“innganger”) til hvilke adresser (“utganger”). Denne meldingen er kryptografisk signert med de private nøklene som tilsvarer sendeadressene, og viser at eieren av disse myntene opprettet transaksjonen. Pakken (transaksjonen pluss signaturer) blir deretter sendt over Bitcoin-nettverket for til slutt å bli inkludert i en Bitcoin-blokk av en gruvearbeider.

Det er teknisk mulig å bare sende private nøkler som betaling i stedet: Dette gjør at mottakeren av den private nøkkelen kan bruke de tilhørende myntene. Men det er ikke sikkert. Hvis avsenderen – la oss være original og kalle henne “Alice” – sender en privat nøkkel til mottakeren – hvorfor ikke kalle ham “Bob”? – det er ingen måte for Bob å være sikker på at Alice ikke oppbevarte en kopi av nøkkelen. Hvis hun beholdt en kopi av nøkkelen, som vi vil kalle den “forbigående nøkkel” i denne sammenheng, kan Alice fortsatt bruke mynten på blockchain, så mynten er ikke utelukkende Bob’s.

Statechains ‘første løsning på dette problemet er å legge til en ny nøkkel til blandingen. Ved å låse mynten i et to-av-to-multi-signatur (multisig) oppsett, kan den bare flyttes på blockchain hvis begge nøklene logger på.

Denne andre nøkkelen genereres av et nøytralt parti, Victor, som blir tilrettelegger for statskjeden. Victor har en veldig viktig oppgave. Victor må signere en transaksjon hvis, og bare hvis den siste mottakeren av den midlertidige nøkkelen ber ham om det.

La oss si at Alice setter opp en statskjede, med Victor som tilrettelegger. Alice genererer en forbigående nøkkel, Victor genererer Victor’s nøkkel, og de bruker sine to nøkler til å lage en multisig-adresse. Alice sender deretter en bitcoin til denne adressen, “låser den opp” mellom Alice og Victor. Nå, hvis Alice ønsker å sende mynten til Bob, kan hun opprette en transaksjon, signere den med den midlertidige nøkkelen og be Victor om å signere den også. Med begge signaturer kan Alice kringkaste transaksjonen og sende mynten til Bob som en vanlig blockchain-transaksjon.

Men det savner selvfølgelig poenget med statskjeden. Alice har en bedre ide. Alice sender i stedet den midlertidige nøkkelen til Bob og forteller Victor at hun gjorde det. Dette gjør Bob til den siste mottakeren av den midlertidige nøkkelen. Bob kan nå kontakte Victor og be ham om en signatur for å flytte mynten.

Alice har fremdeles den midlertidige nøkkelen selv også. Imidlertid, hvis hun skulle be Victor om å hjelpe til med å signere en transaksjon for å flytte mynten, ville Victor nekte. Alice eier ikke lenger mynten så langt det gjelder Victor. Og siden hun bare har den midlertidige nøkkelen, klarer hun faktisk ikke å flytte den på egen hånd.

Skulle Bob noen gang ønske å flytte myntene til noen andre – si Carol – kunne han selvsagt gjenta statekjettingstrikset. Når han sender den midlertidige nøkkelen til Carol og forteller Victor, vil Victor bare samarbeide med Carol fra da av og effektivt lage mynten Carol’s. Denne prosessen kan gjentas et vilkårlig antall ganger, videresende den forbigående nøkkelen til Dan, Erin, Frank og så videre, uten å måtte kreve en blockchain-transaksjon..

Ikke stole på Victor

Scenariet som beskrevet ovenfor fjerner faktisk ikke all tillit fra systemet. Snarere er det stor tillit til Victor.

For det første, hvis Victor ikke signerer en blockchain-transaksjon når du blir bedt om det, kan mynten ikke flyttes i det hele tatt. (Kanskje Victor’s datamaskin krasjet, eller at han ble truffet av en buss, eller kanskje Victor – klar over sin makt – utpresser den siste mottakeren av den midlertidige nøkkelen for å betale ham en del av mynten i retur for signaturen.)

Dette problemet kan løses – men det er her statekjededesignen blir litt mer kompleks.

Når hun opprinnelig setter opp statekjeden, tar Alice et føre-var skritt. Selv før hun sender mynten til multisig-adressen, oppretter hun en “backup-transaksjon” som sender mynten fra denne multisig-adressen til en ny adresse..

Mynten kan brukes fra denne nye adressen under to forhold. Enten både Victor og eieren av den midlertidige nøkkelen signerer transaksjonen, som normalt, eller Alice kan bruke myntene på egenhånd etter for eksempel en uke.

Alice sender ikke denne sikkerhetskopieringstransaksjonen til Bitcoin-nettverket. I stedet gir hun den til Victor, ber ham om å signere transaksjonen og får ham til å gi den tilbake til henne.

Først etter at Alice har mottatt denne signerte (men foreløpig ikke sendte) backup-transaksjonen fra Victor, sender hun mynten sin til multisig-adressen. På denne måten, selv om Victor forsvinner, kan hun kringkaste backup-transaksjonen og kreve myntene tilbake etter en uke.

Nå, når Alice vil sende den midlertidige nøkkelen til Bob, kontakter hun først Victor og ber ham om å signere en ny backup-transaksjon for Bob og gi den til ham. Så når Bob får den midlertidige nøkkelen fra Alice, har han allerede en ikke-kringkastet, men signert backup-transaksjon fra Victor, slik at han kan kreve mynten hvis Victor forsvinner..

Som en siste touch bruker Alice og Bob (og alle påfølgende eiere av den midlertidige nøkkelen) et triks designet for Lightning Network, kalt Eltoo. Eltoo ville tillate Bob å “overstyre” Alice’s backup-transaksjon med sin egen backup-transaksjon. Så hvis Alice noen gang prøver å jukse ved å kringkaste sin gamle backup-transaksjon, kan Bob enten bruke uken Alice trenger å vente på å samarbeide med Victor og kreve mynten, eller han kan bare overstyre Alice’s oppdateringstransaksjon med sin egen for å få pengene.

Første problem løst.

Stoler på Victor (litt)

Mens problemet med at Victor forsvinner er løst, er det et annet problem: Victor kan jukse. Han kunne samarbeide med en tidligere eier av den private nøkkelen, som Alice, for å stjele mynten fra Bob, Carol, Dan, Erin, Frank eller den som var den siste mottakeren av den midlertidige nøkkelen. (Han kunne senere også samarbeide med Bob for å stjele fra Carol, Dan, Erin, Frank … og så videre.)

Dette problemet kan faktisk ikke løses helt – og dette er kanskje den største ulempen med statskjeder. Men risikoen kan minimeres.

Et skritt mot å minimere denne risikoen er å “dele opp” Victor og erstatte ham med flere enheter. “Victor’s key” er delt. Det blir dermed et eget multisig-oppsett hvor for eksempel åtte deltakere av for eksempel 12 må samarbeide med den midlertidige nøkkelholderen for å flytte mynten. Samarbeid med åtte “Victors” burde være vanskeligere enn å samarbeide med bare en Victor.

For det andre kan det gjøres åpenbart for omverdenen hvis disse “Victors” jukser. Dette gjøres ved å lage en ny, miniatyr blockchain – faktisk “statekjeden” – der Alice, Bob, Carol og de andre signerer en melding som bekrefter at de har videresendt mynten og til hvem. Hvis Victors samarbeider med Alice for å bruke mynten etter at hun signerte den for Bob på statekjeden, ser alle. (Detaljene om hvordan denne miniatyrblokkjeden selv ville se ut, er ikke utarbeidet ennå, men dette er ikke et veldig vanskelig problem å løse.)

For det tredje kan disse “seierne” være kjente enheter; for eksempel en gruppe Bitcoin-selskaper. Disse selskapene vil ha sitt rykte på linjen og har derfor noe å tape på juks – selv om de kunne tjene en mynt ved å gjøre det. Selv om det ikke er kryptografisk perfekt, gjør dette sikkerhetsforutsetningen for statskjeder som federerte sidekjeder, som Blockstreams Liquid eller den nåværende implementeringen av RSK Labs ‘RSK.

Og det er det!

Statekjeder lar deg sende private nøkler utenfor kjeden i stedet for å sende mynter til nye adresser. Men du kan fortsatt bruke nøklene til å bruke myntene på kjeden.Statekjeder lar deg sende private nøkler utenfor kjeden i stedet for å sende mynter til nye adresser.

Begrensninger for Statechains (og potensielle løsninger)

I tillegg til den nødvendige tilliten til “Victors” for ikke å samarbeide med en tidligere statkjededeltaker, har statekjeder noen begrensninger.

Begrensninger

Den første tingen å merke seg er at, som de blir forklart i denne artikkelen, statekjeder krever to protokolloppgraderinger: Schnorr-signaturer og Sighash_Anyprevout (eller noe lignende). Begge disse oppgraderingene er i gang, men virker usannsynlige å være omstridte.

En annen begrensning er at statekjeder kun tillater overføring av hele UTXO-er; Alice’s coin i sammenheng med denne artikkelen. Siden Alice i utgangspunktet låste nøyaktig en bitcoin, og hun sender den midlertidige nøkkelen som tilsvarer denne bitcoin, må hun gi hele mynten videre, og det samme må Bob, Carol og de andre. Dette er en ganske stor begrensning sammenlignet med en vanlig Bitcoin-transaksjon, der en hvilken som helst brøkdel av en mynt kan brukes, mens resten returneres til avsenderen som endring..

Løsninger

Likevel er dette ikke nødvendigvis en showstopper. For det første kan statskjeder kombineres med et annet triks som kalles “atombytter.” Dette trekket ville tillate Alice å bytte hele mynten sin med Zach, som har to halvmynter, på en slik måte at ingen av dem trenger å stole på den andre for ikke å gå ut av handelen halvveis. Alt dette kan skje uten at det kreves en on-chain transaksjon. Dette øker fleksibiliteten.

For det andre, selv overføring av hele UTXO-er kan være veldig nyttig i noen sammenhenger. Kanskje det mest interessante er at deltakerne kan overføre hele lynkanaler. Ved å balansere en lynkanal til nøyaktig riktig beløp (for eksempel ved først å betale seg selv i en annen kanal), kan Alice likevel betale Bob en brøkdel av mynten. Som en bonus kan dette la Bob åpne lynkanaler umiddelbart uten å kreve en finansieringstransaksjon på kjeden (som tar tid og gebyrer).

I tillegg, siden Lightning-transaksjoner har det motsatte problemet – overføringer av store verdier er vanskeligere å gjennomføre enn mindre – statekjeder og Lightning Network kan utfylle hverandre ganske pent.

Personvern spørsmål

Det er heller ikke klart hvor mye personvernstatuskjeder kan tilby nøyaktig. I verste fall ville seierne og andre deltakere i statskjeden vite nøyaktig hvem som betalte hvem. (Selv om dette i virkeligheten fremdeles vil være offentlige nøkler, ikke ekte navn.) Det er måter å forbedre dette når det gjelder seierne. Å bruke blinde signaturer (et kryptografisk triks som for første gang ble foreslått av eCash-oppfinneren David Chaum på 1980-tallet), har for eksempel den ekstra fordelen av å kunne avlaste ansvaret for transaksjoner fra Victors til brukerne selv. (Seierne ville ideelt sett ikke engang vite hva de ville signere.)

Personvern fra andre deltakere kan i sin tur også løses med atombytter, noe som vil bidra til å tilsløre eierkjeden. Det er sannsynligvis flere løsninger for å forbedre personvernet, som CoinJoin-tilpasninger. (Dette er for eksempel også det personvernbevarende Wasabi Wallet bruker.) Men detaljer har ennå ikke blitt utarbeidet.

Det er også noen bekymringer for tidligere deltakere i kjeden som prøver å jukse ved å prøve å kreve mynter gjennom backup-transaksjonen. Selv om dette neppe vil lykkes, koster det bare et (on-chain) transaksjonsgebyr å prøve, så opportunistisk jukseatferd kan begrense statekjeders potensial.

Til slutt er statskjeder selvfølgelig et relativt nytt konsept; fagfellevurdering pågår.

Takk til Ruben Somsen for informasjon og tilbakemelding. For mer informasjon om statekjeder, se hans forklarer på Medium eller hans presentasjon kl Breaking Bitcoin i Amsterdam.