jpitts
November 6, 2018, 5:39pm
1
Everyone hates checklists, but Ethereum will only reach its potential if we can regulate it with the gravity of flight engineering.
“Ethereum Engineering Processes” is an excellent resource proposed / created by @karalabe .
He starts by proposing EEP-1, a workflow for network participants on how to roll out consensus upgrades onto the Ethereum mainnet reliably and reproducibly.
---
EEP: 1
Title: Consensus update rollout
Authors: Péter Szilágyi <peter@ethereum.org>
Status: Draft
Version: 2018-11-06
Discuss:
---
*Ethereum is a mission critical system, the long-term sustainability of which requires strict engineering practices over rock-star development. Part of that effort is ensuring we have well defined processes that all ecosystem participants understand, agree with and adhere to. Everyone hates checklists, but Ethereum will only reach its potential if we can regulate it with the gravity of flight engineering.*
*All amendments to this standardized workflow must be rationalized via real world failures, which must be included for future reference to avoid regressions. When adding a new item, please also include an inline explanation to help newcomers.*
## Abstract
The goal of this document is to act as a step-by-step guide for network participants on how to roll out consensus upgrades onto the Ethereum network in a reliable and reproducible fashion. It defines the timelines and deliverables different teams must follow, as well as the emergency procedures in case something foreseeable goes wrong.
The scope of this document is *not* the specification, implementation and preparation of forks. Rather, the scope of this document is to outline their safe rollout once the ecosystem gives the green light on deploying them.
## Preconditions
show original
Related to this topic are recent posts about the disorderly Constantinople-related fork on Ropsten:
This case brings up interesting developer coordination issues and illustrates the importance of a well-defined testing process as client developers prepare to implement changes affecting mainnet.
In this planned activation of changes on Ropsten testnet, when the forking block was reached, there was not enough mining power from Ropsten clients implementing Constantinpole changes. This led to a disorderly forking in which the intended upgraded network failed to quickly materialize / become domina…
Context: AllCoreDevs meetings notes #47 on Fri, September 28, 2018
“Geth, Parity, aleth, ethereumj, mana, nethermind - completed implementation of all EIPs”
“we should probably pick a block number today for testnet fork”
“Let’s go with Ropsten block 4.2M, that puts us at this time in 11 days, on Oct. 9”
Certain client development stakeholders wanted to activate forking changes / Constantinople in order to identify possible consensus bugs and reduce risks for when these changes are activate…
1 Like