-
Notifications
You must be signed in to change notification settings - Fork 852
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
Snap server rebase #6640
Snap server rebase #6640
Conversation
6fb37f2
to
80eb1ac
Compare
b4fc969
to
a0ec424
Compare
...ore/src/main/java/org/hyperledger/besu/ethereum/worldstate/WorldStateStorageCoordinator.java
Outdated
Show resolved
Hide resolved
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/EthProtocolConfiguration.java
Show resolved
Hide resolved
f571c45
to
b51f3c6
Compare
besu/src/main/java/org/hyperledger/besu/cli/ConfigurationOverviewBuilder.java
Outdated
Show resolved
Hide resolved
besu/src/main/java/org/hyperledger/besu/cli/options/unstable/SynchronizerOptions.java
Outdated
Show resolved
Hide resolved
...src/main/java/org/hyperledger/besu/ethereum/trie/bonsai/cache/CachedWorldStorageManager.java
Outdated
Show resolved
Hide resolved
...ger/besu/ethereum/eth/sync/snapsync/request/heal/StorageFlatDatabaseHealingRangeRequest.java
Outdated
Show resolved
Hide resolved
b51f3c6
to
63e21da
Compare
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.
Added some questions but in general I like the implementation 💯
worldStateStorageCoordinator.worldStateKeyValueStorage()) | ||
.getFlatDbStrategy(); | ||
if (!flatDbStrategy.isCodeByCodeHash()) { | ||
LOGGER.warn("SnapServer requires code stored by codehash, but it is not enabled"); |
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.
what we are doing in this case ? not sure to understand if we are stopping the snapserver ?
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.
for now, snap server will operate as normal with just a warning. Essentially we will just serve empty code requests if the storage hasn't migrated. If we think it is necessary we can refuse to start snap server if we are not in code-by-code hash storage mode. I was thinking that we would address this corner case via the storage migration subcommand PR
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapServer.java
Show resolved
Hide resolved
...ices/kvstore/src/main/java/org/hyperledger/besu/services/kvstore/LayeredKeyValueStorage.java
Outdated
Show resolved
Hide resolved
...th/src/main/java/org/hyperledger/besu/ethereum/eth/messages/snap/GetStorageRangeMessage.java
Show resolved
Hide resolved
...ices/kvstore/src/main/java/org/hyperledger/besu/services/kvstore/LayeredKeyValueStorage.java
Show resolved
Hide resolved
} | ||
} | ||
|
||
MessageData constructGetTrieNodesResponse(final MessageData message) { |
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 we need to limite the number of trie nodes to serve by request as Geth. Because it seems to be a possible dos vector
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 will 👀 what geth is doing here. Just to clarify, what about trie nodes queries makes you think they are disproportionately expensive? I would think range requests would represent more resource consumption, especially considering we are not directly using an iterator but rather collecting in memory to serve the requests.
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 ask you 30000 trie nodes that does not exist. You will still have to read in base to find out if the trie node exists. So I can spam you as much as I want. The Range is not the same I ask you for a range and the peers will control what it returns in this range according to the number of leaves. To test. it is an intuition that I have it could be wrong
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapServer.java
Outdated
Show resolved
Hide resolved
82a5de6
to
3560866
Compare
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.
few nits mostly for logging
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapServer.java
Outdated
Show resolved
Hide resolved
.map(DefaultSynchronizer.class::cast) | ||
.ifPresentOrElse( | ||
z -> this.listenerId.set(z.subscribeInitialSync(this)), | ||
() -> LOGGER.warn("SnapServer created without reference to sync status")); |
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.
nit: would be nice for logs to be consistent with snap server vs SnapServer
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapServer.java
Outdated
Show resolved
Hide resolved
|
||
var resp = StorageRangeMessage.create(collectedStorages, proofNodes); | ||
LOGGER.debug( | ||
"returned in {} storage {} to {} range {} to {} with {} storages and {} proofs, resp size {} of max {}", |
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.
nit: this log message is duplicated, could be refactored to a method
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 am going to skip this one for now since all of the return messages at least subtly different.
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapServer.java
Outdated
Show resolved
Hide resolved
ethereum/eth/src/main/java/org/hyperledger/besu/ethereum/eth/manager/snap/SnapServer.java
Outdated
Show resolved
Hide resolved
|
||
/** See https://github.com/ethereum/devp2p/blob/master/caps/snap.md */ | ||
@SuppressWarnings("unused") |
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.
can this annotation be removed now
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.
apparently yes 👍
Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
…ing more than 5 seconds Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
…ests Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
…circuit Signed-off-by: garyschulte <[email protected]>
…rather than protocol Signed-off-by: garyschulte <[email protected]>
…nap request takes too long Signed-off-by: garyschulte <[email protected]>
…or proof generation Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
Co-authored-by: Sally MacFarlane <[email protected]> Signed-off-by: garyschulte <[email protected]>
Signed-off-by: garyschulte <[email protected]>
3251ae7
to
270e2cc
Compare
* initial snap server implementation Signed-off-by: garyschulte <[email protected]> Co-authored-by: Sally MacFarlane <[email protected]> Signed-off-by: amsmota <[email protected]>
* initial snap server implementation Signed-off-by: garyschulte <[email protected]> Co-authored-by: Sally MacFarlane <[email protected]> Signed-off-by: amsmota <[email protected]>
* initial snap server implementation Signed-off-by: garyschulte <[email protected]> Co-authored-by: Sally MacFarlane <[email protected]>
* initial snap server implementation Signed-off-by: garyschulte <[email protected]> Co-authored-by: Sally MacFarlane <[email protected]>
PR description
Initial implementation of snap server using streaming flat database. Obseletes #5887
This PR adds snap server functionality behind a feature flag
--Xsnapsync-server-enabled
which enables besu to serve snap/1 protocol fully.Snap server has a specific set of storage requirements:
--data-storage-format=BONSAI
, snap server only works with bonsai storage--Xbonsai-code-using-code-hash-enabled
, snap server nodes need to store code by code hash in order to serve snap code requests--Xsnapsync-synchronizer-flat-db-healing-enabled
, Snap server nodes must be snap synced with full flat db enabled, (or the node has to have been full-synced to have a fully-flattened db)Given two of these requrirements (code-by-code-hash and flat-db-healing), most nodes will have to resync in order to serve snap data, with these parameters in the config file:
Performance Impact
Testing the initial implementation has shown serving snap data has slight impact to execution performance in normal network conditions, on the order of 10%
Load Test
To get an idea of the cost to execution performance in less than ideal conditions, besu was tested with the load of 2 static syncing peers (besu serving all of the sync load to both clients simulatenously). In this case besu showed roughly 2x the block execution times of besu nodes which were not serving snap data.
Normally besu would only serve some fraction of the load of syncing clients. We could push this further with more static syncing clients, but this was sufficient to get signal about the performance impact.
Once the snap clients completed their worldstate sync, besu performance returned to the mean immediately
Read vs write during this time:
Testing Clients
Besu 23.4.x
Geth 13.14
Nethermind 1.25.4
What's Next
Optimizations. This is an initial implementation of snap server and now that we are satisfied in its correctness, we will turn to optimizing to minimize its impact on block execution times.
A follow-on PR will add a storage subcommand to convert existing databases to fully flattened and code-by-code-hash storage, without the need for a resync.
Fixed Issue(s)
fixes #3165
Thanks for sending a pull request! Have you done the following?
doc-change-required
label to this PR if updates are required.Most advanced CI tests are deferred until PR approval, but you could:
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests