RFC-000-036: Ren 2.0

From the proposal I understand it as follows (and I invite the team to post specifics around this to clear up any confusion).

There is a core layer, the sMPC layer, providing the current bridging functionality (mint, burn, burn-and-mint, custody, etc) similar to what RenJS provides. This layer is relatively stable and moving to the Greycore phase of progressive decentralization. Any active Darknode by default secures the core layer.

The Ren 2.0 subnet model proposes to add an additional layer. Call it the subnet layer, this is distinct and separate form the core layer. But subnets do interface by default with the core layer through its API’s to access its cross chain functionality and liquidity:

Because the subnet layer is distinct from the core layer, it results in compartmentalization between the two layers (and also between different subnets btw). Since the core layer is not changed and only accessed through its regular interfaces, this means experimentation can happen on the subnet layer without affecting the stability on the core layer (I assume in the quote below @MaxRoszko is referring to the core layer when saying no attack vectors are introduced as he refers to the main network):

It has also been mentioned that active Darknodes can opt-in to secure a specific subnet by running a subnet node on a different instance. I think we should take @Susruth’s example here and differentiate between a darknode and a subnet node as there seems to be some confusion in this thread.

This implies there is a one-to-many relationship between a darknode and subnet nodes, as in, a Darknode Operator running a single darknode can participate in multiple different subnets by running multiple separate subnet nodes, one for each subnet that the operator opts in to.

This would fit nicely in to the progressive decentralization framework, as the core layer is relatively unaffected, while the subnet layer goes down its own track of development, experimentation and hardening.

There are some assumptions and reading-between-the-lines going in to this though. Would appreciate if the team can clarify, and as @davoice321 suggested, architecture diagrams would greatly help here.

Another point which is unclear is how we get to the end stage. As the proposal mentions, Darknodes can opt in to run subnet nodes, but will this be available to community darknodes from the get-go, or do we go down a similar decentralization path as the core layer? Since subnets are distinct and the blast radius limited, maybe we could consider going full decentralization from the get-go for the subnet layer.

5 Likes