Vitalik Buterin Brings Contract Code Size Debate To The Ethereum Community
Vitalik Buterin, creator of Ethereum, believes in transparency and reaching group consensus; core values of blockchain technology. That’s likely why he posted to the r/Ethereum subreddit a GitHub link titled: “EIP highlight: contract code size limit (debating for inclusion in HF2).”
He posted mainly to reach out to the community with his suggestion for fixing one of the few remaining issues before the next hard fork. It seems he wanted to stir up a little debate, so he could hear the community’s thoughts on his proposed solution. The issue at stake was regarding a contract code size limit. Vitalik posted on GitHub:
“Currently, there remains one slight quadratic vulnerability in ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block's proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern - not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits (an pathological worst-case contract can be created with ~23200 bytes using 4.7 million gas, and a normally created contract can go up to ~18 kb).
If this is to be added, it should be added as soon as possible, or at least before any periods of higher than 4.7 million gas usage allow potential attackers to create contracts larger than 24000 bytes.”
It appears that Vitalik is reaching out to share his struggle with capping the code size. On one hand, setting a limit would help mitigate potential attacks. On the other hand, this cap could potentially impact future scalability.
Posting his thoughts to Reddit got people talking, so hopefully Vitalik will find what he’s looking for somewhere within. This whole idea of openness and outreach really speaks to the way times are changing, and will only serve to improve the projects publicly debated.