py-evm
py-evm copied to clipboard
ethereum
Stable release
I think that we're very close to cutting the first "stable" release. What are the things that would/should hold us back from doing so?
The introduction of eth.abc module defines our external/public API in a reasonably thorough manner. This may be a good guideline for deciding what is/is-not a public API and thus subject to rules about breaking changes.
https://github.com/ethereum/py-evm/issues/1807 is going to introduce breaking changes. Do we need to do that before cutting a stable release or is is something that we can iterate on? I'm not sure.
Maybe it would also be good to add support for Clique first to ensure that doesn't cause a breaking change soon after the release. I've just started working on that.
In fact, I've hit a bit of a road block that might need redesigning the APIs a bit (I hope not!).
Here's what I'm having trouble with:
Many APIs of the VM class work stateless including validate_seal and validate_header. This works fine with the mainnet pow based consensus where we can validate each header without relying on any external data (not entirely true as it relies on a cache that it maintains locally).
It crumbles with clique consensus though. In clique consensus, to validate headers you have to reach out to the database to load and save snapshots that hold a set of currently legal signers per checkpoint.
https://github.com/ethereum/go-ethereum/blob/7b32d2a47017570c44cd7f8a83612a29656c9857/consensus/clique/clique.go#L348-L426
Maybe anyone has other clever ideas but I think we'll have to lift validate_header and validate_seal to become instance methods so that they can depend on a consensus engine which in turn depends on the database.
@cburgdorf breaking changes are expected with implementing a totally new consensus engine. I'd recommend figuring out something that works first and then we can reduce that down to a standard API that both POW/clique can fit nicely into.
I'd also like to think through eip centric forking. We have bundled-fork centric forking in py-evm now, and it looks like it will be helpful or required to be able to turn on and off specific eips individually. I can imagine that causing API instability.
See https://ethereum-magicians.org/t/eip-centric-forking/3536/5?u=carver
IMO this shouldn't go ahead until https://github.com/ethereum/trinity/issues/1478 is fixed...
The underlying issue is in py-evm - no issue in this repo yet, can't formulate it concisely, other than:
Seems that if a contract is created and deleted within the same block, then we're erroneously re-creating its storage as "empty".
Current plan is to not go to stable until the Trinity client has been fully operational syncing with mainnet for a few months to ensure that we don't run into an issue where we need to make a breaking change due to something like a performance constraint or fundamental API adjustment that is needed to make the client work.