Faster, lighter, more secure.
These are just some of the benefits Metropolis, the next upgrade to the ethereum blockchain, promises to introduce when it's finally unveiled. Long the subject of curiosity and debate, the third phase in a four-step roadmap first unveiled in 2015 stands to enact perhaps the platform's most substantial changes.
But far from just a boon for the nascent technology, there is real risk in the rollout.
"Ethereum isn't safe or scalable. It is immature experimental tech," ethereum protocol developer Vlad Zamfir emphasized in a tweet earlier this year. If there's one upgrade that will lay this fact bare, Metropolis may be it.
Because substantial changes to the platform put real money in danger, ethereum developers have been inclined to take their time, choosing to write off grumblings from users, entrepreneurs and a market that seems eager for the technology to make its next big advance.
Hudson Jameson, the unofficial release manager for Metropolis, emphasised that the devs "always err on the side of caution" – a hesitancy which, although well advised, has lead to a string of delays. (A recent thread on r/ethereum, perhaps the biggest collection of the tech's enthusiasts globally even went so far as to question what exactly was the promised deadline to begin with – to conflicting conclusions).
But timeline aside, there's actually been big changes to the plans.
Metropolis, once conceived as the stage at which a user-friendly version of the technology would finally go live, has seen shifts that could change the final code rollout dramatically.
While once thought to usher in an age of "abstraction" – Vitalik Buterin referred to the concept in 2015 as "arguably its entire raison d’être" – what may finally be published is a more conservative version of the code.
Accordingly, the upgrade has now been split into two steps, named Byzantium and Constantinople, and though both are still evolving, an early picture of how they might ultimately impact the network is now taking shape.
Byzantium
As it stands today, Byzantium is set to involve a total of nine ethereum improvement protocols (EIPs), or individual code patches to the network. These include changes such as fixing the problem of difficulty adjustments, 'returndata' operations, 'static call' operations, new precompiles, a difficulty delay feature and embedding transaction return data in receipts.
All of these are engineered to make the network function more efficiently while minimizing potential exploits. Most correct small details which won’t be obvious to non-developers.
However, some are quite substantial.
Changes are underway that will better handle faulty code within smart contracts, so that payments will fail if there are mistakes in the programming. Additionally, these changes will have a transformative impact for the lifecycle of a contract, as contract upgrades can be pre-configured into the original code.
Contracts will also be newly secure, as certain changes are engineered to protect against something called a re-entrancy attack (when untrusted code enters a contract to manipulate it).
A new feature for embedding transaction return data in receipts will make it possible for light clients to determine if a transaction was successful or not without actually executing the transaction in a virtual machine. This will also affect off-chain tools.
Another upgrade will delay the difficulty bomb which currently detonating across the network, ensuring that transaction times do not become intolerable. (Transaction times are currently at around 25 seconds – high by ethereum's 10-second standards.)
This update will also decrease the rewards that miners are given for blocks, which will mean that the mining process will be faster and cheaper.
Another mining fix eliminates a previous error in the difficulty adjustment, to insure that the block time remains more stable.
New precompiles released on Byzantium pave the way for something called zk-snarks – a cryptographic procedure that for the first time, will allow genuinely private transactions to occur on the ethereum network. This is produced in collaboration with z-cash, the privacy-centric cryptocurrency that is the first widespread application of the technology.
Constantipole
So, what’s missing? Unfortunately, there is no release date set for Constantipole, the second hardfork of Metropolis. This is because certain edits were found to threaten assumptions set deep in ethereum's code, opening the doors to a number of potential exploits.
One EIP that is planned, though, paves way for lighter client implementations, by simplifying the process of evaluating a transaction. Currently, the evaluation of contracts requires both the current state of the blockchain and the hashes of the last 256 blocks. For lighter clients to exist this heavy information processing needs to be substantially reduced – and EIP 96 does this in an elegant way.
Yet, the main roadblock appears to be with EIP 86, the planned centerpiece of the project, and the most interesting (and complicated) of all EIPs.
EIP 86 wants to bring about the abstraction of account security, making accounts more flexible and more customizable, while allowing new features to be elaborated. Users can define their own security model, writing their cryptographic specifications into payments.
But, the problems with EIP 86 were so substantial that they will need a lot of time and effort to properly address.
For one, the protocol was revealed to mutate several invariants, opening endless loops of problems. Back in June, an exploit was discovered that would allow a malicious miner to take ownerships of wallets by reorganising the blockchain, or execute the same transaction repeatedly.
However, it is also possible that within the time it takes to finish coding them, new issues and potential improvements will emerge.
Alien city via Shutterstock
The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Interested in offering your expertise or insights to our reporting? Contact us at This email address is being protected from spambots. You need JavaScript enabled to view it..