SegWit og Vidne-data: Hvordan Bitcoin opgraderede transaktionseffektivitet og blokvægt

Bitcoins historie er præget af kritiske opdateringer, der har defineret dens udvikling som en global digital valuta. Blandt disse tekniske milepæle har få været så transformative eller så heftig debatterede som implementeringen af Segregated Witness. Ofte omtalt med dens forkortelse, SegWit, blev denne protokolopgradering aktiveret i august 2017 efter en periode med intens community-diskussion og konsensusopbygning. Den repræsenterede et afgørende øjeblik for netværket og adresserede langvarige problemer relateret til skalerbarhed og sikkerhed.

Før SegWit stod Bitcoin-netværket over for stigende pres fra sin voksende brugerbase. Efterhånden som adoptionen øgede sig, blev begrænsningerne i den originale blokstørrelse en flaskehals, hvilket førte til netværkskongestion og stigende transaktionsomkostninger. Udviklere og interessenter søgte en løsning, der kunne lindre dette pres uden at gå på kompromis med blockchainens decentraliserede natur. Segregated Witness opstod som en smart ingeniørløsning, der optimerede, hvordan data blev lagret, i stedet for blot at øge blokstørrelsesgrænsen.

Opgraderingen gjorde mere end blot at forbedre kapaciteten. Den ændrede fundamentalt mekanismen bag transaktionsbehandling ved at adressere en teknisk sårbarhed kendt som transaktionsmalleabilitet. Ved at løse dette problem lagde SegWit det nødvendige grundlag for andenlagsløsninger som Lightning Network til at blomstre. Dette banede vejen for øjeblikkelige, lavomkostningstransaktioner, der tidligere var svære at implementere sikkert.

At forstå SegWit kræver at kigge ud over blot de tekniske specifikationer. Det involverer undersøgelse af Bitcoins styringsmodel, blokpladseøkonomien og community-dynamikkerne, der driver protokolevolutionen. Denne opgradering demonstrerede, at Bitcoin kunne tilpasse og skalere gennem soft forks, mens den bevarede bagudkompatibilitet og introducerede radikale forbedringer i effektivitet og brugbarhed.

Skalerbarhedsudfordringen

Bitcoin blev oprindeligt designet med en grænse for størrelsen af blokke, der kunne tilføjes blockchainen. Denne grænse, sat til 1 megabyte (MB), tjente som et beskyttende tiltag mod spam-angreb i netværkets tidlige dage. Dog begyndte denne sikkerhedsfunktion, da Bitcoin voksede fra et obskurt eksperiment til et globalt anerkendt aktiv, at fungere som en begrænsning for vækst.

Blokstørrelsesflaskehalsen

Hver Bitcoin-transaktion består af data, der skal behandles og lagres af minere. Disse data inkluderer inputs, outputs og digitale signaturer, der beviser ejerskab af de midler, der bruges. I pre-SegWit-æraen skulle al denne information konkurrere om plads inden for den stive 1MB-blokgrænse.

Da netværkets popularitet skød i vejret, overskred efterspørgslen efter blokplads ofte det tilgængelige udbud. Brugere befandt sig i en budkrig og tilknyttede højere gebyrer til deres transaktioner for at motivere minere til at inkludere dem i næste blok. Denne dynamik resulterede i langsommere bekræftelsestider for brugere, der betalte standardgebyrer.

Under topperioder blev netværket overbelastet, hvilket gjorde det upraktisk for små betalinger eller mikrobetalinger. Communityet erkendte, at for at Bitcoin effektivt kunne fungere både som et værdiopbevaringsmiddel og et udvekslingsmiddel, skulle netværkets gennemstrømning øges. Debatten drejede sig om, hvordan denne skalering kunne opnås uden at ofre sikkerhed eller decentralisering.

Hard Fork-dilemmat

En foreslået løsning på skalerbarhedsproblemet var en hard fork. En hard fork er en radikal ændring af protokollen, der gør tidligere ugyldige blokke/transaktioner gyldige, eller omvendt. I skaleringssammenhæng ville dette have betydet blot at omskrive koden for at tillade større blokke, såsom 2MB eller 8MB.

