I am looking for ways/ideas to automate validator selection strategy of a nomination pool via a smart contract based on on-chain metrics of a validator (such as number of stakers, slashed history, how long they have been validating, etc). Something like 1kv programme but on-chain.
We have a lot of nomination pools today with their own custom validator selection strategies which are off-chain and opaque (and in most cases manual or static). Having an easy way to write smart contracts to strategise staking operations on the relay chain would create an open playground to build innovative staking pools.
Since relay chain does not have support for smart contracts, can this be easily achieved via smart contracts on parachains like Astar or Moonbeam? Is it possible for smart contracts to read the state of relay chain (via xcm)? Or do they have to depend on an oracle? May be a phala phat contract can read the state by querying a full node directly? Are there existing parachain projects (including pallet) who use some kind of on-chain logic to choose validators on the relay chain?
Happy to hear any experiences/blockers in building these kind of smart contracts.
I’ve been thinking about this for Talisman’s nomination pools recently! One example of contracts managing some nominations on the relay chain are the Lido finance contracts. Looks like they’re reliant on an oracle to read state.
We also had a brief conversation with Phala about implementing some nomination pool strategy logic in a Phat contract and it seems possible, since you can make http requests from a Phat contract.
How is this going? Are you guys still working on it?
Good mention. It seems Lido had an automated validator election algorithm based on performance metrics of the validator (off-chain) to maximise for APR.
Unfortunately, it seems Lido has decided to stop supporting Polkadot.
I keep coming back to this, and I find it immensely valuable to have.
If there was a pool that would autonomously mimic 1kv behavior, I would happily start using it. This would allow some pools to essentially act as ETFs, tracking certain behavior.
Doing it via oracles and so on is a good start, but should not be the end goal.
Other than the suggestion to use Phala, I wonder if anyone from Oak network reads this or has an opinion?
Thanks @kianenigma for your response. This is interesting and I can imagine a Staking UI where a potential staker can choose to either:
Stake to their own set of up to 16 validators.
Stake to a pool that follows/mirrors another nominator (your suggestion would enable this).
Stake to a pool where someone manages the validator selection for the pool members.
For the third kind of pools, we still have to put lot of trust in the pool operators. Especially, what happens when a pool member does not agree when a pool changes its nominations? One has to wait 28 days to even switch a pool.
Ultimately, there are number of ways to solve for these use cases. I am very interested to understand how we can build a healthy dapp ecosystem tackling these problems. For example, can we use smart contracts to build
1kv like behaviour on-chain.
a DAO controlling a pool and voting to select their top 16 validators.
With respect to nomination mirroring, I think doing this at the smart contract level would be the right place for it.
One of the issues of the 1KV is high variance, i.e. it can only nominate some of the validators some of the time, not all of the validators all of the time. It would be interesting for other smart contracts controlling nomination pools to be able to plug into that data directly and smooth out the variance curve (cc @will)
I think state query via XCM is quite challenging at the production stage. But we used ink to call a smart contract on another chain. So I assume VMP on ink smart contracts is possible. Having said that, the lack of documentation or work on the XCM state query is the major blocker (especially if we want to develop a chain extension that can do that)
XCM state query is probably a bad way to do it. Instead, there should be a pallet for querying state on other chains by traversing down from the relay-parent hash into the remote header and state root.
I like that idea for sure, but is there any documentation or PoC for that? I wonder how that can translate to a generic remote chain state query pallet that can be built into a chain extension. At least on Astar, we want to build pallets that can serve a generic utility to most contracts and avoid creating a pallet that serves a specific function for specific types of dApps.
It looks like the topic has gradually shifted to having a state querying mechanism. I think Phala’s Phat Contract can definitely help to build a State Oracle:
We have implemented a request-response programming model on Phat Contract. It enables a Phat Contract to watch and respond to a smart contract. So it allows an on-chain contract to initiate a relay chain state query with arbitrary parameters.
Phat Contract itself can send arbitrary HTTP request. So it’s pretty simple to query full node to get the data you want.
Recently we are trying to launch a low-code tool to enable writing javascript-based customized oracle. So to build a substrate state oracle, the developer may even not need to have deep knowledge of Phat Contract (rust & ink! 4.0). Simple javascript code can work.
So to put them together, I think it’s very viable to build a relay chain state query oracle by creating a Phat Contract listening to the on-chain contract requests, and answer the request with a HTTP request to the relay chain full nodes. The code can be implemented in ink! 4.0 or javascript.
In addition to the state query oracle, it’s also possible to create a “remote control” Phat Contract as well. Phat Contract can store secrets by default. We have implemented the substrate and EVM wallet libraries inside Phat Contract. That means, we can also create some Phat Contract owned wallets and use those wallets to interact with any chain by signing and broadcasting regular transactions. So it’s not hard to imagine building more complex logic (e.g. computing on a large dataset and trigger some on-chain actions automatically).
How far away from there? Let me list the current progress of Phat Contract and the challenges:
Phat Contract on mainnet launch: Will be launched on Phala Network in this month. Phat Contract has been running for more than half year on the public testnet. So I’d not consider it a blocking issue.
Low-code tool: Will also be launched in this month. However the first release will only come with a domain specific oracle. The version with custom javascript editor will be ready after 2-3 weeks. It’s possible to construct the low level contract call directly to use javascript-based oracle framework or develop in ink! though.
Security of full node access: If the oracle only query the data from one full node, and the requester accepts the response blindly, even with the security guarantee of Phat Contract, the full node itself will become a single point of failure. It’s ok to play with a toy oracle fetching data from a single source, but eventually we must introduce some way to verify the fetched data. One way is to simply add more full nodes and aggregate the data, like what ChainLink does. A better way is to run a full Grandpa light client inside the Phat Contract so that it can verify the full state trie with the light client level security guarantee.
On-chain contract integration: So far we have full EVM support (congratulations, Moonbeam!), experimental Substrate support (via a special pallet). The ink! support can be added but it’s still a pending item on the TODO list. If anyone is interested to add the integration, I believe we can extend the support pretty soon.
