-
Notifications
You must be signed in to change notification settings - Fork 1
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
base: develop
Are you sure you want to change the base?
feat: hashi #1
Conversation
…hain in order to add hashi for cross chain communication
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.
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 |
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 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); |
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.
Should the nonce be in the event sig?
@@ -0,0 +1,248 @@ | |||
// SPDX-License-Identifier: LGPL-3.0-only | |||
pragma solidity ^0.8.0; |
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.
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. |
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.
when are ancestral blocks required for verification and when are they not?
*/ | ||
event ShoyuBashiSet(address shoyuBashi); | ||
|
||
function __HashiProverUpgradeable_init(address shoyuBashi_) public onlyInitializing { |
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.
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. |
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.
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. |
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.
nit: rm layer zero
No description provided.