The idea with subnets is to allow teams to build chains and/or applications on top of Ren, adding value to darknodes and the ecosystem, which in turn boosts the security of the network, making it more attractive. With subnets, teams can get access to a decentralized pool of validators (darknodes) to run their chains/applications, which natively supports cross-chain and multichain functionality, while allowing them flexibility in what programming framework they want to use. Deploying on some other chain and only integrating RenJS does already support a lot of use-cases, but it’s not the same package deal and introduces much more dependence on confirmation times and wrapped liquidity. Deploying on Ren would significantly alleviate those multichain UX frictions. It’s one of the ways we’ll stay more competitive in this scene as well.
Chico’s post regards the idea about whether nodes running on subnets would need additional bonds. This is not something we have suggested, what I mentioned previously was a design possibility where subnet deployers would need to bond some REN to spin up a subnet, which is the opposite of requiring darknode operators to bond additional REN to run validators on subnets.
One possibility we are considering is simply to make it so that anyone running a darknode can spin up a validator in a subnet, so it is opt-in, instead of some rotation mechanism where only a fixed number of nodes less than the total amount of darknodes are able to participate at one time. At least for the flagship EVM subnet that could be a possibility.
But if we want to allow teams to deploy private/permissioned subnets on top of Ren (generating volume and value for every darknode), or some fast centralized subnet with only a few super-computers powering their application while darknodes handle all the MPC stuff, then we might have to consider a model where they would have to spin up darknodes themselves to be able to run their private/permissioned/centralized subnets, since it would be impossible to force them to allow other darknodes to participate as that is not the solution they are looking for anyways.
Either way the point of it all is to bring more value to darknodes in the end. But if the community doesn’t support this proposal the team can drop the focus on developing Ren into an L1 and shift all focus to decentralizing the network, which we will make a proposal about soon as well.