Skip to content
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

pass extra bytes directly to precompiles #675

Closed
wants to merge 1 commit into from

Conversation

darioush
Copy link
Collaborator

@darioush darioush commented Oct 21, 2024

Why this should be merged

I don't think the libevm shim needs to know about the length of the dynamic fee window, as this is a somewhat leaky abstraction.
IMO it's simpler to give access to the whole extra bytes in the precompile.
The VM maintains the promise to parse this data for any errors before passing them to the precompile, so this has no semantic changes.

How this works

Refactoring (moves call to predicate.GetResultsBytes from libevm shim to precompiles)

How this was tested

CI

Comment on lines +64 to +65
extra := accessibleState.GetBlockContext().Extra()
predicateResultsBytes := predicate.GetPredicateResultBytes(extra)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the logic in this file from line 63-72, should be moved somewhere else.

ie, this contract is called in the context of some block and some tx, so it should not have to specify the hash of the tx currently being executed to the statedb to query it for the predicates, then query the results from the block header.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'm happy to review that as part of this PR, or as a later one if you'd like. I'm approving in case you choose the latter so please ping me if you want a re-review.

@darioush darioush marked this pull request as ready for review October 21, 2024 20:44
@darioush darioush requested review from ceyonur and a team as code owners October 21, 2024 20:44
// GetPredicateResults returns an byte array result of verifying the predicates
// of the given block.
GetPredicateResultsBytes() []byte
Extra() []byte // Exta returns the Extra field of the block header
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about HeaderExtra() []byte and remove the comment? That way it's also implicitly documented at the call site.

Comment on lines +64 to +65
extra := accessibleState.GetBlockContext().Extra()
predicateResultsBytes := predicate.GetPredicateResultBytes(extra)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'm happy to review that as part of this PR, or as a later one if you'd like. I'm approving in case you choose the latter so please ping me if you want a re-review.

@@ -241,6 +237,6 @@ func (b *BlockContext) Timestamp() uint64 {
return b.time
}

func (b *BlockContext) GetPredicateResultsBytes() []byte {
return b.predicateResultsBytes
func (b *BlockContext) Extra() []byte {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR conflicts with my comment here

If we can extend the BlockContext here, why we avoid using full and parsed types here?

@@ -61,7 +61,8 @@ func handleWarpMessage(accessibleState contract.AccessibleState, input []byte, s
warpIndex := int(warpIndexInput) // This conversion is safe even if int is 32 bits because we checked above.
state := accessibleState.GetStateDB()
predicateBytes, exists := state.GetPredicateStorageSlots(ContractAddress, warpIndex)
predicateResultsBytes := accessibleState.GetBlockContext().GetPredicateResultsBytes()
extra := accessibleState.GetBlockContext().Extra()
predicateResultsBytes := predicate.GetPredicateResultBytes(extra)
Copy link
Collaborator

@ceyonur ceyonur Oct 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO:

  • warp contract should not need to deal with parsing predicate results (we already parse them for verification). I'm looking at the upstream and seems they also don't include header in the block context. If we can be flexible in BlockContext (we should be), we don't actually need to abstract everything. I do think BlockContext should be the place where we can have custom stuff derived from block/header to present for the execution.
  • warp contract should not know about extra at all
  • Predicaters does not need to be just for warp messaging, any other predicater should not re-implement all this parse-from-extra logic.

These are my observations after looking at just diffs, block context and warp handler. I haven't considered libevm or any other cyclic dependency. LMK if there is another concern that outweighs these considerations (especially parsing).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This approach #679 tries to follow the comment above, let me know your thoughts.

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.

3 participants