Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
core/tracing: state journal wrapper #30441
base: master
Are you sure you want to change the base?
core/tracing: state journal wrapper #30441
Changes from all commits
8659e68
b4e0174
f670a7f
cf873c3
365b715
aac4024
dbe5f83
b87c4fe
702a42f
c915bed
838fc25
1cc58cf
3c58155
501f302
1a64297
1862333
6650000
d9de74e
d2ba76f
a2ca5f8
85a85d0
2754b41
92337d8
36b4194
efed5a6
ea92ef4
fbd1d19
0f005af
5e4d6b8
4d2fb0e
b37f2ac
a0f7cd6
87582a4
6e4d14c
553f023
be93d72
1dda30d
4acea3b
018df6b
60b2222
6c56ea5
f4cf2a5
7fb2688
3228063
95b82cf
de48d55
9cae376
bf51dde
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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 needed?
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.
The use-case is to have access to the headers of hashes that are accessed by the EVM. Alternative would be if we added a GetHeaderByHash method somewhere. But getting the hash from OnOpcode is also tricky since the hash will be put on the stack after OnOpcode is invoked.
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 looks like a hack. I don't see how this can be accurately updated going forward and backward along the entries. I mean, an inner scope will overwrite the outer
lastCreator
, and when the inner scope is reverted, thelastCreator
will not be set back correctly.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.
Or if we're inside a creation, and inside the constructor we call ripemd to calculate a signature: we lost lastCreator.
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 see why you need to track this. Why not just maintain a list of entries, and you hand out the
id
which is the current length of the entries?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.
the
linearJournal
in my PR #30660 is IMO a better base to start from. It does away with validrevisions and revIds, instead it just as a list of indexes,revisions
, which point to an entry.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 have looked at #30660 and agree it is a better way to do journaling for tracers. The key point for me there is that there will be only 1 revert hook emitted as opposed to one for each change to a state element.
Given that #30660 seems to be still in flux I like to wait on it to be merged and implement it for tracers in a future PR as an improvement.
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.
These points were discussed at standup:
OnAccountReverted
and the inconsistencies there around emitting state changes on the field level and the reverts being on the account level.On the second point I'd like to add my perspective: This journal is simply a wrapper around the tracers. We are not changing tracing interface semantics at all. Users can copy this file and run it themselves right now. And we are exposing every state modification, and I believe the reverse of it is the same.
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 get it. The two PRs, the two journals are unrelated. You have opted to copy-paste the legacy linear journal-implementation. I think the new linear journal-implementation is better/simpler.
You could also have chosen to copy-paste the set-based journal-implementation. I don't care which you choose, really, but I don't see any point in picking one now and switching later. If you want another, pick that one from the get-go ?
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.
They can't perform
WrapWithJournal
from "user-space," can they? Isn't that what makes this a big "blessed" ?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.
Right exact copy wouldn't work. They'd have to implement WrapWithJournal locally, but it's totally possible.
I think the current journal is good, it is consistent with the existing interface, and it has been running in geth for quite a while.
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.
Hm, what? Doesn't that depend on ... things.. ? Or is it always the case?
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 evm-creates (as opposed to create-tx where the flow is different), the new scope begins here: https://github.com/ethereum/go-ethereum/blob/master/core/vm/evm.go#L425 , and the nonce-bump happens a few lines later: https://github.com/ethereum/go-ethereum/blob/master/core/vm/evm.go#L442
However, the actual snapshot is taken even further below: https://github.com/ethereum/go-ethereum/blob/master/core/vm/evm.go#L479 .
So that's the mismatch you see. What the tracing percieves is
But the reality is
So when the scope reverts, you see this weird inconsistency that somehow nonce is a special snowflake.
The proper fix would be to move the
captureBegin
-invocation down, so it happens close to where we take the snapshot. The nonce-bump belongs to the parent scope.