Offentliggjøring: forfatteren av denne artikkelen er grunnleggeren og sjefforskeren av Ethereum-prosjekt

I forrige uke kom Adam Back og Austin Hill ut med en kunngjøring på Let’s Talk Bitcoin, der de kunngjorde sitt nyeste prosjekt: “sidekjeder”. Ideen, som de beskrev, ville tillate eksistensen av alternative blokkjeder, kanskje med forskjellige regler som tillater forskjellige typer tilleggsfunksjoner eller transaksjonstyper, men med en valutaenhet hvis verdi er knyttet til bitcoin. Hensikten er å tillate eksperimentering med forskjellige utvidelser av Bitcoin-protokollen, ved å bruke separate nettverk for å unngå enhver risiko for Bitcoin selv, mens du fortsatt bruker den samme underliggende valutaenheten. Så snart ideen ble kunngjort, har det vært en stor mengde offentlig interesse for konseptet, og har gitt fornyet håp om at Bitcoin-protokollen potensielt kan bli mye kraftigere enn den er i dag.

Under panseret

Ideen bak sidekjedene er ikke ny; konseptet har eksistert siden minst i fjor i desember, og en forløper for ideen har eksistert i flere år før da. Forløperen, en protokoll kjent som enveis pegging, var en mekanisme som teoretisk ville brukes til å håndtere en overgang fra “Bitcoin 1.0” til “Bitcoin 2.0”, og fungerte som følger. Anta at det i Bitcoin 1.0 allerede er utstedt 13 millioner valutaenheter gjennom gruvedrift, med 8 millioner igjen å gi ut. Distribusjonsmodellen for BTC2.0 ville frigjøre 8 millioner enheter gjennom gruvedrift, i henhold til nøyaktig samme tidsplan som BTC1.0 etter dette punktet, men de andre 13 millionene ville bli distribuert gjennom en mekanisme kjent som “proof-of-burn”.

I hovedsak vil man ta en enhet av BTC1.0, sende den til en ubrukelig adresse (f.eks. 1111111111111111111114oLvT2), og sende inn et kryptografisk bevis på at denne transaksjonen fant sted, signert av den samme private nøkkelen som sendte transaksjonen, som en transaksjon til Bitcoin 2.0. I følge Bitcoin 2.0-protokollen vil dette gi brukeren rett til å motta en enhet på 2,0. Dette kalles en “enveisplugg” fordi verdien på en BTC2.0 maksimalt kan være lik en BTC1.0; Ellers vil folk arbitrage forskjellen ved å konvertere bitcoins til 1: 1-kurs. Bortsett fra å selge BTC2.0 for BTC1.0 på markedet, er det imidlertid ingen måte å gå tilbake, så hvis eksperimentet mislykkes, kan verdien av BTC2.0 falle til null.

Bitcoin sidekjeder bruker en forbedret versjon av dette systemet kalt “to-veis pegging”, som fungerer som følger. For å motta en enhet av BTC2.0, må man ta en enhet av BTC1.0 og sende den til et “skript” som vi vil kalle X og la være ubeskrevet for nå. Et skript i Bitcoin er en adresse som, i stedet for å eies av en privat nøkkel, i hovedsak fungerer som en låsekasse som bare låser opp bitcoins når den får en transaksjon som oppfyller visse betingelser. For eksempel kan man ha et skript som låser opp midlene til den første personen som sender inn et femti-sifret primtall som utelukkende består av sifrene 3 og 5. Å gjøre transaksjonen, og publisere et kryptografisk bevis på at en slik transaksjon ble gjort, til Bitcoin 2.0 blockchain gir brukeren rett til en enhet av BTC2.0.

Nå er definisjonen av X enkel: X låser opp midlene (husk, dette er en enhet av BTC1.0) hvis det gis et gyldig kryptografisk bevis på at avsenderen ødela en enhet av BTC2.0. Dermed eksisterer det en mekanisme for å konvertere BTC 1.0 til BTC2.0, og akkurat den mekanismen skaper en annen mekanisme, begrenset i verdi til det totale antallet BTC2.0 opprettet, som kan brukes til å konvertere BTC2.0 tilbake til BTC1.0 . Derfor toveis pinne.

