Drivkjeder lar sidekjede-nodeoperatører betale gruvearbeidere for å gruve – og mer!

Dette er en meningsredaksjon av Shinobi, en selvlært pedagog i Bitcoin-området og teknologiorientert Bitcoin-podcastvert.

Denne gangen skal jeg bryte ned og diskutere hvordan drivkjeder fungerer; de ble opprinnelig foreslått i 2015. Av alle forslagene som er diskutert så langt, er drivkjeder de eldste og de mest konkrete når det gjelder spesifikke implementeringsdetaljer og design, dokumentert i BIP-er 300 og 301. Paul Sztorc, skaperen av konseptet, hadde noen hoveddesignmål i tankene, og selv om dette ikke er utfyllende i det hele tatt, her er noen:

• Isoler hver sidekjede slik at enhver feil eller problem bare vil påvirke de som bruker den.
• Tillat sidekjeder å spinnes opp uten å trenge en ny gaffel for hver enkelt.
• Aktiver overføring av bitcoin inn og ut av en sidekjede med en toveis knagg.
• Tillat gratis eksperimentering i design som han håper ville foreldet behovet for altcoins.

Det er to primære aspekter ved hele designet, og det er derfor det er to separate BIP-er. Den første er pinnemekanismen (BIP300), som er det som gjør at toveispinnen kan fungere. Sztorc designet noe som kalles en hash rate escrow, som i de mest grunnleggende termer lar gruvearbeidere som en amorf gruppe kollektivt forvare myntene i alle sidekjedene. Den andre er en "blind" sammenslått gruveordning, der målet er å la bitcoin-gruvearbeidere være blokkprodusenter på et konsensusnivå uten å være pålagt å validere sidekjeden for å gjøre det. Begge disse delene presenterer til sammen en toveis pinnemekanisme og en måte for bitcoin-gruvearbeidere å ta del i å utvinne sidekjedene mens de forsøker å redusere sentraliseringsrisikoen det utgjør.

BIP300 spesifiserer logikken for forslaget til en ny sidekjede, aktiveringen av en ny sidekjede, forslaget om et samlet sett med uttak, godkjenningen av et slikt sett med uttak, valideringslogikken for faktiske uttakstransaksjoner og valideringen for innskuddstransaksjoner.

Aktivering av en ny sidekjede under drivkjedeforslaget er veldig lik prosessen med en myk gaffel aktivert gjennom gruvearbeidersignalering. Den største forskjellen er selvfølgelig at det faktisk ikke er en myk gaffel - en enkelt gaffel for å aktivere konsensusreglene for drivkjeden lar gruvearbeidere når som helst signalisere at de aktiverer en ny sidekjede innenfor konsensusregler for drivkjeden. For å foreslå aktivering av en ny sidekjede, må en gruvearbeider plassere en OP_RETURN-data i sin myntbase-utgang som inkluderer en unik identifikator for den sidekjeden, en offentlig nøkkel til bruk i innskuddsoperasjoner, versjonsdata, menneskelesbare beskrivelser og hashes til programvareklienten. og GitHub-historien om det (det er ingen konsensushåndhevelse her, bare data som mennesker kan referere til).

Når en gruvearbeider foreslår å aktivere en ny sidekjede og inkludere alle nødvendige data i sin myntbase, blir det en slags "miner-signaleringsperiode" angående hvorvidt denne nye sidekjeden skal opprettes fra synspunktet om hovedkjedekonsensus. En gruvearbeider kan bruke et spesielt format for å inkludere et forslag i myntbaseutgangene sine, og andre gruvearbeidere kan lage en annen utgang etter et andre format for å signalisere for aktivering. Et nytt sidekjedeforslag krever at 90 % av blokkene i en vanskelighetsperiode signaliserer aktivering for at en ny sidekjedeoppretting skal bekreftes. Dette skaper pinnemekanismen for å aktivere sidekjeden, men samspillet mellom sidekjede og hovedkjede er mer nyansert enn som så.

På dette tidspunktet kan hvem som helst feste mynter i sidekjeden. For å koble til sidekjeden, oppretter en bruker ganske enkelt en transaksjon med to innganger med sin egen inngang og UTXO som tilsvarer sidekjedebalansen med en enkelt utgang som tildeler alt til sidekjeden. Dette garanterer at sidekjeden bare har en enkelt UTXO som inneholder alle midlene låst i seg. Uttak håndteres ved gruveavstemning. Hovedkjeden har ingen forståelse av hvem som eier hva på sidekjeden, og hovedkjeden vil vurdere ethvert uttak godkjent av gruvearbeidere innenfor stemmemekanismen som gyldig. På grunn av dette er det en lang forsinkelse i uttaksprosessen. Det er to faser i prosessen med å trekke seg fra en sidekjede: et uttaksforslag (bunt), og deretter tilbaketrekningsstemmefasen. Gruvearbeidere må lage en OP_RETURN-utgang i sin myntbasetransaksjon med en hash av den foreslåtte uttakstransaksjonen for å foreslå et uttak. Denne hashen, i likhet med sighash, flagger imidlertid bare som forplikter seg til en del av en transaksjon i stedet for hele greia. Den forplikter seg ikke til inngangen UTXO som representerer midler låst i en drivkjede eller utgangen som returnerer alt som ikke blir trukket tilbake til en spesiell sidekjede UTXO. Dette er fordi eventuelle innskudd i drivkjeden vil skape en ny UTXO, og dermed ugyldiggjøre forpliktelsen til uttakstransaksjonen når folk gikk for å validere den.

