Processen att Utveckla Tokens, NFTs och DeFi på Bitcoin
Processen att utveckla tokens, NFTs och DeFi på Bitcoin är faktiskt mer komplicerad än vad den verkar vid första anblick. Till exempel, på Ethereum Virtual Machine (EVM) och andra smarta kontraktsplattformar är smarta kontrakt Turing-kompletta, vilket innebär att nya funktioner kan läggas till genom att implementera ett anpassat kontrakt. Men på Bitcoin måste utvecklare vara försiktiga för att undvika att orsaka en hård gaffel och måste arbeta inom begränsningarna av befintliga protokollfunktioner.
Bitcoin och dess Unika Originalitet
En av de avgörande faktorerna som gör Bitcoin både unikt och värdefullt är dess efterlevnad av ”originalitet”. Huvudkedjan har genomgått få förändringar genom tiderna. Trots detta var Bitcoin den första blockkedjan att få allmän spridning, och många teknologier som senare implementerades på mer flexibla blockkedjor hade sina tidigaste frön i Bitcoin. Faktum är att NFTs först dök upp på Bitcoin i form av Colored Coins; konceptet med State Channels liknar ganska mycket dagens L1-L2-arkitektur; och Atomic Swaps lade grunden för moderna cross-chain-bryggor. Vi har redan introducerat några av dessa utvecklingar i den tidigare artikeln ”Börja med Bitcoin: Den sanna ursprunget av DeFi”.
För att verkligen förstå det oöverträffade värdet av Bitcoin som infrastruktur för Botanix och andra Bitcoin-kedjor behöver vi dock en djupare förståelse för hur dessa tidiga innovationer har banat väg för dagens ekosystem. Även om Bitcoin i sig är relativt ”enkelt”, är det faktiskt ett av de mest komplexa och fascinerande ekosystemen inom Web3-fältet, med en rik historia.
Utforska Bitcoins Funktionsteori
Är Bitcoins kapabiliteter tillräckliga för att stödja ett komplext ekosystem? När Bitcoin lanserades 2009 hade den ett inbyggt skriptspråk som inte bara möjliggjorde enkla betalningar, utan även stödde mer komplexa operationer som multi-sig och tidslås från början. Satoshi Nakamoto beskrev även hur ojusterade transaktioner som använder nLockTime och sekvensnummer kan uppdateras flera gånger mellan två parter för högfrekventa transaktioner, där endast det slutliga tillståndet registreras på kedjan.
Bitcoin Script är en intressant mekanism: å ena sidan är den Turing-incomplete, vilket begränsar dess funktionalitet, men å andra sidan förblir den enkel och säker. Därför måste utvecklare som bygger komplexa funktioner på Bitcoin designa dem inom de ramar som tillhandahålls av Script. Det finns ett stort antal kommandon (Opcode) i detta språk för att programmera olika åtgärder, som så småningom skrivs in i transaktionsdatan. Bitcoin Script definierar villkoren för att spendera mynt, och du kan tänka på Script som ett recept – en uppsättning steg för att baka en tårta. Opcodes är byggstenarna i detta språk – grundläggande instruktioner som används av programmerare när de skriver skript, som till exempel ”rör om” och ”värm”.
Lånemekanismer
Som vi nämnt tidigare kan opcodes kombineras för att bygga en serie små kedjor av instruktioner för att uppnå mer komplexa beteenden. Utvecklare kan till exempel konstruera komplexa skript med lånekontraktsfunktioner genom att kombinera opcodes. Detta kan uppnås genom en kombination av tidslåsningar och multi-signaturer: Dessa verktyg kan implementera ”bilaterala escrows med timeout.” Tänk dig att Alice tillhandahåller BTC som säkerhet, och Bob lånar henne stabila mynt offline. De hoppas kunna ställa in följande regler genom kontraktet: Om Alice inte återbetalar lånet i tid, kommer Bob att få hennes BTC, men om hon återbetalar i tid kommer BTC att låsas upp och återlämnas till Alice. För att kombinera detta kan de använda en 2-av-2 multi-signaturutgång (där både Alice och Bob måste signera för att använda medlen).
Det finns dock en stor svårighet i detta: Bitcoin självt kan inte automatiskt beräkna ränta, övervaka säkerhetsgrad eller verkställa likvidationer. När det gäller räntebetalningar, måste dessa göras off-chain eller med hjälp av förhandsundertecknade transaktioner, vilket är ganska komplicerat i praktiken. Om priset på BTC sjunker under låneperioden kan Bitcoin-skriptet inte veta det och kan inte automatiskt utlösa en likvidation. För att uppnå denna funktion måste en oracle eller ett off-chain-protokoll användas. Utan en oracle kan kontraktet endast göra bedömningar baserat på slutdatumet. Därför är det mycket svårt att direkt implementera trustless BTC-säkerställda stabila myntlån på Bitcoin-lagret.
AMM-funktioner
Som nämnts tidigare kan låne- och insatsmekanismer teoretiskt implementeras genom Bitcoin Script, men i praktiken är de mindre effektiva. Vi kan fortfarande utforska om det är möjligt att bygga mer komplexa mekanismer, liknande automatiserade marknadsskapare (AMM) på Bitcoin. Bitcoin Script innehåller matematiska opcodes som OP_ADD, OP_SUB och OP_MUL (även om vissa av dem har inaktiverats), samt jämförelseopcodes som OP_LESSTHAN. I teorin kan dessa funktioner användas för att implementera prisberäkningslogik. Utvecklare kan konstruera ett skript med ett fast pris eller en uppsättning fördefinierade acceptabla prisnivåer, men det är omöjligt att dynamiskt justera priset efter varje transaktion.
Anledningen är att Bitcoin använder UTXO-modellen, och varje transaktion genererar en ny UTXO och skript, vilket innebär att varje möjligt tillstånd måste förberedas eller ett kontrakt måste återimplementeras efter varje transaktion. En annan avgörande faktor för implementationen av AMM är förmågan att byta tillgångar. I teorin stöder Bitcoin atomiska swaps, som kan byggas i form av orderböcker istället för likviditetspooler.
Liknande AMM-beteende kan också simuleras genom att bygga en serie HTLC:er (hash-time-lock contracts) eller utfärda utestående order vid olika prisnivåer för att skapa ett statiskt automatiserat marknadsproduktionssystem (liknande en avkastningskurva).
Men att underhålla ett sådant system är mycket besvärligt, och skriptet behöver uppdateras manuellt; UTXO måste omissuers efter varje transaktion, vilket innebär extremt höga kostnader på kedjan.
Utökad Script-funktionalitet och Taproot
Ovanstående punkter förklarar varför Bitcoin genomgår stora uppdateringar regelbundet för att förbättra sin funktionalitet. En av de viktiga uppdateringarna är Taproot, som introducerades genom en mjuk gaffel men som kraftigt förändrade hur Script är designat. Taproots OP_SUCCESS-mekanism: Med införandet av Taproot-uppgraderingen (BIP 342) konverterades många tidigare inaktiverade eller reserverade opcodes till OP_SUCCESS i Tapscript (dvs. SegWit v1-skript). OP_SUCCESS innebär att så länge opkoden körs avslutas skriptet framgångsrikt omedelbart.
Denna design gör det enklare och säkrare att lägga till nya opcodes genom mjuka gafflar. Specifikt i Tapscript, om värdet för opkoden ligger inom ett specifikt intervall (till exempel: 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, 0xbb–0xfe), kommer det att betraktas som OP_SUCCESSx. När denna opcodes stöts på, kommer skriptet oåterkalleligt att bedömas som framgångsrikt och annan logik ignoreras.
Denna mekanism ersätter den gamla OP_NOP (ingen opcode)-metoden för uppgradering, vilket medför högre säkerhet och flexibilitet. Framtida mjuka gafflar kan omdefiniera beteendet hos en viss OP_SUCCESS-opcode, och noder med äldre versioner kommer fortfarande att betrakta det som ”skriptframgång”, vilket därmed undviker ogiltiga transaktioner orsakade av versionsinkonsekvenser.
Sammanfattningsvis, alla opcodes som inte listas som ”tillgängliga” är antingen reserverade eller har konverterats till att alltid återge framgångsrik OP_SUCCESS i Taproot. En annan viktig aspekt är att opcodes kan föreslås via BIP (Bitcoin Improvement Proposal)-processen och det finns redan några kraftfulla förslag under övervägande eller avvisning. Om något av dessa förslag antas kommer det avsevärt att utöka Bitcoins funktionalitet och göra det möjligt för den att utföra mer komplexa operationer.
Utmaningar med Stabila Mynt i Bitcoin-ekosystemet
Hur effektiva är de i Bitcoin-ekosystemet? Stabila mynt har blivit en nyckelkomponent i alla Web3-ekosystem, även sådana som inte är direkt relaterade till DeFi. De möjliggör för användare att säkra sig mot volatilitetens risker och överföra pengar utan att oroa sig för förändringar i tillgångspriser.
Bitcoin-nätverket har alltid sökt en balans mellan funktionell enkelhet och mängden data som kan registreras. Intressant nog uppnåddes det tidigaste försöket att utfärda tillgångar på Bitcoin genom utvecklingen av Colored Coins, vilket är snarlikt NFTs. Så tidigt som 2012 föreslog JR Willett idén att utfärda nya tillgångar på Bitcoin och lade fram konceptet ”colored coins”. Han hjälpte sedan till att skapa Mastercoin-protokollet (senare omdöpt till Omni), vilket lade grunden för tokenisering av tillgångar på Bitcoin (inklusive tokens förankrade i fiat-valutor).
Eftersom det inte finns något direkt ”token” opcode i det standardiserade Bitcoin Script kan utvecklare endast infoga tokenmetadata i transaktionsutgångar med hjälp av OP_RETURN (vilket gör utgången obrukbar och kommer med data). Innan OP_RETURN standardiserades användes till och med multi-signatur-skript som en ”omväg” för att koda data. Bitcoin Script självt kan inte verkställa några tokenregler – reglerna upprätthålls av off-chain-mjukvara som är ansvarig för att tolka Bitcoin-transaktioner.
Protokoll som Colored Coins, Omni Layer (tidigare Mastercoin), Counterparty och Open Assets representerar tokens genom att ”färga vissa satoshis eller UTXOs”. Open Assets-protokollet använder en OP_RETURN-utgång som innehåller metadata som specificerar antal tokens och tillgångs-ID. Grundläggande är att Bitcoin-blockkedjan själv inte är medveten om existensen av ”tokens” – den bearbetar bara data. Giltigheten av tokens (t.ex. utbud, ägande) spåras av externa plånböcker efter att ha tolkat OP_RETURN-datan.
Det är värt att notera att OP_RETURN har en datastorleksgräns. Den standardpolicyn för Bitcoin Core-klienten stipulerar att varje OP_RETURN-utgång högst får innehålla 80 byte godtycklig data. Data som överskrider 80 byte kommer att betraktas som en ”icke-standardtransaktion” och kommer som standard inte att vidarebefordras. Teoretiskt kan en transaktion innehålla flera OP_RETURN-utgångar för att öka mängden medföljande data (upp till 80 byte vardera), men för att förhindra skräpposttransaktioner tillåter Bitcoins nuvarande standardrelaypolicy vanligtvis endast att varje transaktion innehåller en OP_RETURN-utgång.
Denna förmåga att infoga metadata i Bitcoins transaktioner ledde till skapandet av Mastercoin-protokollet 2012, som senare blev kallad Omni. Omni Layer spelade en nyckelroll i den tidiga driften av Tether och blev det underliggande överföringsprotokollet för de första batcherna av USDT-överföringar. Under en period i mitten av 2010-talet var USDT, baserat på Bitcoin (Omni), den mest dominerande stabila myntet på marknaden, särskilt populärt i börser som Bitfinex. Omni-transaktioner är i huvudsak standard Bitcoin-transaktioner med ytterligare metadata. Omni har därefter utvecklat flera olika implementeringskategorier, vilket har skapat sin egen tekniska evolutionsväg.