Hard forks medfører dog betydelige risici. De kræver, at alle noder på netværket opgraderer deres software samtidigt. Hvis en del af communityet nægter at opgradere eller er uenig i ændringen, kan blockchainen splittes i to separate kæder. Dette skete med oprettelsen af Bitcoin Cash, som valgte at øge blokstørrelsen via en hard fork.

Bitcoin Core-udviklere prioriterede en sikrere tilgang kendt som en soft fork. En soft fork er en bagudkompatibel opgradering, hvilket betyder, at noder kørende ældre versioner af softwaren stadig kan deltage i netværket. SegWit blev designet som en soft fork for at sikre, at netværket forblev forenet, mens det stadig leverede de nødvendige kapacitetsforbedringer.

Konsensus og styring

Vejen til at aktivere SegWit fremhævede den unikke natur af Bitcoin-styring. I modsætning til centraliserede systemer, hvor en leder dikterer ændringer, er Bitcoin afhængig af konsensus blandt en mangfoldig gruppe af deltagere. Dette inkluderer minere, udviklere, node-operatører og slutbrugere.

Forslaget om SegWit, kendt som Bitcoin Improvement Proposal (BIP) 141, krævede en meget høj tærskel for støtte fra minere for at aktivere. Specifikt skulle 95 % af mining-hashkraften signalere beredskab i løbet af en to-ugers periode. Denne høje bar sikrer, at opgraderinger har overvældende støtte, før de håndhæves, hvilket minimerer risikoen for netværksustabilitet.

Sådan fungerer SegWit under motorhjelmen

Den primære innovation i Segregated Witness er hintet i dens navn. "Segregated" betyder at adskille, og "Witness" henviser til de digitale signaturer, der verificerer en transaktion. I legacy Bitcoin-transaktioner var signaturdata flettet sammen med transaktionsdata og optog en betydelig del af den værdifulde 1MB-blokplads.

Adskillelse af Vidne-data

SegWit restrukturerede transaktionsformatet ved at flytte vidne-data (signaturer) ud af den hovedblokstruktur. Selvom disse data stadig optages og valideres, lagres de i en separat struktur, der kører parallelt med base-transaktionsblokken. Denne adskillelse var nøglen til at låse mere kapacitet op uden teknisk at øge 1MB-grænsen for gamle noder.

For at visualisere dette, forestil dig et tog, der repræsenterer en Bitcoin-blok. I legacy-systemet var passagerer (transaktionsdetaljer) og deres bagage (signaturer) alle klemt ind i de samme tovognene. Togene havde en streng grænse for, hvor meget volumen det kunne bære.

SegWit tilføjede effektivt en specialiseret fragtvogn til bagsiden af toget specifikt til bagagen. Ved at flytte den tunge bagage ud af passagervognene kunne toget pludselig bære betydeligt flere passagerer inden for de samme hovedafdelinger. "Bagagen" rejser stadig med toget, men optager ikke længere den premium-plads, der er nødvendig for passagererne selv.

Blokvægt vs. Blokstørrelse

For at implementere denne ændring introducerede SegWit et nyt koncept kaldet "blokvægt". Den gamle måling af blokstørrelse i simple bytes blev erstattet af et system, der tildeler forskellige "vægte" til forskellige dele af en transaktion. Dette tillod netværket at differentiere mellem kritiske transaktionsdata og vidne-data.

Under dette nye system tælles base-transaktionsdata til fuld størrelse, mens vidne-data gives rabat. Specifikt vejer vidne-data betydeligt mindre end transaktionsdata i beregningen af blokgrænsen. Denne ændring øgede effektivt blokstørrelsesgrænsen fra 1MB til en teoretisk 4MB af "vægtenheder".

Denne forskydning motivere brugere og pungudbydere til at adoptere SegWit-adresser. Transaktioner, der udnyttede det nye format, var billigere at sende, fordi de forbrugte mindre "vægt" i en blok sammenlignet med legacy-transaktioner. Denne økonomiske incitament hjalp med at drive adoptionen af opgraderingen på tværs af økosystemet.

Virtuelle Bytes (vBytes)

