SigVM: Toward Fully Autonomous Smart Contracts
SSigVM: Toward Fully Autonomous Smart Contracts
Ryan Song ∗ [email protected] University of Toronto
Zihan Zhao ∗ [email protected] University of Toronto
Yuxi Cai [email protected]
University of Toronto
Andreas Veneris [email protected]
University of Toronto
Fan Long [email protected]
University of Toronto
Abstract
This paper presents SigVM, a novel blockchain virtual ma-chine that supports an event-driven execution model, en-abling developers to build fully autonomous smart contracts.SigVM introduces another way for contracts to interact witheach other. Contracts in SigVM can emit signal events, onwhich other contracts can listen. Once an event is triggered,corresponding handler functions are automatically executedas signal transactions. We built an end-to-end blockchainplatform SigChain and a contract language compiler SigSolidto realize the potential of SigVM. Experimental results showthat SigVM enables contracts in our benchmark applicationsto be reimplemented in a fully autonomous way, eliminatingthe dependency on unreliable mechanisms like off-chain re-lay servers. SigVM can significantly simplify the executionflow of our benchmark applications and can avoid securityrisks such as relay manipulation attacks.
Blockchain has become a revolutionary technology that pow-ers decentralized ledgers at internet-scale. The capability ofprocessing smart contracts is one of the most important fea-tures in many blockchain platforms. A smart contract is aprogram operating on the blockchain ledger to encode cus-tomized transaction rules. Once deployed, the contract andthe encoded rules are then faithfully executed and enforcedby all participants of the blockchain platform, eliminatingany potential counter-party risks in the future.Despite the ambitious goal of enabling decentralized au-tonomous entities that can execute arbitrarily complex trans-action rules, smart contracts currently have a very limitedexecution model. For example, in Ethereum [7], the most pop-ular blockchain for smart contracts, the contract executionstarts from a function invoked by an external transactionfrom a blockchain user and the interactions between con-tracts are limited to only function calls. Under this model, itis not possible to develop a contract with automatic timerevents to periodically execute certain logic (e.g. sending afixed amount of digital assets each time), not to mentiontruly autonomous contracts. ∗ The first two authors have equal contribution
As smart contracts on blockchains become more and morecomplicated and inter-dependent, this execution model prob-lem exacerbates. For example, in Ethereum, there are oraclecontracts [8, 30], which feed off-chain data to the blockchain;there are also decentralized finance (DeFi) smart contracts [15,20, 27], for which the most recent price of a digital asset iscritical, e.g., collateral liquidation is required when the assetprice passes a certain threshold. However, in the currentexecution model, it is unnatural to execute a DeFi contractbased on asset price changes. The oracle contract typicallycannot directly call the DeFi contract because 1) they aredeveloped and maintained by different parties, 2) the oraclecontract is not aware of the DeFi contract, and/or 3) the ora-cle maintainers are not obligated to pay transaction fees forexecuting the DeFi contract.To this end, many smart contracts circumvent this problemvia off-chain relay servers . Such a server constantly monitorsthe blockchain ledger. When a critical event from a sourcecontract (e.g., the oracle contract) occurs, the server will senda poke transaction to a target contract (e.g., the DeFi contract)so to respond to the event. However, this solution has twosevere security consequences. First, it creates a central pointof failure that defeats the purpose of encoding transactionrules as smart contracts in the first place. Secondly, the poketransaction may not be packed in a block in time, creatinga chance for malicious relay manipulation to exploit the re-sponding contracts. On March 12 2020, in MakerDAO, one ofthe largest DeFi contracts on Etheruem [16], its price oraclefailed to update price feed due to network congestion andthe fact that off-chain relay servers pushed the price feedexacerbated the delay during the market collapse. Meantime,malicious relay manipulation took advantage of server de-lay variance, contributing to a financial loss of $4.5M forMakerDAO users.
SigVM:
We present SigVM, a novel virtual machine that sup-ports an event-driven execution model that enables develop-ers to build fully autonomous smart contracts. In additionto standard function calls, SigVM introduces another wayfor contracts to interact with each other. Contracts in SigVMcan emit signal events, on which other contracts can listen.When a contract wants to listen to a signal event, it bindsa function as its handler and a non-negative integer as thedesired delay for the handler execution in number of blocks. a r X i v : . [ c s . P L ] F e b onference’21, June 2021, Virtual Conference When the event is triggered, the handler function will beautomatically executed after the specified delay.We developed SigChain, an end-to-end prototype blockchainplatform that supports SigVM on top of standard EthereumVirtual Machine (EVM) opcodes. We also develop SigSolid,a modified version of Solidity programming language thatcan utilize the potential of SigVM.One important design decision is that, instead of naivelyexecuting these handler functions immediately, SigVM exe-cutes them asynchronously and separately as signal transac-tions , a special kind of transactions generated by the SigVMexecution engine when a signal event is emitted. These spe-cial transactions will be packed along with normal transac-tions in future blocks. They come with slightly higher buttunable transaction fees, which incentivizes miners to packthem as soon as possible.The signal transaction design has several important bene-fits. First, individual handler functions triggered by one eventare asynchronously executed in separated transactions sothat they do not interfere with each other in unintendedways. Secondly, the design enables SigVM to charge the costof signal transactions from the listener contracts instead ofthe initiator of the signal. This is more incentive compati-ble as the listener contracts are the service users. Thirdly,the design allows customized delay for handler execution.This makes implementing timer events in smart contractsstraightforward. Last but not least, this design enables SigVMto use the transaction fee mechanism to address the potentialtermination problem caused by event-handler recursions.One challenge SigVM faces is the possibility of manipu-lation attacks against signal transactions. Because a signaltransaction is packed along with normal transactions, a ma-licious miner may attempt to submit a normal transactionwith an extremely high transaction fee to front-run the sig-nal transaction. SigVM addresses this challenge with a novel contract event lock mechanism. If a contract has any pendingsignal transactions, SigVM will lock the contract. Any trans-actions interacting with a locked contract become no-ops.The miner who packs the transaction will get no reward andthe transaction may be packed again in the future when thepending signal transactions are processed and the contractis unlocked. This mechanism effectively stops any manipu-lation transactions from exploiting a contract in the middleof signal transaction handling.
Experimental Results:
We evaluate SigVM with five bench-mark contracts from three popular decentralized applicationsthat are critical to the economic ecosystem of Ethereum. Wereimplemented these contracts in SigVM. Our results showthat with the event-driven execution model in SigVM, thesenew contracts no longer depend on off-chain relay serversand therefore are not exposed to any malicious relay manip-ulations. Our results also show that the SigSolid languagepowered by SigVM is expressive and easy to use. The devel-opment effort of implementing these contracts in SigVM is moderate, i.e., we modified on average 4.3% of the contractcode.
Contributions:
This paper makes the following contribu-tions: • SigVM:
This paper presents SigVM, the first blockchainvirtual machine that supports event-driven executionmodel to enable secure and fully autonomous smartcontracts. • Signal Transaction and Contract Event Lock:
Thispaper proposes the novel signal transaction mechanismto address the series of challenges of integrating SigVMwith a blockchain platform. This paper also presentsthe novel contract event lock mechanism to preventmanipulation attacks against signal transactions. • Implementation and Results:
This paper describesan end-to-end prototype blockchain platform poweredby SigVM and an evaluation of five popular smart con-tract applications on this platform. Our results showthat SigVM enables the development of significantlymore autonomous and secure contracts.The rest of this paper is organized as follows. Section 2presents a motivating example of developing smart contractsin SigVM. Section 3 presents the design of SigVM. Section 4discusses the implementation challenges of our end-to-endprototype blockchain platform that supports SigVM. Weevaluate SigVM in Section 5. We discuss related work inSection 6 and finally conclude in Section 7.
We next present a motivating example to illustrate howto use SigVM to build fully autonomous contracts. Listing 1presents the simplified code snippet of MakderDAO. Linespreceded with "-" and "+" are changes we made to the orig-inal implementation to adopt SigSolid, our modified Solid-ity language that supports SigVM opcodes. MakerDAO isa decentralized platform, which provides collateral-backedstablecoin called Dai [15]. It follows the Maker Protocol tokeep Dai softly pegged to USD by a fixed ratio. This is ac-complished by backing Dai with crypto assets based on themarket prices. In order to generate Dai, users send collat-eral to the Collateralized Debt Position smart contract tocreate a vault. To meet the long-term solvency of the system,the ratio between the deposit to the vault and the Dai thevault owner obtains must be greater than a ratio decided bya MakerDAO governance committee at all time. Once theratio drops below the set ratio, the Maker Protocol forcesthe collateral to be liquidated.
MakerDAO Oracle Components:
There are three smartcontracts in Listing 1,
Median , OSM , and
Spotter . Median is the oracle contract that maintains the spot price of onedigital asset type. A group of authorized maintainers sendbatched transactions via the feed() function to report thereal world spot price (see line 8 in Listing 1). The function igVM: Toward Fully Autonomous Smart Contracts Conference’21, June 2021, Virtual Conference contract Median { uint256 val; //The price // Peek to get current price of a digital asset function peek () public view returns ( uint256 , bool ) { return (val , val > 0);} // Signal event for price updates + signal PriceFeed(uint256 , bool); // Feed to set current price of a digital asset function feed( uint256 [] val_ , uint8 [] v, bytes32 [] r, bytes32 [] s) public { // Check the signature info in r, s, v ... val = computeMedian(val_); // Emit PriceFeed to OSM + PriceFeed.emit(val , val > 0).delay (0); } ... } contract OSM { struct Feed { uint256 val; bool has; } Feed cur , nxt; // Obtained prices uint64 zzz; // Last price feed block number // Spotter call peek to acquire price feed - function peek () public view returns(uint256 ,bool) - { return (cur.val , cur.has); } // Signal event for the delayed price update + signal DelayedPrice(uint256 , address) // Poke to update price from Median - function poke () public { // Handler function to receive price from Median + function price_update(uint256 wut , bool ok) handler { - require(block.timestamp >= zzz + ONE_HOUR); - // peek current price - (uint256 wut ,bool ok)=Median(median).peek (); if (ok) { - cur = nxt;nxt = Feed(wut , true); - zzz = uint64(block.timestamp - - (block.timestamp % ONE_HOUR)); + DelayedPrice.emit(wut , this.address) + .delay(ONE_HOUR); } } constructor ( address median , ...) public { // Handler SendUpdate binds to signal PriceFeed + price_update.bind(median ,Median.PriceFeed ,0.1); // Other initialization statements ...} } interface VatLike { function notify( bytes32 , uint ) external ; } contract Spotter { // Main MakerDAO Engine VatLike public vat; // Maps OSM addresses to asset type hashes mapping ( address => byte32) asset_map; // Poke to update price for one asset type - function poke(address osm) public { // Handler function to receive price from OSM + function price_update(uint256 data , address osm) + handler { - (bytes32 val , bool has) = OSM(osm).peek (); - if (has) { vat.notify(asset_map(osm), val); - } } constructor ( address osm0 , address osm1 , ...) public { // Bind handlers to the signal PriceFeed from OSMs. + price_update.bind(osm0 ,OSM.DelayedPrice ,0.1); + price_update.bind(osm1 ,OSM.DelayedPrice ,0.1); // Other initialization statements ... }... } Listing 1.
Simplied Code Snippet of MakerDAO
Median
OSMSpot
Smart Contracts OracleMaintainer
1. Update price2. Request forPrice Update3. Read andupdate price iftime constraintis met 4. Request forPrice Update5. Read and up-date price call call result
Off-ChainRelayServers poking
Figure 1.
Overview of smart contracts and user interactionin MakerDAO OSM module.computes the median of the reported price as the oracle spotprice. Anyone on the blockchain can access the latest oracleprice via the peek() function (see line 4).
OSM is the acronym of Oracle Security Module. OSM de-lays the price obtained from
Median by an hour. Based onthe MakerDAO documentation, this is to allow an emer-gency committee to supervise the oracle prices. In case ofa emergency, the committee may pause the price feed andthe MakerDAO system via administrative interfaces (omit-ted in the code snippet).
Spotter is a contract that collectsspot prices from multiple
OSM contracts for different kinds ofdigital asset colaterals.
Spotter eventually invokes the coreMakerDAO engine to notify the price change at line 59.
Off-chain Relay Server Poking:
It is not feasible to im-plement this price information propagation fully on chainvia function calls because
Median , OSM , and
Spotter aregoverned by different groups of people and
OSM needs tointroduce a one-hour delay to the price feed.To this end, MakerDAO implementation relies on off-chainrelay servers to drive the price information flow. Figure 1presents an illustration of the interaction between off-chainservers and the contracts. The off-chain relay servers areexpected to call poke() in OSM (see line 27) for each digitalasset every one hour to extract the price from the
Median contracts. They are also expected to call poke() in Spotter (see line 53) frequently to feed the price information to thecore engine.
Security Risks and Loss:
Knowing a reasonably accurateprice for its underlying digital assets is critical for the securityof MakerDAO contracts. If the off-chain relay server failsor if the network is congested so that poke transactions arenot processed in time, the core MakerDAO engine wouldoperate with outdated price information and make incorrectliquidation decisions. onference’21, June 2021, Virtual Conference On March 12 2020, the price of crypto currencies droppedsignificantly. Meanwhile, the Ethereum network becameoverwhelmed with too many transactions. Critical poketransactions containing price information were delayed, caus-ing the core MakerDAO engine to operate with stale pricesfor hours. As a result, many MakerDAO users had their po-sitions liquidated while getting much less collateral backcomparing to the amount they should have retained with thecorrect prices. Even after the prices returned to the requiredlevel, the collateral was auctioned because of delayed priceupdate. The total financial loss of MakerDAO users duringthis event is approximately $4.5M [16].
SigSolid Powered by SigVM:
We next show how to imple-ment the oracle components of MakerDAO in SigSolid, ourmodified Solidity language that can utilize special SigVMopcodes for an event-driven execution model.SigSolid allows a contract to define its signal events viathe “ signal " keyword (e.g., line 6 in Listing 1). The contractcan emit defined events during its execution together withattached event data and a customized delay number (e.g.,line 13). SigSolid also introduces a new function modifier“ handler ”. These functions with “ handler ” are signal han-dler functions that can be bound to signal events (e.g., lines29 and 42). Once bound, handler functions will be invokedas a separate signal transaction with the customized datasupplied by the event as parameters.Note that the third parameter of a “ bind ” statement is apositive float number as a fraction of the additional gas pricethe contract is willing to pay. For example, 0 . Implementation of Median, OSM, and Spotter in Sig-Solid:
To implement the desired price information flow, wedefine one signal event in
Median (line 6 in Listing 1) and onesignal event in
OSM (line 25). Instead of passively waiting forother contracts to call peek() , Median emits the
PriceFeed event whenever there is a valid batch of oracle price updates(line 13). This event is automatically handled by the func-tion in
OSM at line 29, which in turn emits a
DelayedPrice event with a delay of one hour. The emitted
DelayedPrice event will be eventually handled by the price_update() function at line 55 in
Spotter . Spotter then notifies thecore MakerDAO engine with the new price information.Listing 1 highlights the advantages of SigVM. It no longeruses the unreliable poking mechanism and it eliminates theoff-chain relay servers from the picture. The execution modelof SigVM guarantees that the core MakerDAO engine operatewith the most recent one-hour delayed prices reported bythe oracle maintainers. The code snippet also highlights theexpressiveness of SigSolid. Challenging features like timedelays can be implemented in SigSolid in a straightforwardway. 𝐼 ∈ 𝐼𝑛𝑠𝑡 :: = pop | push 𝑎 | dup | swap | load | store | add | jump | stop | createsignal | deletesignal | emit | bind | detach 𝑃 ∈ 𝑃𝑟𝑜𝑔𝑟𝑎𝑚 :: = pc ↦→ 𝐼𝜇 ∈ 𝐸𝑥𝑒𝑐𝐸𝑛𝑣𝑖𝑟𝑜𝑛𝑚𝑒𝑛𝑡 :: = ⟨ pc , 𝐺, gas , addr , 𝑆, 𝑀, 𝑅, 𝐸 ⟩ 𝑆 ∈ 𝑆𝑡𝑎𝑐𝑘 :: = 𝑥 ◦ 𝑥 ◦ . . . ◦ 𝑥 𝑛 𝑀 ∈ 𝑆𝑡𝑜𝑟𝑎𝑔𝑒𝑀𝑎𝑝 :: = 𝑎 ↦→ 𝑥𝑅 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑅𝑒𝑐𝑜𝑟𝑑𝑀𝑎𝑝 :: = 𝑘 ↦→ 𝐻𝑘 ∈ 𝐾𝑒𝑦 :: = ⟨ addr , 𝑎 ⟩ 𝐻 ∈ 𝐻𝑎𝑛𝑑𝑙𝑒𝑟𝑅𝑒𝑐𝑜𝑟𝑑𝑆𝑒𝑡 :: = { ℎ , ℎ , . . . } ℎ 𝑖 ∈ 𝐻𝑎𝑛𝑑𝑙𝑒𝑟𝑅𝑒𝑐𝑜𝑟𝑑 :: = ⟨ addr , pc , 𝑔 ⟩ 𝐸 ∈ 𝐸𝑚𝑖𝑡𝑆𝑖𝑔𝑛𝑎𝑙𝑆𝑒𝑡 :: = { 𝑒 , 𝑒 , . . . } 𝑒 𝑖 ∈ 𝐸𝑚𝑖𝑡𝑆𝑖𝑔𝑛𝑎𝑙𝑅𝑒𝑐𝑜𝑟𝑑 :: = ⟨ 𝑘, 𝑆, 𝑙, pc , 𝑔 ⟩ addr , 𝐺, pc , gas , 𝑎, 𝑏, 𝑦, 𝑧, 𝑔, 𝑙, 𝑥 𝑖 ∈ N Figure 2.
Core Language Syntax of SigVM 𝐵 ∈ 𝐵𝑙𝑜𝑐𝑘 :: = ⟨ height ,𝑇, 𝑈 , 𝑉 ⟩ 𝑇 ∈ 𝐶𝑟𝑒𝑎𝑡𝑒𝑇𝑥𝑆𝑒𝑡 :: { 𝑡 , 𝑡 , . . . } 𝑡 𝑖 ∈ 𝐶𝑟𝑒𝑎𝑡𝑒𝑇𝑥 :: = ⟨ addr , 𝑠, 𝑛, 𝑏, 𝐶 ⟩ 𝑈 ∈ 𝑅𝑒𝑔𝑢𝑙𝑎𝑟𝑇𝑥𝑆𝑒𝑡 :: = { 𝑢 , 𝑢 , . . . } 𝑢 𝑖 ∈ 𝑅𝑒𝑔𝑢𝑙𝑎𝑟𝑇𝑥 :: = ⟨ 𝑠, addr , 𝑛, 𝑏, pc , 𝑆 ⟩ 𝑉 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥𝑆𝑒𝑡 :: = { 𝑣 , 𝑣 , . . . } 𝑣 𝑖 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥 :: = ⟨ height , addr , pc , 𝑔, 𝑆 ⟩ 𝜎 ∈ 𝐵𝑙𝑜𝑐𝑘𝑐ℎ𝑎𝑖𝑛𝑆𝑡𝑎𝑡𝑒 :: = ⟨ height , 𝐵, 𝑅, 𝑄, 𝐴, 𝑁 ⟩ 𝑄 ∈ 𝑇𝑥𝑄𝑢𝑒𝑢𝑒𝑀𝑎𝑝 :: = height ↦→ 𝐿𝐿 ∈ 𝑇𝑥𝑄𝑢𝑒𝑢𝑒 :: = 𝑣 ◦ 𝑣 . . . ◦ 𝑣 𝑛 𝐴 ∈ 𝐴𝑐𝑐𝑜𝑢𝑛𝑡𝑆𝑡𝑎𝑡𝑒𝑀𝑎𝑝 :: = addr ↦→ 𝐷𝐷 ∈ 𝑆𝑡𝑎𝑡𝑒𝑅𝑒𝑐𝑜𝑟𝑑 :: = ⟨ 𝑀, 𝐿, 𝑃 ⟩ 𝑁 ∈ 𝐴𝑐𝑐𝑜𝑢𝑛𝑡𝑁𝑜𝑛𝑐𝑒𝑀𝑎𝑝 :: = addr ↦→ 𝐹𝐹 ∈ 𝐵𝑎𝑙𝑎𝑛𝑐𝑒𝑅𝑒𝑐𝑜𝑟𝑑 :: = ⟨ 𝑛, 𝑏 ⟩ height , 𝑠, 𝑛 ∈ N Figure 3.
Block, Transaction, and Blockchain State Syntax
This section formalizes the design of SigVM. Similar to othersmart contract virtual machines like EVM [7], SigVM con-tains two layers, the virtual machine execution layer thatdictates how SigVM executes a transaction and the block pro-cessing layer that dictates how the blockchain state evolvesover multiple transactions in a block.
Figure 2 presents the core language that we use in this sectionto illustrate the design of SigVM. It is a stack-based virtualmachine language similar to EVM. The first four opcodes pop , push , dup , and swap are common stack manipulationoperations. The two storage operations, load and store , fa-cilitate read and write operations to an accounts individual igVM: Toward Fully Autonomous Smart Contracts Conference’21, June 2021, Virtual Conference storage, which is a simple key-value map. For completeness,we include add for addition, jump for program counter ma-nipulation, and stop for program termination.In addition to the above standard opcodes, SigVM pro-vides the createsignal , deletesignal , bind , detach , and emit opcodes to enable an event-driven execution model.The createsignal and deletesignal opcodes handle sig-nal event creation and deletion. Signals are represented bykeys, which are composed of an account address and an in-teger identifier. SigVM keeps track of signal event creationsand deletions with a map in the execution environment. Theopcodes bind and detach allow handler functions to inter-act with signal events. The bind opcode attaches a handlerfunction to a signal event while detach removes a handlerfunction from an event. Finally, the emit opcode emits sig-nal events. When a signal event is emitted, special signaltransactions that execute the corresponding handlers arecreated.Although the language is simplified in many aspects forbrevity, it is enough to illustrate the main ideas of SigVM.For example, the language assumes all primitive values are32-byte integers (i.e., N ). The language has only the add opcode for arithmetic operations, but it is straightforwardto introduce more. The language contains no inter-contractcall opcode, but our prototype implementation of SigVMactually supports all EVM-style contract call opcodes (seeSection 4.3). The execution environment ofSigVM is represented by 𝜇 = ⟨ pc , 𝐺, gas , addr , 𝑆, 𝑀, 𝑅, 𝐸 ⟩ ,where pc is the program counter, 𝐺 is the gas price, gas is the gas counter, addr is the current executing accountaddress, 𝑆 is the stack, 𝑀 is the persistent storage, 𝑅 is thesignal record map, and 𝐸 is the emit signal set. The signalrecord map 𝑅 keeps track of all existing signals as well aswhich handlers are bound to each signal. A signal with key 𝑘 exists only if 𝑘 ∈ 𝑅 . The emit signal set 𝐸 tracks all createdsignal transactions during execution. For the simplicity ofour notation, 𝐸 is a set here. But in SigVM, 𝐸 is a list and ithas to track the order in which signals are emitted. Small Step Semantics:
Figure 4 presents the small stepsemantics for SigVM opcodes. The notation 𝜇 = ⟦ inst ⟧⇒ 𝜇 ′ represents the state transition of 𝜇 to 𝜇 ′ after executingoperation inst . The first nine opcodes are straightforwardand perform basic stack, storage, arithmetic, and programcounter operations. For example, load takes a storage key 𝑥 off the stack and pushes 𝑀 ( 𝑥 ) onto the stack. Likewise, store takes 𝑥 ◦ 𝑦 off the stack and sets 𝑀 ( 𝑥 ) → 𝑦 . The restof the opcodes warrant more discussion as they relate tosignals and handlers.The createsignal opcode takes value 𝑎 as input andcreates a signal key 𝑘 . If a signal with key 𝑘 does not yet existin the signal record map 𝑅 , an empty entry in 𝑅 is created (rule 10 in Figure 4). For completeness, the deletesignal opcode deletes entry 𝑅 ( 𝑘 ) if it exists (rule 12). The executionfailure cases are also shown. If we try creating a new signalwith key 𝑘 but a 𝑘 already exists in 𝑅 , then execution fails(rule 11). Likewise, if signal 𝑘 does not exist, then trying todelete signal 𝑘 halts execution (rule 13). The bind opcodeallows handlers to append an entry onto the list 𝑅 ( 𝑘 ) , where 𝑘 is the key of the signal listened to by the handler (rule14). Stack inputs for bind describe the signal to listen to (i.e., addr ′ and 𝑎 ) as well as information on the handler such asthe handler function entry point (i.e., pc ′ ), and gas incentive(i.e., 𝑔 ). Similar to bind , detach also manipulates entriesof 𝑅 ( 𝑘 ) . Given a signal key 𝑘 and the handler entry point, detach removes all instances of the specified handler from 𝑅 ( 𝑘 ) (rule 16). Both the bind and detach operation fail if thesignal 𝑘 does not exist (rules 15 and 17). Lastly, the emit opcode takes a signal 𝑘 and creates a signal transaction foreach of the handlers found in 𝑅 ( 𝑘 ) (rule 18). It pushes thesecreated signal transactions into 𝐸 , which will be eventuallyprocessed by SigVM after the transaction (see Section 3.3). Ifsignal 𝑘 does not exist, then execution of emit fails (rule 19).Note that for brevity the rules in Figure 4 are simplifiedin the following aspects. The rules assume every opcode hasthe same gas cost of 𝐺 , while in Ethereum and our imple-mentation, different opcodes can charge different amountsof gas. We also omit the rules that check the current usedgas against the limit to terminate execution early. This is thestandard practice in Ethereum to address the terminationproblem and our prototype implementation uses the samepractice as well. SigVM executes three kinds of trans-actions: create transactions, regular transactions, and signaltransactions. The create transaction creates a new accountand transfers balance. The regular transaction executes smartcontract code and transfers balance. Finally, the signal trans-action is a special transaction generated by signal emits inprevious blocks. Signal transactions do not transfer balance.
Blockchain State:
The blockchain state of SigVM is rep-resented by 𝜎 :: = ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ where height is blockheight, 𝑅 is signal record map, 𝑄 is transaction queue map, 𝐴 is account state map, and 𝑁 is account nonce map. Eachaccount in 𝐴 is represented by ⟨ 𝑀, 𝐿, 𝑃 ⟩ , where 𝑀 is the stor-age, 𝐿 is the list of pending signal transactions, and 𝑃 is thecontract code. Each entry in 𝑁 contains a nonce and a bal-ance value. To enforce delayed signal emission, 𝑄 maps blockheight to a queue of signal transactions. When a block height x is reached, each signal transaction in 𝑄 ( x ) is dequeued andsent to their respective account signal transaction queues,where they are then ready to be executed (see Algorithm 2). Transaction Execution Rules:
Figure 5 presents the trans-action execution rules. Note that we use the notation 𝜇 = ⟦ onference’21, June 2021, Virtual Conference ⟨ addr , 𝐺, pc , gas , 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ pop ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ push 𝑥 ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ dup ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑥 ◦ 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑥 ◦ 𝑦 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ swap ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝐺, 𝑦 ◦ 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ load ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑀 ( 𝑥 ) ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑦 ◦ 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ store ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀 [ 𝑥 ↦→ 𝑦 ] , 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑦 ◦ 𝑥 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ add ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, ( 𝑥 + 𝑦 ) ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑝𝑐 ′ ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ jump ⟧⇒ ⟨ addr , 𝐺, 𝑝𝑐 ′ , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩⟨ addr , 𝐺, pc , gas , 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ stop ⟧⇒ ⟨ addr , 𝐺, nil , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩ 𝑘 = ⟨ addr , 𝑎 ⟩ 𝑘 ∉ 𝑅 ⟨ addr , 𝐺, pc , gas , 𝑎 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ createsignal ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀, 𝑅 [ 𝑘 ↦→ ∅] , 𝐸 ⟩ 𝑘 = ⟨ addr , 𝑎 ⟩ 𝑘 ∈ 𝑅 ⟨ addr , 𝐺, pc , gas , 𝑎 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ createsignal ⟧⇒ ⟨ addr , 𝐺, err , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩ 𝑘 = ⟨ addr , 𝑎 ⟩ 𝑘 ∈ 𝑅 ⟨ addr , 𝐺, pc , gas , 𝑎 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ deletesignal ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀, 𝑅 [ 𝑘 ↦→ nil ] , 𝐸 ⟩ 𝑘 = ⟨ addr , 𝑎 ⟩ 𝑘 ∉ 𝑅 ⟨ addr , 𝐺, pc , gas , 𝑎 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ deletesignal ⟧⇒ ⟨ addr , 𝐺, err , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩ 𝑘 = ⟨ addr ′ , 𝑎 ⟩ 𝑘 ∈ 𝑅 𝐻 = 𝑅 ( 𝑘 ) 𝐻 ′ = 𝐻 ∪ {⟨ addr , pc ′ , 𝑔 ⟩}⟨ addr , 𝐺, pc , gas , 𝑔 ◦ pc ′ ◦ 𝑎 ◦ addr ′ ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ bind ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀, 𝑅 [ 𝑘 ↦→ 𝐻 ′ ] , 𝐸 ⟩ 𝑘 = ⟨ addr ′ , 𝑎 ⟩ 𝑘 ∉ 𝑅 ⟨ addr , 𝐺, pc , gas , 𝑔 ◦ pc ′ ◦ 𝑎 ◦ addr ′ ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ bind ⟧⇒ ⟨ addr , 𝐺, err , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩ 𝑘 = ⟨ addr ′ , 𝑎 ⟩ 𝑘 ∈ 𝑅 𝐻 = 𝑅 ( 𝑘 ) 𝐻 ′ = 𝐻 \ {⟨ addr , pc ′ , 𝑔 ⟩ | 𝑔 ∈ N }⟨ addr , 𝐺, pc , gas , pc ′ ◦ 𝑎 ◦ addr ′ ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ detach ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀, 𝑅 [ 𝑘 ↦→ 𝐻 ′ ] , 𝐸 ⟩ 𝑘 = ⟨ addr ′ , 𝑎 ⟩ 𝑘 ∉ 𝑅 ⟨ addr , 𝐺, pc , gas , pc ′ ◦ 𝑎 ◦ addr ′ ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ detach ⟧⇒ ⟨ addr , 𝐺, err , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩ 𝑘 = ⟨ addr , 𝑎 ⟩ 𝑘 ∈ 𝑅 𝑆 ′ = 𝑀 ( 𝑦 ) ◦ . . . ◦ 𝑀 ( 𝑦 + 𝑧 − ) 𝐸 ′ = 𝐸 ∪ {⟨ 𝑘 ′ , 𝑆 ′ , 𝑙, pc ′ , 𝑔 ⟩ | ⟨ 𝑘 ′ , pc ′ , 𝑔 ⟩ ∈ 𝑅 ( 𝑘 )}⟨ addr , 𝐺, pc , gas , 𝑦 ◦ 𝑧 ◦ 𝑙 ◦ 𝑎 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ emit ⟧⇒ ⟨ addr , 𝐺, pc + , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ′ ⟩ 𝑘 = ⟨ addr , 𝑎 ⟩ 𝑘 ∉ 𝑅 ⟨ addr , 𝐺, pc , gas , 𝑦 ◦ 𝑧 ◦ 𝑙 ◦ 𝑎 ◦ 𝑆, 𝑀, 𝑅, 𝐸 ⟩ = ⟦ emit ⟧⇒ ⟨ addr , 𝐺, err , gas + 𝐺, 𝑆, 𝑀, 𝑅, 𝐸 ⟩ Figure 4.
Small-Step Semantics 𝐴 ⟧⇒ ∗ 𝜇 ′ to denote the execution state transition of execut-ing a program or a transaction. The first two rules deal withcreate transactions which, as the name implies, create newaccounts. As long as the account to be created does not al-ready exist, that the sender has sufficient balance to transferthe specified amount to the new account, and that the senderprovides the correct nonce that matches the sender accountstate, the transaction is executed without any errors.The next four rules pertain to regular transactions. Regu-lar transactions execute contract code and at the same timesend balance. Prior to establishing an execution environment,SigVM checks that both sender and contract addresses exist,that the nonce is valid, and that the contract address signal transaction queue is empty. This last condition enforces the contract event lock , which guarantees that as long as an ac-count has pending signal transactions, regular transactionscannot be executed on that account. Rule 3 handles the casewhere one of these conditions fails.Once these conditions are verified, SigVM establishes theinitial execution environment. The code address, initial pro-gram counter, and initial stack are specified by the trans-action. For simplicity, we assume that regular transactionsexecute with a standard gas price of 100 and an initial gascounter of 0. The storage and signal record map are copiedfrom the current blockchain state, and the emit signal recordis initialized as empty. With this, the program is executed. igVM: Toward Fully Autonomous Smart Contracts Conference’21, June 2021, Virtual Conference ⟨ addr , 𝑠, 𝑛, 𝑏, 𝑃 ⟩ = 𝑡 ∈ 𝐶𝑟𝑒𝑎𝑡𝑒𝑇𝑥 ⟨ 𝑛 ′ , 𝑏 ′ ⟩ = 𝑁 ( 𝑠 ) 𝑛 ≡ 𝑛 ′ 𝑏 ′ ≥ 𝑏 addr ∉ 𝐴 𝐹 = ⟨ , 𝑏 ⟩ 𝐷 = ⟨∅ , ∅ , 𝑃 ⟩ 𝐹 ′ = ⟨ 𝑛 ′ + , 𝑏 ′ − 𝑏 ⟩⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑡 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴 [ addr ↦→ 𝐷 ] , 𝑁 [ addr ↦→ 𝐹 ] [ 𝑠 ↦→ 𝐹 ′ ]⟩⟨ addr , 𝑠, 𝑛, 𝑏, 𝑃 ⟩ = 𝑡 ∈ 𝐶𝑟𝑒𝑎𝑡𝑒𝑇𝑥 ⟨ 𝑛 ′ , 𝑏 ′ ⟩ = 𝑁 ( 𝑠 ) 𝑛 (cid:46) 𝑛 ′ ∨ 𝑏 ′ < 𝑏 ∨ addr ∈ 𝐴 ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑡 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ ⟨ 𝑠, addr , 𝑛, 𝑏, pc , 𝑔 ⟩ = 𝑢 ∈ 𝑅𝑒𝑔𝑢𝑙𝑎𝑟𝑇𝑥 ⟨ 𝑛 ′ , 𝑏 ′ ⟩ = 𝑁 ( 𝑠 ) ⟨ 𝑀, 𝐿, 𝑃 ⟩ = 𝐴 ( addr ) 𝑠 ∉ 𝐴 ∨ addr ∉ 𝐴 ∨ 𝑛 (cid:46) 𝑛 ′ ∨ 𝐿 (cid:46) ∅⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑢 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩⟨ 𝑠, addr , 𝑛 ′ , 𝑏 ′ , pc , 𝑆 ⟩ = 𝑢 ∈ 𝑅𝑒𝑔𝑢𝑙𝑎𝑟𝑇𝑥 𝑠, addr ∈ 𝐴 ⟨ 𝑛 ′′ , 𝑏 ′′ ⟩ = 𝑁 ( 𝑠 ) ⟨ 𝑀, 𝐿, 𝑃 ⟩ = 𝐴 ( addr ) 𝑛 ′ ≡ 𝑛 ′′ 𝐿 ≡ ∅⟨ addr , , pc , , 𝑆, 𝑀, 𝑅, ∅⟩ = ⟦ 𝑃 ⟧⇒ ∗ ⟨ addr , , nil , gas ′ , 𝑆 ′ , 𝑀 ′ , 𝑅 ′ , 𝐸 ′ ⟩ 𝑏 ′′ ≥ 𝑏 ′ + gas ′ ⟨ 𝑄 ′ , 𝐴 ′ ⟩ = ProcessExec ( height , addr , 𝑄, 𝐴, 𝑀 ′ , 𝐿, 𝐸 ′ ) 𝑁 ′ = 𝑁 [ 𝑠 ↦→ ⟨ 𝑛 ′′ + , 𝑏 − 𝑏 ′ − 𝑔𝑎𝑠 ′ ⟩] [ addr ↦→ ⟨ 𝑛, 𝑏 + 𝑏 ′ ⟩]⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑢 ) ⟧⇒ ∗ ⟨ height , 𝑅 ′ , 𝑄 ′ , 𝐴 ′ , 𝑁 ′ ⟩⟨ 𝑠, addr , 𝑛 ′ , 𝑏 ′ , pc , 𝑆 ⟩ = 𝑢 ∈ 𝑅𝑒𝑔𝑢𝑙𝑎𝑟𝑇𝑥 𝑠, addr ∈ 𝐴 ⟨ 𝑛 ′′ , 𝑏 ′′ ⟩ = 𝑁 ( 𝑠 ) ⟨ 𝑀, 𝐿, 𝑃 ⟩ = 𝐴 ( addr ) 𝑛 ′ ≡ 𝑛 ′′ 𝐿 ≡ ∅⟨ addr , , pc , , 𝑆, 𝑀, 𝑅, ∅⟩ = ⟦ 𝑃 ⟧⇒ ∗ ⟨ addr , , err , gas ′ , 𝑆 ′ , 𝑀 ′ , 𝑅 ′ , 𝐸 ′ ⟩ 𝑁 ′ = 𝑁 [ 𝑠 ↦→ ⟨ 𝑛 ′′ + , 𝑚𝑖𝑛 { 𝑏 − gas ′ , }⟩] [ addr ↦→ ⟨ 𝑛, 𝑏 ⟩]⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑢 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ′ ⟩⟨ 𝑠, addr , 𝑛 ′ , 𝑏 ′ , pc , 𝑆 ⟩ = 𝑢 ∈ 𝑅𝑒𝑔𝑢𝑙𝑎𝑟𝑇𝑥 𝑠, addr ∈ 𝐴 ⟨ 𝑛 ′′ , 𝑏 ′′ ⟩ = 𝑁 ( 𝑠 )⟨ 𝑀, 𝐿, 𝑃 ⟩ = 𝐴 ( addr ) 𝑛 ′ ≡ 𝑛 ′′ 𝐿 ≡ ∅ ⟨ addr , , pc , , 𝑆, 𝑀, 𝑅, ∅⟩ = ⟦ 𝑃 ⟧⇒ ∗ ⟨ addr , , nil , gas ′ , 𝑆 ′ , 𝑀 ′ , 𝑅 ′ , 𝐸 ′ ⟩ 𝑏 ′′ < 𝑏 ′ + gas ′ 𝑁 ′ = 𝑁 [ 𝑠 ↦→ ⟨ 𝑛 ′′ + , ⟩] [ addr ↦→ ⟨ 𝑛, 𝑏 ⟩]⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑢 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ′ ⟩⟨ height ′ , addr , pc , 𝑔, 𝑆 ⟩ = 𝑣 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥 addr ∈ 𝐴 ⟨ 𝑀, 𝐿 ′ ◦ 𝑣 ′ , 𝐶 ⟩ = 𝐴 ( addr )⟨ 𝑛, 𝑏 ⟩ = 𝑁 ( addr ) height ′ ≥ height 𝑣 ≡ 𝑣 ′ ⟨ addr , + 𝑔, pc , , 𝑆, 𝑀, 𝑅, ∅⟩ = ⟦ 𝑃 ⟧⇒ ∗ ⟨ addr , + 𝑔, nil , gas ′ , 𝑆 ′ , 𝑀 ′ , 𝑅 ′ , 𝐸 ′ ⟩ 𝑏 ≥ gas ′ ⟨ 𝑄 ′ , 𝐴 ′ ⟩ = ProcessExec ( height , addr , 𝑄, 𝐴, 𝑀 ′ , 𝐿 ′ , 𝐸 ′ ) 𝑁 ′ = 𝑁 [ addr ↦→ ⟨ 𝑛, 𝑏 − gas ′ ⟩]⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑣 ) ⟧⇒ ∗ ⟨ height , 𝑅 ′ , 𝑄 ′ , 𝐴 ′ , 𝑁 ′ ⟩⟨ height ′ , addr , pc , 𝑔, 𝑆 ⟩ = 𝑣 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥 ⟨ 𝑀, 𝐿 ′ ◦ 𝑣 ′ , 𝑃 ⟩ = 𝐴 ( addr ) addr ∉ 𝐴 ∨ height ′ < height ∨ 𝑣 (cid:46) 𝑣 ′ ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑣 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩⟨ height ′ , addr , pc , 𝑔, 𝑆 ⟩ = 𝑣 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥 addr ∈ 𝐴 ⟨ 𝑀, 𝐿 ′ ◦ 𝑣 ′ , 𝑃 ⟩ = 𝐴 ( addr )⟨ 𝑛, 𝑏 ⟩ = 𝑁 ( addr ) height ′ ≥ height 𝑣 ≡ 𝑣 ′ ⟨ addr , + 𝑔, pc , , 𝑆, 𝑀, 𝑅, ∅⟩ = ⟦ 𝑃 ⟧⇒ ∗ ⟨ addr , + 𝑔, err , gas ′ , 𝑆 ′ , 𝑀 ′ , 𝑅 ′ , 𝐸 ′ ⟩ 𝐴 ′ = 𝐴 [ addr ↦→ ⟨ 𝑀, 𝐿 ′ , 𝑃 ⟩] 𝑁 ′ = 𝑁 [ addr ↦→ ⟨ 𝑛, 𝑏 − gas ′ ⟩]⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑣 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴 ′ , 𝑁 ′ ⟩⟨ height ′ , addr , pc , 𝑔, 𝑆 ⟩ = 𝑣 ∈ 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥 addr ∈ 𝐴 ⟨ 𝑀, 𝐿 ′ ◦ 𝑣 ′ , 𝑃 ⟩ = 𝐴 ( addr )⟨ 𝑛, 𝑏 ⟩ = 𝑁 ( addr ) height ′ ≥ height 𝑣 ≡ 𝑣 ′ ⟨ addr , + 𝑔, pc , , 𝑆, 𝑀, 𝑅, ∅⟩ = ⟦ 𝑃 ⟧⇒ ∗ ⟨ addr , + 𝑔, nil , gas ′ , 𝑆 ′ , 𝑀 ′ , 𝑅 ′ , 𝐸 ′ ⟩ 𝑏 < gas ′ 𝐴 ′ = 𝐴 [ addr ↦→ ⟨ 𝑀, 𝐿 ′ , 𝑃 ⟩] 𝑁 ′ = 𝑁 [ addr ↦→ ⟨ 𝑛, ⟩]⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = ⟦ transact ( 𝑣 ) ⟧⇒ ∗ ⟨ height , 𝑅, 𝑄, 𝐴 ′ , 𝑁 ′ ⟩ Figure 5.
Transact Function for Blockchain StateIf execution fails, gas is deducted from the sender accountand no changes are committed to the state (rule 5). If exe-cution is successful, then both gas and balance transfer arededucted from the sender account (rule 4). Following this,the execution results are processed and committed to theblockchain state. Algorithm 1 defines ProcessExec () whichdescribes how the execution result is processed. It queues thenew signal transactions in 𝐸 ′ onto the global signal trans-action queue 𝑄 . It then updates the account state map to reflect changes made to storage. If the sender has insuffi-cient balance, then balance is deducted from the sender andchanges to the state are not committed (rule 6). In all casesthat execution takes place, nonce is incremented.The last four rules execute signal transactions. Althoughsimilar to regular transactions, there are several key differ-ences. Before establishing the execution environment, SigVMverifies that the account address exists, that the signal trans-action height is greater than or equal to the current block onference’21, June 2021, Virtual Conference height, and that the signal transaction matches the first trans-action on the account signal transaction queue. Note thatthere is no nonce as executing the top of the account sig-nal transaction queue removes the possibility of duplicateexecutions. Once all the conditions are verified, the initialexecution environment is established. The address is set tothe contract address. The program counter and stack arespecified by the transaction. Gas price is set to 100 + 𝑔 where 𝑔 is the gas incentive. The initial gas counter is initializedas 0. The storage and signal record map are copied fromthe blockchain state, and the emit signal set is initialized asempty. If execution is successful and the contract addresshas sufficient balance, gas is charged to the contract accountaddress and the execution results are processed (rule 7). Notethat regardless of whether the execution was successful ornot, the signal transaction is dequeued from the accountsignal transaction queue (see rules 9 and 10). We next define how SigVM processes a new block. A block is 𝐵 = ⟨ height ,𝑇 , 𝑈 , 𝑉 ⟩ . 𝑇 , 𝑈 , and 𝑉 are sets of create, regular,and signal transactions respectively. On receipt or creationof a new block, the block is executed on top of the blockchainstate as shown in Algorithm 2. Given the current blockchainsstate 𝜎 and the block 𝐵 , the algorithm first executes all trans-actions in 𝐵 to update the blockchain state. It then checksthe global signal transaction queue 𝑄 and pushes all signaltransactions at the next height to the pending queues ofthe corresponding accounts. In addition, a block with morethan 20% transactions being signal transactions is consideredinvalid so that normal transactions are not ignored. We implemented SigChain, an end-to-end blockchain plat-form that supports SigVM. We also implemented SigSolid, amodified Solidity language together with a compiler to utilizeSigVM features. We built SigChain based on OpenEthereum [34]and the SigSolid compiler based on the Solidity compiler [12].Our implementation supports full EVM opcodes plus addi-tional SigVM opcodes for signal events described in Section 3.
The goal of the SigSolid language is to provide high levellanguage features for utilizing SigVM opcodes while main-taining support for Solidity code. SigSolid introduces thefollowing kinds of statements: • Declare Signal Event:
Developers can declare a sin-gle event E using “ signal E(data_list) ” in a con-tract, where data_list is a list of data types associatedwith the event. The SigSolid compiler translates suchdeclarations into createsignal opcodes in SigVM. • Emit an Event:
Developers can emit a declaredsignal event with the statement of the form“
E.emit(data).delay(t) ”, where E is the signal Algorithm 1
Process execution result function
ProcessExec( height , addr , 𝑄, 𝐴, 𝑀, 𝐿, 𝐸 ) 𝑄 ′ ← 𝑄 for all ⟨ addr ◦ 𝑎, 𝑆, 𝑙, pc , 𝑔 ⟩ ∈ 𝐸 do height ′ ← height + 𝑙 + 𝑣 ← ⟨ height ′ , addr , pc , 𝑔, 𝑆 ⟩ 𝑄 ′ ← 𝑄 ′ [ height ′ ↦→ ( 𝑄 [ height ′ ] ◦ 𝑣 )] end forlet ⟨ _ , _ , 𝑃 ⟩ = 𝐴 ( addr ) return ⟨ 𝑄 ′ , 𝐴 [ addr ↦→ ⟨ 𝑀, 𝐿, 𝑃 ⟩]⟩ end functionAlgorithm 2
Execute new block function
ExecuteNewBlock( 𝜎, 𝐵 ) if number of 𝑆𝑖𝑔𝑛𝑎𝑙𝑇𝑥 in 𝐵 number of 𝑇𝑥 in 𝐵 > thenreturnend iffor every transaction 𝑤 in 𝐵 dosuppose 𝜎 = ⟦ transact ( 𝑤 ) ⟧⇒ ∗ 𝜎 ′ 𝜎 ← 𝜎 ′ end forlet ⟨ height , 𝑅, 𝑄, 𝐴, 𝑁 ⟩ = 𝜎 height ′ ← height + for all 𝑣 ∈ 𝑄 ( height ′ ) dolet ⟨ _ , addr , _ , _ , _ ⟩ = 𝑣 let ⟨ 𝑀, 𝐿, 𝑃 ⟩ = 𝐴 ( addr ) 𝐴 ← 𝐴 [ addr ↦→ ⟨ 𝑀, 𝐿 ◦ 𝑣, 𝑃 ⟩] end forreturn ⟨ height ′ , 𝑅, 𝑄 [ height ′ ↦→ ∅] , 𝐴, 𝑁 ⟩ end function event to emit, data is the list of data associated withthis emitted instance of the event, and t is a non-negative integer that specifies the number of blocksas the delay. The SigSolid compiler translates suchstatements into emit opcodes in SigVM. • Declare and Bind Handlers:
Developers can declarea function as a handler with the “ handler ” modifier.For such a declared handler, a statement of the form“
H.bind(addr, C.E, g) ” binds the handler to anevent, where addr is the address of the event’s sourcecontract ,
C.E is the event type, and g is a float numberratio that indicates the additional gas price the contractis willing to pay for the generated signal transactions.The SigVM compiler translates such statements into bind opcodes in SigVM automatically. • Detach:
Developers can detach a handler from anevent with the statement of the form “
H.detach(addr,C.E) ”. The SigVM compiler translates such statementsinto detach opcodes in SigVM. igVM: Toward Fully Autonomous Smart Contracts Conference’21, June 2021, Virtual Conference To support signal transactionexecution, we augment the state of our prototype blockchainaccording to Section 3. It includes an event record map thatmaps each signal event to its bound handler information (i.e., 𝑅 in Figure 2) and a timer map that maps each block height tothe list of signal transactions that will become active at thatheight (i.e., 𝑄 in Figure 3). For each smart contract account,the blockchain state also maintains a list of pending signaltransactions to execute (i.e., 𝐿 in Figure 3). Generate Signal Transaction:
Our SigVM implementa-tion checks the event record map when a signal event isemitted. It then creates one signal transaction for every han-dler function that is bound to the signal. Each of these signaltransactions is then inserted into the timer map, and at thespecified time, moved from the timer map to specific accountsignal transaction queues. Our implementation also providesminers a method for retrieving pending signal transactionsquickly. This is done by maintaining a list of all accountswith pending signal transactions on the state.
Incentivize Miners to Pack Signal Transactions:
To in-centivize miners to pack signal transactions as soon as pos-sible, these transactions pay a higher gas price than regulartransactions. For the sake of simplicity, Section 3 assumesthat all gas prices of regular transactions are constant. Inreality, gas prices are set by users and vary with network de-mand. In our prototype implementation, we set the gas priceof signal transactions to be the average gas price of regulartransactions in the block multiplied by the signal transactiongas ratio which is set when the handler is created. Note thatas long as this gas ratio is greater than one, the gas priceof signal transactions will always be competitive in relationto regular transactions. This therefore incentivizes minersto pack signal transactions. To avoid situations where theaverage gas price of normal transactions cannot be deter-mined due to an overabundance of signal transactions, ourblockchain platform sets a separate gas limit for signal trans-actions to reserve room for regular transactions. In addition,to prevent attackers from packing a significant number of sig-nal transactions and ignoring normal transactions, besidessetting higher gas fee for signal transactions, there is a fixedmaximum ratio between signal and normal transactions inthe same block. The remaining of the signal transactionsshould be queued and executed at the future blocks.
Enforce Contract Lock:
When processing a block, ourSigVM implementation enforces contract event lock on alltransactions. Before executing a regular transaction, our im-plementation verifies that the pending signal transactionqueue is empty. Before executing a signal transaction, ourimplementation verifies that the signal transaction is indeedthe next transaction in the pending queue. If these verifica-tion steps fail, the transaction will not be executed and willhave no effect. The miner who packs this transaction will receive no transaction fee reward from the transaction andthe transaction will await future packing.
Execute Signal Transaction:
The execution of a signaltransaction is similar to that of a regular transaction. Themain difference is that it starts execution at a handler func-tion rather than a user specified function. In Section 3, thiswas described as setting the initial pc to some value. This isnot accurate in the context of an Ethereum-based system asit has its own ABI which describes how to execute methods.Thus, instead of a pc value, our blockchain platform keepstrack of the handler function method id and the ABI encodedsignal emitted data to initiate signal transaction execution. Our SigVM implementation supports all inter-contract callopcodes in EVM. For normal transactions, our implementa-tion also enforces contract event locking at the boundaryof inter-contract calls. It checks whether the pending signaltransaction list of the callee contract is empty or not. If thelist is not empty, the whole transaction will be reverted withno effect and the miner will receive no transaction fee re-ward. Note that for the delegate call opcode, this verificationis skipped because delegate calls do not change the state ofthe callee contract.For inter-contract calls in signal transactions, the case ismore challenging. If we enforce the rule like that in normaltransactions, we may cause deadlocks. Suppose that two con-tracts listen to the same signal event and that each of thehandler functions of the two contracts calls functions fromthe other contract. Neither of the two signal transactionswould be allowed to proceed further. To this end, SigVMhas a different treatment for signal transactions. If the con-tract event lock verification fails for a inter-contract call ina signal transaction, the call will not be executed and willreturn with a special error code, but the execution of the sig-nal transaction is allowed to proceed to avoid the potentialdeadlock. It is the responsibility of the caller to check thespecial error code to handle this corner case.
We next evaluate the design of SigVM with five contractsfrom three representative decentralized applications onEthereum. Our evaluation is driven by the following ques-tions:1. Can SigVM enable fully autonomous contracts? Specif-ically, can we implement popular smart contractsfrom Ethereum in SigVM to eliminate off-chain relayservers?2. Is SigVM easy to use? What is the development effortof implementing smart contracts in SigVM?3. What kinds of security risks are associated with off-chain relay server solutions? Can the contract eventlock mechanism in SigVM eliminate these risks? onference’21, June 2021, Virtual Conference Solidity SigSolidApp. Contract
Table 1.
Statistics of Benchmark Contracts
Our benchmark set con-tains five contracts from three representative decentral-ized applications deployed on Etheruem, including Maker-DAO [15], Compound [20], and Augur [29]. MakerDAO is astablecoin derivative application that can mint Dai tokens bycollateralizing crypto assets. Dai is designed to have a stablevalue of one USD. Compound is a decentralized lending ser-vice platform where users could deposit one type of digitalasset as collateral to borrow another type of digital assetfrom its shared pool. Augur is a decentralized predictionmarket where users bet on future result of real-world events.In total, these applications manage more than $3B of digitalassets on the Ethereum network, making up an essential partof the Ethereum economic ecosystem.Table 1 shows some statistics of our benchmark contracts.Each of these three applications contain many sophisticatedcontracts that are interdependent with each other but aremaintained by different groups of users. In our evaluation,we focus on five benchmark contracts (shown in Column 2 ofTable 1) that are currently relying on off-chain relay serversto invoke the corresponding poke functions. Column 3 and4 present the number of poke functions and the number oflines of code in each contract respectively.
Implement Contracts in SigSolid:
We reimplement thesebenchmark contracts in SigSolid with the goal of eliminatingoff-chain relay servers from the picture. Because SigSolid iscompatible with Solidity, our modification is merely replac-ing the poke functions with SigSolid signal event statements.We are able to reimplement all five contracts in SigSolid.Column 5 and column 6 of Table 1 present the number ofdeclared signal events and the number of declared handlerfunctions in the new contract implementation, respectively.We find that the new code is typically simpler than the origi-nal contract code while the reimplementation effort is mod-erate. Column 7 presents the number of lines of code of thenew contract. Column 8 presents the number of line diffsbetween the new and old code.
Validate and Analyze:
We deploy those benchmark con-tracts together with the remaining components of the appli-cations in our SigChain platform. We manually validate thatall three benchmark applications function correctly with the contract Timelock { struct LockedTx {// Information of a transaction address target; uint txvalue; string signature; bytes datain; uint user_delay; bool ready ;} // Transaction queue mapping ( bytes32 =>LockedTx) private queuedTx; //max delay when poking executeTransaction - uint public constant GRACE_PERIOD = 14 days; + uint public delay ;// Base delay to execute + signal TimesUp(bytes32); // signal event function queueTransaction ( address target , uint txvalue , string memory signature , bytes memory datain , uint user_delay ) public returns ( bytes32 ) { // Hash transaction parameters as index bytes32 txHash= keccak256 (abi.encode(target ,txvalue ,signature ,datain ,user_delay)); // Replace timestamp with offset delay - require(eta >= getBlockTimestamp ().add(delay)); + require(user_delay >= delay); // Push the new transaction to queuedTx queuedTx[txHash ]= LockedTx(target ,txvalue , signature ,datain ,user_delay , true ); // Emit signal event with txHash + TimesUp.emit(txHash , this.address) + .delay(user_delay); // Handler for executing tx - function executeTx(bytes32 txHash) public { + function executeTx(bytes32 txHash) handler { //no check sender is admin - require(msg.sender == admin); //no check the tx is under correct period - require( getBlockTimestamp () >= eta); - require( getBlockTimestamp () - <= eta.add(GRACE_PERIOD)); //use queuedTx[txHash] to do function call ... } constructor ( address admin_ , uint delay_) public { + // signal initializations + // bind handler to signal + executeTx.bind(this.address ,TimesUp ,0.1) ; } ... } Listing 2.
Code Snippet of Timelock.sol in Compoundnew contract code. We then analyze the code of the newcontracts again and report our experience as case studies.
As described in Section 2, we reimplementedthe three contracts in the oracle components of MakerDAO,eliminating the dependency on off-chain relay servers. Thenew contracts powered by SigVM ensure that the core Mak-erDAO engine will always operate with the updated priceof its underlying digital asset. In addition, before the Maker-DAO contract processes these price feed signal transactions,by lock mechanism, other transactions like liquidation andbidding will be put on-hold to avoid them operating withstale price information. See Section 2 for details.
Compound:
Compound protocol is a decentralized marketto lend or borrow assets. Users communicate with the Com-pound contracts to supply, withdraw, borrow and repay as-sets. In the protocol, the key parameters of the market, suchas interest rate, risk model and underlying price, are man-aged by a decentralized government body in Compound [20]. igVM: Toward Fully Autonomous Smart Contracts Conference’21, June 2021, Virtual Conference Any proposals of updating the parameters must be votedfor approval and queued in
Timelock contract. To give mar-ket participants time to react for any parameter changes,the queued proposals will be executed in the required delayspecified in the proposals.We reimplemented the
Timelock contract of Compoundin SigSolid and validated it with our prototype SigChainplatform. Listing 2 presents the simplified code snippet of
Timelock . Lines preceded with “-" and “+" signs are changeswe made to the source code to utilize the even-driven execu-tion model in SigSolid.In the original Compound design, Governor calls queueTransaction() function (line 10) to queue proposals.But to implement the desired delay, Governor or an off-chainrelay server needs to send another poke transaction to call executeTransaction() (line 26) at the time right after thedelay and before its proposal expiration time. The functionfirst checks whether the proposal is queued and whether thecurrent timestamp falls in the required interval (lines 31-33).If so, the proposal is executed. This design is not desirablebecause the governor or the off-chain relay server may failand/or the poke transaction may not be packed in time if theblockchain network is suddenly congested.In SigSolid, we can eliminate the dependency on poketransactions with the signal event mechanism. We define anew signal event called
TimeUp at line 9. The queueTransaction() function will emit this event with thespecified delay (lines 23-24). Instead of being a public func-tion, the executeTransaction() function is declared as anevent handler function (line 27). When the contract is con-structed, we will bind executeTransaction() as the han-dler for
TimeUp events in the same contract. This will cause executeTx() to be automatically executed once the spec-ified delay time (measured in the number of blocks) haspast after each
TimeUp event. Many conditional checkings in executeTx() are removed because the conditions are guar-anteed by the underlying execution engine of SigVM.We deployed the modified
Timelock contract togetherwith the rest of Compound smart contracts on our SigChainplatform. Our results show that the deployed Compoundapplication in SigChain can operate successfully andthere is no need to run off-chain server to poke the executeTransaction() function anymore.
Augur:
Augur is a decentralized prediction market whereusers can bet on future real-world outcomes [29]. Augurmarkets follow four stages: creation of the market, trading,reporting outcomes and prediction settlement. During report-ing stage, one of the reporters report results of a real-worldevent by staking REP tokens on one of the outcomes of themarket. If a Dispute Bond is reached on an alternative out-come, the Tentative Winning Outcome changes to the newalternative outcome. This process happens every 24 hours.The contract that implements this process in Augur is
Universe . The design of the contract is that every 24 hours, contract Universe is IUniverse { // define MIN_RATE as min of exec period // daily block rate of the network uint public DAILYBLOCKRATE ; + signal DailySignal ();// Signal event + function Update () handler {// Handler function + sweepInterest (); + // signal emission + DailySignal.emit(this.address) + .delay(DAILYBLOCKRATE ); } function sweepInterest () public returns ( bool ) {...} + function setBlockRate(uint dailyblockrate ) + public returns (bool) { + require(dailyblockrate >= MIN_RATE); + DAILYBLOCKRATE = dailyblockrate ;} + function start_emit () public { + // emit a signal immediately + DailySignal.emit(this.address).delay (0);} constructor (Augur _augur , ..., + uint dailyblockrate ) public { //set handler execution period + DAILYBLOCKRATE = dailyblockrate ; // bind handler to signal + Update.bind(this.address ,DailySignal ,0.1); // Other initializations ...}..} Listing 3.
Code Snippets of Universe.sol in Augurthe sweepInterest() function has to be executed so that thecontract can finalize the last round results and can start a newround if required. Because this functionality is not feasibleto implement in EVM, Augur instead relies on external usersto periodically poke sweepInterest() function.Listing 3 presents the code snippet of our
Universe con-tract implementation in SigSolid. We define a signal eventcalled
DailySignal at line 5 and we define a handler func-tion called
Update() for this event at lines 6-10. The handlerfunction calls the sweepInterest() function. It also recur-sively emits the
DailySignal event with a delay of one day(in the number of blocks) at the end at lines 9-10. There-fore once the first
DailySignal event is triggered (e.g., viathe start_emit() function), the
Update() function will beautomatically invoked once every 24 hours.We deployed the new
Universe contract together withthe rest of contracts in Augur on our SigChain platform. Thedeployed version of Augur operates successfully and the sweepInterest() function is automatically called every 24hours as expected. This example highlights the expressive-ness of SigSolid powered by SigVM. This recursive event han-dler pattern enables developers to create customized infinitetimer ticks conveniently. The desired handler function willbe automatically and periodically invoked as signal trans-actions by the execution engine of SigVM, as long as thecontract has enough native tokens to pay for the transactionfee of the recurring transactions.
We next run two experiments to quantitative study mali-cious relay manipulation of relying on off-chain relay server onference’21, June 2021, Virtual Conference Transaction Rate
P(interference) under poking P(interference) under SigVM
Figure 6.
Malicious Relay Manipulation Rate Line Chartto drive execution. We also evaluate whether SigVM caneliminate these associated risks.
Malicious relay manipulation:
Using off-chain relayservers to simulate event-driven execution models may makethe contract vulnerable to malicious relay manipulations.Miners may pack an interference transaction before a poketransaction for an event and therefore the contract will exe-cute the interference transaction in an incorrect state.We setup an experiment with the three benchmark Mak-erDAO contracts to quantitatively illustrate this problem.We start an Ethereum network with a block generation rateof one block per second. We develop a random transactiongenerator to generate three types of transactions randomly,1) simple transfer transactions that do not interact with Mak-erDAO, 2) MakerDAO transactions, and 3) poke transactionsthat attempt to update price for MakerDAO. In this experi-ment, the ratio of these three kinds of transactions is 10 : 4 : 1.The gas price of these transactions is following the normaldistribution with 𝜇 = , 𝜎 = , 𝑚𝑎𝑥 = ≥
30 TPS and goes as high as 0.0125 whenthe throughput is 70 TPS. We also repeat the experimentswith the new MakerDAO contracts in our SigChain platformby replacing poke transactions with the automatic signalevent mechanism. The relay manipulation never occurs be-cause of our novel contract event lock mechanism. The lockmechanism has minimum impact on the performance be-cause the miners are incentivized to pack signal transactionsas soon as possible.
Event-driven Proxy Services:
On Ethereum, there are anumber of proposals involving proxy service of function exe-cutions in respondence to event emission. EventWarden [22]is a proxy service protocol requiring a user to create a smartcontract specifying events to listen, the function handler tocall when a event occurs, and the service fee for the executor.Executors of the system monitor the event log, invoke thespecified function, and earn a service fee in return. Similarly,Ethbase [13] provides a registry smart contract where userscan deposit and subscribe to the automatic function invo-cation service. When the specified event is seen in the log,miners invoke the callback function accompanied by a proofof the event emission to the registry. Both EventWarden and Ethbase are variants of an off-chain relay server solution, though they provide some au-tomated incentive mechanisms. Unlike SigVM, one or moresteps in these proposals rely on off-chain actors to timelysend poke transactions. This does not prevent malicious at-tackers from front-running these poke transactions. On theother hand, the existence of these proposals suggests a needfor event-driven execution models in blockchains.
Message Passing Language Design:
New smart contractlanguages such as RhoLang [10], Scilla [31], and Nomos [11]replace inter-contract function calls with message-passingmechanisms to eliminate security errors like re-entrance.Although these message-passing mechanisms are also asyn-chronous, they behave otherwise like function calls and can-not implement the desired event-listener model to eliminateoff-chain relay servers.In fact, it would be difficult to implement many decen-tralized finance contracts like our example in Section 2 inthese languages, because these contracts depend on synchro-nous inter-contract function calls. Making a function callasynchronous via message-passing may make a contract vul-nerable to malicious manipulation attacks that front-run theasynchronous massage-passing transaction. One possiblesolution to this problem is to lock the callee contract untilthe message-passing transaction is resolved like the contractlocking mechanism in SigVM.
Language Design for Security:
In addition to Solidity, anumber of languages have been designed specifically forsmart contract programming. Some proposals focus on en-hancing security by restricting specific expressions, provid-ing formal verification tools and introduce types. Vyper [33]is a popular language on Ethereum network that restrictsloops and disallows recursion with the aim of enhancingsecurity and readability. Simplicity [26] is a functional lan-guage for smart contract programming accompanied byformal denotational semantics defined in Coq. Tezos [17]blockchain supports contracts written in Liquidity [25],which is a high-level typed language with a formal verifica-tion framework under development. Sophia [1] is the con-tracting language in Æternity [2] that is strongly typed andcomes with restricted mutable state. In Libra [4], Move [6]proposes resource types, and guarantees that resources arestatically moved in storage without being copied or deleted.DeepSEA [32] supports formal verification of smart con-tracts with the use of Coq proof assistant in CertiK chain [14].DeepSEA reduces the overhead for developers to write proofsin Coq system. Obsidian [9] defines typestates and lineartypes to prevent unsafe state changes and asset uses. Theselanguages improve smart contract security by limiting lan-guage expressiveness, while SigVM improves the expressive-ness by introducing the event-driven execution model. Inter-estingly, because the event-driven execution model is highlydemanded and many smart contracts are insecurely simu-lating such an execution model via off-chain relay servers, igVM: Toward Fully Autonomous Smart Contracts Conference’21, June 2021, Virtual Conference SigVM may also improve the security of these contracts byeliminating the need of such insecure practice.
Scheduled Transaction Execution:
Bitcoin supports a na-tive mechanism called timelocks [3] to delay transactionexecution. The transaction-level timelock feature can be uti-lized by specifying an execution delay with the nLocktimefield. Additional timelock features, Check Lock Time Verify(CLTV) and Check Sequence Verify (CSV), were introducedlater to the scripting language. CLTV limits the availabilityof the associated Unspent Transaction Output (UTXO) un-til a certain age. CSV utilizes the the value of nSequence, atransaction field, to prevent mining of a transaction untilthe time limit specified for the UTXO is met. These featuresare proven to be useful in layer 2 designs, such as statechannels and the Lightning Network. The timelock featuresprovides a convenient way to delay transaction executionon Bitcoin. However, with the lack of programmability onBitcoin network and the difficulty of generalizing such a de-sign to non-UTXO networks, the usability of such a designis limited. Another implementation of delayed or periodictransaction is to setup relay servers through the networkclient as we have discussed in the paper. This approach isoften not desirable, because it assumes the particular serveris online during the desired transaction time and does notenforce timely execution of the scheduled transaction.
Network Security and Correctness Validation:
Anotherpath taken by many to improve the security of smart contractprogramming is through static verification and runtime vali-dation tools. There is a rich body of literature on detectingvulnerability in smart contracts through static analysis andverification [5, 18, 19, 23, 24, 28]. With symbolic execution,Oyente [23] secures smart contracts against various attacksincluding re-entrance attacks and mishandled exception at-tacks. Verx [28] uses delayed abstraction to detect and verifytemporal safety properties automatically. Solythesis [21] in-serts runtime checks to enforce customized validation rulesin an automatic manner. KEVM [18] defines the semanticof EVM in K and verifies the smart contract against user-defined specifications. These proposals enhance security ofsmart contract programming mostly by preventing unin-tended behaviors in smart contract codes. As smart contracts become more complicated and inter-dependent with each other, the event-driven execution modelis an increasingly demanded feature. Unsatisfied by currentblockchain virtual machines, smart contracts start to use un-reliable off-chain mechanisms such as off-chain relay serversto drive the contract execution. SigVM provides the firstblockchain virtual machine with an integrated solution tonatively enable event-driven execution models on-chain. Itpaves the way for developers to build fully autonomoussmart contracts securely in the future.
References [1] æernity dev team. 2020. The Sophia Language. https://github.com/aeternity/aesophia/blob/lima/docs/sophia.mdl [2] æternity dev team, Thomas Arts, Yanislav Malahov, and Sascha Hanse.2020. Æternity: Open source blockchain for scalable and secure smartcontracts. https://raw.githubusercontent.com/keypair/white-paper/master/aeternity-whitepaper.pdf [3] Andreas M. Antonopoulos. 2017.
Mastering Bitcoin: Programming theOpen Blockchain (2nd ed.). O’Reilly Media, Inc.[4] The Libra Association. 2020. The Libra Blockchain. https://developers.libra.org/docs/the-libra-blockchain-paper [5] Karthikeyan Bhargavan, Antoine Delignat-Lavaud, Cédric Fournet,Anitha Gollamudi, Georges Gonthier, Nadim Kobeissi, Natalia Kula-tova, Aseem Rastogi, Thomas Sibut-Pinote, Nikhil Swamy, and San-tiago Zanella-Béguelin. 2016. Formal Verification of Smart Con-tracts: Short Paper. In
Proceedings of the 2016 ACM Workshop onProgramming Languages and Analysis for Security . 91–96. https://doi.org/10.1145/2993600.2993611 [6] Sam Blackshear, Evan Cheng, David L. Dill, Victor Gao, BenMaurer, Todd Nowacki, Alistair Pott, Shaz Qadeer, Rain,Dario Russi, Stephane Sezer, Tim Zakian, and Runtian Zhou.2020. Move: A Language With Programmable Resources. https://developers.libra.org/docs/assets/papers/libra-move-a-language-with-programmable-resources/2020-05-26.pdf [7] Vitalik Buterin. 2014. Ethereum: A next-generation smart contractand decentralized application platform. https://github.com/ethereum/wiki/wiki/White-Paper .[8] ChainLink. 2020. ChainLink: Using Price Feeds. https://docs.chain.link/docs/get-the-latest-price [9] Michael Coblenz, Reed Oei, Tyler Etzel, Paulette Koronkevich, MilesBaker, Yannick Bloem, Brad A. Myers, Joshua Sunshine, and JonathanAldrich. 2019. Obsidian: Typestate and Assets for Safer BlockchainProgramming. arXiv:1909.03523 [cs.PL][10] RChain Cooperative. 2019. Rholang. https://github.com/rchain/rchain/tree/master/rholang [11] A. Das, S. Balzer, J. Hoffmann, F. Pfenning, and I. Santurkar. 2021.Resource-Aware Session Types for Digital Contracts. In . IEEE ComputerSociety, Los Alamitos, CA, USA, 111–126. https://doi.org/10.1109/CSF51468.2021.00004 [12] Ethereum. 2020. The Solidity Contract-Oriented Programming Lan-guage. https://github.com/ethereum/solidity [13] Planet Ethereum. 2018. Ethbase. https://github.com/planet-ethereum/ethbase [14] CertiK Foundation. 2020. CertiK Chain Whitepaper. [15] The Maker Foundation. 2019. The Maker Protocol: MakerDAO’s Multi-Collateral Dai (MCD) System. https://makerdao.com/en/whitepaper/ [16] The Maker Foundation. 2020. The Market Collapse of March 12-13,2020: How It Impacted MakerDAO. https://blog.makerdao.com/the-market-collapse-of-march-12-2020-how-it-impacted-makerdao/ [17] L.M Goodman. 2014. Tezos: A Self-Amending Crypto-LedgerPosition Paper. https://tezos.com/static/position_paper-841a0a56b573afb28da16f6650152fb4.pdf [18] E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu, P. Daian, D. Guth, B.Moore, D. Park, Y. Zhang, A. Stefanescu, and G. Rosu. 2018. KEVM: AComplete Formal Semantics of the Ethereum Virtual Machine. In . 204–217. https://doi.org/10.1109/CSF.2018.00022 [19] Sukrit Kalra, Seep Goe, Mohan Dhawan, and Subodh Sharma. 2018.ZEUS: Analyzing Safety of Smart Contracts. In
Proceedings of the 25thNetwork and Distributed Systems Security (NDSS) Symposium 2018 . https://doi.org/10.14722/ndss.2018.23092 onference’21, June 2021, Virtual Conference [20] Robert Leshner and Geoffrey Hayes. 2019. Compound: The MoneyMarket Protocol. https://compound.finance/documents/Compound.Whitepaper.pdf [21] Ao Li, Jemin Andrew Choi, and Fan Long. 2020. Securing Smart Con-tract with Runtime Validation. In Proceedings of the 41st ACM SIGPLANConference on Programming Language Design and Implementation . 438–453. https://doi.org/10.1145/3385412.3385982 [22] Chao Li and Balaji Palanisamy. 2020. EventWarden: A DecentralizedEvent-driven Proxy Service for Outsourcing Arbitrary Transactions inEthereum-like Blockchains. In
Proceedings of 27rd IEEE InternationalConference on Web Services .[23] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and AquinasHobor. 2016. Making Smart Contracts Smarter. In
Proceedings of the2016 ACM SIGSAC Conference on Computer and Communications Secu-rity . 254–269. https://doi.org/10.1145/2976749.2978309 [24] Ivica Nikolić, Aashish Kolluri, Ilya Sergey, Prateek Saxena, and AquinasHobor. 2018. Finding The Greedy, Prodigal, and Suicidal Contracts atScale. In
Proceedings of the 34th Annual Computer Security ApplicationsConference . 653–663. https://doi.org/10.1145/3274694.3274743 [25] OCamlPRO. 2020. Liquidity Documentation. [26] Russell O’Connor. 2017. Simplicity: A new language for blockchains. In
Proceedings of the 2017 Workshop on Programming Languages and Anal-ysis for Security . 107–120. https://doi.org/10.1145/3139337.3139340 [27] Michael Oved and Don Mosites. 2017. Swap: A Peer-to-Peer Protocolfor Trading Ethereum Tokens. [28] A. Permenev, D. Dimitrov, P. Tsankov, D. Drachsler-Cohen, and M.Vechev. 2020. VerX: Safety Verification of Smart Contracts. In . 1661–1677. https://doi.org/10.1109/SP40000.2020.00024 [29] Jack Peterson, Joseph Krug, Micah Zoltu, Austin K. Williams, andStephanie Alexander. 2019. Augur: a Decentralized Oracle and Predic-tion Market Platform (v2.0). [30] provable.xyz. 2019. Provable: Ethereum Quick Start. https://docs.provable.xyz/ [31] Ilya Sergey, Vaivaswatha Nagaraj, Jacob Johannsen, Amrit Kumar,Anton Trunov, and Ken Chan Guan Hao. 2019. Safer smart contractprogramming with Scilla.
Proceedings of the ACM on ProgrammingLanguages
3, OOPSLA (2019), 1–30.[32] Vilhelm Sjöberg, Yuyang Sang, Shu-chun Weng, and Zhong Shao.2019. DeepSEA: A Language for Certified System Software. (2019). https://doi.org/10.1145/3360562
Article No: 136.[33] Vyper Team. 2020. Vyper. https://vyper.readthedocs.io/en/stable/ [34] Parity Technologies. 2019. OpenEthereum.