-
Notifications
You must be signed in to change notification settings - Fork 0
Conversation
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.
Looking good. A few minor comments/clarifications regarding the struct derive macro, but I think we can move to the interface type computation to see how the end-to-end would look like. Thanks!
version = "0.1.0" | ||
edition = "2021" | ||
|
||
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html |
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.
remove?
let name = &ast.ident; | ||
|
||
// A failed experiment to access to the fields of MyStruct | ||
// The next line doesn't compiles |
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? Is this still true?
.map(|field| field.ty.clone()) | ||
.collect::<Vec<_>>(), | ||
_ => { | ||
panic!("The StructSignature derive macro can only be applied to named fields."); |
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 named files? you are using types to compute the signature right?
version = "0.1.0" | ||
edition = "2021" | ||
|
||
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html |
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.
remove?
pub test3: Option<String>, | ||
} | ||
|
||
println!("{:?}", Foo::signature()); |
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.
What about adding an assert_eq!
to validate that the hash computation is correct?
const SIGNATURE_STR: &'static str = stringify!(#(#field_types),*); | ||
|
||
fn signature() -> String { | ||
use interface_trait::blake2::{Blake2b512, Digest}; |
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.
To prevent having to hash for every method in the interface (which is a lot of unnecessary computation), we can maybe return here directly the concatenated string of method arguments as the signature and then for the final method ID concat all method signatures. WDYT?
Consider this code for the interface identification: https://github.com/consensus-shipyard/ipc-atomic-execution/blob/e5d70adfecfd7883382fdb84ece2308027c5617f/examples/fungible-token/src/lib.rs#L1 |
Close for now (unless there is a strong opinion against it), we can use FRC-42 or an adaptation of it for this: https://github.com/helix-onchain/filecoin/tree/main/frc42_dispatch |
Changes
Implements derive parameter struct method signature hash macro. It will generate a method hash string based on the types of the fields of the struct. Internally it is performing blake2 hashing then hex encoding. As an example, consider this struct:
It would first concate the types to "String, usize", then blake2 hash the string then hex encode.
Tests
check out
src/lib.rs:7
as an example for demo, it is also part ofcargo test
.Issues