Mekanismen som disse “kryptografiske bevisene” bruker, er avhengig av en kryptografisk konstruksjon som brukes i Bitcoin, kalt et Merkle-tre. I en Bitcoin-blokk, i stedet for å bare ha hver transaksjon blokken direkte, er bare en enkelt 32-byte hash faktisk inkludert i blokkoverskriften. Denne 32-byte hasjen er i seg selv beregnet fra to andre 32-byte hashes, som hver kommer fra to andre 32-byte hashes, og så videre til endelig er verdiene nederst selve transaksjonene. Det er nettopp poenget med denne mekanismen å tillate eksistensen av kompakte bevis for at en bestemt transaksjon er i en bestemt blokk; alt man trenger er den ene grenen av hashes som går opp fra den transaksjonen til rotnoden, eller totalt 10 hashes for 1000 transaksjoner eller 20 hashes for en million transaksjoner. Dette er umulig å smi; hvis du prøver å endre til og med en enkelt transaksjon i treet, forplantes endringene oppover gjennom hasjene til endelig rotnoden ender helt annerledes.

Dette løser imidlertid ikke problemet helt; alt det forteller deg er at noen blokker, et eller annet sted, inneholder en gitt transaksjon. Det forteller deg ikke at transaksjonen er i hovedkjeden; i virkeligheten kunne de samme bitcoins som ble brukt i transaksjonen allerede ha blitt sendt til en annen kilde, noe som gjør transaksjonen ugyldig. Det er to måter å løse dette på. En tilnærming, og langt den enklere, er at bevismekanismen i Bitcoin 2.0 ikke bare ber om Merkle-tregrenen, men også for blockchain som går tilbake seks blokker, omtrent som en kjøpmann som ber om seks bekreftelser ved å bruke gruvedrift. som fullmektig for gyldighet. For høyere sikkerhet kan det kreves et mye større antall blokker som seksti. Denne tilnærmingen er enkel, og ser ut til å oppfylle alle nødvendige parametere.

Utfordringer

Ovennevnte mekanisme er imidlertid, som beskrevet, svært ufullkommen. Når en vanlig kjøpmann ber om seks bekreftelser, krever det å produsere seks blokker raskere enn resten av nettverket kombinert i sanntid for å trekke et dobbeltbruk-angrep mot den selgeren, en oppgave som krever minst 30 av den totale nettverkshash-kraften for å jobbe med alle ikke-ubetydelig suksessrate. Med den ovenfor beskrevne toveis-pegging-mekanismen, kan en ondsinnet gruvearbeider med til og med 1 hashpower til slutt generere seks blokker, eller til og med seksti blokker, og deretter bruke disse blokkene til å svindle med å kreve alle BTC1.0 som er blitt satt i BTC2.0-låseboksene (eller, i den andre retningen, hevder ubegrenset et ubegrenset antall BTC2.0). En mulig oppdatering som kan komme i tankene, er å kreve at den samme personen som opprettet låsekassen skal åpne den, og derved begrense mengden skade som kan gjøres per person, men dette løser ikke problemet fordi den ondsinnede gruvearbeideren lett kan kollidere med noen ellers. Det grunnleggende problemet, at det ikke er noen måte å komme opp med en mekanisme for å validere blockchain som ikke oppdaterer seg over tid, er enten veldig vanskelig å løse eller kan sannsynligvis ikke løses mens du holder deg rent innenfor Bitcoins “static lockbox” skriptparadigme.

En annen tilnærming, som kan løse dette problemet uten store problemer, er mer intrikat og påtrengende. Det krever i hovedsak å inkludere det som kalles en “lett klient” for Bitcoin 1.0 i Bitcoin 2.0. Den lette klienten beskrives lettest som en langvarig “kontrakt”, et program på blockchain med en stor mengde intern tilstand som kjører hver gang en transaksjon blir sendt til den, som vil akseptere blokker og bekrefte blokkoverskrifter i nøyaktig på samme måte som en Bitcoin-klient på mobiltelefonen din ville gjort. Denne kontrakten vil da føre en løpende liste over alle blokkoverskrifter i Bitcoin 1.0, og for å motta en BTC2.0 må du sende inn et kryptografisk bevis på at du har gjort den nødvendige transaksjonen i BTC1.0 i kontrakten, sammen med en sikkerhet innskudd på 0,1 BTC2.0.

