[abandon] release: draft release v1.2.0 #1491
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
) * core/vm: deepcopy jumptable when enabling extra eips When the interpreter is configured to use extra-eips, this change makes it so that all the opcodes are deep-copied, to prevent accidental modification of the 'base' jumptable. Original-auther: yihuang <huang@crypto.com> Co-authored-by: Martin Holst Swende <martin@swende.se> * core/vm: implement EIP-3860: Limit and meter initcode Implementation of https://eips.ethereum.org/EIPS/eip-3860, limit and meter initcode. Most of this change takes the go-ethereum implementation as reference. Original-author: Andrei Maiboroda <andrei@ethereum.org> Co-authored-by: lightclient@protonmail.com <lightclient@protonmail.com> Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de> * core/vm: implement EIP-3855: PUSH0 instruction * core/vm: Implement PUSH0 * Move PUSH0 to enable3855 * Add method doc Original-author: Alex Beregszaszi <alex@rtfs.hu> * core/vm: enable EIP-3855 (PUSH0) in Boneh Original-author: Andrew Ashikhmin <34320705+yperbasis@users.noreply.github.com> * core/vm: Fix issue of incorrect instructionSet used for jump_table Also update the related test case for gas change. * core/vm: fix test cases issues that not suitable for boneh * core/vm: reuse ErrMaxInitCodeSizeExceeded as error message --------- Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: lightclient@protonmail.com <lightclient@protonmail.com> Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>
Integration API for EIP-4337 bundler with an L2 validator/sequencer
Co-authored-by: Matus Kysel <matus.kysel@binance.com>
brilliant-lx
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
v1.2.0 is a hard-fork release for BSC testnet.
It is a big release, since it includes the big feature: FastFinality.
The Chapel testnet is expected to have a scheduled hardfork upgrade named
Bonehat block height 29,295,050. The current block generation speed forecasts this to occur around 27th April 2023 at 06:30 AM (UTC).The
Bonehhardfork includes 3 BEPs:BEP-126: Introduce Fast Finality Mechanism 6(The 1st Part)
BEP-174: Cross Chain Relayer Management 5
BEP-221: CometBFT Light Block Validation
The validators and full node operators on Chapel testnet should switch their software version to v1.2.0 before 27th April 2023.
Rationale
FEATURE
#936 BEP-126: Introduce Fast Finality Mechanism
#1325 genesis: add BEP174 changes to relayer contract
#1357 Integration API for EIP-4337 bundler with an L2 validator/sequencer
#1463 BEP-221: implement cometBFT light block validation
IMPROVEMENT
#1486 feature: remove diff protocol registration
#1434 fix: improvements after testing fast finality
BUGFIX
#1430 docker: upgrade alpine version & remove apks version
#1458 cmd/faucet: clear reqs list when reorg to lower nonce
#1464 fix: panic on using WaitGroup after it is freed
#1484 fix: a deadlock caused by bsc protocol handeshake timeout
Example
None