-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Make ClientIoMessage generic over the Client #10981
Conversation
Move the BlockInfo trait to new crate
Contains code extracted from ethcore that defines `Machine`, `Externalities` and other execution related code.
* master: Fix compiler warnings in util/io and upgrade to edition 2018 Upgrade mio to latest (#10953)
Initial version of extracted Engine trait
Cleanup Executed as exported from machine crate
Sort out default impls for EpochVerifier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This introduces some changes that need to be reverted later, but the ability to build the light client w/o ethcore is cool!
* master: fix compile warnings (#10993)
client: Arc<Client<T>>, | ||
io_service: IoService<ClientIoMessage>, | ||
io_service: IoService<ClientIoMessage<()>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why is this ()
?
does it work because we only care about ClientIoMessage::BlockVerified
for the light client?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great question. So before this PR light
depends on ethcore
essentially only for ClientIoMessage
, and then only because it has a Execute
variant that embeds a Callback
which is a Fn
that takes an ethcore::Client
as a param… So the dependency was actually not "real" but merely ceremonial, to satisfy the types as they were set up.
Once I made the Callback
generic over the Client (and all the other types using it) @ordian spotted that it's actually not necessary to use anything other than ()
in light
.
Now, we all agree that ClientIoMessage<()>
looks plenty odd and hopefully someone will come along and refactor this further. ;)
In particular I know that @ngotchac is working on changes to the IO code that may, as a desired side-effect, result in a better message passing infrastructure, one that does not need a Client
(or whatever stand-in we use).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see.
In particular I know that @ngotchac is working on changes to the IO code that may, as a desired side-effect, result in a better message passing infrastructure, one that does not need a Client (or whatever stand-in we use).
Cool 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice work.
I have one remaining question regarding the light-client when that is answered you'll get my final approval!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…/eip-1884-reprice-trie-size-dependent-ops * dp/feature/eip-1344-add-ChainID-opcode: more merge fallout Update ethcore/vm/src/schedule.rs Fix a few warnings merge conflict error Make ClientIoMessage generic over the Client (#10981) bump spin to 0.5.2 (#10996) fix compile warnings (#10993) Fix compilation on recent nightlies (#10991) [ipfs] Convert to edition 2018 (#10979)
* master: EIP 1884 Re-pricing of trie-size dependent operations (openethereum#10992) xDai chain support and nodes list update (openethereum#10989) [trace] check mem diff within range (openethereum#11002) EIP-1344 Add CHAINID op-code (openethereum#10983) Make ClientIoMessage generic over the Client (openethereum#10981) bump spin to 0.5.2 (openethereum#10996) fix compile warnings (openethereum#10993)
The one big remaining issue in ethcore is the
ClientIoMessage
type which has anExecute
variant that embeds aClient
. This is a blocker for several things, e.g. making a freestandingethcore/light
, extractingverification
etc.This PR attempts to disentangle this type by making it generic and extracts
verification
fromethcore
.There are some questionable changes made here, in particular wrt to the traits used/modified. Careful review of these areas is much appreciated.
ImportBlock
trait gains a method despite theFIXME
that seems to indicate that the trait should not even existTick
traitSnapshotClient
trait (maybe theSnapshotWriter
trait should be combined with this?)making the light client's fetcher type param'static
– better way?After this PR we can build the eth light client without depending on
Client
.Based on #10978.
I have synced mainnet with this branch.