Drivkæder gør det muligt for sidekædeknudeoperatører at betale minearbejdere for at mine - og mere!

Dette er en meningsredaktion af Shinobi, en selvlært underviser i Bitcoin-området og teknologiorienteret Bitcoin-podcastvært.

Denne gang vil jeg bryde ned og diskutere, hvordan drivkæder fungerer; de blev oprindeligt foreslået i 2015. Ud af alle de forslag, der er diskuteret indtil videre, er drivkæder de ældste og de mest udfyldte med hensyn til specifikke implementeringsdetaljer og design, dokumenteret i BIP'er 300 , 301. Paul Sztorc, skaberen af ​​konceptet, havde et par hoveddesignmål i tankerne, og selvom dette slet ikke er omfattende, er her et par stykker:

• Isoler hver sidekæde, så enhver fejl eller problem kun vil påvirke dem, der bruger den.
• Tillad sidekæder at blive spundet op uden at skulle bruge en ny gaffel til hver enkelt.
• Aktiver overførsel af bitcoin ind og ud af en sidekæde med en to-vejs peg.
• Tillad gratis eksperimentering i design, han håber ville forælde behovet for altcoins.

Der er to primære aspekter af hele designet, hvorfor der er to separate BIP'er. Den første er pindmekanismen (BIP300), som gør det muligt for to-vejs pinden at fungere. Sztorc designede noget, der kaldes en hash rate escrow, som i de mest basale termer tillader minearbejdere som en amorf gruppe kollektivt at opbevare mønterne i alle sidekæderne. Den anden er en "blind" fusioneret minedrift, hvor målet er at tillade bitcoin-minearbejdere at være blokproducenter på et konsensusniveau uden at være forpligtet til at validere sidekæden for at gøre det. Begge disse dele præsenterer tilsammen en tovejs-pin-mekanisme og en måde for bitcoin-minearbejdere at deltage i at udvinde sidekæderne, mens de forsøger at afbøde den centraliseringsrisiko, som det udgør.

BIP300 specificerer logikken for forslaget om en ny sidekæde, aktiveringen af ​​en ny sidekæde, forslaget om et bundtet sæt af udbetalinger, godkendelsen af ​​et sådant sæt af udbetalinger, valideringslogikken for faktiske udbetalingstransaktioner og valideringen for indbetalingstransaktioner.

Aktivering af en ny sidekæde under drivkædeforslaget ligner meget processen med en blød gaffel aktiveret gennem minearbejdersignalering. Den største forskel er selvfølgelig, at det faktisk ikke er en blød gaffel - en enkelt gaffel til at aktivere drivkædens konsensusregler gør det muligt for minearbejdere til enhver tid at signalere at de skal aktivere en ny sidekæde inden for drivechain konsensus regler. For at foreslå aktivering af en ny sidekæde skal en minearbejder placere en OP_RETURN-data i deres møntbase-output, der inkluderer en unik identifikator for den sidekæde, en offentlig nøgle til brug i indbetalingsoperationer, versionsdata, menneskelæselige beskrivelser og hashes af softwareklienten og GitHub-historien om det (der er ingen konsensushåndhævelse her, kun data, som mennesker kan referere til).

Når en minearbejder foreslår at aktivere en ny sidekæde og inkludere alle de nødvendige data i deres møntbase, bliver det en slags "miner-signaleringsperiode" med hensyn til, om denne nye sidekæde skal oprettes eller ej ud fra hovedkædens konsensussynspunkt. En minearbejder kan bruge et specielt format til at inkludere et forslag i deres møntbase-output, og andre minearbejdere kan oprette et andet output efter et andet format for at signalere til aktivering. Et nyt sidekædeforslag kræver, at 90 % af blokkene i en sværhedsperiode signalerer til aktivering, for at en ny sidekædeoprettelse kan bekræftes. Dette skaber pegmekanismen for at aktivere sidekæden, men interaktionen mellem sidekæde og hovedkæde er mere nuanceret end som så.

På dette tidspunkt kan enhver stifte mønter i sidekæden. For at tilknytte sidekæden opretter en bruger blot en transaktion med to input med deres eget input og UTXO svarende til sidekædebalancen med en enkelt output, der tildeler alt til sidekæden. Dette garanterer, at sidekæden kun har en enkelt UTXO, der indeholder alle midlerne låst i sig. Udbetalinger håndteres ved minearbejderafstemning. Hovedkæden har ingen forståelse for, hvem der ejer hvad på sidekæden, og hovedkæden vil anse enhver tilbagetrækning godkendt af minearbejdere inden for afstemningsmekanismen for gyldig. På grund af dette er der en lang forsinkelse i tilbagetrækningsprocessen. Der er to faser i processen med at trække sig fra en sidekæde: et tilbagetrækningsforslag (bundt) og derefter tilbagetrækningsafstemningsfasen. Minearbejdere skal oprette et OP_RETURN-output i deres møntbase-transaktion med en hash af den foreslåede tilbagetrækningstransaktion for at foreslå en tilbagetrækning. Denne hash, der ligner sighash, markerer dog kun at forpligte sig til en del af en transaktion i stedet for det hele. Den forpligter sig ikke til input UTXO, der repræsenterer midler låst i en drivechain eller output, der returnerer alt, der ikke trækkes tilbage til en speciel sidechain UTXO. Dette skyldes, at enhver indbetaling i drivkæden ville skabe en ny UTXO og dermed ugyldiggøre forpligtelsen til udbetalingstransaktionen, når folk gik for at validere den.

