[Meta] Moving Staking off the Relay Chain #491
Comments
|
Do we know how much relay chain usage is staking related now? |
This is more XCM v4 related, but it'd still be nice to have So, we don't have to use these instructions for DOT staking, but it'd be nice to have them in XCM v4 so that other chains can impl those instructions, and on Asset Hub we can have a |
Do you mean by block weight? I don't have any numbers but I can try to dig it up if you think its relevant? The primary reason as I understand to move staking (as well as governance and other functions) out of relay chain is not only for freeing up bandwidth on relay chain but to move towards a vision of relay chain only being used to back parachain blocks. |
I could see a solution where we can use the AliasOrigin instruction together with the Transact instruction. We use AliasOrigin to alias the remote origin to a local origin. XCM(vec![
... // possibly paying for fees etc
AliasOrigin(MultiLocation{
parents:0,
interior: X1(AccountId32{Network: ..., id: Alice})
}),
Transact{origin_kind: Native, ..., call: *set_keys call*}
])The origin is changed from: The question is if we should allow aliasing staking hub accounts in the relay chain (and maybe vice versa) as it would mean that StakingHubAlice == RelayAlice. But I think it could solve a lot of problems around the parallel staking in staking hub and asset hub. |
the-right-joyce
added
I6-meta
Adding more detail to my last comment, I missed the retreat but would like to revisit this decision, or at least bring up a few tradeoffs. First, I understand that just moving DOT to a staking chain makes things much simpler for staking, since it will minimize the number of changes needed. But there are two major downsides I see:
The tradeoff with (2) that we should minimize is that AH should not become a "do everything" chain, because that defeats the purpose of separate cores. Specific things like validator ops in staking or submitting referenda in governance should still all be handled on their respective chains. But I still think there's a minimal amount (e.g. stake, vote) that can be done from AH with specific implementations of that logic handled on other chains. |
It's relevant to how fast we do the move probably. An easier target might be NPoS because NPoS blocks are way too heavy for paracains right now, which also block this, but that's basically the only problem with doing NPoS on a parachain. If we could run the blocks, like by dividing them, then we could just fork the relay chain state into a parachain of itself, where NPoS runs. |
This is the tricky part during the transition phase where we will slowly scale the validator set coming from staking hub. Since staking on staking hub and staking on relay chain would be completely independent of each other, Alice validating on relay chain and Alice validating on Staking hub should be considered different validators. |
We definitely want staked dots to be available for governance and this I believe should be very similar to dots on Asset Hub. That is, 1) hold the dots in the asset hub/staking chain, 2) send
We did start with the assumption to go with the idea that you are proposing (AssetHub be the central point of action for any asset mutation op). As you said though, this makes AssetHub a bottleneck since almost every action would start there. There are other complexities such as large number of xcm instructions needed for reward payouts (and slashes), fee payments on the non-asset chain. Most of these instructions will need followup interaction with the non asset chain, such as stake would require a follow up action of nominate (voting instruction with So even if we go with the Asset Hub being the entry point, I think most apps would need to integrate with multiple chains one way or another. Since staking funds are semi-liquid, it seems a reasonable compromise to keep assets there as well (which simplifies lot of things). Once we have that, I think we can still strive to move towards the goal that you are suggesting, i.e. to be able to stake funds in the asset hub (or move funds to staking and then stake). |
Actually I meant the opposite of this when I wrote, "many chains (Polkadot included) will have custom staking/governance logic, but we can provide apps/tools with embedded light clients for transacting on those chains with custom application logic". As such, only the first interaction would be from AH (viz. represent my assets in some destination chain for some purpose). However, further interaction would be on the destination chain with your Agent.
Yeah, so the "one way or another" part is key here, because running an archive node for every chain is burdensome. Ideally an archive node solely on AH would allow people to track balance changes for users (these could be batched, e.g. accumulate rewards for a month on the staking chain and then send a message to update your balance on AH). But all transacting could be done via light client on other chains. |
|
This issue has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/remote-stake-any-asset-on-asset-hub/4210/1 |
|
Some thoughts after discussing this in person over the last 2 weeks: Realistic PlanI would divide this in general into two tasks:
These are fairly independent and can be pursued in parallel for the most part. Ideal PlanThis is probably out of reach, but if time had permitted, I would refactor the staking and pools to be just one staking primitive. Everything should be pools. enum Nomination {
/// Managed pool. AccountId can be a smart contract.
Mirror(AccountId),
/// Robot pool.
Fixed(BoundedVec<AccountId, 16>),
} |
|
This issue has been mentioned on Polkadot Forum. There might be relevant details there: |
…2504) > highly WIP, opening draft PR for early feedback. This PR implements a PoV friendly, multi-block EPM to be used by the staking parachain. It is split into multiple sub-pallets for better logic and storage encapsulation and better readability. The pallet split consists of a main pallet and several other sub-pallets that implement the logic for different sub-systems, namely: - **main pallet**: - implements the `trait ElectionProvider` - `fn elect(remaining_pages)` basically fetches the queued page from the `pallet::verifier`, which keeps the valid solutions in its storage. - manages current election `Phase` in `on_initialize`. The current phase signals other sub-pallets what to do. - stores and manages the (paged) target and voter snapshots. - *note*: the staking pallet needs to return/interpret a paged fetching of the snapshot data for both voters and targes. - **signed pallet**: - implements the `trait SolutionDataProvider`, which provides a paged solution for the current best score (the `pallet::verifier` is the consumer, when trying to fetch the best queued solution to verify). - keeps track of the best solution commitments from submitters. - exposes `Call::register` for submitters to submit a commitment score for their solution. - exposes callable `Call::submit_page` for submitters to submit a page of their solution. - upon the verifier pallet finalizing the paged solution verification, it handles the submission deposit/rewards based on the reported `VerificationResult` (from `pallet::signed`). - **verifier pallet**: - implements the `trait Verifier`: verifies one solution page on-call. The inputs for the verification are provided in-place. - implements the `trait AsyncVerifier`: fetches pages from the implementor of `SolutionDataProvider` (implemented by `pallet::signed`) and verifies the paged solution. - `on_initialize`, it checks if the verification is ongoing and proceeds with it - it has it's own `VerificationStatus` which signals the current state of the verification - for each successfully verified page, add it to the `QueuedSolution` storage. - at the end of verifying a solution, it reports the results of the verification back to the implementor of `trait SolutionDataProvider` (`pallet::signed`) - **unsigned pallet**: - `on_initialize` checks if on `UnsignedPhase` and no queued solution; compute a solution with offchain Miner. - implements the off-chain unsigned (paged) miner. - implements the inherent call that processes unsigned submissions. --- ### Todo/discussion - [x] E2E multi-page election with staking and EPM-MB pallet integration. - [ ] refactor the current `on_initialize` across all pallets to make explicit calls depending on the current phase, rather than relying on the pallet's `on_initialize` and current phase to decide what to do at a given block (TBD). - [ ] remove the `Emergency` phase and instead just keep trying the election in case of failure. - [ ] refactor current `SignedValidation` phase to have enough blockspace to verify all queued signed submissions, for security purposes (ie. at least `max_num_queued_submissions * T::Pages` blocks allocated to signed verification, return early if a submission is valid and accepted). - [x] implement the paged ingestion of the election results in the staking pallet. How to convert from multiple `BoundedSupports` to `Exposures` in the staking pallet in a nice way (add integration tests). - idea: if each page contains up to `N` targets and a validator may appear only in one page, we can process the pages in serie in the staking side, keeping track of the state of `Exposures` across the pages. - [ ] allow the validator to replace the current submission if their submission has better score than the accepted queued submission. - [ ] mutations to both the target and voter lists need to "freeze" while the snapshot is being generated (now multi-block). what's the best approach? Closes: #2199 Related to: #491 Inspiration from https://github.com/paritytech/substrate/tree/kiz-multi-block-election
Updated on 7th August 2024 based on the Plaza proposal..
Design
Balances will exist in the same chain as Staking. Staking chain will have its own pallet-balances. DOT tokens can be transferred (teleported) to staking chain in order to stake. The chain cannot burn or mint the tokens that changes the total issuance of DOTs (teleport is fine).Staking will be on same chain as Balances which simplifies the reward minting logic.
There are three major discussion points that we have identified and some of them may deserve its own RFC.
Reward minting logicRelay Chain <> Staking Chain interface
Migration Strategy
Snapshot based: Freezing and migrating all staked balance to the Staking Chain
Rough steps:
Advantages
Other thoughts
Staking Chain performs election for all collators of system parachains
Since Staking chain already elects the winners for the validator set of the relay chain, it could also become the central place where collators stake, gets elected and rewarded for collating on other system chains such as Asset Hub, Collectives as well as collating for Staking Chain itself.
Other links
The text was updated successfully, but these errors were encountered: