Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Validator should be able to be configured submit checkpoints on-chain #4586

Open
nambrot opened this issue Sep 27, 2024 · 5 comments · May be fixed by #4659
Open

Validator should be able to be configured submit checkpoints on-chain #4586

nambrot opened this issue Sep 27, 2024 · 5 comments · May be fixed by #4659
Labels
agent bounty good first issue Good for newcomers medium bounty size relayer validator

Comments

@nambrot
Copy link
Contributor

nambrot commented Sep 27, 2024

Hyperlane agents have the checkpoint syncer abstraction to allow validators to publish their checkpoints and relayers to read them. Currently, the primary options for those are web2 cloud storage like S3 and GCS. This bounty suggests the addition of a web3 native one where checkpoints are just written on-chain.

The easiest way would be to write a simple smart contract that allows any account to publish a checkpoint. It would be useful to indicate the location of the checkpoint syncer similar to s3://bucket-name/region as onchain://chainName/contractAddress. Validators could then use the existing chain signer abstraction to submit these checkpoints on-chain.
@daniel-savu
Copy link
Contributor

daniel-savu commented Sep 27, 2024 •
edited
Loading

Noting that although development for this can start now, there is an upcoming method (here #4587) that the checkpoint store will need to support in addition to the above. All other required methods are in the Rust trait used by the validator implementation:

hyperlane-monorepo/rust/main/hyperlane-base/src/traits/checkpoint_syncer.rs

Lines 11 to 37 in 330b058

pub trait CheckpointSyncer: Debug + Send + Sync {
/// Read the highest index of this Syncer
async fn latest_index(&self) -> Result<Option<u32>>;
/// Writes the highest index of this Syncer
async fn write_latest_index(&self, index: u32) -> Result<()>;
/// Update the latest index of this syncer if necessary
async fn update_latest_index(&self, index: u32) -> Result<()> {
let curr = self.latest_index().await?.unwrap_or(0);
if index > curr {
self.write_latest_index(index).await?;
}
Ok(())
}
/// Attempt to fetch the signed (checkpoint, messageId) tuple at this index
async fn fetch_checkpoint(&self, index: u32) -> Result<Option<SignedCheckpointWithMessageId>>;
/// Write the signed (checkpoint, messageId) tuple to this syncer
async fn write_checkpoint(
&self,
signed_checkpoint: &SignedCheckpointWithMessageId,
) -> Result<()>;
/// Write the agent metadata to this syncer
async fn write_metadata(&self, metadata: &AgentMetadata) -> Result<()>;
/// Write the signed announcement to this syncer
async fn write_announcement(&self, signed_announcement: &SignedAnnouncement) -> Result<()>;
/// Return the announcement storage location for this syncer
fn announcement_location(&self) -> String;
}

@chuthanktoan
Copy link

cac

@nambrot nambrot mentioned this issue Oct 8, 2024
Open
@NOOMA-42
Copy link
Contributor

Hi I'm interested in this issue. I'll send a draft PR soon

@NOOMA-42 NOOMA-42 linked a pull request Oct 10, 2024 that will close this issue
Draft
@NOOMA-42
Copy link
Contributor

A few more clarification questions for @daniel-savu and @nambrot

  1. Should the smart contract handle signature verification? signedCheckpoint has ecdsa signature
  2. Does write_latest_index method make sense in on chain storage? when writing checkpoint, it should be able to write the latest index as well.
  3. Why do some methods (e.g., in mailbox.rs) override the transaction gas fee, while others (e.g., in validator_announce.rs) do not? I wonder should I keep the gas override in onchain_checkpoint.rs
  4. In mailbox.rs, I notice there is a special handler for Arbitrum Nitro. Should this be retained similarly in onchain_checkpoint.rs?

@nambrot
Copy link
Contributor Author

nambrot commented Oct 21, 2024

  1. Nice to have
  2. You can make it a no-op if you want
  3. override everywhere makes sense, because the announce only happens once, we probably never noticed
  4. If its easy enough yes. It's primarily to account for Arbitrum's multi-dimensional gas fees which we need to meter for IGP, but that is less relevant for onchain checkpoints

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
agent bounty good first issue Good for newcomers medium bounty size relayer validator
Projects
Hyperlane Tasks
Status: No status
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: onchain checkpoint NOOMA-42/hyperlane-monorepo
4 participants
@nambrot @daniel-savu @NOOMA-42 @chuthanktoan