Author: Michael Johnson
The Ethereum network will be undergoing a scheduled upgrade at block number 9,200,000, which is predicted to occur on Wednesday, January 1, 2020. The exact date is subject to change due to variable block times and timezones. Please upgrade your node before Wednesday, December 30, 2019 to account for the variable block times Ethernodes.org has kindly provided Istanbul node statistics and a countdown timer located at https://ethernodes.org/muir_glacier. etherscan.io has provided a countdown timer located at https://etherscan.io/block/countdown/9200000. You can monitor the network upgrade in real time at http://forkmon.ethdevops.io/ (it will be updated shortly before the fork). What is Muir Glacier? Muir…
In the last edition of The 1.x files, we did a quick re-cap of where the Eth 1.x research initiative came from, what’s at stake, and what some possible solutions are. We ended with the concept of stateless ethereum, and left a more detailed examination of the stateless client for this post. Stateless is the new direction of Eth 1.x research, so we’re going to do a pretty deep dive and get a real sense of the challenges and possibilities that are expected on the road ahead. For those that want to dive even deeper, I’ll do my best to…
The idea behind the Vyper Project was to develop something that was designed at the language level to naturally exhibit a high degree of safety. The project was originally authored by Vitalik as a proof-of-concept replacement for Serpent, its predecessor, but shortly after its creation Vyper found itself without a dedicated maintainer. Luckily, there were enthusiastic community members that took up the torch and continued development of the project, and we (the EF Python Team) became re-involved in the project for some time earlier this year. This fall, a preliminary security audit was performed by the Consensys Diligence team on…
Thanks to Joseph Schweitzer and Danny Ryan for review. Welcome back! Having discussed eth2’s design philosophy last time, today’s focus is on eth2’s incentives through the lens of that philosophy. More specifically, we look at the incentives effecting eth2 and how they are realised in the form of rewards, penalties, and slashings. We then walk through how and why validators are incentivised to remain online, why you won’t be slashed for going offline, and more. Let’s dig in. If not for being offline, when do slashings occur? ⚔️ Slashing has two purposes: (1) to make it prohibitively expensive to attack…
Welcome to the first eth2 quick update of 2020! This is going to be an exciting year. tldr; Release of v0.10.0 spec as stable target for multi-client testnets and security reviews@paulhauner and @sigp_io team hard at work building LighthouseRelaunch of Prysm testnet, now with aggregators and mainnet configurationA new proposal for an expedited merging of eth1+eth2 (aka Phase 1.5) Release of v0.10.0 for security reviews and multi-client testnets v0.10.0 — 404 Not Found was released last week. Read the release notes for the technical details (integration of IETF BLS, simpler eth1 caching, etc), but what does it actually mean for…
January 14th tl;dc (too long, didn’t call) Disclaimer: This is a digest of the topics discussed in the recurring Eth1.x research call, and doesn’t represent finalized plans or commitments to network upgrades. The main topics of this call were Rough data quantifying advantages of switching to a binary trie structureTransition strategies and potential challenges for a switch to binary tries”Merklizing” contract code for witnesses, and implications for gas scheduling/meteringChain pruning and historical chain/state data — network implications and approaches to distribution. Logistics The weekend following EthCC (March 7-8), there will be a small 1.x research summit, with the intent of…
I started to write a post that detailed a “roadmap” for Ethereum 1.x research and the path to stateless Ethereum, and realized that it’s not actually a roadmap at all —— at least not in the sense we’re used to seeing from something like a product or company. The 1.x team, although working toward a common goal, is an eclectic collection of developers and researchers independently tackling intricately related topics. Consequently, there is no “official” roadmap to speak of. It’s not complete chaos though! There is an understood “order of operations”; some things must happen before others, certain solutions are…
The try/catch syntax introduced in 0.6.0 is arguably the biggest leap in error handling capabilities in Solidity, since reason strings for revert and require were released in v0.4.22. Both try and catch have been reserved keywords since v0.5.9 and now we can use them to handle failures in external function calls without rolling back the complete transaction (state changes in the called function are still rolled back, but the ones in the calling function are not). We are moving one step away from the purist “all-or-nothing” approach in a transaction lifecycle, which falls short of practical behaviour we often want.…
Keep it coming tldr; Runtime Verification audit and verification of deposit contract Runtime Verification recently completed their audit and formal verification of the eth2 deposit contract bytecode. This is a significant milestone bringing us closer to the eth2 Phase 0 mainnet. Now that this work is complete, I ask for review and comment by the community. If there are gaps or errors in the formal specification, please post an issue on the eth2 specs repo. The formal semantics specified in the K Framework define the precise behaviors the EVM bytecode should exibit and proves that these behaviors hold. These include…