Offentliggørelse
De synspunkter og meninger, der udtrykkes her, tilhører udelukkende forfatteren og repræsenterer ikke synspunkterne fra crypto.news’ redaktion.
Smart Kontraktplatforme og Gebyrer
Hver smart kontraktplatform har et indbygget gebyraktiv. For eksempel har Ethereum (ETH) ETH, Solana (SOL) har SOL, men med Bitcoin (BTC) bliver tingene mere komplicerede. Hvis du ønsker at udvikle udtryksfulde apps, ender du ofte med at adoptere en anden netværksøkonomi. På Stacks, for eksempel, betaler du gebyrer i STX.
På EVM-baserede Bitcoin-lag kan du blive informeret om, at BTC fungerer som gas-tokenet, men det er typisk en L2-nativ repræsentation med EVM-lignende konventioner (inklusive 18 decimaler), og du opererer stadig inden for det L2-miljø.
Bitcoin’s Gebyrmarked
Bitcoin har imidlertid allerede et velfungerende gebyrmarked, hvor brugere byder på blokplads i sat/vB, og minearbejdere prioriterer højere gebyrsatser. Med dette in mente, hvad nu hvis en smart kontraktinteraktion kunne initieres og betales som en normal Bitcoin-transaktion, med gebyrer i BTC-termer (uden ekstra gas-token eller fork), mens den smarte del kører et andet sted og forbliver beviseligt knyttet til Bitcoin? OpNet sigter mod at give et svar.
Udførelseslag og Gebyrer
Bitcoins gebyrmarked er fremragende til én ting: prissætning af blokplads. Du konkurrerer i sat/vB, minearbejdere vælger de højeste gebyrsatser, og netværket forbliver simpelt og modstandsdygtigt over for angreb. Hvad Bitcoin ikke gør, er at køre et generelt udførelsesmiljø, hvor kæden kan måle og opkræve for vilkårlig beregning. Bitcoin Script er bevidst stateless og ikke Turing-komplet, specifikt uden loops eller gotos, så hver node kan validere scripts forudsigeligt uden at åbne døren for ubegribelig beregning.
Derfor ender de fleste Bitcoin smart kontraktmetoder med at placere udførelsen på et separat system, der kan måle beregning og køre et eget gebyrmarked. Når du har det separate udførelseslag, kommer det normalt med et separat gebyraktiv (Stacks opkræver for eksempel gebyrer i STX). Dette er ikke ideelt, og et system, hvor du kunne holde betalingen inden for Bitcoins native gebyrmarked, mens du flytter udførelsen et andet sted, ville være at foretrække.
OpNets Design
Når du accepterer, at Bitcoin Script er bevidst begrænset (stateless og ikke designet til ubegribelig beregning), begynder du at tænke på, hvordan man får Bitcoin til at afregne resultaterne og betalingerne. Faktisk kan udførelsen finde sted i en dedikeret virtuel maskine, der er bygget til at køre smart kontraktlogik deterministisk, mens Bitcoin forbliver basislaget, der tidsstemper, ordner og prissætter interaktionerne gennem sit eksisterende gebyrmarked.
I OpNets design evalueres kontraktlogik af en Wasm-orienteret VM (OP-VM), mens den bredere node-stak er eksplicit bygget til at administrere og udføre smart kontrakter ved hjælp af Bitcoins eksisterende transaktions- og UTXO-mekanik. Vigtigt er det, at dette ikke er parret med et nyt gebyraktiv. Bitcoin behøver ikke at måle beregning for at være gasvaluta. Det skal være det endelige afregningslag, som alt i sidste ende betaler ind i og forankrer til.
Interaktionsmodel
Vores interaktionsmodel følger et simulere-så-brug-flow snarere end et konventionelt smart kontraktudførelsesmønster, hvor det sidste udførelsestrin finder sted som en faktisk Bitcoin-transaktion. Først kalder din app en kontraktmetode i simuleringsmode. Den anmodning går gennem en udbyder til en OPNet-node, som udfører kontrakten i sin VM og returnerer et CallResult (inklusive gas-/gebyrestimater) uden at sende noget til Bitcoin.
Hvis opkaldet ændrer tilstanden, tager du det CallResult og sender det som en udførelse. På dette tidspunkt bygger biblioteket en Bitcoin-transaktion, underskriver den og sender den til Bitcoin-netværket. To punkter er værd at huske: I mellemtiden eksisterer OpNets egen beregningsmåling stadig. Men det prissættes i satoshis (estimeret SATS Gas, refusioner i SATS osv.), så enheden driver aldrig ind i en separat tokenøkonomi.
Konklusion
Brugere behøver ikke længere at adoptere en anden gebyrøkonomi bare for at interagere med apps. På Bitcoin er gebyrer allerede en auktion for blokplads, prissat pr. byte og betalt til minearbejdere. Når kontraktopkald blot er Bitcoin-transaktioner, er du tilbage på velkendt grund (med sat/vB-gebyrer, mempool-churn og minearbejderincitamenter), uden at skulle lære et separat gas-tokenmarked.
Desuden læner værktøjerne sig ind i standard Bitcoin-arbejdsgange som UTXO-håndtering, udbyderforbindelser og endda offline/kold underskrift. Kontrakter lever i et Wasm-runtime og er skrevet i AssemblyScript, med det mål at opnå Solidity-lignende udtryksfuldhed uden at lade som om Bitcoin Script pludselig blev en VM.
Påstanden om, at BTC ikke kan fungere som gas, hviler normalt på antagelsen om, at basislaget skal måle beregning for at prissætte det. Bitcoin måler ikke beregning; det måler blokplads og afregner værdi. Løsningen er at lade en virtuel maskine håndtere udførelsen deterministisk og derefter rute hver tilstandsændrende interaktion gennem en standard Bitcoin-transaktion, hvor gebyrer udtrykkes i velkendte termer som sat/vB og begrænses i satoshis.
I vores tilfælde implementeres dette på klientniveau gennem parametre som feeRate og maximumAllowedSatToSpend. Så måske er BTC som gas virkelig plausibel. Gebyrer forbliver BTC-native fra ende til ende, mens kontrakt-runtime forbliver WebAssembly-baseret (AssemblyScript → Wasm), hvilket holder logikken udtryksfuld uden at ændre gebyrvalutaen.
Frederic Fosco
