What you might not know about VeChainThor yet (Part VII) - Contract Awareness of Transaction Runtime Information



  • What you might not know about VeChainThor yet (Part VII) - Contract Awareness of Transaction Runtime Information

    This is the 7'th article of the "What you might not know about VeChainThor yet" series. You can find the links of the previous articles at the end.

    VeChainThor deploys the builtin contract ExtensionV2 to allow any contract method to be aware of the runtime information of the transaction that invokes the method. Here by "runtime", we mean the kind of information available to the method only when its code is executed by the blockchain system.

    Contract ExtentionV2 is deployed at address

    0x000000000000000000457874656e73696f6e5632

    at block height 3337300 on both the mainnet and testnet.

    The following table lists all the methods that can be called to get different transaction runtime info.

    Contract Method Depscription
    txID() Get TxID at runtime.
    txBlockRef() Get BlockRef at runtime.
    txExpiration() Get Expiration at runtime.
    txProvedWork() Get ProvedWork at runtime.
    txGasPayer() Get the account that pays the TX fee at runtime. It is implemented due to the fact that there are two transaction-fee-delegation protocols (MPP and VIP191) running on VechainThor.

    Example

    pragma solidity >=0.5.0;
    
    interface Extension {
        function txID() external view returns(bytes32);
    }
    
    contract TestExtension {
        address public ext;
    
        constructor(address _ext) public {
            ext = _ext;
        }
    
        function dummyFunc() public {
            bytes32 txID = Extension(ext).txID();
            emit TxID(txID);
        }
    
        event TxID(bytes32 indexed txID);
    }
    

    I have created Contract TestExtension to demonstrate how to get the runtime TxID. Method txID is first defined and the contract address of ExtensionV2 passed to contract TestExtention via its constructor. Method dummyFunc calls txID to get the TxID of the transaction that invokes the method. It then emits an event that logs the TxID.

    Output

    # Deploy voting contract
    	TXID: 0x898fd96e7c496599cedba021c8082765582627c062d7afb9b3c231edc477a7a0
    	Contract Address: 0xe836df3c018cb0b53b168a09ab7a8e1b10077f25
    
    # Call TestExtention.dummyFunc
    	TXID (obtained after sending TX): 0x713ce28832cdc22aeabeb6c3deb495e5e54792bec609ee979437b7290c524a55
    	TXID (obtained at runtime and logged in Receipt): 0x713ce28832cdc22aeabeb6c3deb495e5e54792bec609ee979437b7290c524a55
    

    My demo code can be found here. It deploys contract TestExtension on the testnet and sends a transaction that invokes its method dummyFunc. The first TxID is immediately returned by Connex after the transaction is sent off. The second TxID is obtained from the transaction receipt after the transaction is executed by the blockchain system. It can be seen that the two TxIDs are exactly the same, demonstrating the effectiveness of the transaction-runtime-info mechanism.

    Previous Articles

    What you might not know about VeChainThor yet (Part I) - Transaction Uniqueness

    What you might not know about VeChainThor yet (Part II) - Forcible Transaction Dependency

    What you might not know about VeChainThor yet (Part III) - Transaction Fee Delegation (VIP-191)

    What you might not know about VeChainThor yet (Part IV) - Mining gas price

    What you might not know about VeChainThor yet (Part V) - Customizing Your Own VeChainThor

    What you might not know about VeChainThor yet (Part VI) - On-Chain Governance


Log in to reply