Med introduktionen af blokvægt udviklede konceptet med transaktionsgebyrer sig også. Gebyrer begyndte at blive beregnet i "virtual bytes" (vBytes) i stedet for rå bytes. En vByte er en måleenhed afledt af transaktionens vægt.

Fordi vidne-data gives rabat, har en SegWit-transaktion en mindre vByte-størrelse end en legacy-transaktion af samme råstørrelse. Dette betyder, at for den samme gebyrsats (satoshis per byte) koster en SegWit-transaktion mindre i totale gebyrer.

Denne effektivitet gevinst var øjeblikkelig for brugere, der skiftede til SegWit-kompatible punge. Det tillod netværket at behandle flere transaktioner pr. sekund, hvilket effektivt øgede gennemstrømningen uden de farer, der er forbundet med en hard fork. Optimeringen beviste, at intelligent ingeniørarbejde kunne presse mere ydeevne ud af den eksisterende infrastruktur.

Løsning på transaktionsmalleabilitet

Selvom skalering var den overskriftsskapende funktion i SegWit, løste opgraderingen et andet kritisk teknisk problem kendt som transaktionsmalleabilitet. Dette problem havde plaget Bitcoin siden begyndelsen og fungere som en stor barriere for udviklingen af avancerede andenlagsprotokoller.

Malleabilitet henviser til muligheden for, at en tredjepart kan ændre transaktionens unikke identifikator (TXID), før den bekræftes på blockchainen. Vigtigt nok kan denne ændring ske uden at ugyldiggøre transaktionen selv eller ændre de fundamentale detaljer som afsender, modtager eller beløb.

