Introduksjon
Avsløring: Synspunktene og meningene som uttrykkes her tilhører utelukkende forfatteren og representerer ikke synspunktene til redaksjonen i crypto.news.
Smart Kontraktplattformer og Avgiftsressurser
Hver smart kontraktplattform har en innebygd avgiftsressurs. For eksempel har Ethereum (ETH) ETH, Solana (SOL) har SOL, men med Bitcoin (BTC) blir ting komplisert. Hvis du ønsker å utvikle uttrykksfulle apper, ender du vanligvis opp med å adoptere økonomien til et annet nettverk. På Stacks, for eksempel, betaler du avgifter i STX.
På EVM-stil Bitcoin-lag kan du bli fortalt at BTC fungerer som gass-tokenet, men det er vanligvis en L2-nativ representasjon med EVM-lignende konvensjoner (inkludert 18 desimaler), og du opererer fortsatt innenfor det L2-miljøet. Bitcoin selv har imidlertid allerede et rent avgiftsmarked, hvor brukere byr på blokkplass i sat/vB, og gruvearbeidere prioriterer høyere avgiftssatser.
OpNet: En Løsning for Bitcoin
Med dette i tankene, hva om en smart kontraktsinteraksjon kunne initieres og betales som en vanlig Bitcoin-transaksjon, med avgifter i BTC-termer (uten ekstra gass-token eller fork), mens den smarte delen kjører et annet sted og forblir beviselig knyttet tilbake til Bitcoin? OpNet setter seg som mål å gi et svar.
Bitcoins avgiftsmarked er utmerket til én ting: prising av blokkplass. Du konkurrerer i sat/vB, gruvearbeidere velger de høyeste avgiftssatsene, og nettverket forblir enkelt og motstandsdyktig mot angrep. Det Bitcoin ikke gjør, er å kjøre et generelt utførelsesmiljø hvor kjeden kan måle og ta betalt for vilkårlig beregning.
Begrensninger i Bitcoin Script
Bitcoin Script er bevisst stateless og ikke Turing-komplett, spesifikt uten løkker eller gotos, slik at hver node kan validere skripter forutsigbart uten å åpne døren for ubegrenset beregning. Det er derfor de fleste Bitcoin smart kontrakt-tilnærminger ender opp med å plassere utførelsen på et eget system som kan måle beregning og kjøre et eget avgiftsmarked.
Når du har det separate utførelseslaget, kommer det vanligvis med en egen avgiftsressurs (Stacks, for eksempel, tar betalt i STX). Dette er ikke ideelt, og et system hvor du kunne holde betaling innen Bitcoins native avgiftsmarked mens du flytter utførelsen et annet sted ville vært å foretrekke.
OpNets Design og Interaksjonsmodell
Når du aksepterer at Bitcoin Script er bevisst begrenset (stateless og ikke designet for ubegrenset beregning), begynner du å tenke på hvordan du kan få Bitcoin til å oppgjøre resultatene og betalingene. Faktisk kan utførelsen skje i en dedikert virtuell maskin som er bygget for å kjøre smart kontraktlogikk deterministisk, mens Bitcoin forblir grunnlaget som tidsstempel, ordner og priser interaksjonene gjennom sitt eksisterende avgiftsmarked.
I OpNets design evalueres kontraktslogikken av en Wasm-orientert VM (OP-VM), mens den bredere nodestakken er eksplisitt bygget for å håndtere og utføre smart kontrakter ved hjelp av Bitcoins eksisterende transaksjons- og UTXO-mekanikker. Viktig er det at dette ikke er parret med en ny avgiftsressurs.
Bitcoin trenger ikke å måle beregning for å være gassvalutaen. Det må være det endelige oppgjørslaget som alt til slutt betaler inn i og forankrer til.
Vår interaksjonsmodell følger en simulere-deretter-bruke flyt i stedet for et konvensjonelt smart kontrakt utførelsesmønster, med det endelige utførelsestrinnet som skjer som en faktisk Bitcoin-transaksjon. Først kaller appen din en kontraktmetode i simuleringsmodus. Den forespørselen går gjennom en leverandør til en OPNet-node, som utfører kontrakten i sin VM og returnerer et CallResult (inkludert gass/avgiftsestimater) uten å kringkaste noe til Bitcoin.
Konklusjon
To punkter er verdt å huske: I mellomtiden eksisterer OpNets egen beregningsmåling fortsatt. Men det prises i satoshier (estimert SATS Gas, refusjoner i SATS, osv.), så enheten driver aldri inn i en separat tokenøkonomi. Brukere trenger ikke lenger å adoptere en annen avgiftsøkonomi bare for å samhandle med apper.
På Bitcoin er avgifter allerede en auksjon for blokkplass, priset per byte og betalt til gruvearbeidere. Når kontraktsanrop bare er Bitcoin-transaksjoner, er du tilbake på kjent grunn (med sat/vB avgifter, mempool churn, og miner insentiver), uten å måtte lære et separat gass-tokenmarked.
Også verktøyene leaner inn i standard Bitcoin arbeidsflyter som UTXO-håndtering, leverandørforbindelser, og til og med offline/kald signering. Kontrakter lever i en Wasm-runtime og er skrevet i AssemblyScript, med mål om Solidity-lignende uttrykksmuligheter uten å late som om Bitcoin Script plutselig ble en VM.
Påstanden om at BTC ikke kan fungere som gass hviler vanligvis på antagelsen om at grunnlaget må måle beregning for å prise det. Bitcoin måler ikke beregning; det måler blokkplass og oppgjørsverdi. Løsningen er å la en virtuell maskin håndtere utførelsen deterministisk, og deretter rute hver tilstandsforandrende interaksjon gjennom en standard Bitcoin-transaksjon, hvor avgifter uttrykkes i kjente termer som sat/vB og begrenses i satoshier.
I vårt tilfelle er dette implementert på klientnivå gjennom parametere som feeRate og maximumAllowedSatToSpend. Så kanskje BTC som gass er virkelig plausibelt. Avgifter forblir BTC-naturlige fra ende til ende, mens kontraktskjøringen forblir WebAssembly-basert (AssemblyScript → Wasm), som holder logikken uttrykksfull uten å endre avgiftsvalutaen.