Herfra begynder minearbejdernes afstemningsperiode om tilbagetrækningsforslaget. Efter at et bundt er blevet foreslået, er minearbejdere i stand til at stemme om, hvorvidt de skal godkendes eller ej. Hver blok, der udvindes, tillader, at minearbejderen øger en godkendelsestæller, op eller ned med en eller to for at undlade at gøre noget. Der er nogle specifikke begrænsninger ud over dette, fordi det er muligt at have mere end et bundt til en enkelt sidekæde - hvis en minearbejder vælger at stemme "ja" (hæver tælleren med én) for et udbetalingsbundt til en sidekæde, skal stemme "nej" (sænk tælleren med én) for hvert andet bundt, der er forbundet med den specifikke sidekæde.

Dette er for at garantere, at der ikke er nogen "dobbelte udbetalinger", hvor nogen har et output i flere bundter, der ville betale dem mere bitcoin på hovedkæden, end de skylder.

På den anden side har minearbejdere også lov til at stemme nej for hvert eneste foreslåede bundt. Dette formodes at fungere som en slags alarm for alle om, at en minearbejder, der validerer disse hævninger (som sikrer, at de er lovligt ejede mønter på sidekæden, der trækkes tilbage) har bemærket, at der sker noget ugyldigt. Husk, at et nøglepunkt i dette design er, at minearbejdere ikke behøver at validere noget på sidekæden, så medmindre de alligevel vælger det, kan mange minearbejdere give op til bundter, de ikke verificerer. Denne alarmfunktion er designet til, at de bliver advaret om, at de skal verificere bundterne for at sikre, at der ikke sker en svigagtig tilbagetrækning.

Når en pakke har nået den påkrævede tærskel (13,150 blokke, eller omkring 90 dage), bliver transaktionen, der faktisk behandler tilbagetrækningen, gyldig og kan bekræftes. Men hvad gør folk, hvis minearbejdere godkender en svigagtig hævning, der stjæler penge fra sidekæden? Sztorcs forslag er at engagere sig i en brugeraktiveret soft fork (UASF) for at ugyldiggøre den ugyldige peg-out-transaktion. Dette udgør en enorm risiko med hensyn til konsensus til hovedkæden. UASF i 2017 var et højrisiko-træk, der kun med nød og næppe lykkedes, og Bitcoin var meget mindre, end det er i dag. Jo større Bitcoin vokser, jo sværere vil sådanne handlinger være at koordinere.

Hvis du husker fra artikel om rumkæder, at design var baseret på blind merged minedrift (BMM). Ruben Somsens BMM-design er faktisk den anden variant af det, den første er Sztorcs design som udlagt i BIP301. BMM-specifikationen i drevkæder er sammensat af to meddelelser: en anmodningsmeddelelse og en acceptmeddelelse. Begge koordineres henholdsvis gennem en særlig transaktionstype på hovedkæden og speciel output i en minearbejders møntbase-transaktion.

Anmodningstransaktionen er konstrueret af den, der opretter sidekædeblokke. Hele pointen med BMM er, at denne person kan være en person, der ikke er minedrift, så anmodningstransaktionen er der for at give dem mulighed for at betale minearbejdere for at bekræfte deres foreslåede sidekædeblok. Sidekædeblokforslaget konstruerer en transaktion, der inkluderer hashen af ​​sidekædeblokken, det ID, der blev tildelt sidekæden, da den blev oprettet, og de sidste fire bytes af den forrige hovedkædeblokoverskrift. Der er tre yderligere konsensusregler, der anvendes på disse typer transaktioner. For det første er en anmodningstransaktion ugyldig, medmindre der også er et matchende acceptoutput i møntbasetransaktionen for den pågældende blok. Dette er for at garantere, at minearbejdere ikke kan opkræve et gebyr fra anmodningen uden også at acceptere og udvinde sidekædeblokken. For det andet er det kun tilladt at inkludere én anmodningstransaktion i en hovedkædeblok for hver sidekæde. Dette er for at sikre, at kun én blok fra enhver sidekæde rent faktisk kan udvindes pr. hovedkædeblok. Til sidst skal de sidste fire bytes af den forrige hovedkædeblok matche. Dette sikrer, at en anmodning kun er gyldig til at blive udvundet i den næste blok, og sådanne transaktioner kan ikke udvindes senere og stjæle penge fra en sidekædeblokforslagsstiller, efter at en andens blok er blevet udvundet.

Acceptudgangen er meget enkel: meddelelsesheaderdata og hash for sidekædeblokken. Hvis en minearbejder selv kører en drivechain-knude, kan de simpelthen ignorere anmodningstransaktioner og altid inkludere deres eget accept-output i deres møntbase for at mine egne sidekædeblokke. Sammen giver disse to aspekter minearbejdere mulighed for enten selv at betjene en sidekædeknude eller en anden ikke-miner til at gøre det og betale minearbejderen for at mine deres blokke. Tanken er, at hvis minearbejdere ikke selv driver sidekæderne og spiser de ekstra valideringsomkostninger, så kan en anden gøre det for dem. Hvis der er konkurrence i ikke-minearbejdere, der forsøger at tjene gebyrer på sidekæden, vil de sandsynligvis blive ved med at byde op for det gebyr, de er villige til at betale minearbejdere i deres anmodningstransaktion, indtil det repræsenterer størstedelen af ​​de gebyrer, de tjener, med de ikke- minearbejder beholder kun en lille procentdel af fortjenesten og betaler resten til minearbejdere.

Det er mekanikken bag, hvordan drivkæder fungerer. Næste op, fødererede sidekæder, og derefter, efter det, en opdeling af alle de negative og ulemper, hvert design kan have.

Dette er et gæsteindlæg af Shinobi. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc eller Bitcoin Magazine.