Utviklingen av Tokens, NFTs og DeFi på Bitcoin
Utviklingen av tokens, NFTs og DeFi på Bitcoin er mer kompleks enn det først kan virke. På plattformer som Ethereum Virtual Machine (EVM) har smarte kontrakter Turing-kompletthet, noe som gjør det enkelt å legge til nye funksjoner ved å deployere tilpassede kontrakter. I motsetning til dette må Bitcoin-utviklere være forsiktige med innovasjon for ikke å forårsake en hard fork, og de må operere innenfor rammen av eksisterende protokollfunksjoner. En av de viktigste faktorene som gjør Bitcoin både unikt og verdifullt, er dets forpliktelse til «originalitet»; hovedkjeden har gjennomgått få endringer over tid.
Historiske Innovasjoner på Bitcoin
Til tross for det, var Bitcoin den første blokkjeden med bred adopsjon, og mange teknologier som senere ble implementert på mer fleksible blokkjeder, hadde tidlige frø i Bitcoin. For eksempel dukket NFTs først opp på Bitcoin som «Colored Coins», mens konseptet med State Channels ligner på dagens L1-L2-arkitektur, og Atomic Swaps la grunnlaget for moderne krysskjede-broer.
I vår forrige artikkel, «Starter fra Bitcoin: Den sanne opprinnelsen til DeFi», introduserte vi noen av disse utviklingene. For å forstå den enestående verdien av Bitcoin som infrastruktur for Botanix og andre Bitcoin-baserte kjeder, må vi dykke dypere inn i hvordan disse tidlige innovasjonene banet veien for dagens økosystem.
Selv om Bitcoin er relativt «enkelt», er det et av de mest komplekse og fascinerende økosystemene innen Web3, med en rik historie.
Utforsking av Bitcoins Funksjonalitetsteori
Da Bitcoin ble lansert i 2009, inkluderte det et skriptspråk som ikke bare muliggjorde enkle betalinger, men også støtte for mer komplekse operasjoner som multisig og tidslåser fra begynnelsen. Satoshi Nakamoto beskrev til og med at ikke-bekreftede transaksjoner som bruker nLockTime og sekvensnumre kan oppdateres flere ganger mellom to parter for høyfrekvente transaksjoner, hvor kun den endelige tilstanden blir skrevet til kjeden.
Bitcoin Script er en interessant mekanisme: den er Turing-inkomplett, noe som begrenser funksjonaliteten, men samtidig enkel og sikker. Utviklere må derfor designe komplekse funksjoner innenfor rammen som Script gir. Script inneholder et stort antall kommandoer (Opcode) for programmering av forskjellige handlinger som til slutt blir skrevet inn i transaksjonsdata.
Du kan tenke på Script som en oppskrift – et sett med steg for å «bake en kake». Opcodes fungerer som byggesteiner i dette språket – de er de grunnleggende instruksjonene programmerere bruker når de skriver skript, som «rør» og «varm opp». En studie fra NCC Group oppsummerte 156 forskjellige skriptmønstre og utførte en detaljert analyse av disse skriptstrukturene.
Kan vi bygge dekompliserte kontrakter på Bitcoin?
«Lånemekanisme:»
Som tidligere nevnt, kan opcodes kombineres for å bygge serier med små kjeder av instruksjoner for mer komplekse oppgaver. Utviklere kan for eksempel konstruere kompliserte skript med lånekontraktsfunksjoner ved å kombinere opcodes.
Dette kan oppnås gjennom en kombinasjon av tidslåser og multisignaturer: disse verktøyene kan implementere «bilaterale depotkontrakter med tidsfrister». Anta for eksempel at Alice gir BTC som sikkerhet, og Bob låner henne stablecoins offline. Kontrakten kan inneholde følgende regler: Hvis Alice ikke betaler tilbake lånet i tide, vil Bob få hennes BTC; hvis hun betaler tilbake i tide, vil BTC bli låst opp og returnert til Alice. Her kan de bruke en 2-av-2 multisignaturutgang (begge parter må signere for å bruke midlene). Skriptlogikken kan da være at hvis lånet ikke er betalt tilbake innen en viss blokk høyde, kan kun Bob bruke midlene.
Det er imidlertid en stor utfordring: Bitcoin kan ikke automatisk beregne renter, overvåke sikkerhetsnivåer eller håndheve likvidasjoner. Enhver rente- eller betalingsprosess må skje off-chain eller gjennom forhånds signerte transaksjoner, som kan være kompliserte i praksis. Hvis BTC-prisen faller i låneperioden, kan Bitcoin-skriptet ikke registrere dette og kan ikke automatisk utløse likvidasjonen. For å oppnå denne funksjonaliteten vil en oracle eller off-chain-protokoll være nødvendig. Uten en oracle kan kontrakten kun gjøre vurderinger basert på den endelige utløpstiden. Av den grunn er det vanskelig å implementere tillitsløse BTC-sikrede stablecoin-lån direkte på Bitcoin-hovedkjeden. Nåværende praksis stoler ofte på betrodde tredjeparter eller bruker mekanismer for atombytte på andre kjeder for å oppnå dette.
AMM-funksjoner og videre utfordringer
Som nevnt kan låne- og innsatsmekanismer teoretisk implementeres gjennom Bitcoin Script, men de er mindre effektive i praksis. Vi kan også undersøke muligheten for å bygge mer kompliserte mekanismer som automatiserte markedsprodusenter (AMMs) på Bitcoin. Bitcoin Script har matematiske opcodes som OP_ADD, OP_SUB og OP_MUL (selv om noen av disse er deaktivert), samt sammenlignings-opcodes som OP_LESSTHAN. Teoretisk kan disse funksjonene brukes til å implementere prisberegningslogikk. Utviklere kan konstruere skript med en fast pris eller et sett av forhåndsbestemte akseptable prisnivåer, men det er umulig å justere prisen dynamisk etter hver transaksjon. Dette er fordi Bitcoin bruker UTXO-modellen, hvor hver transaksjon genererer en ny UTXO og skript, noe som krever at hver mulig tilstand må beregnes på forhånd, eller at en kontrakt må distribueres på nytt etter hver transaksjon.
En annen kritisk faktor for implementering av AMM er evnen til å bytte eiendeler. Bitcoin støtter atombytter, som kan oppbygges gjennom ordrebøker fremfor likviditetspools. Lignende AMM-atferd kan simuleres ved å bygge en serie HTLCs (hash tidslåse kontrakter) eller ved å utstede ventende ordrer på ulike prispunkter for å lage et statisk automatisk markedssystem (sammenlignbart med en avkastningskurve). Likevel er vedlikeholdet av et slikt system besværlig, ettersom skript må oppdateres manuelt og UTXO reutstedes etter hver transaksjon, noe som medfører betydelige on-chain kostnader.
Utvidelse av Skriptfunksjonalitet
De tidligere nevnte punktene forklarer hvorfor Bitcoin gjennomgår jevnlige betydelige oppdateringer for å forbedre funksjonaliteten. En av de viktige oppdateringene er Taproot, som ble introdusert via en myk fork, men som i stor grad endret måten Script er designet på. Taproot oppgraderingen (BIP 342) innførte mange tidligere deaktivere eller reserverte opcodes som ble konvertert til OP_SUCCESS opcodes i Tapscript. OP_SUCCESS betyr at så lenge opcodes utføres, så avsluttes skriptet vellykket.
Denne designen tillater en sikrere og enklere legging av nye opcodes gjennom myke forks. Spesielt i Tapscript, hvis verdien av opcode er i et spesifikt område (f.eks. 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, 0xbb–0xfe), vil det bli betraktet som OP_SUCCESSx. Når disse opkodene oppfylles, vil skriptet bli vurdert som vellykket, mens annen logikk vil bli oversett.
Denne mekanismen erstatter den tidligere OP_NOP (ingen opcode) metoden for oppgradering, og gir høyere sikkerhet og fleksibilitet. Fremtidige myke forks kan omdefinere oppførselen til en spesifikk OP_SUCCESS opcode, og gamle versjonsnoder vil fortsatt betrakte det som «søkriftlig suksess», noe som unngår ugyldige transaksjoner forårsaket av versjonsinkonsekvenser.
Oppsummert er alle opcodes som ikke er oppført som «tilgjengelige» enten reserverte eller har blitt konvertert til alltid å returnere vellykket OP_SUCCESS i Taproot.
Stablecoins og Effektivitet i Bitcoin-økosystemet
Stablecoins har blitt en nøkkeldel av ethvert Web3-økosystem, også i miljøer som ikke er direkte koblet til DeFi. De lar brukere begrense volatilitet og overføre penger uten å bekymre seg for svingninger i eiendelpriser. Bitcoin-nettverket har ofte søkt å finne en balanse mellom funksjonell enkelhet og datalagringskapasitet. Tidlig forskning på eiendelutstedelse på Bitcoin ble oppnådd med «Colored Coins», som ligner på NFTs.
I 2012 foreslo JR Willett ideen om å utstede nye eiendeler på Bitcoin, som ledet til lanseringen av «colored coins». Han bidro også til opprettelsen av Mastercoin-protokollen (senere kjent som Omni), som la grunnlaget for eiendeltokenisering på Bitcoin (inkludert tokens koblet til fiat-valutaer).
Siden det ikke finnes noen direkte «token» opcode i standard Bitcoin Script, kan utviklere bare inkludere tokenmetadata i transaksjonsutgangene ved hjelp av OP_RETURN (som gjør utgangen uspendbar og bærer data). Før OP_RETURN ble standardisert, ble til og med multisig-skript brukt som en omvei for å kode data. Bitcoin Script selv kan ikke håndheve tokenregler; reglene opprettholdes av programvare off-chain som parser Bitcoin-transaksjoner.
Protokoller som Colored Coins, Omni Layer (tidligere Mastercoin), Counterparty og Open Assets representerer tokens ved å «farge» spesifikke satoshier eller UTXOs. Forklarende kodestruktur opprettholder metadata og angir antall tokens og eiendel-ID-er. Bitcoin-blokkjeden er i praksis uvitende om eksistensen av «tokens»; den prosesser bare data. Gyldigheten av tokens (f.eks. tilbud, eierskap) spores av eksterne lommebøker som parser OP_RETURN-dataene.
Det er også verdt å merke seg at OP_RETURN har en grense for datastørrelse. Det standardpolitikken til Bitcoin Core-klienten er at hver OP_RETURN-utgang kan inneholde opptil 80 bytes med data. Data utover 80 bytes vil bli betraktet som «ikke-standard transaksjon» og ikke videresendt som standard. Teoretisk kan en transaksjon ha flere OP_RETURN-utganger for å øke datavolumet (opptil 80 bytes hver), men for å hindre spam-transaksjoner tillater Bitcoins nåværende standardrelayspolitikk generelt bare én OP_RETURN-utgang pr. transaksjon.
Denne evnen til å inkludere metadata i Bitcoin-transaksjoner førte til opprettelsen av Mastercoin-protokollen i 2012, som senere ble kjent som Omni. Omni Layer spilte en viktig rolle i tidlig drift av Tether, og fungerte som den underliggende overføringsprotokollen for den første bølgen av USDT-overføringer. Midt på 2010-tallet var USDT basert på Bitcoin (Omni) den mest dominerende stablecoinen på markedet, særlig populær på børser som Bitfinex. Omni-transaksjoner er standard Bitcoin-transaksjoner med ekstra metadata, og Omni har utviklet flere implementeringskategorier, og etablerte sin egen tekniske utviklingsbane.
