-
Notifications
You must be signed in to change notification settings - Fork 839
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
Make access event keys eip 6800 compatible #7594
Make access event keys eip 6800 compatible #7594
Conversation
a12ee48
to
7a26729
Compare
Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
7a26729
to
755f58c
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.
I like the proposed modification, I just have some remarks and we must not forget to add the equals method in VerkleAccount.
} | ||
} | ||
if (accountUpdate.isUnchanged()) { | ||
return; |
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 cannot use if, else if , else if ? I think it will be better
} | ||
|
||
private void updateAccountStorageState( | ||
private void generateStorageValue( |
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.
generateStorageValue-S ?
@@ -40,22 +40,16 @@ public class TrieKeyPreloader { | |||
public TrieKeyPreloader() { | |||
this.hasher = new PedersenHasher(); | |||
trieKeyAdapter = new TrieKeyBatchAdapter(hasher); | |||
trieKeyAdapter.versionKey( | |||
Address.ZERO); // TODO REMOVE is just to preload the native library for performance check | |||
} | |||
|
|||
public List<Bytes32> generateAccountKeyIds() { |
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 still need a list for this one ?
Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
657a18e
to
764ce3a
Compare
minor change and method renames Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
use 0.0.3-SNAPSHOT with timestamp Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
private Hash storageRoot; // TODO REMOVE AS USELESS | ||
private int hashCode; |
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.
should we remove storageRoot while we are here
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.
good shout. @matkt mentioned he will remove it in future PR so I didn't want to create conflicts unnecessarily
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 comment but approve to unblock
.getStorageKeyValuesForUpdate() | ||
.forEach( | ||
(storageSlotKey, pair) -> { | ||
var storageAccountUpdate = worldStateUpdater.getStorageToUpdate().get(accountKey); |
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 don't think this one is still needed as we already checked here https://github.com/hyperledger/besu/pull/7594/files#diff-a8c0068954d44abe33b85a9a6c2b70309adb959255e417350abe54c858574b62R267 but maybe I missing something ?
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.
Not sure I understand. So the link you posted is when the key values are generated. Here we commit them to the trie in one go.
On generation we only have the storageSlotKey
and corresponding key/value. We don't have the storageUpdate
ref where we should save the prior value
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 was talking about this check (==null)
https://github.com/hyperledger/besu/pull/7594/files/2d12b659a7478f155f9a7be52e1dfed6dfcb3c7d#diff-a8c0068954d44abe33b85a9a6c2b70309adb959255e417350abe54c858574b62R341
when we are generating the key we already check if the collection is empty, so imo when we enter this loop we cannot have a null
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.
yes you're right that we if there are elements we can't have null. I added it based on a defensive approach since we don't know how the programmer will generate keys and values. What if it's based on another object?
If someone changes the code above, then we will not break here. I would prefer to leave it
final Bytes priorValue = | ||
accountUpdate.getPrior() == null ? null : accountUpdate.getPrior().serializeAccount(); | ||
final Bytes accountValue = accountUpdate.getUpdated().serializeAccount(); | ||
if (!accountValue.equals(priorValue)) { |
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 we still need this check if we have now https://github.com/hyperledger/besu/pull/7594/files#diff-a8c0068954d44abe33b85a9a6c2b70309adb959255e417350abe54c858574b62R208 ?
I noticed that adding |
2d12b65
to
1a07247
Compare
Signed-off-by: Karim Taam <karim.t2am@gmail.com>
Signed-off-by: Luis Pinto <luis.pinto@consensys.net>
afa6cce
to
e8ed0e7
Compare
new HashSet<>(accumulator.getAccountsToUpdate().keySet()); // accountsToUpdate | ||
mergedAddresses.addAll(accumulator.getCodeToUpdate().keySet()); // codeToUpdate | ||
mergedAddresses.addAll(accumulator.getStorageToClear()); // storageToClear | ||
mergedAddresses.addAll(accumulator.getStorageToUpdate().keySet()); // storageToUpdate |
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 need to check the performances of these merges. Depending on the number of addresses, it can have a non negligeable overhead, as it is on the critical path of calculating the root hash
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.
it's something similar we are doing during // but clearly we will have to check the performance impact of this when will do benchmark for verkle
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
PR description
This PR encodes balance, nonce, version and code size into a single leaf in Verkle, while code hash has its own leaf, as mandated by EIP-6800.
I'm not doing fixes to gas costs for EIP-4762 yet, most changes are just to superficially not charge for the same leaf twice and to make code compile. I will implement EIP-4762 gas costs in a subsequent PR.
Fixed Issue(s)
This is needed for fixing gas costs for EIP-4762
Thanks for sending a pull request! Have you done the following?
doc-change-required
label to this PR if updates are required.Locally, you can run these tests to catch failures early:
./gradlew build
./gradlew acceptanceTest
./gradlew integrationTest
./gradlew ethereum:referenceTests:referenceTests