burdges
commented
1 year ago Do we know how much relay chain usage is staking related now?
Open Ank4n opened 1 year ago
burdges
commented
1 year ago Do we know how much relay chain usage is staking related now?
joepetrowski
commented
1 year ago We talked about not having tokens on Staking chain at all (or may be a small balance just for paying fees) but eventually decided against the complexity introduced because of it. The topic is a bit beyond the scope of this issue, though we could revisit it if someone has strong opinions about it.
This is more XCM v4 related, but it'd still be nice to have Stake and Unstake instructions in v4. A value proposition of Asset Hub is that it gives custodians the ability to support parachain native assets without running infrastructure for those parachains. But a lot of their users also want to stake, and if they have to teleport the assets back to the parachain to make certain calls, then it puts them back in the same problem of needing to run nodes there.
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 stake_remote(asset, amount) call.
Ank4n
commented
1 year ago Do we know how much relay chain usage is staking related now?
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.
vstam1
commented
1 year ago Validators need to set session keys on the session pallet and tie it to their ValidatorID (stash account). The validators on staking chain would probably need to set session keys on the relay chain with a remote origin from Staking chain. Would this work?
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. Lets say Alice on staking hub wants to set session keys on the relay chain session pallet:
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:
Parachain(StakingHubId)\AccountId32{id:Alice}
to:
AccountId32{id:Alice}
So it is as if the local Alice account dispatches the set_keys call.
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.
joepetrowski
commented
1 year ago DOT tokens can be transferred to staking chain in order to stake. The chain cannot burn or mint the tokens. Relay chain (in future this could be Asset hub) could mint 8% of total supply and teleport it to the Staking Chain at the start of each cycle where each cycle is 28 eras. This 8% then is only used for Staking rewards.
We talked about not having tokens on Staking chain at all (or may be a small balance just for paying fees) but eventually decided against the complexity introduced because of it. The topic is a bit beyond the scope of this issue, though we could revisit it if someone has strong opinions about it.
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.
burdges
commented
1 year ago 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.
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.
Ank4n
commented
1 year ago 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.
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.
Ank4n
commented
1 year ago
- Until now, staked DOT has been non-transferrable but still usable for other locking (now freezing) activities, namely governance. Moving DOT to a staking chain means either (a) those funds can only be used for staking, or (b) governance (and other freezing activities) will need to know about a user's DOT in multiple locations (Asset Hub and staking chain).
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 NoteUnlockable instruction to governance chain, 3) vote action on governance chain once it receives proof of hold. Governance chain would just know there are some dots locked in asset hub/staking chain and it can be used for voting. Apps/wallets would need to integrate with both Asset Hub/Staking chain to see all the Assets/DOTs a user has.
- As alluded to in my previous comment, it adds extra integration work for applications/services to provide a very common service. Ideally Asset Hub can be somewhat a single entry point for "universal" user stories (transfer, stake, vote). All asset mutations (transfers, rewards, slashes, holds, etc.) would be accessible via an Asset Hub node. Of course, 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, but the asset-related side effects come to Asset Hub. With this pattern, custodians/applications could support transferring, staking, and voting for any asset on any chain reachable from Polkadot that implements the relevant XCM instructions.
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 what-to-vote) which means apps would need to integrate with both chains anyways. There were also some reservations around how a staking operation would work. Current LockAsset instruction iirc does not propagate the intent of locking to the non-asset chain, and so we need another xcm instruction describing the intent (such as stake the locked funds) but ensure that NoteUnlockable is processed first at the non-asset chain before the intent xcm. This from what I understood was not so trivial, and as it works today, apps would still need to integrate with both chains, listen for NoteUnlockable before issuing the next instruction.
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).
joepetrowski
commented
1 year ago Most of these instructions will need followup interaction with the non asset chain, such as stake would require a follow up action of nominate
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.
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.
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.
Polkadot-Forum
commented
1 year ago 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
kianenigma
commented
1 year ago Some thoughts after discussing this in person over the last 2 weeks:
I would divide this in general into two tasks:
Code refactor: Refactor EPM to be multi-block. There is also a branch for this that needs reviving. Refactor staking to not contain any notion of controller. Refactor staking to contain a simple approval-stake tracking system, and track the total amount of stake that is bonded, is active, and is unbonding. There is an endless list of other refactors, but they are not needed.
Interfaces: Put a staking parachain with the current incomplete pallets asap on a test network and start working on the interactions between the RC and the parachain.
These are fairly independent and can be pursued in parallel for the most part.
This 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. Fixed nomination is robot-pools, Mirror nomination is robot pools. There are some downsides to this, mayhaps a more limited ability to "switch your pool", but all in all would yield a much much simpler staking system.
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:
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