Proposal: enable the return value of the chainid opcode optimization

[yanghang8612]

Proposal to enable the return value of the chainid opcode optimization

Simple Summary

This proposal aims to optimize the return value of the chainid opcode. For more detailed information about chainid opcode optimization, please refer to: TIP-474.

Motivation

In different networks, the return values of the chainid opcode are as follows:

• mainnet: 0x00000000000000001ebf88508a03865c71d452e25f4d51194196a1d22b6653dc
• nile: 0x0000000000000000d698d4192c56cb6be724a558448e2684802de4d6cd8690dc
• shasta: 0x0000000000000000de1aa88295e1fcf982742f773e0419c5a9c134c994a9059e

The return value of the chainid opcode shown above has the following drawbacks:

1. The return value of the chainid opcode does not match the chainId value queried by the jsonrpc 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.

2. 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 is Number.MAX_SAFE_INTEGER = 2**53 - 1 = 9007199254740991, and it is clear that the above return values exceed that Number.MAX_SAFE_INTEGER.

Therefore, it is necessary to optimize the return value of the chainid opcode.

Timeline

Voting request expected to be submitted in early May.

How to Initialize the Voting Request

• Open the return value of the chainid opcode optimization proposal.

  • CreateProposal 71 1

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, after analyzing the bytecode of the smart contracts on the mainnet and extensive community discussions, we concluded that the proposal has no significant forward compatibility issues. See issue for related analysis and discussion.

[WalterBrooks]

Ok ... finally someone came up with this idea, it trapped me a lot in permit transaction. When can I test it on testnet?

[CooperDepp]

Hi I have one question, I noticed that in #tip-474 you mentioned the new return values do not conflict with any chain ID of existing EVM networks.

But how can you ensure that there will not be one in the future, is there a list to record it or something to let people know the return value of TRON networks?

[yanghang8612]

@WalterBrooks It will soon be opened on the nile testnet.

[Ademillery]

Hi I have one question, I noticed that in #tip-474 you mentioned the new return values do not conflict with any chain ID of existing EVM networks.

But how can you ensure that there will not be one in the future, is there a list to record it or something to let people know the return value of TRON networks?

The return value of EVM networks starts from 1, in descending order by natural number. While the return value of TRON networks is a 9 to 10 digit number, it is hardly to have conflict in the future.

[Ademillery]

I have a new question, when I look back at the TIP #474 , you were saying that: 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.

However, actually, I can not add TRON network in the Metamask wallet, is it due to this chainId opcode issue? If so, after this tip is enabled, can I add TRON network in Metamask? Will there be any other problems such as address transfer.

[okwapa210]

I have a new question, when I look back at the TIP #474 , you were saying that: 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.

However, actually, I can not add TRON network in the Metamask wallet, is it due to this chainId opcode issue? If so, after this tip is enabled, can I add TRON network in Metamask? Will there be any other problems such as address transfer.

Java-tron supports json-rpc interface, metamask still cannot access TRON, because the TRON protocol is not fully compatible with ETH json-rpc.

Metamask use the json-rpc:eth_chainId to query the chainid, and then send the permit transaction to smartcontract, but the problem now is that the chainid returned by Java-tron:Json-rpc is inconsistent with the chainid obtained in the smart-contract, smart-conract can not verify the permit transaction, but I think he is assuming that metamask can connect to TRON

[Velmurganvelmurgan]

vvelmurgan623@gmail.com

[yanghang8612]

Thanks to everyone's contribution to this proposal.

This issue will be closed as it is already going to effect, check detail at: https://tronscan.org/#/proposal/85