Kontrakten vil kontrollere at beviset er gyldig, havner i en blokk som er i kontraktens egen interne mini-blockchain, og deretter vente en av to ting som skjedde. Først, når seksti flere Bitcoin 1.0-blokker blir lagt til i kontrakten, vil det frigjøre en enhet BTC2.0 til avsenderen pluss sikkerhetsdepositumet. Alternativt, hvis noen andre sender inn et kryptografisk bevis på at transaksjonen er ugyldig av en eller annen grunn (f.eks. Den bruker bitcoins som ikke eksisterer) innen den tiden, vil de motta depositumet..

Dette vil løse sikkerhetsproblemet, men har en viktig feil: det kan ikke gjøres innenfor Bitcoin-protokollen slik den er. Det er ganske enkelt å implementere i en protokoll som Ethereum, fordi den er spesielt designet for kontrakter, men Bitcoins skriptfunksjonalitet tillater ikke eksistensen av kontrakter som har intern tilstand, så det å gjøre dette inne i Bitcoin vil kreve en veldig betydelig endring av Bitcoin 1.0-protokollen. Til syvende og sist, tilnærmingen som ble tatt av Austin Hill og Adam Back, ser kanskje ikke ut som noen av disse strategiene; imidlertid, den store kompleksiteten i problemet viser at det fremdeles er mange utfordringer som ligger foran oss.

Gruvedrift

Et annet viktig spørsmål er: hvordan vil disse sidekjedene sikres? Standardmekanismen for å sikre en blockchain er gruvedrift, men gruvedrift krever en mekanisme for å belønne gruvearbeidere i den kjeden. I en sidekjede må hver enhet i sidekjedevalutaen støttes av en script-lockbox som inneholder en enhet BTC på Bitcoin blockchain, så det er ingen enkel mulighet til å utstede valutaenheter fra siden ingensteds. Det er to muligheter for dette: demurrage (dvs. en prosentvis skatt per år på alle BTC i sidekjeden) og transaksjonsgebyrer. Begge disse gir imidlertid ganske lave inntekter, og det er derfor ikke sikkert at vanlig gammel uavhengig gruvedrift vil løse problemet.

Det er to tilnærminger for å komme rundt dette problemet. En tilnærming er å sørge for at sidekjeden sikres ved bevis på innsatsen, ved å bruke de små inntektene fra transaksjonsgebyrer for å kompensere deltakende interessenter med en rente. Imidlertid ville denne tilnærmingen være veldig vanskelig å implementere i en sidekjede, fordi beregningene som er involvert i validering av bevis på innsats, sannsynligvis er for kompliserte til å effektivt implementere direkte på en blockchain. Den andre tilnærmingen, og den som promoteres av Adam Back og Austin Hill, kalles “merge-mining”; i hovedsak inkluderer gruvearbeidere i Bitcoin blokker data fra både Bitcoin-blokken og Namecoin-blokken, slik at gruvearbeidere kan gi sikkerhet for begge kjedene samtidig ved å bruke samme beregningsinnsats.

Imidlertid, som argumentert av Bitcoin-utvikler Peter Todd, har konseptet med fusjonsgruving en veldig viktig sikkerhetsfeil: med mindre flertallet av Bitcoin-gruvearbeidere er enige om å slå sammen en bestemt kjede, er kjeden uten tvil ikke i det hele tatt. For å forstå hvorfor, bør du først vurdere tilfellet med en mer tradisjonell altcoin, i vårt eksempel som kjører SHA256 for enkelhets skyld (hvis altcoin bruker en tilpasset algoritme, kan Litecoin-gruvearbeidere trekke ut angrepet i stedet). Hvis altcoin har 5 av hashpower of Bitcoin, må minst 5 av Bitcoin-nettverkets kraft midlertidig omdirigere seg til gruvedrift på altcoin for å kunne angripe kjeden via et dobbeltbruk. Dette er potensielt mulig, men er et kostbart trekk: mens angrepet er på plass, vil Bitcoin-gruvearbeidere miste inntektene fra gruvedrift på Bitcoin. I tilfelle en sammenslått sidekjede er gruvedrift på hovedlinjen til en sidekjede eller angrep på den begge kostnadsfrie, så det ville ikke være noe økonomisk avskrekk for å angripe den alternative kjeden. Dette er ikke bare en formodning; det har vært faktiske eksempler på at gruvebassenger i virkeligheten angriper sammenslåtte kjeder.

