Upplysning
De åsikter och synpunkter som uttrycks här tillhör enbart författaren och representerar inte åsikterna från crypto.news redaktion.
Avgiftsresurser och Smart Kontrakt
Varje smart kontraktsplattform har en avgiftsresurs inbakad. Till exempel har Ethereum (ETH) ETH, och Solana (SOL) har SOL. Men med Bitcoin (BTC) blir det mer komplicerat. Om du vill ha uttrycksfulla applikationer hamnar du vanligtvis i att anta en andra nätverks ekonomi. På Stacks, till exempel, betalar du avgifter i STX.
På EVM-baserade Bitcoin-lager kan du bli tillsagd att BTC fungerar som gas-token, men det är typiskt en L2-infödd representation med EVM-liknande konventioner (inklusive 18 decimaler), och du arbetar fortfarande inom den L2-miljön. Bitcoin har å sin sida redan en ren avgiftsmarknad, där användare budar på blockutrymme i sat/vB, och gruvarbetare prioriterar högre avgiftsnivåer.
OpNet och Bitcoin
Med detta i åtanke, vad om en smart kontraktsinteraktion kunde initieras och betalas som en vanlig Bitcoin-transaktion, med avgifter i BTC-termer (utan extra gas-token eller fork), medan den smarta delen körs någon annanstans och förblir bevisligen kopplad till Bitcoin? OpNet syftar till att ge ett svar.
Bitcoins avgiftsmarknad är utmärkt på en sak: prissättning av blockutrymme. Du tävlar i sat/vB, gruvarbetare väljer de högsta avgiftsnivåerna, och nätverket förblir enkelt och motståndskraftigt. Vad Bitcoin inte gör är att köra en allmän exekveringsmiljö där kedjan kan mäta och ta betalt för godtycklig beräkning.
Bitcoin Script är avsiktligt stateless och inte Turing-komplett, specifikt utan loopar eller gotos, så varje nod kan validera skript på ett förutsägbart sätt utan att öppna dörren för obegränsad beräkning.
Det är därför de flesta Bitcoin smart kontraktsmetoder hamnar i att placera exekvering på ett separat system som kan mäta beräkning och köra en egen avgiftsmarknad. När du har det separata exekveringslagret kommer det vanligtvis med en separat avgiftsresurs (Stacks, till exempel, tar ut avgifter i STX). Detta är inte idealiskt, och ett system där du kan hålla betalningen inom Bitcoins inhemska avgiftsmarknad medan exekvering flyttas någon annanstans skulle vara att föredra.
Exekvering och Interaktion
När du accepterar att Bitcoin Script är avsiktligt begränsad (stateless och inte designad för obegränsad beräkning), börjar du tänka på hur man får Bitcoin att reglera resultaten och betalningarna. Faktum är att exekvering kan ske i en dedikerad virtuell maskin som är byggd för att köra smart kontraktslogik deterministiskt, medan Bitcoin förblir baslagret som tidsstämplar, ordnar och prissätter interaktionerna genom sin befintliga avgiftsmarknad.
I OpNets design utvärderas kontraktslogik av en Wasm-orienterad VM (OP-VM), medan den bredare nodstacken är explicit byggd för att hantera och exekvera smarta kontrakt med hjälp av Bitcoins befintliga transaktions- och UTXO-mekanik. Avgörande är att detta inte kopplas ihop med en ny avgiftsresurs.
Bitcoin behöver inte mäta beräkning för att vara gasvaluta. Det behöver vara det slutliga avvecklingslagret som allt i slutändan betalar in i och förankrar till. Vår interaktionsmodell följer ett simulera-och-sedan-betala-flöde snarare än ett konventionellt smart kontrakts exekveringsmönster, där det slutliga exekveringssteget äger rum som en faktisk Bitcoin-transaktion.
Sammanfattning
Först anropar din app en kontraktsmetod i simuleringsläge. Den begäran går genom en leverantör till en OPNet-nod, som exekverar kontraktet i sin VM och returnerar en CallResult (inklusive gas-/avgiftsuppskattningar) utan att sända något till Bitcoin. Om anropet förändrar tillståndet tar du den CallResult och skickar den som en exekvering. Vid denna punkt bygger biblioteket en Bitcoin-transaktion, signerar den och sänder den till Bitcoin-nätverket.
Två punkter är värda att komma ihåg: Under tiden finns OpNets egen beräkningsmätning fortfarande kvar. Men den prissätts i satoshis (uppskattad SATS Gas, återbetalningar i SATS, etc.), så enheten glider aldrig in i en separat token-ekonomi. Användare behöver inte längre anta en andra avgifts ekonomi bara för att interagera med appar.
På Bitcoin är avgifter redan en auktion för blockutrymme, prissatta per byte och betalda till gruvarbetare. När kontraktsanrop bara är Bitcoin-transaktioner är du tillbaka på bekant mark (med sat/vB-avgifter, mempool-rörelse och gruvarbetarincitament), utan att behöva lära dig en separat gas-token-marknad.
Dessutom lutar verktygen sig mot standard Bitcoin-arbetsflöden som UTXO-hantering, leverantörsanslutningar och till och med offline/kall signering. Kontrakt lever i en Wasm-runtime och är skrivna i AssemblyScript, med målet att uppnå Solidity-liknande uttrycksfullhet utan att låtsas att Bitcoin Script plötsligt blev en VM.
Påståendet att BTC inte kan fungera som gas vilar vanligtvis på antagandet att baslagret måste mäta beräkning för att prissätta det. Bitcoin mäter inte beräkning; det mäter blockutrymme och reglerar värde. Lösningen är att låta en virtuell maskin hantera exekvering deterministiskt, och sedan styra varje tillståndsförändrande interaktion genom en standard Bitcoin-transaktion, där avgifter uttrycks i bekanta termer som sat/vB och begränsas i satoshis.
I vårt fall implementeras detta på klientnivå genom parametrar som feeRate och maximumAllowedSatToSpend. Så kanske BTC som gas verkligen är plausibelt. Avgifter förblir BTC-infödda från början till slut, medan kontraktsruntime förblir WebAssembly-baserad (AssemblyScript → Wasm), vilket håller logiken uttrycksfull utan att ändra avgiftsvalutan.
Frederic Fosco
