Initial draft of FRC for calling convention #399
Conversation
anorth
requested review from
momack2,
arajasek,
jennijuju and
kaitlin-beegle
as code owners
|
(Edited by @anorth: discussion moved to #382 (reply in thread)) |
| let domain_separation_tag = "1|" // Note `|` is illegal in method names | ||
| let mut digest Vec<u8>= blake2b(domain_separation_tag + method_name) | ||
| while !digest.is_empty() { | ||
| let method_id = u32::from_be(digest[0..4]) |
There was a problem hiding this comment.
I'm assuming we are using big-endian to be consistent with existing protocols.
There was a problem hiding this comment.
It's "network" byte order and also the order used by CBOR.
Co-authored-by: Jakub Sztandera <kubuxu@protocol.ai>
|
The draft lgtm, more discussion may take place in #382 and to be |
|
Agreed! Thanks for reviewing. Not to state the obvious, but I think we should recognize a policy wherein any FIP editor who authors a FIP/FRC cannot also be the primary reviewer for their work. Glad you were able to take a look at this :) |
|
@kaitlin-beegle i think we will have to revert the PR, or create a new pr as FIP number was not updated in the proposal yet |
|
|
||
| Note that removing both those differences would *not* automatically make this scheme compatible with the Solidity ABI, | ||
| since method parameter types have fundamentally different schemas between the two environments. | ||
| A future FVM/EVM embedding will need to translate method selectors along with the rest of the EVM ABI. |
There was a problem hiding this comment.
I doubt we will have logic to translate method selectors; that would rely on a number of assumptions that I don't feel good encoding in the protocol (even if in actor land). Instead, Ethereum CALLs would set a fixed dynamic method number and rely on the call convention in parameters to perform dispatch.
An actor calling convention that derives method numbers by hashing method names.
This proposal describes a convention for the labelling of methods across actors which will support the development of standardised APIs, e.g. a token API. The convention maps human-friendly method names to method numbers by hashing the method name. This supports the definition of multiple standardized APIs with minimal potential for collision on method numbers.
See #382 for discussion.
PTAL @Kubuxu @raulk @Stebalien