-
Notifications
You must be signed in to change notification settings - Fork 2
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
Mailbox indexer #39
Mailbox indexer #39
Conversation
If you add this to your .gitattributes it will add syntax highlighting on Github btw |
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.
couldn't get deployment working so have much still to test but great work and docs!
const expectedMailboxContractId = ContractUtils.getContractId( | ||
bytecode, | ||
CONTRACT_SALT, | ||
ContractUtils.getContractStorageRoot([]), |
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 ID derived from storage root?
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.
Check out https://specs.fuel.network/master/protocol/id/contract.html#contract-id, it's just part of the way they implemented computing IDs when a contract is deployed
if (maybeDeployedContract) { | ||
console.log('Contract already deployed'); | ||
return new Contract( | ||
expectedMailboxContractId, | ||
HyperlaneMailboxAbi__factory.abi, | ||
wallet, | ||
); | ||
} | ||
|
||
console.log('Deploying contract...'); | ||
return factory.deployContract({ | ||
salt: CONTRACT_SALT, |
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.
does factory.deployContract
fail if already deployed?
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 it does, you get something like this:
Error: ClientError: Transaction(0x74deef4b669dfca1d2a5e1679639c29ea53e572268fa123e7359286f85c9711d) execution error: Panic(ContractIdAlreadyDeployed)
In another terminal, build and deploy the Mailbox. This is idempotent if just deploying the mailbox. | ||
|
||
``` | ||
yarn deploy |
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.
did you have yarn local-node
running in a different terminal?
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.
yes
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.
hmmmm interesting
I assume you did a fresh yarn
in the deploy package?
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.
caused by node v19
type DispatchedMessage { | ||
# The nonce as a u64 | ||
# See https://fuellabs.github.io/fuel-indexer/master/components/database/ids.html | ||
id: ID! |
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.
easily conflated with contract_id
// See https://fuellabs.github.io/fuel-indexer/v0.1.12/components/database/ids.html | ||
id: message.nonce as u64, |
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.
ah nvm about the id comment then
contract_id: log_metadata.contract_id, | ||
block_number: log_metadata.block_number, | ||
block_hash: log_metadata.block_hash, | ||
transaction_hash: log_metadata.transaction_hash, | ||
transaction_index: log_metadata.transaction_index, | ||
receipt_index: log_metadata.receipt_index, | ||
} |
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.
is there no spread operator?
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.
unfortunately no
The closest is you can do:
MyStruct {
foo,
..my_existing_struct
}
but my_existing_struct
has to be an instance of the MyStruct
struct
impl HyperlaneMessage { | ||
/// Convert the message to a message id | ||
pub fn id(&self) -> H256 { | ||
H256::from_slice(Keccak256::new().chain(self.to_vec()).finalize().as_slice()) |
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.
bit hard to read
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.
Also copied directly from the monorepo so I'm inclined to leave as is
But what I can do instead is do what I mention here https://github.com/hyperlane-xyz/fuel-contracts/pull/39/files/ec0ceaccbbbd620dbb78207bb1d2735c98a0f287#diff-c1df921b29777e810d4612bf6e315c71cf5f404d83cf0413cdeea3b4d2134aceR10 and move these into their own crate in the monorepo so that we don't need to copy and paste these
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.
actually this may be a decent undertaking so I'd like to not block this PR on that. I created hyperlane-xyz/hyperlane-monorepo#1977 to do this later
…cts into trevor/indexer
|
||
message_id: Bytes32! | ||
|
||
# TODO: rip the following out into a LogMetadata type. |
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.
Tracking this with #50
log_with_id
tobytes_extended
, which is used for logging dispatched messages. The rationale is that logs generated byforc
compiler make use of therB
register (see https://fuellabs.github.io/fuel-specs/master/vm/instruction_set.html#logd-log-data-event) to have a marker value so that logs can be identified / differentiated. The compiler will look at all logs and generate marker values starting with0
and counting upward, and it generates the correspondinglog
/logd
instructions with these marker values. You can see these are also present in the ABI if you look at theloggedTypes
section. Because we're calling the logd instruction directly in an asm block, we don't get the luxury of the compiler auto-generating a marker value to easily identify this log, so we have to do it manually. This is imo the easiest way to allow us to easily identify dispatched message logs. Tbh I'd be open to other options here, either in this PR or in the future when we revisit Fuel with greater effort closer to their mainnet dateindexer/mailbox
, which so far indexes dispatched messages. There are a number of necessary quirks that I've done my best to annotate with comments & relevant issues. I recommend reading theREADME.md
in there first and referring to the Fuel Indexer Book / docs as needed.deploy
package, adapted from Super basic deploy tooling #15. It now allows messages to be sent0.35.5
, somecargo fmt
, andcargo clippy
changes