Skip to content

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

Merged
merged 1 commit into from
Jun 21, 2021

Conversation

leo-bogastry
Copy link
Contributor

Description

In order to simplify the Blockchain complexity, methods getEvmCodeByHash and mptStateSavedKeys where removed, since they are used in just a few locations
getEvmCodeByHash is just a get done directly to the EvmCodeStorage
mptStateSavedKeys is used only in SyncStateScheduler so it was moved there

Testing

All should work as before

@@ -20,6 +21,7 @@ import io.iohk.ethereum.network.p2p.messages.Codes
*/
class BlockchainHostActor(
blockchain: Blockchain,
evmCodeStorage: EvmCodeStorage,
Copy link
Contributor

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.)

Copy link
Contributor

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).

Copy link
Contributor Author

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,
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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,
Copy link
Contributor

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,
Copy link
Contributor

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.

@leo-bogastry leo-bogastry merged commit 4f9c093 into develop Jun 21, 2021
@leo-bogastry leo-bogastry deleted the refactor/ETCM-938 branch June 21, 2021 11:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants