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.

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

feat: hashi #1

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from
Open

Conversation

allemanfredi
Copy link

No description provided.

Copy link
Collaborator

@jordaniza jordaniza left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it nicely strips the layer zero elements out - I would love to do a code walkthrough to better understand how the flow changes for Dapps and how we would wire the original oapp via L0

});

emit ActionsRelayed(_callId, _params.dstEid, receipt);
uint256 _destinationChainId
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To confirm my understanding of Hashi: the destinationChainId is it:

  • The chainId for the specific protocol
  • A chainId used by Hashi that reconciles to the specific chainId for the xchain protocol

unchecked {
++_nonce;
}
emit ActionsRelayed(_callId, _destinationChainId, commitment);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the nonce be in the event sig?

@@ -0,0 +1,248 @@
// SPDX-License-Identifier: LGPL-3.0-only
pragma solidity ^0.8.0;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This contract all looks good but I'd need to review in the context of how it fits in the wider application and the workflow. Would appreciate a walkthrough.

uint256 chainId; // The ID of the blockchain where the proof is applicable.
uint256 blockNumber; // The block number at which the proof is generated.
bytes blockHeader; // The RLP-encoded header of the block containing the account state.
uint256 ancestralBlockNumber; // The block number of an ancestral block if needed for verification.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when are ancestral blocks required for verification and when are they not?

*/
event ShoyuBashiSet(address shoyuBashi);

function __HashiProverUpgradeable_init(address shoyuBashi_) public onlyInitializing {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe you would define an init_unchained method to allow for inheritance. Not 100% necessary though

/// @notice Emitted when ShoyuBashi is changed.
event ShoyuBashiSet(address shoyuBashi);

/// @notice Emitted when ShoyuBaactionRelayStorageKeyshi is changed.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: typo

/// @notice Metadata to identify a remote proposal. Logged on receipt.
/// @param callId The ID of the proposal on the foreign chain. No guarantees of uniqueness.
/// @param srcEid The LayerZero foreign chain ID.
/// @param srcChainid The LayerZero foreign chain ID.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: rm layer zero

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants