What’s in Atlantis? EIP-170 (Contract Code Size Limit)
During the core dev Atlantis call on May 30th, some developer stakeholders expressed uncertainty or alternative solutions to EIP-170.
Let’s just acknowledge there’s discussion around EIP 170 and take this time, another one or two weeks [to discuss] what’s the problem with a maximum code size limits and how to move on — May 30th, Atlantis core dev call, by Talha Cross.
EIP-170 introduces a code size limit of 24 kilobytes. This is a precautionary measure due to dynamic gas limit rules. A contract call takes a constant amount of gas but 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. While this is not an issue at current gas limits, it can cause inconvenience at higher gas limits. The solution is adding a hard cap to contract code size limits.
By enacting a limit sooner than later, we mitigate colossal sized contracts being deployed on the network. If someone desires a contract greater than the specified hard cap, then this can be accomplished by using multiple smaller contracts.
Community QA Highlights
Does EIP-170 cause issues with existing large contracts on ETC?
No. Large contracts deployed before the fork will not be affected to ensure backward compatibility. However, contracts equal to and after the fork’s block number will be affected by the hard cap.
Will rejected large contracts lose initial ETC?
No. The transaction will not be rejected and the value will not be lost. The transaction will operate normally.
Can these rules be applied via a soft-fork rather than a hard-fork?
Yes, but EIP-170 has no mutability concerns and maintains compatibility with ETH test-suites. With our size, including it into Atlantis is the most feasible option. These contract caps may also be changed in future forks if need be.
Specification
If block.number >= FORK, then if contract creation initialization returns data with length of more than0x6000 (2**14 + 2**13) bytes (24 kb), contract creation fails with an out of gas error.
References
Jade is coming!
Jade-service-runner has been released. Service Runner is an opinionated JSON-RPC service manager, that provides daemonization, installation, and discovery for JSON-RPC based services.
Allows dApp developers to specify what services they’d like to use:
- Provides defaults for the services to run
- Provides users with an easy installation path
- Provides reliable discovery of pre-existing services run by the service runner
- Provides OpenRPC interface to the Service Runner functionality, as well as the underlying services
- Allows dApp developers the ability to retrieve reliable JSON-RPC connection information from the service
- Provides typed interfaces to develop applications against
Jade-service-runner is a fundamental milestone in the Jade tooling to come that will improve the dApp development environment.
