Open
Conversation
franciscoaguirre
force-pushed
the
hop-base
branch
from
ca71b86 to
fce9a5f
Compare
In order to support promotion to Bulletin in HOP, we need both node-side and runtime-side changes. This PR adds the node-side changes to sc-hop and ultimately to polkadot-omni-node, since that's what will be used to run the Bulletin chain. The runtime-side is tested in [polkadot-bulletin-chain](paritytech/polkadot-bulletin-chain#348) before the real deploy to fellowship runtimes. ## How promotion works When entries are about to expire, the collator will submit low-priority transactions to store them in Bulletin. These transactions are not propagated, they'll stay in the collators transaction pool until they expire or it's his turn to build a block and he can fit them in. Given that they are low-priority, all other external transactions take precedence. That's why promotion is a best-effort system. It only tries to fill in blocks if they have some space available. A background HopMaintenanceTask runs on a configurable interval (default 60s). Each cycle it: 1. Queries the pool for entries within hop_buffer_blocks (default ~2h) of their expiry that haven't been promoted yet (get_promotable) 2. For each, calls HopPromoter::promote(data) which uses the HopPromotionApi runtime API to construct a general transaction extrinsic and submits it to the local tx pool 3. Marks successfully promoted entries 4. Cleans up expired entries Promoted entries don't get immediately deleted, they wait for their actual expiry. This is so that the recipient can quickly get them from HOP if he comes online before the expiry time. If he comes online after the expiry time, then it will try to get it from HOP, fail and then go try to retrieve it from Bulletin via IPFS. ## Runtime API detection try_build_promoter() probes for HopPromotionApi support at startup. If the runtime doesn't implement it, the node logs a warning and runs in cleanup-only mode. The pool still works for submit/claim, just without automatic on-chain promotion. This keeps the node functional regardless of whether the runtime has pallet-hop-promotion. We don't want the omni node to crash if the runtime is not Bulletin, clearly. Ideally we want all of this to be enabled only when the node is run with --enable-hop. ## Companion: bulletin-chain runtime The companion to this PR is on bulletin-chain. It has pallet-hop-promotion which implements the runtime API. This API gives the node the necessary promote() extrinsic to submit. To know more, go to that PR. We'll have to deploy that pallet to Polkadot to make use of HOP promotion.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.