You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To properly build IBC messages to be sent from Sovereign to Cosmos, we need to design the IBC payload types for Sovereign to contain sufficient information that are fetched from the Sovereign rollup.
The key difference of the Sovereign payloads as compared to the Cosmos payloads is that we need to use Jellyfish Merkle proofs to construct the proofs.
It is not clear whether we can reuse the Cosmos types such as Proofs and CommitmentProofBytes.
On the sovereign-ibc side, it looks like the proofs are returned in the form of Vec<u8> raw bytes, as a result, the relayer do not need to parse the proofs into the Jellyfish domain type
There may need to be two payload types if we also need to fetch information from the DA
The rollup payload type only contain information fetched from the rollup
The chain payload type is a composition of the rollup payload, with additional DA information.
Other than client creation and update, it is unlikely that we need to interact with the DA for other IBC payloads. But this note is just in case if we need it.
Summary
To properly build IBC messages to be sent from Sovereign to Cosmos, we need to design the IBC payload types for Sovereign to contain sufficient information that are fetched from the Sovereign rollup.
Proofs
andCommitmentProofBytes
.Vec<u8>
raw bytes, as a result, the relayer do not need to parse the proofs into the Jellyfish domain typeTasks
SovereignReceivePacketRollupPayload
SovereignAckPacketRollupPayload
SovereignTimeoutUnorderedPacketRollupPayload
The text was updated successfully, but these errors were encountered: