-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Glamsterdam PFI stand
❌ We should not have two CL headliners in a fork.
✅ Reasonable and easy to implement. Also no backwards compatibility concerns.
One caveat is that intrinsic gas calculation will begin to depend on the state.
Also, why is COLD_ACCOUNT_COST_NOCODE so much cheaper than COLD_ACCOUNT_COST_CODE?
❌ Seems too disruptive, would be better accompanied by a larger change e.g. a change from hexary trie to binary trie. Should be done as part of a stateless headliner.
❓ Looks like it can improve security, but may lead to confusion, if the PAY opcode is used to send ETH to a contract address that can only manage funds via callbacks. In this case the ETH would be locked forever in the target contract, and rendered unusable.
❌ It should be part of the Pureth headliner.
❌ Verkle related. If nothing is planned for Verkle, then better off not to bother with this.
❌ Implemented already.
❌ zkEVM is a very fast-moving target. We should wait until it matures a bit more and we have a zkEVM headliner. It might be premature to change the semantics of gas pricing to fit zk costs (which could vary over time by the way). Hash functions are ubiquitous in a variety of contexts, and discouraging their use via gas price increase is not conducive to scaling.
✅ Removal of an almost unused feature. Will reduce block sizes and protocol complexity.
EIP-7686: Linear EVM memory limits
✅ Makes EVM more zk-friendly without any dramatic implications. Seems also nice for EVM implementations (evmone plans similar feature even without this EIP). This is however one of the "quick Vitalik's ideas" so some other devs must step in and take it over. May be in confclict with other EVM memory EIPs (e.g. EIP-7923).
❓
✅ Allows tracking ETH transfers without using debug RPCs.
❌ Too complicated. Perhaps solutions should be developed off-protocol and we should do EIP-7668 instead. Demand for it is uncertain.
❓
❓
❓
❓
❓
❓
✅ Removes arbitrary cap, and uses gas metering instead. Needs some care to prevent worst case scenarios from becoming an attack vector.
❌ Lowering the cost of computational opcodes is a relatively low priority IMO,
while the effort required to do comprehensive benchmarks and repricing is quite big.
I'd suggest instead to concentrate on bumping the price of the most underpriced things
(like we did with MODEXP in Fusaka).
✅ Makes lives of smart contract devs easier.
EIP-7923: Linear, Page-Based Memory Costing
❓ This has potential as an EVM devex improvement, but currently contains technical issues, requires extensive prototyping and design verification (also in Solidity).
❌ Quantum computers are still far away from breaking ECC signatures.
❓ Best practice, but not a protocol change.
✅ Makes TLOAD/TSTORE economical for reentrancy protection.
❓
✅ Helps with further Ethereum scaling.
❌ EOF is a much better and comprehensive alternative. We should reconsider EOF after Glamsterdam.
❓
❓
❌ Not necessarily against it per se, but it's a massive change and won't fit into Glamsterdam (i.e. it's a headliner size).
❓ Generally, good feature for EVM devex, but not very happy about sophisticated decoding.
❌ Quantum computers are still far away from breaking ECC signatures.
❌ Agree with the motivation behind this, but the currently proposed implementation seems too complex.
❓
❓ Agree with the motivation and the approach, but comprehensive benchmarks are needed for a concrete repricing proposal.
❓
❌ There is a natural variance of the real costs of VM operations due to different software and hardware. Milli-gas attempts to make the gas schedule more precise, but that precision improvement is dwarfed by the real cost variance. The resulting bump in complexity is not worth it. If precision improvement is nevertheless deemed material for better EVM performance, it can be achieved via gas schedule re-scaling rather than the milli-gas.
❓
❓
❌ "Currently, deploying duplicate bytecode costs the same as deploying new bytecode, even though execution clients don’t store duplicated code in their databases. When the same bytecode is deployed multiple times, clients store only one copy and have multiple accounts point to the same code hash." -> This is not true for Erigon afaik.
❓