EIP Fun Weekly #28: Parallel EVM
Get the latest updates on EIP discussions about parallel EVM, discussion about modification of EIP process to account for security treatments,and more.
Hello everyone! Welcome to read the 28th issue of EIP Fun Weekly. Let's take a look at what happened in the EIP community this week.
EIP Updates
Due to the Christmas holiday, meetings and formal changes to EIPs have been suspended this week. Therefore, let's shift our focus to the "EIP of the Week."
EIP of the Week
Then let's take a look together at the applications or developments related to EIPs this week.
EIP 6467: Stealth Meta-Address Registry
This specification outlines a standardized method for storing and retrieving a stealth meta-address associated with an entity. It expands upon the concepts introduced in EIP-5564.
Why propose it?
Standardizing the generation of stealth addresses has the potential to significantly improve privacy on the Ethereum platform. It allows recipients of transfers to remain anonymous when receiving assets. By implementing a central smart contract for storing stealth meta-addresses, both external owned accounts (EOAs) and contracts can engage in stealth interactions using various stealth address schemes.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/stealth-meta-address-registry/12888/6
New Idea: Modification of EIP process to account for security treatments
The current EIP process assumes that once an EIP reaches the "final" state, its text cannot be modified, including the "Security Considerations" section. This can be problematic because security flaws can be discovered at any time, even in programs or specifications that have been in use for years. To address this, either the Security Considerations section should never reach its "final" state, or a specific process needs to be designed within the EIP procedure to allow for security disclosures in any EIPs.
Detailed Discussion
Proposal 1: Revise the existing paradigm of "Final EIPs are immutable" to a new approach where the "Abstract, Motivation, Specification, and Rationale" sections of final EIPs remain unchangeable, while allowing for updates to the "Security Considerations" section even after EIP finalization.
Proposal 2: Write an Ethereum Security Guideline - a set of rules that an application-level standard/program must adhere to. Violation of any of the Ethereum Security Guideline principles must be considered a red flag and indicated in the Security Considerations section of the proposal upon disclosure.
Proposal 3: Proposed changes to EIP-1 aim to enhance security by referencing the Security Guideline and updating the definition of the "final" status of EIPs to include the ability to add Security Considerations updates. If any new Security Considerations are discovered after the original EIP text is published, they can be proposed and included in the Security Considerations section. It is important to highlight any violations of Security Guideline principles in a prominent manner to raise awareness among potential implementers.
Further Reading
FEM forum discussion:
https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265ERC-7579: Minimal Modular Smart Accounts
Anecdote of the Week: Parallel EVM
Parallel EVM refers to the concept of running multiple Ethereum Virtual Machines (EVMs) in parallel, allowing for increased scalability and performance. This approach aims to address the limitations of the current single-threaded EVM by enabling concurrent execution of smart contracts, potentially leading to improved efficiency and throughput in blockchain networks.
Why do we need parallel EVM?
As we know, the EVM is the core of Ethereum, responsible for executing smart contracts and processing transactions.
Currently, the EVM is designed with an important feature to maintain network consistency and security: transactions are executed in a sequential manner. Sequential execution ensures that transactions and smart contracts are executed in a deterministic order, making it easier to manage and predict the state of the blockchain. This design choice prioritizes security and reduces the potential complexity and vulnerabilities associated with parallel execution.
In situations of high network load, the EVM's current sequential execution can lead to congestion and delays. To illustrate, imagine the original design of the EVM as vehicles on a single-lane road, where each vehicle must travel at the speed of the one in front. If one vehicle (transaction) experiences congestion, all subsequent vehicles are stuck behind. In contrast, parallel EVM is akin to expanding this single lane road into a multi-lane highway, allowing multiple vehicles to travel simultaneously. From a technical standpoint, parallel EVM enables independent transactions or smart contracts to execute concurrently, greatly enhancing EVM processing speed and system throughput.
How can we implement parallel EVM?
There are several ways to implement parallel EVM. One approach is to introduce a multi-threaded or multi-process execution model, allowing multiple EVM instances to execute smart contracts and process transactions in parallel.
Another method is to use sidechains or sharding techniques, dividing the entire network into parallel running segments, with each segment responsible for processing a portion of transactions and contract executions.
Furthermore, hardware acceleration and parallel computing technologies can be utilized to improve EVM processing speed. The key is to ensure the security, consistency, and scalability of the network while implementing parallel EVM.
EIP Events
Ethereum Cat Herders Meeting #123
Date & Time - January 2, 2024, at 16:00 UTC
For details about the meeting, you can visit this GitHub issue.
EIPIP Meeting #97
Date & Time - January 3, 2024, at 15:00 UTC
For details about the meeting, you can visit this GitHub issue.
AllCoreDevs Execution Layer Meeting #178
Date & Time - January 4, 2024, at 14:00 UTC
For details about the meeting, you can visit this GitHub issue.
That's all for this week from EIP Fun. EIP Fun is created and supported by LXDAO and PlanckerDAO. We aim to serve as the “layer 2” of the EIP ecosystem, simplifying and accelerating the adoption of EIPs.
Please inform us if you have any additional suggestions or feedback. EIP Fun is a fully open-source and community-driven public good! Donate to us here.
Join the Telegram of EIP Fun: https://t.me/eipfun for more discussions and build connections with EIP buidlers. Follow our Twitter: @EIPFun.