Bortsett fra sikkerhet, avslører denne avhengigheten av sammenslåing av gruvedrift også en annen bekymringsfull begrensning av sidekjedene: Mens kryptovalutaens ånd uten tvil er den av tillatelsesfri innovasjon, krever det å skape en sidekjede tillatelse og aktiv assistanse av 50 av alle Bitcoin gruveoperatører. Disse begrensningene tilsier at sidekjedeprotokollen, selv om den er bra i mange brukssaker, absolutt ikke vil være ideell for alle.

Løftet

Hvis de tekniske problemene rundt sidekjeder kan løses, hva er løftet de gir? Akkurat nå kan utvikling av kryptovaluta i hovedsak klassifiseres i fire kvadranter. Den første kvadranten består av prosjekter som bruker Bitcoin-valutaen og Bitcoin-blockchain – i hovedsak Bitcoin selv. Den andre kvadranten er protokoller som bruker Bitcoin-blokkjeden, men ikke Bitcoin-valutaen; Mastercoin, fargede mynter og motpart er gode eksempler på dette. Den tredje kvadranten bruker både en uavhengig valuta og en uavhengig blockchain; dette inneholder applikasjoner som (for å ta vidt forskjellige eksempler) Ripple, Litecoin og NXT. Nå, med sidekjeder, er også den siste kvadranten fylt: ved hjelp av et uavhengig nettverk, men bruker Bitcoin som den underliggende valutaen.

Det vil være interessant å se hvilke applikasjoner som nisje fungerer best for. For helt nye økosystemer er det sannsynligvis ikke den riktige tilnærmingen; det gir liten mening for et helt uavhengig nettverk som Ripple eller Ethereum å knytte sitt viktigste interne token til Bitcoin økonomisk og få de to til å bli utsatt for hverandres prisbevegelser. Når det gjelder så store anstrengelser, er det også fornuftig å eksperimentere med forskjellige pengepolitikker; Ethereums eter har en lineær utstedelsesmodell som kontinuerlig frigjør et bestemt fast antall valutaenheter hvert år, mens Ripple ga ut alle 100 milliarder enheter XRP til Ripple-organisasjonen samtidig, og organisasjonen frigjør dem over tid til utviklere, investorer og mennesker som deltar i distribuerte dataprosjekter. For en gaffel som er ment å tjene som en stor protokollendring, som å oppgradere fra SHA256 til SHA3, eller når det gjelder kvantecomputere fra ECDSA til Lamport-signaturer eller NTRU, er det definitivt fornuftig. For alt i midten vil det være fra sak til sak å finne ut.

Når det gjelder Ethereum, er det en spesiell vurdering å huske på: Ethereum er en generell kryptografisk konsensusplattform, ikke en spesifikk “altcoin”. Derfor kan man ha mange forskjellige valutaer som eksisterer på Ethereum-plattformen som kontrakter; man kan ha kjedelige gamle fastforsyningsvalutaer, valutaer med en pengepolitikk som styres av en desentralisert autonom organisasjon, valutaer som eksisterer for å subsidiere vitenskapelig forskning eller gi en grunninntekt, og til og med valutaer med en innebygd toveis-vekslingsmekanisme for fungere som sidekjeder. Dermed kan Ethereum ikke nøyaktig bli pigeonholed i hverken sidekjedekvadranten eller Ripple / Litecoin / NXT-kvadranten; den eksisterer i begge.

Faktisk er det veldig sannsynlig at så snart Ethereum-generasjonsblokken lanseres, vil det være sidekjeder for Bitcoin, Litecoin og Dogecoin implementert som kontrakter innen tre måneder. Hvis sidekjeder kan implementeres vellykket og sikkert, betyr dette at Ethereum til og med kan bli det foretrukne middel for lagring av BTC, LTC eller DOGE ved bruk av kraftige multisignaturlagringskontrakter som inkluderer funksjoner som uttaksgrenser. Mellom kontrakter på en generell kjede, høyytelses spesialaltcoins, kvasi-sentraliserte OpenTransactions-servere, sidekjeder og Bitcoin i seg selv, blir en ting tydelig: kryptovalutaer vil kunne samarbeide som aldri før.