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

IF: SHiP changes to support IBC services #2235

Closed
Tracked by #2110
arhag opened this issue Feb 12, 2024 · 0 comments · Fixed by #2321
Closed
Tracked by #2110

IF: SHiP changes to support IBC services #2235

arhag opened this issue Feb 12, 2024 · 0 comments · Fixed by #2321
Assignees

Comments

@arhag
Copy link
Member

arhag commented Feb 12, 2024

Depends on #2080.

The newly calculation action Merkle root for each block should be provided. This can either be part of the existing stream of blocks or can be put in some new stream perhaps alongside additional data that is useful to IBC (although technically everything else needed for IBC can come from the existing block header with its extensions). Additionally, whatever structure contains the new action Merkle root will likely be expanded in the future to contain other data necessary for control Finality Tree Leaf Nodes, such as the state root.

Note that the action_mroot in the block header would instead contain the finality Merkle root after the IF transition, which is why the new action Merkle root must be provided separately.

Additional data to be included (to support IBC clients):

  1. Protocol version
  2. Active finalizer policy generation
  3. Base digest

Note that the actual active finalizer policy is not required since it would have been provided earlier in a block header extension. Also the finality Merkle root does not need to be provided separately since it can already be found in the block header.

The history of new action Merkle roots will need to be stored on disk somewhere. One option is to include them in the irreversible block log by including it in a new block extension. This means when a block is validated, it would have to be mutated to add the block extension. Also, a node may receive a block with or without that block extension. If the block extension is present, it should ensure it is well-formed but it does not need to validate the data present within at the time it receives it. However, when it validates that block, if a block extension is already present, it should ensure the data within it is correct. If it is not, then it should correct the data at that time. Part of determining if this new block extension is well-formed includes determining whether it is allowed to be present in the first place; this new block extension should not be present on a block that does not have the finality header extension.

@enf-ci-bot enf-ci-bot moved this to Todo in Team Backlog Feb 12, 2024
@arhag arhag added 👍 lgtm and removed triage labels Feb 12, 2024
@linh2931 linh2931 self-assigned this Mar 7, 2024
@linh2931 linh2931 added this to the Leap v6.0.0-rc1 milestone Mar 7, 2024
@linh2931 linh2931 moved this from Todo to In Progress in Team Backlog Mar 7, 2024
@linh2931 linh2931 moved this from In Progress to Awaiting Review in Team Backlog Mar 18, 2024
@arhag arhag closed this as completed Mar 27, 2024
@github-project-automation github-project-automation bot moved this from Awaiting Review to Done in Team Backlog Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants