Bitcoins historie er preget av kritiske oppdateringer som har definert dens bane som en global digital valuta. Blant disse tekniske milepælene har få vært så transformative eller så heftig debattert som implementeringen av Segregated Witness. Ofte referert til med sitt korte navn, SegWit, ble denne protokolloppgraderingen aktivert i august 2017 etter en periode med intens samfunnsdiskusjon og konsensusbygging. Den representerte et avgjørende øyeblikk for nettverket, og adresserte langvarige problemer knyttet til skalerbarhet og sikkerhet.
Før SegWit sto Bitcoin-nettverket overfor økende press fra sin voksende brukerbase. Etter hvert som adopsjonen økte, ble begrensningene i den opprinnelige blokkstørrelsen en flaskehals, noe som førte til nettverksbelastning og stigende transaksjonskostnader. Utviklere og interessenter søkte en løsning som kunne lindre dette presset uten å gå på kompromiss med blockchainens desentraliserte natur. Segregated Witness dukket opp som en smart ingeniørløsning som optimaliserte hvordan data ble lagret i stedet for bare å øke blokkstørrelsesgrensen.
Oppgraderingen gjorde mer enn bare å forbedre kapasiteten. Den endret fundamentalt mekanismene for transaksjonsbehandling ved å adressere en teknisk sårbarhet kjent som transaksjonsmalleabilitet. Ved å fikse dette problemet la SegWit grunnlaget som var nødvendig for andre-lags-løsninger som Lightning Network for å blomstre. Dette banet vei for øyeblikkelige, lavkostnadbetalinger som tidligere var vanskelige å implementere sikkert.
Å forstå SegWit krever å se utover bare de tekniske spesifikasjonene. Det involverer undersøkelse av Bitcoins styringsmodell, økonomien rundt blokkplass og samfunnsdynamikken som driver protokollutvikling. Denne oppgraderingen demonstrerte at Bitcoin kunne tilpasse seg og skalere gjennom soft forks, og bevare bakoverkompatibilitet samtidig som den introduserte radikale forbedringer i effektivitet og nytteverdi.
Skalerbarhetsutfordringen
Bitcoin ble opprinnelig designet med en grense for størrelsen på blokkene som kunne legges til i blockchainen. Denne grensen, satt til 1 megabyte (MB), tjente som et beskyttende tiltak mot spamangrep i nettverkets tidlige dager. Imidlertid begynte denne sikkerhetsfunksjonen å virke som en begrensning for vekst etter hvert som Bitcoin vokste fra et obskurt eksperiment til en globalt anerkjent eiendel.
Blokkstørrelsesflaskehalsen
Hver Bitcoin-transaksjon består av data som må behandles og lagres av minera. Denne dataen inkluderer inndata, utdata og digitale signaturer som beviser eierskap av midlene som brukes. I pre-SegWit-tiden måtte all denne informasjonen konkurrere om plass innenfor den stive 1 MB blokkgrensen.
Etter hvert som populariteten til nettverket skjøt i været, oversteg etterspørselen etter blokkplass ofte det tilgjengelige tilbudet. Brukere havnet i en budkrig og festet høyere gebyrer til transaksjonene sine for å motivere minera til å inkludere dem i neste blokk. Denne dynamikken resulterte i lengre bekreftelsestider for brukere som betalte standard gebyrer.
Under toppperioder ble nettverket overbelastet, noe som gjorde det upraktisk for små betalinger eller mikrobetalinger. Samfunnet innså at for at Bitcoin skulle fungere effektivt både som en verdilager og et byttemiddel, måtte nettverkets gjennomstrømning økes. Debatten dreide seg om hvordan man skulle oppnå denne skaleringen uten å ofre sikkerhet eller desentralisering.
Hard fork-dilemmaet
En foreslått løsning på skalerbarhetsproblemet var en hard fork. En hard fork er en radikal endring i protokollen som gjør tidligere ugyldige blokker/transaksjoner gyldige, eller omvendt. I skaleringssammenheng ville dette betydd å bare omskrive koden for å tillate større blokker, som 2 MB eller 8 MB.
Imidlertid medfører hard forks betydelige risikoer. De krever at alle noder på nettverket oppgraderer programvaren sin samtidig. Hvis en del av samfunnet nekter å oppgradere eller er uenig i endringen, kan blockchainen splittes i to separate kjeder. Dette skjedde med skapelsen av Bitcoin Cash, som valgte å øke blokkstørrelsen via en hard fork.
Bitcoin Core-utviklere prioriterte en sikrere tilnærming kjent som en soft fork. En soft fork er en bakoverkompatibel oppgradering, noe som betyr at noder som kjører eldre versjoner av programvaren fortsatt kan delta i nettverket. SegWit ble designet som en soft fork for å sikre at nettverket forble samlet samtidig som det leverte de nødvendige kapasitetsforbedringene.
Konsensus og styring
Veien til aktivering av SegWit belyste den unike naturen til Bitcoin-styring. I motsetning til sentraliserte systemer der en leder dikterer endringer, baserer Bitcoin seg på konsensus blant en mangfoldig gruppe deltakere. Dette inkluderer minera, utviklere, nodeoperatører og sluttbrukere.
Forslaget for SegWit, kjent som Bitcoin Improvement Proposal (BIP) 141, krevde en svært høy terskel for støtte fra minera for å aktiveres. Spesifikt måtte 95 % av gruvedriftens hash-kraft signalisere beredskap i løpet av en to ukers periode. Denne høye terskelen sikrer at oppgraderinger har overveldende støtte før de håndheves, og minimerer risikoen for nettverksinstabilitet.
Hvordan SegWit fungerer under panseret
Den primære innovasjonen i Segregated Witness antydes i navnet. «Segregated» betyr å skille, og «Witness» refererer til de digitale signaturene som verifiserer en transaksjon. I tradisjonelle Bitcoin-transaksjoner var signaturdataen flettet sammen med transaksjonsdataen og okkuperte en betydelig del av den verdifulle 1 MB blokkplassen.
Å skille vitnedataen
SegWit restrukturerte transaksjonsformatet ved å flytte vitnedataen (signaturer) ut av hovedblokkstrukturen. Selv om denne dataen fortsatt registreres og valideres, lagres den i en separat struktur som kjører parallelt med basistraksaksjonsblokken. Denne separasjonen var nøkkelen til å låse opp mer kapasitet uten teknisk å øke 1 MB-grensen for gamle noder.
For å visualisere dette, forestill deg et tog som representerer en Bitcoin-blokk. I det tradisjonelle systemet var passasjerer (transaksjonsdetaljer) og bagasjen deres (signaturer) alle klemt inn i de samme togvognene. Togene hadde en streng grense for hvor mye volum de kunne bære.
SegWit la effektivt til en spesialisert godsvogn bakerst på toget spesielt for bagasjen. Ved å flytte den tunge bagasjen ut av passasjervognene kunne toget plutselig frakte betydelig flere passasjerer innenfor de samme hovedkompartmentene. «Bagasjen» reiser fortsatt med toget, men den okkuperer ikke lenger den premium-plassen som trengs for passasjerene selv.
Blokkvekt vs. blokkstørrelse
For å implementere denne endringen introduserte SegWit et nytt konsept kalt «block weight». Den gamle målingen av blokkstørrelse i enkle bytes ble erstattet av et system som tildeler forskjellige «vekter» til forskjellige deler av en transaksjon. Dette tillot nettverket å skille mellom kritisk transaksjonsdata og vitnedata.
Under dette nye systemet telles basistraksaksjonsdataen med full størrelse, mens vitnedataen rabatteres. Spesifikt veier vitnedataen betydelig mindre enn transaksjonsdata i beregningen av blokkgrensen. Denne endringen økte effektivt blokkstørrelsesgrensen fra 1 MB til en teoretisk 4 MB «vekteenheter».
Denne skiftet motiverte brukere og lommebokleverandører til å adoptere SegWit-adresser. Transaksjoner som brukte det nye formatet var billigere å sende fordi de forbrukte mindre «vekt» i en blokk sammenlignet med tradisjonelle transaksjoner. Denne økonomiske insentiven bidro til å drive adopsjonen av oppgraderingen på tvers av økosystemet.
Virtuelle bytes (vBytes)
Med introduksjonen av blokkvekt utviklet også konseptet med transaksjonsgebyrer seg. Gebyrer begynte å beregnes i «virtual bytes» (vBytes) i stedet for rå bytes. En vByte er en måleenhet avledet fra vekten av transaksjonen.
Fordi vitnedata rabatteres, har en SegWit-transaksjon en mindre vByte-størrelse enn en tradisjonell transaksjon av samme råstørrelse. Dette betyr at for samme gebyrsats (satoshis per byte) koster en SegWit-transaksjon mindre i totale gebyrer.
Denne effektiviseringsgevinsten var umiddelbar for brukere som byttet til SegWit-kompatible lommebøker. Det tillot nettverket å behandle flere transaksjoner per sekund, og økte effektivt gjennomstrømningen uten farene forbundet med en hard fork. Optimaliseringen beviste at intelligent ingeniørkunst kunne presse mer ytelse ut av den eksisterende infrastrukturen.
Løsning på transaksjonsmalleabilitet
Mens skalering var hovedfunksjonen til SegWit, løste oppgraderingen et annet kritisk teknisk problem kjent som transaksjonsmalleabilitet. Dette problemet hadde plaget Bitcoin siden oppstarten og virket som en stor barriere for utviklingen av avanserte andre-lags-protokoller.
Malleabilitet refererer til evnen til en tredjepart å endre den unike identifikatoren (TXID) til en transaksjon før den bekreftes på blockchainen. Viktigvis kunne denne endringen gjøres uten å ugyldiggjøre transaksjonen selv eller endre de fundamentale detaljene som avsender, mottaker eller beløp.
I det tradisjonelle systemet ble den digitale signaturen inkludert i beregningen av transaksjonshashen (TXID-en). Signaturer kan imidlertid representeres matematisk på litt forskjellige måter samtidig som de forblir gyldige. En angriper eller en relay-node kunne endre signaturdataen litt, noe som ville resultere i en helt annen TXID.
Hvis TXID-en endret seg, kunne avsenderen tro at transaksjonen mislyktes, mens mottakeren (eller angriperen) bekreftet den modifiserte versjonen. Dette skapte forvirring og gjorde det farlig å koble ubekreftede transaksjoner sammen. Hvis den første transaksjonen i en kjede hadde sin ID endret, ville enhver etterfølgende transaksjon som refererte til den ID-en bli ugyldig.
SegWit fikset dette ved å fjerne signaturdataen fra den delen av transaksjonen som brukes til å generere TXID-en. Siden «witness» ble segregert, ville eventuelle endringer i signaturdataen ikke lenger påvirke transaksjons-ID-en. Dette gjorde transaksjons-ID-en uforanderlig fra øyeblikket den ble opprettet.
Aktivering av Lightning Network
Fiksingen av transaksjonsmalleabilitet var katalysatoren for Lightning Network. Lightning Network er en lag-2-skaleringsløsning som i stor grad avhenger av evnen til å opprette kjeder av ubekreftede transaksjoner sikkert.
Grunnlaget for lag 2
For at betalingskanaler skal fungere, åpner to parter effektivt en felles konto på blockchainen og handler deretter signerte transaksjoner frem og tilbake off-chain. Disse off-chain-transaksjonene oppdaterer balansen i kanalen uten å treffe hovedblockchainen.
Imidlertid avhenger disse off-chain-transaksjonene av at den initiale «funding-transaksjonen» er forankret sikkert. Hvis transaksjonsmalleabilitet fortsatt var mulig, kunne en skurk potensielt endre ID-en til funding-transaksjonen. Dette ville ugyldiggjøre all etterfølgende off-chain-logikk som partene hadde blitt enige om.
Ved å sikre transaksjons-ID-en ga SegWit det urokkelige grunnlaget som trengtes for disse smarte kontraktene. Det tillot Lightning-noder å stole på at transaksjonene de signerte off-chain ville forbli gyldige når de til slutt ble avgjort på hoved-Bitcoin-nettverket.
Øyeblikkelige oppgjør
Med malleabilitetsrisikoen fjernet kunne Lightning Network rulles ut trygt. Dette muliggjorde nesten øyeblikkelig oppgjør av betalinger mellom brukere over hele verden. Mens SegWit ga en beskjeden økning i on-chain-kapasitet, åpnet Lightning for potensialet for virtuelt ubegrenset off-chain-skalering.
Brukere kunne nå transigere millioner av ganger uten å belaste hovedblockchainen, og bare avgjøre det endelige resultatet. Denne kombinasjonen av on-chain-effektivitet (via SegWit) og off-chain-skalering (via Lightning) representerer Bitcoins primære strategi for å håndtere global transaksjonsvolum.
Aktiverings sagaen: BIP 141 og UASF
Utrullingen av SegWit var ikke bare en teknisk oppdatering; det var en historisk begivenhet i desentralisert styring. Prosessen avslørte de komplekse maktbalansene mellom minera, utviklere og brukere i Bitcoin-økosystemet.
Forslaget (BIP 141)
SegWit-oppgraderingen ble formelt foreslått som Bitcoin Improvement Proposal 141. For å aktivere jevnt satte utviklerne en terskel som krevde at 95 % av blokkene signaliserte støtte for oppgraderingen innenfor en to ukers vanskelighetsperiode. Dette var ment å sikre at nettverket ikke skulle splittes.
Imidlertid viste det seg å være vanskelig å oppnå denne konsensusen. Forskjellige politiske og økonomiske interesser blant store mining pools førte til dødvann. Noen minera foretrakk en hard fork for å øke blokkstørrelsen direkte, mens andre var nølende med å oppgradere infrastrukturen sin.
I måneder svevde aktiveringssignaleringen godt under den nødvendige terskelen. Det virket som om oppgraderingen kunne stoppe opp på ubestemt tid, noe som fremhevet en potensiell feil i avhengigheten av miner-signalering for protokolloppgraderinger.
User Activated Soft Fork (BIP 148)
Frustrert over mangelen på fremgang oppsto en gressrotsbevegelse i samfunnet. Denne initiativet var kjent som User Activated Soft Fork (UASF), eller BIP 148. Konseptet var revolusjonerende: i stedet for å vente på at minera skulle stemme, ville den økonomiske majoriteten av noder (brukere, børser og bedrifter) håndheve oppgraderingen selv.
Deltakere i UASF kjørte en versjon av Bitcoin-programvaren som avviste enhver blokk som ikke signaliserte støtte for SegWit etter en viss dato. Dette trakk effektivt en strek i sanden. Hvis minera fortsatte å ignorere SegWit, ville blokkene deres bli avvist av en betydelig del av nettverket, noe som fikk dem til å tape inntekter.
Trusselen om en User Activated Soft Fork endret maktbalansen. Den demonstrerte at mens minera behandler transaksjoner, definerer brukerne reglene for protokollen. Konfrontert med det økonomiske presset fra UASF, ga minera etter, og SegWit ble låst inn og aktivert i august 2017.
Adresstyper og kompatibilitet
Etter aktiveringen av SegWit så Bitcoin-økosystemet fremveksten av forskjellige adresseformater. Å forstå disse formatene er essensielt for brukere som ønsker å dra nytte av de lavere gebyrene og effektiviseringsfordelene som SegWit tilbyr.
Legacy-adresser
Det opprinnelige Bitcoin-adresseformatet er kjent som Legacy. Disse adressene starter vanligvis med tallet 1. Transaksjoner sendt fra Legacy-adresser er større i størrelse fordi de ikke utnytter separasjonen av vitnedata. Derfor er de de dyreste å bruke i form av transaksjonsgebyrer.
Nested SegWit (P2SH)
For å sikre jevn adopsjon introduserte utviklere et kompatibilitetslag kjent som Pay to Script Hash (P2SH). Disse adressene starter med tallet 3. De tillot brukere å sende SegWit-transaksjoner selv om avsenderens lommebok ikke fullt ut støttet det nye native formatet.
Nested SegWit ga en mellomvei. Den tilbød betydelige gebyrbesparinger sammenlignet med Legacy-adresser, selv om ikke like mye som den fulle native implementeringen. I lang tid var dette standarden for mange børser og lommebokleverandører mens de oppdaterte systemene sine.
Native SegWit (Bech32)
Det mest effektive formatet er Native SegWit, også kjent som Bech32. Disse adressene starter med bc1. Native SegWit-adresser er distinkte fordi de er case-insensitive, noe som reduserer risikoen for skrivefeil.
Viktigere er det at Native SegWit-transaksjoner er mindre i virtuelle bytes enn sine Nested-motparter. Dette resulterer i de laveste mulige transaksjonsgebyrene for brukere. Etter hvert som økosystemet har modnet, har Native SegWit blitt standarden for de fleste moderne lommebøker og tjenester.
| Adresstype | Prefiks | Gebyreffektivitet | Kompatibilitet |
|---|---|---|---|
| Legacy | 1... | Lav | Universell |
| Nested SegWit | 3... | Middels | Høy |
| Native SegWit | bc1... | Høy | Moderne lommebøker |
Utover SegWit: Taproot og Ordinals
Den vellykkede implementeringen av SegWit beviste at Bitcoin kunne gjennomgå komplekse oppgraderinger uten å forstyrre dens kjerneverdiposisjon. Denne suksessen banet vei for påfølgende innovasjoner som har utvidet nettverkets evner ytterligere.
Taproot og Schnorr-signaturer
I november 2021 aktiverte Bitcoin Taproot-oppgraderingen. Taproot bygde direkte på grunnlaget lagt av SegWit. Den introduserte Schnorr-signaturer, som tillot enda større effektivitet og personvern.
Akkurat som SegWit endret Taproot hvordan data lagres på blockchainen. Den muliggjorde signaturaggregasjon, der flere signaturer i en kompleks transaksjon kunne kombineres til en enkelt signatur. Dette gjorde komplekse smarte kontrakter umulige å skille fra vanlige transaksjoner, og forbedret personvernet samtidig som det sparte blokkplass.
Uten de strukturelle endringene introdusert av SegWit, spesifikt script-versjoneringssystemet, ville oppgraderinger som Taproot vært betydelig vanskeligere å rulle ut. SegWit etablerte en klar vei for fremtidig utvidbarhet.
Oppgangen til Ordinals
Mer nylig har introduksjonen av Bitcoin Ordinals utnyttet SegWit-infrastrukturen på uventede måter. Ordinals tillater brukere å inngraffe vilkårlig data – som bilder, tekst eller kode – direkte på individuelle satoshis.
Dette er mulig fordi SegWit rabatterte «vekten» til vitnedata. Inngravere innså at de kunne lagre store mengder data i vitnefeltet i en transaksjon for en brøkdel av kostnaden ved å lagre det i hovedblokkområdet. Selv om kontroversielt for noen som ser det som spam, demonstrerte Ordinals fleksibiliteten i vitnedataplassen.
Denne uventede bruken fremhever den robuste naturen til SegWit-designet. Ved å skape en separat, rabattert bane for data, skapte oppgraderingen utilsiktet et lerret for digitale artefakter, og diversifiserte ytterligere nytten av Bitcoin-blockchainen.
Konklusjon
Segregated Witness står som et vitnesbyrd om motstandskraften og tilpasningsevnen til Bitcoin-nettverket. Overfor en kritisk flaskehals som truet med å kvele veksten, samlet samfunnet seg bak en løsning som var elegant, bakoverkompatibel og fremtidsrettet. Ved å tenke nytt om hvordan transaksjonsdata er strukturert, ga SegWit umiddelbar lettelse fra høye gebyrer samtidig som den bevarte desentraliseringen som gir Bitcoin dens verdi.
Arven etter SegWit strekker seg langt utover enkle blokkvektberegninger. Den løste den vedvarende sårbarheten til transaksjonsmalleabilitet og låste opp potensialet for lag-2-skaleringsløsninger som Lightning Network. Videre etablerte den en presedens for brukerstyrt styring, og beviste at den økonomiske majoriteten effektivt kan holde maktbalansen over gruveenheter.
Etter hvert som Bitcoin fortsetter å utvikle seg, forblir strukturene bygget av SegWit sentrale for dens drift. Fra effektiviteten til Native SegWit-adresser til de avanserte evnene til Taproot og Ordinals, definerte oppgraderingen på nytt hva som er mulig på blockchainen. Den sikret at Bitcoin kunne skalere for å møte global etterspørsel uten å gå på kompromiss med prinsippene det ble grunnlagt på.
SegWit revolusjonerte Bitcoin ved å skille signaturer fra transaksjonsdata, og økte effektivt blokkkapasiteten og fikset kritiske feil for å muliggjøre fremtidig skalering.