The security specialist published his thoughts on one of Ethereum’s currently prominent improvement proposals. His thoughts on the matter provide insight into some new features coming with the next hard fork, Constantinople.
Today, Ethereum security lead, Martin Swende[1], published the first entry of a series[2] focusing on features that are being considered for the forthcoming Ethereum hard fork, Constantinople[3].
The series begins with a thorough analysis of EIP 210[4], which was authored by Vitalik Buterin and intended to address blockhash refactoring.
Blockhash refactoring allows newer blocks in a blockchain to link directly to much older ones, helping to increase connections between blocks. This helps to streamline light client proofs, allowing them to verify subchain "key blocks" instead of requiring light clients to verify an entire header chain.
Building from Buterin's EIP, Swende explains how a blockhash refactoring update as part of Constantinople would be implemented via a peculiar three-part process. Per Swende:
Designed to "both replace and expand" the way pre-Constantinople contracts obtain blockhashes, EIP 210 proposes to update the way EDCCs (or smart contracts) access hashes. Swende said that this "enables improving the light client protocol," and Buterin believes it will make "the protocol more 'pure.'"
As noted by Buterin's EIP, these blockchash updates will save Ethereum client implementations from having to explicitly "look into historical block hashes," allowing a significant portion of the "implied state" (data that is technically apart of the state but not a part of the state tree) to be removed.
As the second part of Metropolis[5] after Byzantium[6], the Constantinople fork received "meta" EIP 1013[7], which, in addition to EIP 210, contains EIP