Herfra begynner gruvearbeiderens stemmeperiode på tilbaketrekningsforslaget. Etter at en bunt er foreslått, kan gruvearbeidere stemme om de skal godkjennes eller ikke. Hver blokk som utvinnes lar den gruvearbeideren øke en godkjenningsteller opp eller ned med én eller to for å avstå fra å gjøre noe. Det er noen spesifikke begrensninger i tillegg til dette, fordi det er mulig å ha mer enn én bunt for en enkelt sidekjede - hvis en gruvearbeider velger å stemme "ja" (hev telleren med én) for en uttaksbunt for en sidekjede må stemme "nei" (senk telleren med én) for hver annen bunt knyttet til den spesifikke sidekjeden.

Dette er for å garantere at det ikke er noen "doble uttak", der noen har en utgang i flere bunter som vil betale dem ut mer bitcoin på hovedkjeden enn de skylder.

På den andre siden har gruvearbeidere også lov til å stemme nei for hver eneste foreslåtte bunt. Dette er ment å fungere som en slags alarm for alle om at en gruvearbeider som validerer disse uttakene (forsikrer seg om at de er legitimt eide mynter på sidekjeden som blir trukket ut) har lagt merke til at noe ugyldig skjer. Husk at et nøkkelpoeng med denne designen er at gruvearbeidere ikke trenger å validere noe på sidekjeden, så med mindre de velger det likevel, kan mange gruvearbeidere stemme opp bunter de ikke bekrefter. Denne alarmfunksjonen er designet for at de skal bli varslet om at de bør verifisere pakkene for å sikre at et uredelig uttak ikke skjer.

Når en pakke har nådd den nødvendige terskelen (13,150 90 blokker, eller omtrent 2017 dager), blir transaksjonen som faktisk behandler uttaket gyldig og kan bekreftes. Men hva gjør folk hvis gruvearbeidere godkjenner et uredelig uttak som stjeler penger fra sidekjeden? Sztorcs forslag er å engasjere seg i en brukeraktivert myk gaffel (UASF) for å ugyldiggjøre den ugyldige tilkoblingstransaksjonen. Dette utgjør en enorm risiko når det gjelder konsensus for hovedkjeden. UASF i XNUMX var et høyrisikotrekk som bare så vidt lyktes og Bitcoin var mye mindre enn det er i dag. Jo større Bitcoin vokser, desto vanskeligere vil slike handlinger være å koordinere.

Hvis du husker fra artikkel om romkjeder, at designet var basert på blind merged mining (BMM). Ruben Somsens BMM-design er faktisk den andre varianten av det, den første er Sztorcs design som lagt ut i BIP301. BMM-spesifikasjonen i drivkjeder er sammensatt av to meldinger: en forespørselsmelding og en akseptmelding. Begge koordineres henholdsvis gjennom en spesiell transaksjonstype på hovedkjeden og spesiell utgang i en gruvearbeiders myntbasetransaksjon.

Forespørselstransaksjonen er konstruert av den som lager sidekjedeblokker. Hele poenget med BMM er at denne personen kan være noen som ikke driver med gruvedrift, så forespørselstransaksjonen er der for å la dem betale gruvearbeidere for å bekrefte deres foreslåtte sidekjedeblokk. Sidekjedeblokkforslaget konstruerer en transaksjon som inkluderer hashen til sidekjedeblokken, IDen som ble tildelt sidekjeden da den ble opprettet og de siste fire bytene til forrige hovedkjedeblokkoverskrift. Det er tre ekstra konsensusregler som gjelder for denne typen transaksjoner. For det første er en forespørselstransaksjon ugyldig med mindre det også er en samsvarende akseptutgang i myntbasetransaksjonen til den blokken. Dette er for å garantere at gruvearbeidere ikke kan kreve et gebyr fra forespørselen uten også å akseptere og utvinne sidekjedeblokken. For det andre, for hver sidekjede er det bare tillatt å inkludere én forespørselstransaksjon i en hovedkjedeblokk. Dette er for å sikre at bare én blokk fra en sidekjede faktisk kan utvinnes per hovedkjedeblokk. Til slutt må de siste fire bytene til den forrige hovedkjedeblokken samsvare. Dette sikrer at en forespørsel kun er gyldig for å bli utvunnet i neste blokk, og slike transaksjoner kan ikke utvinnes senere og stjele penger fra en sidekjedeblokkforslagsstiller etter at en annens blokk har blitt utvunnet.

Godta-utgangen er veldig enkel: meldingshodedata og hashen til sidekjedeblokken. Hvis en gruvearbeider kjører en drivkjede-node selv, kan de ganske enkelt ignorere forespørselstransaksjoner og alltid inkludere sin egen akseptutgang i myntbasen for å utvinne sine egne sidekjedeblokker. Sammen lar disse to aspektene gruvearbeidere enten operere en sidekjede-node selv, eller en annen ikke-gruvearbeider til å gjøre det og betale gruvearbeideren for å utvinne blokkene deres. Tanken er at hvis gruvearbeidere ikke selv driver sidekjedene og spiser de ekstra valideringskostnadene, så kan noen andre gjøre det for dem. Hvis det er konkurranse mellom ikke-gruvearbeidere som prøver å tjene avgifter på sidekjeden, vil de sannsynligvis fortsette å by opp gebyret de er villige til å betale gruvearbeidere i forespørselstransaksjonen til det representerer størstedelen av gebyrene de tjener, med ikke- gruvearbeider beholder bare en liten prosentandel av overskuddet og betaler resten til gruvearbeidere.

Det er mekanikken bak hvordan drivkjeder fungerer. Neste opp, fødererte sidekjeder, og deretter, etter det, en oversikt over alle negative og ulemper hvert design kan ha.

Dette er et gjesteinnlegg av Shinobi. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc eller Bitcoin Magazine.