Integrate warp non compatible changes

[minghinmatthewlam]

Why this should be merged

Warp has non compatible changes recently added in v0.5.6 that changes how Teleporter integrates with the precompile. We need to update relayer with any corresponding changes and update subnet-evm version. Fixes #24

How this works

Updates subnet-evm version dependency, uses predicateutils for predicate tx

How this was tested

Building local docker image, and running e2e test with corresponding teleporter changes ava-labs/icm-contracts#29

[geoff-vball]

👍

[michaelkaplan13]

All these changes LGTM, but do we need to encode the signed message as an array now that the warp predicate can contain multiple messages?

I would have also expected there to be a messageIndex parameter added somewhere since it's now a parameter to the getVerifiedWarpMessage precompile call. I'm not sure if we're planning on allowing that to be a parameter in receiveCrossChainMessage in Teleporter or not, though seems like it would likely make sense to.

[minghinmatthewlam]

All these changes LGTM, but do we need to encode the signed message as an array now that the warp predicate can contain multiple messages?

I would have also expected there to be a messageIndex parameter added somewhere since it's now a parameter to the getVerifiedWarpMessage precompile call. I'm not sure if we're planning on allowing that to be a parameter in receiveCrossChainMessage in Teleporter or not, though seems like it would likely make sense to.

The slices are handled by the AccessList where each access tuple would correspond to a predicate's bytes, and predicateutils.NewPredicateTx will help add the message as the first index.

Agreed receiveCrossChainMessage can accept an index, I had hardcoded it to 0, but ill add that in case dapps or future relayer improvements leverages that. Putting back in draft until I address that.

[michaelkaplan13]

All these changes LGTM, but do we need to encode the signed message as an array now that the warp predicate can contain multiple messages?
I would have also expected there to be a messageIndex parameter added somewhere since it's now a parameter to the getVerifiedWarpMessage precompile call. I'm not sure if we're planning on allowing that to be a parameter in receiveCrossChainMessage in Teleporter or not, though seems like it would likely make sense to.

The slices are handled by the AccessList where each access tuple would correspond to a predicate's bytes, and predicateutils.NewPredicateTx will help add the message as the first index.

Agreed receiveCrossChainMessage can accept an index, I had hardcoded it to 0, but ill add that in case dapps or future relayer improvements leverages that. Putting back in draft until I address that.

Oh nice! I didn't realize that about how the predicates are encoded within the AccessList. I like that much better than an array.

And sounds good about the index. 🙏

[bernard-avalabs]

LGTM.

[cam-schultz]

LGTM. Agree with Michael's comment to have Index as the first parameter to receiveCrossChainMessage

[michaelkaplan13]

LGTM

[geoff-vball]

👍