PlatON Mainnet Optimization Upgrade Proposal [PIP-11]

PlatON Global Validating
#1

Hello everyone,

Recently, the PlatON core development team has compiled some optimization suggestions for the PlatON underlying system while collaborating with third-party teams on projects. Some of these suggestions have been organized into governance proposals for implementation on the PlatON mainnet.

PIP: 11
Topic: 1.4.0 Upgrade Proposal
Author: alliswell
Status: Draft
Type: Upgrade
Description: Light Node Protocol Support, Pre-EIP155 Transaction Compatibility
Created: 2023-02-17

PIP-11: PlatON Version Upgrade - 1.4.0

Purpose

By adding support for map protocol, EIP-2470, and other features in the block and transaction information, PlatON can be more flexible in adapting to different applications while remaining compatible with EVM. This will further promote ecological prosperity.

New Features

1, Add validator summary to Block.Header.Extra field

PlatON is a public chain based on Proof of Stake (PoS) consensus. Based on the development requirements of the light node client protocol Map protocol, it is currently impossible to verify PlatON consensus validators based on the block header information. This proposal adds a summary (hash) of the corresponding consensus round validators to the extra field to meet the needs of verifying the consensus validator list.

  • Specific Rules:

block.extra: The first 32 bytes store the hash value of the validator list.

Writing time for hash: Write to the last block of each consensus round.

hash meaning： The hash value after the RLP of the node list in the next consensus round.

hash rule：

// RLP encode the list of nodes for the consensus round.
rlpValue := rlp.encode([{pubKey1,blsPubKey2},{pubKey1,blsPubKey2},...])
// Hash the encoded data.
hash := Keccak256(rlpValue)
  • New RPC interface:

GetValidatorByBlockNumber

The RPC call parameters and return values are as follows:

[ Parameter ]

Field Type Description
blockNumber uint64 block height

[ Return Data ]

Type: collection, arranged in block order.

Field Type Description
address 20byte node address
pubKey 64byte node public key
blsPubKey 96byte node bls public key

2, Compatibility with pre-EIP155 transactions

To solve the problem of DApps needing to use the same instance in different chains as stated in EIP-2470, the underlying chain needs to be compatible with transactions signed without chain IDs (pre-EIP155) in order to achieve this. To further promote the ecological prosperity of PlatON, pre-EIP155 transactions should be supported.

  • Specific Rules：

Startup parameters：Synchronize the content about non eip155 replay protected tx in Ethereum v1.10.0, add the startup parameter rpc.allow-unprotected-txs to allow rpc to submit pre-eip155 type transactions

Transaction execution: allow pre-eip155 type transactions to be packaged into blocks

Impact statement

  1. This proposal involves changes to the block structure information, and after the proposal is passed, old version clients will not be able to continue syncing new blocks.
  2. PlatON’s transaction signature supports 100 and 210425 two chainids, and also supports no chainid. Sending a transaction through the unlock method of the wallet hosted in the node keystore will use the 210425 signature transaction by default.

Version information

The version number for this upgrade is 1.4.0.
Commit-ID: To Be Determined

For the above proposal, everyone is welcome to discuss it together.
Let’s contribute to PlatON together!

1 个赞