-
Notifications
You must be signed in to change notification settings - Fork 11.8k
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
ERC-7786 interfaces and receiver #5255
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: cairo <[email protected]>
Co-authored-by: cairo <[email protected]>
Co-authored-by: cairo <[email protected]>
Co-authored-by: cairo <[email protected]>
Co-authored-by: Ernesto García <[email protected]>
Co-authored-by: cairo <[email protected]>
Co-authored-by: cairo <[email protected]>
|
) public payable virtual { | ||
if (_isKnownGateway(msg.sender)) { | ||
// Active mode | ||
// no extra check |
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.
shouldn't this check that gatewayMessageKey
and gateway
are zero https://github.com/ethereum/ERCs/pull/673/files#diff-07848a22c16b11582927b37d76b2c54a0617b1444b30d11bca783ac98eaed01fR150? or is that checked by the gateway?
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.
As far as I remember the ERC says that in active mode the fields should be empty, not that must be empty. The idea is that we should not expect them to be populated (in fact we don't use these values in active mode)... but we should also not fail if they contain 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.
Yeah I specified it as "SHOULD" so this implementation is compliant. But it's worth considering if it should be "MUST". I don't see any concrete issue with allowing any values and ignoring them.
// no extra check | ||
} else if (_isKnownGateway(gateway)) { | ||
// Passive mode | ||
IERC7786GatewayDestinationPassive(gateway).validateReceivedMessage( |
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.
receiveMessage
is payable so it can receive value, but the value received is not passed to validateReceivedMessage
, how can the passive gateway verify the msg.value
received?
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.
In passive mode, the value is not sent by the relayer. Value (if any) must be sent by the gateway.
So if you expect value with a message, and if you operate in passive mode, you should have a receive function. When you do the validate, the gateway should send you the value using that receive function.
How the receiver detect that value was received is a great question. I think it's more a question for the ERC than for the implementation.
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.
One answer is that any value should come with a corresponding attribute, and that is how it would be visible from the processMessage (instead of using msg.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.
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.
If we want to make payable compatible with passive mode we would have to add a value
parameter to validateReceivedMessage
.
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.
After discussion it feels like the thing is:
- Value should only be part of active mode calls.
- Passive mode should not support value, because value cannot be easily moved in a passive way
- In that case we have a choice of doing
require(msg.value == 0);
in the passive mode, or to allow value to be passed by the relayer, without it being related to the semantics of the message
- In that case we have a choice of doing
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 would do require(msg.value == 0)
. In terms of the spec I think this check should be recommended but not mandatory.
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 a check
Right, I misread the changelog, will go back to 0.8.24 for Bytes and all the code that depends on it directly or indirectly. |
Co-authored-by: cairo <[email protected]>
…elin-contracts into feature/crosschain
Co-authored-by: cairo <[email protected]> Co-authored-by: Arr00 <[email protected]>
* * MUST emit a {MessageCreated} event. | ||
* * SHOULD NOT emit a {MessageSent} event. |
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 should it not emit a MessageSent
event if above it says that when returning zero the message must be sent.
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.
That is part of the ERC specification.
- If the message requires post processing, a unique id is give to that message, otherwize 0 is used
- The MessageSent is used when post processing is done, in that case we say which message was processed using that (non 0) id.
- if no processing is needed, the message is sent automatically when its created. emitting
MessageSent(0)
would be useless (that is implicit by 0 being in MessageCreated) but also confusing (id 0 is not unique)
* standardized) action is required. | ||
*/ | ||
event MessageCreated( | ||
bytes32 outboxId, |
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 this should be indexed
. I know it's not in the spec but we should change that.
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 discussed it.
The MessageSent one is indexed (because we may want to activelly filter a particular MessageSent once we know the id. But for the MessageCreated
part, we don't have a way to predict the value (at least not in general) so creating a is not that meaningfull IMO (hence why its not indexed)
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.
My reasoning was that if you see a MessageSent
event you may want to retrieve the matching MessageCreated
.
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.
make sens
Depends on #5252
ERC PR
NOTE
Bytes.slice
usesmcopy
that was introduced in 0.8.25. This requirement extends to theCAIP2
andCAIP10
libraryPR Checklist
npx changeset add
)