I legacy-systemet var den digitale signatur inkluderet i beregningen af transaktionshashen (TXID'en). Dog kan kryptografiske signaturer matematisk repræsenteres på let forskellige måder, mens de stadig er gyldige. En angriber eller en relay-node kunne modificere signaturdata en smule, hvilket ville resultere i en helt anden TXID.

Hvis TXID'en ændrede sig, kunne afsenderen tro, at transaktionen mislykkedes, mens modtageren (eller angriberen) bekræftede den modificerede version. Dette skabte forvirring og gjorde det farligt at kæde ubekræftede transaktioner sammen. Hvis den første transaktion i en kæde fik sin ID ændret, ville enhver efterfølgende transaktion, der henviste til den ID, blive ugyldig.

SegWit rettede dette ved at fjerne signaturdata fra den del af transaktionen, der bruges til at generere TXID'en. Da "vidnet" var segregeret, ville eventuelle ændringer i signaturdata ikke længere påvirke transaktions-ID'en. Dette gjorde transaktions-ID'en uforanderlig fra det øjeblik, den blev oprettet.

Aktivering af Lightning Network

Løsningen på transaktionsmalleabilitet var katalysatoren for Lightning Network. Lightning Network er en layer-2-skaleringløsning, der i høj grad afhænger af muligheden for sikkert at skabe kæder af ubekræftede transaktioner.

Grundlaget for lag 2

For at betalingskanaler skal fungere, åbner to parter effektivt en fælles konto på blockchainen og handler derefter signeret transaktioner frem og tilbage off-chain. Disse off-chain-transaktioner opdaterer kanalens balance uden at ramme hovedblockchainen.

Disse off-chain-transaktioner afhænger dog af, at den indledende "funding-transaktion" er sikkert forankret. Hvis transaktionsmalleabilitet stadig var mulig, kunne en slem aktør potentielt ændre ID'en på funding-transaktionen. Dette ville ugyldiggøre al den efterfølgende off-chain-logik, som parterne havde aftalt.

Ved at sikre transaktions-ID'en gav SegWit det klippefaste grundlag, der var nødvendigt for disse smart contracts. Det tillod Lightning-noder at stole på, at de transaktioner, de underskrev off-chain, ville forblive gyldige, når de til sidst blev afregnet på hoved-Bitcoin-netværket.

Øjeblikkelige afregninger

Med malleabilitetsrisikoen fjernet kunne Lightning Network rulles sikkert ud. Dette muliggjorde næsten øjeblikkelig afregning af betalinger mellem brugere overalt i verden. Mens SegWit gav en beskedent stigning i on-chain-kapacitet, åbnede Lightning muligheden for virtuelt ubegrænset off-chain-skalering.

Brugere kunne nu handle millioner af gange uden at belaste hovedblockchainen og kun afregne det endelige resultat. Denne kombination af on-chain-effektivitet (via SegWit) og off-chain-skalering (via Lightning) repræsenterer Bitcoins primære strategi til håndtering af global transaktionsvolumen.

Aktiveringssagaen: BIP 141 og UASF

Udrulningen af SegWit var ikke blot en teknisk opdatering; det var en historisk begivenhed i decentraliseret styring. Processen afslørede de komplekse magtdynamikker mellem minere, udviklere og brugere inden for Bitcoin-økosystemet.

Forslaget (BIP 141)

SegWit-opgraderingen blev formelt foreslået som Bitcoin Improvement Proposal 141. For at aktivere glat satte udviklerne en tærskel, der krævede 95 % af blokkene til at signalere støtte til opgraderingen inden for en to-ugers sværhedsæpok. Dette var tiltænkt at sikre, at netværket ikke ville splittes.

At opnå denne konsensus viste sig dog at være svært. Forskellige politiske og økonomiske interesser blandt store mining pools førte til et dødvande. Nogle minere foretrak en hard fork for direkte at øge blokstørrelsen, mens andre var tøvende med at opgradere deres infrastruktur.

I måneder svævede aktiveringssignaliseringen langt under den krævede tærskel. Det syntes, at opgraderingen måske ville stå stille på ubestemt tid, hvilket fremhævede en potentiel fejl i afhængigheden af minersignalisering for protokolopgraderinger.

User Activated Soft Fork (BIP 148)

Frustreret over manglen på fremskridt opstod en græsrodsbevægelse inden for communityet. Denne initiativ var kendt som User Activated Soft Fork (UASF), eller BIP 148. Konceptet var revolutionerende: i stedet for at vente på, at minere stemte, ville den økonomiske majoritet af noder (brugere, børser og virksomheder) håndhæve opgraderingen selv.

Deltagere i UASF kørte en version af Bitcoin-softwaren, der afviste enhver blok, der ikke signalerede støtte til SegWit efter en vis dato. Dette trak effektivt en streg i sandet. Hvis minere fortsatte med at ignorere SegWit, ville deres blokke blive afvist af en betydelig del af netværket, hvilket fik dem til at tabe indtægter.

Truende med en User Activated Soft Fork skiftede magtbalancen. Det demonstrerede, at mens minere behandler transaktioner, definerer brugerne protokolens regler. Konfronteret med det økonomiske pres fra UASF kapitulerede minere, og SegWit blev låst ind og aktiveret i august 2017.

Adressetyper og kompatibilitet

Efter aktiveringen af SegWit opstod forskellige adresseformater i Bitcoin-økosystemet. At forstå disse formater er essentielt for brugere, der ønsker at udnytte de lavere gebyrer og effektivisitetsfordele, som SegWit tilbyder.

Legacy-adresser

Det originale Bitcoin-adresseformat er kendt som Legacy. Disse adresser starter typisk med tallet 1. Transaktioner sendt fra Legacy-adresser er større i størrelse, fordi de ikke udnytter vidne-data-adskillelsen. Som følge heraf er de de dyreste at bruge i forhold til transaktionsgebyrer.

Nested SegWit (P2SH)

For at sikre glat adoption introducerede udviklere et kompatibilitetslag kendt som Pay to Script Hash (P2SH). Disse adresser starter med tallet 3. De tillod brugere at sende SegWit-transaktioner, selvom afsenderens pung ikke fuldt ud understøttede det nye native format.

Nested SegWit gav et mellemgrundlag. Det tilbød betydelige gebyrbesparelser sammenlignet med Legacy-adresser, skønt ikke så meget som den fuldt native implementering. I lang tid var dette standarden for mange børser og pungudbydere, mens de opdaterede deres systemer.

Native SegWit (Bech32)

Det mest effektive format er Native SegWit, også kendt som Bech32. Disse adresser starter med bc1. Native SegWit-adresser er tydeligt skilt ud, fordi de er case-insensitive, hvilket reducerer risikoen for tastefejl.

Endnu vigtigere er Native SegWit-transaktioner mindre i virtuelle bytes end deres Nested-modstykker. Dette resulterer i de laveste mulige transaktionsgebyrer for brugere. Efterhånden som økosystemet er modnet, er Native SegWit blevet standarden for de fleste moderne punge og tjenester.

AdressetypePræfiksGebyreffektivitetKompatibilitet
Legacy1...LavUniversal
Nested SegWit3...MiddelHøj
Native SegWitbc1...HøjModerne punge

Ud over SegWit: Taproot og Ordinals

Den succesfulde implementering af SegWit beviste, at Bitcoin kunne gennemgå komplekse opgraderinger uden at forstyrre dens kerneværdiproposition. Denne succes banede vejen for efterfølgende innovationer, der yderligere har udvidet netværkets kapaciteter.

Taproot og Schnorr-signaturer

I november 2021 aktiverede Bitcoin Taproot-opgraderingen. Taproot byggede direkte på fundamentet lagt af SegWit. Den introducerede Schnorr-signaturer, som tillod endnu større effektivitet og privatliv.

Ligesom SegWit ændrede Taproot, hvordan data lagres på blockchainen. Den muliggjorde signaturaggregation, hvor flere signaturer i en kompleks transaktion kunne kombineres til en enkelt signatur. Dette gjorde komplekse smart contracts uadskillelige fra almindelige transaktioner, hvilket forbedrede privatlivet, mens det sparede blokplads.

Uden de strukturelle ændringer introduceret af SegWit, specifikt script-versioneringssystemet, ville opgraderinger som Taproot have været betydeligt sværere at udrulle. SegWit etablerede en klar vej for fremtidig udvidbarhed.

Oprustningen af Ordinals

På nyere tid har introduktionen af Bitcoin Ordinals udnyttet SegWit-infrastrukturen på uventede måder. Ordinals tillader brugere at indskrive vilkårlige data – såsom billeder, tekst eller kode – direkte på individuelle satoshis.

Dette er muligt, fordi SegWit gav rabat på "vægten" af vidne-data. Indskrivere indså, at de kunne lagre store mængder data i vidne-feltet af en transaktion for en brøkdel af omkostningerne ved at lagre det i hovedblokområdet. Selvom det er kontroversielt for nogle, der ser det som spam, demonstrerede Ordinals fleksibiliteten i vidne-datapladsen.

Denne uventede brugssag fremhæver den robuste natur af SegWit-designet. Ved at skabe en separat, rabatteret bane for data skabte opgraderingen utilsigtet et lærred for digitale artefakter, hvilket yderligere diversificerede brugbarheden af Bitcoin-blockchainen.

Konklusion

Segregated Witness står som et vidnesbyrd om modstandsdygtigheden og tilpasningsdygtigheden i Bitcoin-netværket. Over for en kritisk flaskehals, der truede med at kvæle væksten, forenedes communityet bag en løsning, der var elegant, bagudkompatibel og fremtidsrettet. Ved at genforestille, hvordan transaktionsdata er struktureret, leverede SegWit øjeblikkelig lettelse fra høje gebyrer, mens den bevarede decentraliseringen, der giver Bitcoin dens værdi.

SegWits arv strækker sig langt ud over simple blokvægtsberegninger. Den løste den vedvarende sårbarhed i transaktionsmalleabilitet og låste potentialet for layer-2-skaleringløsninger som Lightning Network op. Desuden etablerede den en præcedens for brugerstyret styring og beviste, at den økonomiske majoritet effektivt kan tjekke magten hos mining-enheder.

Efterhånden som Bitcoin fortsætter med at udvikle sig, forbliver de strukturer bygget af SegWit centrale for dens drift. Fra effektiviteten af Native SegWit-adresser til de avancerede kapaciteter i Taproot og Ordinals gen definerede opgraderingen, hvad der er muligt på blockchainen. Den sikrede, at Bitcoin kunne skalere for at imødekomme global efterspørgsel uden at gå på kompromis med de principper, det blev grundlagt på.

SegWit revolutionerede Bitcoin ved at adskille signaturer fra transaktionsdata, hvilket effektivt øgede blokkapaciteten og rettede kritiske fejl for at muliggøre fremtidig skalering.