Feat/subnet leasing

[l0r1s]

Description

Add the subnet leasing feature that can be used as the call passed to a crowdloan.

This enables each contributor of a crowdloan to become a shareholder of a subnet for a finite or infinite number of blocks, hence receiving a part of the subnet owner's cut when they are distributed, directly to their cold keys.

The distribution is done on each block if the subnet is leased and if there is enough liquidity in the subnet pool, if there is not enough liquidity, the dividends to the lease are accumulated for later distribution.

When the lease has passed his end block, the lease can be terminated by the beneficiary (the crowdloan creator that will target this call) to transfer the ownership of the subnet from the lease to himself.

Related Issue(s)

• Closes #[issue number]

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run cargo fmt and cargo clippy to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

[shamil-gadelshin]

Looks good: I left a couple of small recommendations.

[shamil-gadelshin]

Why did we mark the benchmarks as extra here?

[l0r1s]

Why did we mark the benchmarks as extra here?

Because it makes the benchmarks workflow fails due to the use of parameters and it can't detect correctly that parameters are used. I did run the benchmarks on a beefy server though. It will be changed in the future after the work from @JohnReedV on the macros to autodetect this (if doable btw)

[namoray]

Cool idea. Could it be extended to fulfil its destiny?

There is a very desirable outcome for subnets, which is the ownership is fully decentralised. This would mean that subnets could be composed of multiple different owners, and not controlled by one entity. I think there needs to be 3 things for this to happen:

1. Subnet owner cut is distributed amongst multiple shareholders ✅
2. Each shareholders weight also counts as voting power. For example, when changing hyper-parameters ❓
3. There is no one 'super' owner key which has elevated privileges ❓

I don't believe 2 & 3 are implemented right now (forgive me if I'm wrong, I'm not proficient in rust).

The feature where leases can be temporary is very nice, but in our goal for decentralisation I think 2 & 3 matter more. They don't necessarily need to be mutually exclusive though, instead shareholders could vote to form temporary new leases rather than the 'sudo owner key'.

Is this within scope for the current issue, or should another issue be made? Hopefully the current implementation wouldn't prohibit 2 or 3.

[sam0x17]

Each shareholders weight also counts as voting power. For example, when changing hyper-parameters

I wonder if there is some way to do stake-weighted threshold BLS multi-sigs 🤔

[camfairchild]

Is this within scope for the current issue, or should another issue be made? Hopefully the current implementation wouldn't prohibit 2 or 3.

This is more of a job for the EVM layer. What we should tackle on the runtime-side is to make the subnet owner interface accessible via precompile(s) so that calls can be made to change hyper-params and read storage maps.

Issue #1615 is sufficient for decentralization like this via a smart contract -based DAO. Where arbitrary calls are voted on and approved.

The harder thing is fine-tuning what calls can be voted on, which would be better served by precompile perhaps...