RFC-000-036: Ren 2.0

Thanks for the comment @DryOracle.

Some other models that were discussed include:

  1. Have a single programmable environment, and just choose EVM as it is the most used and has the best tooling. The subnet model is a more generalised version of this

  2. Create a three layer stack, where we split Ren into a storage layer, compute layer and validation layer run by different nodes, each having different bonding requirements and building compute environments that abstract these layers. This is pretty interesting, but it is only possible if we are able to build an efficient proving system.

  3. A multichain payment channel network, where Ren is the counter party to sign. This can be used to build smart contracts that can control payment channels across blockchains. This would require builders to use a newly designed programming framework.

  4. Optimistic cross-chain communication, where we can communicate between blockchains that have smart contracting functionality. Still trying to see how we could support Bitcoin with this model.

The primary reason why the subnet model was chosen is because it gives devs the flexibility to build Dapps at various levels, meaning people can build both Dapps on subnets or subnets themselves depending on the purpose, and keep it separated from the main network. This keeps the core system simple and secure.

With this RFC we are opening up this discussion to everyone. We would love to hear other models that the community proposes that would help with an additional stream of income for DNOs.

8 Likes