Welcome Back! Security for the EIP Process
The risk profile for blockchain protocols creates strong incentives for adversarial actors with potentially severe consequences. No wonder we were surprised to realize that security was not yet explicitly part of Ethereum’s core change management process.
That’s why ‐ earlier last year ‐ we set out on a journey to incorporate Security Considerations into one of Ethereum’s most critical process.
Executive Summary
- We filed Ethereum/EIPs#1963 to re-align the EIP process with PEP/IETF RFC and bring back a mandatory Security Considerations section to proposals.
- Ethereum/EIPs#1963 was accepted and is effective for new EIPs as of late December 2019 🙌.
Background on the EIP process
The Ethereum Improvement Proposal (EIP) process drives change management for Ethereum. It is the primary mechanisms for proposing changes to the Ethereum protocol, collecting community input, and documenting design decisions.
It is defined with EIP-1 and heavily inspired by how the Bitcoin community manages changes with the Bitcoin Improvement Proposal system (BIP). BIP, in turn, is derived from an older version of the Python Enhancement Proposals (PEP), which itself was based on the IETF’s RFC process.
While security discussion has long been required by the IETF RFC process, PEP did not have it until earlier this year. Since BIP is based on an outdated version of PEP, and EIP is based on BIP, neither were designed to explicitly require a security discussion.
This explains why, when we looked at how the EIP process manages the risk of a proposal, we found no explicit call for a security discussion to take place. Without security integrated into the process, risk is managed on an ad-hoc basis. The result is that the inclusion of security considerations is heavily dependant on the reviewer judgement.
Fortunately, our experience is that the majority of EIP authors and editors are highly sensitive to the importance of security, and recognize the need to incorporate it without prompting.
The unsung heroes of the story are the EIP editors who voluntarily moderate the process, guide authors and drive discussion with the community and the Ethereum core developers. They shoulder a large portion of the security burden and in our opinion do not receive sufficient recogniztion for the service. Thank you EIP editors!
Speaking of the process, ideally, security should be a natural part of the change process. Proposals should be required to consider security early on in the design phase and key decisions must be documented with them. Keeping security information up-to-date should ensure that relevant external discussions are referenced, allowing the security community to easily access information and participate in the review process.
EIP Security Considerations to the rescue!
Altering established processes is not an easy task and must be done with care. Even seemingly minor adjustments can have undesirable effects on the process or stakeholders. For this reason followed an approach similar to the one taken by IETF-RFC to integrate security into their proposal system:
1. Embed minimal security into the process:
Requiring a mandatory security discussion with the proposal, beginning with intentionally lax requirements on how to start it. The idea is to minimize the extra effort imposed on authors while establishing it as part of the process. A security discussion can be as simple as “There is no security implications for this proposal”. Proposals that fail to provide a security discussion or at least a statement outlining their reasoning may not proceed to the next stage in the process.
2. Follow-up with guidance:
Observe how security considerations are treated within new proposals as they emerge, and provide guidance on how to write useful security considerations.
Our Journey
Since we couldn’t find a process chart clearly depicting the EIP stages, the inputs, outputs, and activities performed, (and because we love visualizing things) we derived our own chart based on the information we found in EIP-1 and our experience with the process.
The EIP Process chart (click to enlarge)
The current status of our proposal was tracked at Ethereum/EIPs#1963.
We also presented the proposal at the ETH1.x Core Devs Meeting in April last year and gained input from the IETF on improving these processes by presenting at IETF 105 Montreal.
It has been a journey but we are glad to see this change accepted and to have security embedded into the EIP process, step-by-step, similar to PEP and RFC. We are looking forward to participating more actively in the EIP process and continuing to help improve security together with the community ❤.
Appendix
How do other systems integrate security?
Bitcoin (BIP)
The situation is quite similar for Bitcoin and BIP. Security discussions are ad-hoc, driven by security-aware authors, editors and members of the community. However, security is not a requirement of the proposal system either and there is no easy way to quickly access relevant security discussions.
Python (PEP)
Earlier last year Python updated PEP-0001 to require a security discussion with their proposals. The current version states:
- Security Implications – If there are security concerns in relation to the PEP, those concerns should be explicitly written out to make sure reviewers of the PEP are aware of them.
With this move, they are following what is part of the IETF RFC for decades.
IETF RFC
Mandatory security discussions are required since RFC-1543 (1993) and this is still the case with the latest RFC style guide defined with RFC-1543 (2014). Additional guidance for security discussions is provided with RFC-3552 (2003).
References
- EIP: Ethereum/EIPs#1963 - EIP Security Considerations
- ETH-Magicians: Discussion
- CoreDevs eth1x Meeting Berlin 2019: Presentation, Slides, Follow-Up Actions
- IETF 105 Montreal: Talk
- Other: “Security Considerations” as defined in RFC7322
- Initial EIP Draft: eip-draft_security_considerations
Thinking about smart contract security? We can provide training, ongoing advice, and smart contract auditing. Contact us.