How to adapt to Optimization of the Return Value of chainid opcode in TVM?

At present, the return value of the chainid instruction in the smart contract on TRON is the hash of the genesis block. After the optimization is enabled, the return value of the chainid instruction will be the last four bytes of the genesis block hash, please refer to TIP-474. The modified return value will be consistent with the return value of eth_chainId of the JSON-RPC interface of Java-tron.

Currently, the optimization of the return value of chainid opcode has been enabled on nile testnet. And it is expected to be enabled on mainnet in early May. For more information, please refer to TIP-527.

This article will introduce why the return value of chainid is optimized, the optimization principle, and how to adapt to it.

Why should the value be optimized?

After the TRON Istanbul proposal took effect, the TRON Virtual Machine (TVM) can confirm the current chain through the return value of the chainid instruction. The current return values of each chain are as follows,

mainnet: 0x00000000000000001ebf88508a03865c71d452e25f4d51194196a1d22b6653dc

nile: 0x0000000000000000d698d4192c56cb6be724a558448e2684802de4d6cd8690dc

shasta: 0x0000000000000000de1aa88295e1fcf982742f773e0419c5a9c134c994a9059e

However, the return value has two problems,

1. The return value of TVM chainid opcode is inconsistent with the return value of the JSON-RPC interface eth_chainId of the java-tron node. TVM chainid instruction returns the complete hash value of the genesis block and the eth_chainId API returns the last four bytes hash value of the genesis block.
2. The value represented by the hash of the genesis block is too large, exceeding the maximum integer value of the Javascript commonly used in web3: Number.MAX_SAFE_INTEGER = 2**53–1 = 9007199254740991

These problems are inconvenient to developers, therefore, optimization of the return value of chainid opcode is necessary.

Optimization Principles

In order to solve the problems, the proposal defines the return value of TVM `chainid` as the last four bytes of the genesis block hash. After the proposal takes effect, the return value of TVM `chainId` will become as follows,

mainnet:

• In Hex: 0x2b6653dc
• In Decimal: 728126428

nile:

• In Hex: 0xcd8690dc
• In Decimal: 3448148188

shasta:

• In Hex: 0x94a9059e
• In Decimal: 2494104990

So that the optimization of the return value is consistent with Java-tron eth_chainId API.

How to adapt?

After a comprehensive analysis of the deployed smart contracts on-chain, the current contract function involving the TVM chainid instruction on the chain is permit or delegateBySig. This type of application scenario is to sign a message containing chain id off the chain and submit it to the smart contract on the chain for signature verification, the contract obtains the chain id of the current chain through the chainid instruction or uses the hard-coded chain id in the contract code to verify whether the chain id in the message is correct.

Based on the above analysis, after the return value optimization proposal takes effect, if your business meets the above application scenarios, you can refer to the following methods for adaption,

• If the smart contract verifies the message by dynamically obtaining the chain id through the TVM chainid instruction for message verification, then the last four bytes of the genesis block of the current chain must be used as the chain id to construct the message.
• If a hard-coded chain id is used for message verification in the smart contract, the chain id of the off-chain constructed signature message must be consistent with the hard-coded chain id in the contract.

Summary

After the proposal to optimize the return value of the TVM chainid opcode takes effect, it will improve the availability of the off-chain signatures used on the chain and help reduce the complexity of development work.