lexnv: Retain at rank I #213
Open
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.
Argument
Over the recent months, I have focused my efforts on the Ethereum Block Storage implementation in Substrate's Pallet Revive. This is part of a company-wide effort to bring EVM smart contract support to Substrate. At the same time, I continued to offer support for litep2p, pending fixes and reviews on the WebRTC work.
Ethereum Block Storage
I implemented an Ethereum-compatible block within
pallet-revive(the Substrate EVM pallet) to enable full Ethereum block reconstruction, including block hashes, transaction roots, and receipt roots, directly within the Substrate runtime.The #PR 9418 introduces a memory-efficient Ethereum block builder that constructs a full Ethereum block on-chain using only Substrate runtime data.
The implementation achieves a low memory footprint, avoiding pallet storage bloat and consuming up to 90% less memory and storage. This utilizes low-level semantics of RLP encoding to incrementally build the transaction and receipt roots, while keeping a maximum of 3 in-flight transactions.
The RPC layer has also been adjusted by Lukas and me to utilize the pallet changes.
For more details, the workload was monitored weekly in the following public document:
Weekly Progress Tracking
Litep2p Network Backend
I continued to monitor and support the litep2p crate. In doing so, I created a new release, litep2p v0.11.1, which mitigates an edge case that causes nodes to panic on unexpected rust-yamux inbound connections — addressed in PR #445. I also submitted a fix in the upstream
rust-yamuxcrate to ensure poisoned states are no longer polled: rust-yamux #211.During this period, I’ve also been in contact with Tim from ChainSafe to provide feedback on their WebRTC work, which is progressing in the right direction: litep2p WebRTC PR #441.
cc @skunert @sandreim 🙏