Closed yanghang8612 closed 1 year ago
Well done!
permit type transaction has its own specific usage scenarios, and chainid is the required item. So i'm glad to see this optimization.
chainid
?In the upcoming release of the new version of java-tron, the proposal corresponding to this TIP is named as getAllowOptimizedReturnValueOfChainId
.Developers can query the status of the proposal to determine if the proposal has taken effect through the /wallet/getchainparameters
interface provided by the fullnode or TronGrid.
For contracts that dynamically obtain the value of the chainid
, the off-chain signing service should also dynamically obtain the value of the chainid
by reading the contract or querying the eth_chainId
interface provided by the fullnode or TronGird.
For contracts that solidify the value of the chainid
as a constant, the off-chain signing service should also configure the value of the chainid
as a constant.
Close this issue as it is implemented by GreatVoyage-v4.7.0.1. Check TIP detail at TIP-474 Check implementation PR at https://github.com/tronprotocol/java-tron/pull/4863
Abstract
This TIP aims to optimize the return value of the
chainid
opcode.Motivation
The chainId of the TRON mainnet can be queried through the
jsonrpc
interface, as followsAfter the
Istanbul
proposal takes effect, thechainid
opcode becomes valid and it pushes the genesis block id of the current chain onto the stack (defined in tip-174).In different networks, the return values of the
chainid
opcode are as follows:mainnet
: 0x00000000000000001ebf88508a03865c71d452e25f4d51194196a1d22b6653dcnile
: 0x0000000000000000d698d4192c56cb6be724a558448e2684802de4d6cd8690dcshasta
: 0x0000000000000000de1aa88295e1fcf982742f773e0419c5a9c134c994a9059eThe return value of the
chainid
opcode does not match the chainId value queried by thejsonrpc
interface. When dApp developers use tools such as metamask to access the TRON network and send transactions, this difference will cause some transactions to fail, such as permit type transactions.Meanwhile, the return value of the
chainid
opcode is very large. For the javascript language that commonly used in web3 application development, the maximum integer value isNumber.MAX_SAFE_INTEGER
(defined in link), and it is clear that the above return values exceed thatNumber.MAX_SAFE_INTEGER
.Number.MAX_SAFE_INTEGER
: 2**53 - 1 = 9007199254740991Therefore, it is necessary to optimize the return value of the
chainid
opcode in the TRON network.Specification
After the
getAllowOptimizedReturnValueOfChainId(71th)
proposal takes effect, thechainid
opcode pushes the same value as thejsonrpc
interface onto the stack.The new return value of the
chainid
opcode for all networks are as follows:mainnet
:nile
:shasta
:Rationale
The new values above do not conflict with any chainId of the existing EVM networks.
Backwards Compatibility
Firstly the new return values proposed in this tip are consistent with some of the TRON community's protocol standards, such as tip-1193 and tip-712.
Secondly, backwards compatibility is still under consideration for currently existing contracts, especially for some TRC20 with permit extentions.
Based on the mainnet data on April 24, we exhaustively analyzed the bytecode of deployed smart contracts, totaling
1,474,264
, including172
contracts containing thechainid
instruction. We have the following analysis results, starting from the form of thechainid
instruction, TVL and number of transactions. For the form of using thechainid
instruction, we have divided into the following 3 categorieschainid
instruction, 134 in total, including 12 contracts that only query the chainid methodAccording to the TVL of the contract and the number of transactions, we counted the top 10 contracts, as follows:
Most of the above contracts are
Class I
contracts, while the TVL of the top 10 is low. For the remaining types of contracts, they have no TVL and few transactions.The use scenario of the
chainid
instruction is generally for participating in the calculation ofdomainSeparator
ofeip-712
ortip-712
.After analyzing the above 171 contracts, we found that the main methods used are the
permit
method ordelegateBySig
method. The above 2 methods are usually used for users to sign under the chain so as to perform authorization, transfer and some other operations. This method is an extension method and will not affect common contracts such as TRC20, TRC721, DeFi, etc.Based on the above analysis, we believe that this tip's optimization for the return value of the
chainid
instruction will not cause serious problems. However, it needs the attention of dApp developers as follows:Class I
contracts, the developer should modify the non-contract code to use the new chainid for off-chain signature calculation after this tip takes effect.Class II
contracts, developers do not need to modify the code and still use the old chainid for off-chain signature calculation.Class III
contracts, developers should evaluate the impact as soon as possible, and the contracts under this classification are as followsSecurity Considerations
There is no known security consideration.
Welcome to discuss