[English translation]
PIP: 7
Topic: PlatON network to support ChainID 100 and 210425
Author: benbaley
Status: Draft
Type: Upgrade
Description: It is proposed that the PlatON mainnet should support and be adapted to both ChainID 100 and 210425
Created: 2022-02-11
Proposal on Supporting Two ChainIDs in the PlatON Network
Background
The current ChainID of the PlatON mainnet is 100, which conflicts with that of other networks registered in ethereum-lists/chains. To better support DApps like MetaMask, another ChainID is needed, one that is unique and registered by a unified third-party platform under the EVM framework. As the PlatON mainnet has been running for nearly a year, the existing ecosystem tools (wallets, browsers, etc.) cannot be immediately migrated or adapted to the new ChainID. It is therefore proposed that the PlatON mainnet should support two ChainIDs at the same time for a certain period.
Overview
The current ChainID of the PlatON mainnet conflicts with that of other networks, which may lead to the following problems:
-
Transactions on other chains might be replayed on the PlatON network.
-
Third-party applications such as MetaMask may not be uniquely adapted to the PlatON network
As such, our ultimate goal is to update the ChainID of the mainnet from 100 to 210425. This goal will be achieved in two steps:
-
Support the new ChainID 210425
We can first make sure that the mainnet support the new ChainID 210425 through PlatON’s unique upgrade proposal. In the meantime, the existing ChainID100 will also be supported. This means that the mainnet will be well adapted to tools such as MetaMask. Moreover, the upgrade will enable the fast development of new DApps while offering compatibility for applications currently running on PlatON.
-
The PlatON network will stop supporting ChainID100 sometime in the future.
Upon completion of Step 1 of the upgrade, all new applications will be developed and run directly using the new ChainID. For existing DApps (applicable only to applications using ChainID), there will be enough time for adaptation and upgrade. Following a sufficient adjustment period, a new upgrade proposal will be initiated and the old ChainID will no longer be supported.
Principle
The primary functions of ChianID in the PlatON network are as follows:
- Avoid transaction replay
ChainID is added to the transaction signature to distinguish between different chains and avoid executing the transactions on other chains in the PlatON network. In addition to recording the ChainID, the V value is also used to mark the parity of the Y value of the elliptic curve. Therefore, so as long as the two ChainIDs are not consecutive numbers, the ChainID entered when the user provides his/her signature can be obtained based on the V value.
- Prevent alien attack
ChainID is added to the P2P handshake message to determine whether the nodes belong to the same chain. Adaptation is subject to whether the ChainID contained in the handshake message coincides with one of the two ChainIDs supported by PlatON.
Implementation
- Transaction verification
v = v - 2*100 (the existing ChainID)
v = v - 8
if v > 28
then
v = v - (the new ChainID - the existing ChainID)
Determine if v equals 27 or 28
Yes
To be verified using the new ChianID
No
The signature is illegitimate
else
To be verified using the existing ChianID
- P2P handshake
When processing messages that include ping, pong, findnode, and neighbors, the Rest field will be directly verified. The message will be deemed valid if the number coincides with one of the two ChainIDs. When the ChainID of the received ping message coincides with the old ChainID, the returned message of pong will also return the old ChainID. The same principle also applies to findnode and neighbors.
- opCode(0x46)
When the EVM executes the CHAINID command, verification will be subject to the version number. Before the upgrade proposal, the old ChainID will be used; after the upgrade, the new ChainID will be adopted.
Impact Analysis
The implementation of this proposal at the underlying level will have the following impacts:
- An upgrade of on-chain governance is required
Such an upgrade indicates that a fork is required. Though the new client will be compatible with transactions and nodes using the old ChainID, the old client will not be able to support transactions and nodes using the new ChainID.
- Impact on P2P links
As new nodes will be using a new ChainID, the new node message contains a new ChainID when the nodes are discovered (UDP message, corresponding to Ping, Pong, Findnode, Neighbors). To old nodes, such a message means that the nodes do not belong to the current blockchain. Moreover, a new node cannot discover old nodes and may only connect to other new nodes. However, an old node can discover new nodes and connect to such nodes.
- DApps should be upgraded and adapted to the new ChianID
Given that the ChainID of the new client version will be updated to 210425, the EVM command for obtaining the ChaiID should determine whether to return the new ChainID or the old ChainID according to the version number (on-chain). As such, DApps that use ChainID in the contract logic need to be readapted. Applications with a hard-coded ChainID logic in the contract may only be adapted by migrating the relevant data from the old contract to the new contract after the new contract is redeployed. If ChianID is used on the application level (off-chain), self-adaptation in the coding logic of the application level will be required.
Links
-
Chain Agnostic Improvement Proposals
-
Ethereum-lists: Resigtered ChainID of the PlatON mainnet
