-
Notifications
You must be signed in to change notification settings - Fork 75
ETCM-938 Refactor Blockchain and extract methods getEvmCodeByHash and mptStateSavedKeys #1017
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -20,6 +21,7 @@ import io.iohk.ethereum.network.p2p.messages.Codes | |||
*/ | |||
class BlockchainHostActor( | |||
blockchain: Blockchain, | |||
evmCodeStorage: EvmCodeStorage, |
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.
Do you expect it will happen more during the refactoring that actors will have access to the storages directly? (To clarify: I don't really see a problem with it.)
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.
I think might happen for state storage also as the Blockchain class does not really bring anything in term of read access (I think it's ok for read access).
We will probably want write access to be through a single service though, or redefined what we call a storage to be a class that manage several rocksdb namespace internally, because we have some writes that span several storages (for instance when adding a block we want to store the block itself but also update the transaction mapping and potentially some other metadata).
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.
👍
@@ -120,6 +124,8 @@ object SyncController { | |||
def props( | |||
appStateStorage: AppStateStorage, | |||
blockchain: Blockchain, | |||
evmCodeStorage: EvmCodeStorage, | |||
nodeStorage: NodeStorage, |
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.
I wonder at what point we'll create a case class MantisEnv
or something that has all these instances in it.
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.
We already have something similar BlockchainStorages
which is extended by Storages
in the trait StoragesComponent
, and with a concrete implementation in DefaultStorages
.
It is a big bag with every storage in it so we will probably want to separate them to have storages that work together in the same container, and identify storages that are a "view" of other storages.
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.
👍
) | ||
assert( | ||
peer1.bl | ||
.getBestBlockNumber() == peer3.bl.getBestBlockNumber() - peer3.testSyncConfig.pivotBlockOffset |
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.
nitpick: the line break in peer1.bl.getBestBlockNumber()
makes it less readable imho
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.
I've put it back!
@@ -20,6 +21,7 @@ import io.iohk.ethereum.network.p2p.messages.Codes | |||
*/ | |||
class BlockchainHostActor( | |||
blockchain: Blockchain, | |||
evmCodeStorage: EvmCodeStorage, |
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.
I think might happen for state storage also as the Blockchain class does not really bring anything in term of read access (I think it's ok for read access).
We will probably want write access to be through a single service though, or redefined what we call a storage to be a class that manage several rocksdb namespace internally, because we have some writes that span several storages (for instance when adding a block we want to store the block itself but also update the transaction mapping and potentially some other metadata).
@@ -120,6 +124,8 @@ object SyncController { | |||
def props( | |||
appStateStorage: AppStateStorage, | |||
blockchain: Blockchain, | |||
evmCodeStorage: EvmCodeStorage, | |||
nodeStorage: NodeStorage, |
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.
We already have something similar BlockchainStorages
which is extended by Storages
in the trait StoragesComponent
, and with a concrete implementation in DefaultStorages
.
It is a big bag with every storage in it so we will probably want to separate them to have storages that work together in the same container, and identify storages that are a "view" of other storages.
3c076f6
to
589135c
Compare
… mptStateSavedKeys
589135c
to
c001c80
Compare
Description
In order to simplify the Blockchain complexity, methods
getEvmCodeByHash
andmptStateSavedKeys
where removed, since they are used in just a few locationsgetEvmCodeByHash
is just aget
done directly to the EvmCodeStoragemptStateSavedKeys
is used only inSyncStateScheduler
so it was moved thereTesting
All should work as before