RFC-000-036: Ren 2.0

Requests For Comment | RFC
1

Name: Ren 2.0
Authors: Ren Labs
Status: Draft
Scope: Supporting native multichain applications on Ren through the Subnet model

Overview

We propose the Subnet model as the future of Ren as a L1 platform. A Subnet model means Ren would be able to support multiple different kinds of applications and blockchains on top of it such as EVM-based ones. We believe this model balances many of the trade-offs well in terms of deployment time, fund safety, dev UX, and programming flexibility.

Background

The success of the current model of Ren started back in the day of DeFi summer in 2020. New and old DeFi protocols, such as Compound, Synthetix, and Yearn, were launching exciting liquidity mining events aimed at attracting large amounts of liquidity. We had also just a few months before launched the first version of RenVM on mainnet, and together with Curve and Synthetix launched our own first liquidity mining event (https://medium.com/renproject/introducing-an-incentivized-btc-liquidity-pool-by-ren-synthetix-and-curve-213d21691d9a). As a result, during DeFi summer, large amounts of BTC flooded into DeFi, much of it through Ren, generating high volume for the protocol, which rewarded darknode operators plentifully.

While the frenzied DeFi summer is long past us now, and large token emission events are more rare than before, the need to bridge fresh BTC (and other ‘not-smart’ coins such as ZEC, DOGE, and others) into DeFi ecosystems such as Ethereum or Solana will always remain a use-case, especially when accounting for new source chains and host chains launching in the future, some of which might even become bigger than the ones we have today. Ren Labs is dedicated to further contribute to this use-case, through the addition of new source chains, new host chains, and more host-to-host tokens. Supporting more assets and chains also lays the foundation for the use-case of routing, which is typically the moving of an asset from one chain to the most liquid form of that asset on another chain. For instance, moving USDC from Ethereum to USDC on Solana, by wrapping it from Ethereum into renUSDC on Solana and then trading into native USDC on Solana in a stablepool. We will be supporting projects such as Varen (https://varen.finance/) offering this use-case, which will add another source of volume for Ren.

Our original vision of the multichain world has been confirmed. Other teams have also begun to realize the same, resulting in the proliferation of new cross-chain protocols, sometimes multiple new ones launching in the same week. This called for a strategic reevaluation internally in the team, about how we can excel better in the cross-chain space given the mounting competition offering similar utility. That strategic reevaluation started back in 2021, resulting in our organizational evolution into Ren Labs, with the mandate of supporting native multichain applications on Ren (https://medium.com/renproject/the-future-of-ren-bf47bc42244a).

In this proposal, we outline our current thinking on the best way forward for supporting native multichain applications through Ren.

Details

Previously, we announced that we would expand RenVM into an L1, opening up for application development directly on top of it.

  • [We aim to make] its advanced cryptography programmable and usable for arbitrary use-cases, where bridging chains becomes just one of many types of use-cases. This means any kind of application will be able to be built and deployed directly to RenVM. Applications will be able to live on multiple chains simultaneously. Reference

During our intensive R&D phase, one particularly promising pathway has become clear, which balances many of the trade-offs well in terms deployment time, fund safety, dev UX, and programming flexibility, which is the model we will be sharing in this proposal. And that is the ‘Subnet’ model.

A Subnet model in Ren’s case would look somewhat similar to Avalanche, in that there is a dynamic set of validators working together to achieve consensus on the state of a set of blockchains. These subnets would have the ability to access all blockchains supported by Ren, and can be designed completely flexibly, as long as they natively interface with Ren (in a stronger sense than the current way Ren interfaces with chains such as Ethereum and Solana). The subnets could differ in decentralization and programming framework depending on developers’ intentions, offering a whole host of new possibilities which couldn’t be supported by having applications deployed only on the Ren chain itself. This will ensure simplicity of the main network, ensuring no new attack vectors are introduced, while being able to support a multitude of different computational frameworks in parallel.

Additional benefits with this model is that it doesn’t convolute the fee model, as we can have classical mint, burn, and burn-and-mint fees whenever cross-chain assets are brought into the Ren ecosystem and subnets, or moved between chains. The subnets can additionally define their own fee models that are best suited for their use-case, to incentivize Darknodes to participate in their subnet (by offering computational resources). Together with the benefits of being able to launch sooner and keeping the system as safe as before, offering better dev UX and programming flexibility, we believe this to be the most fruitful path forward.

And in this model, Catalog would be the first DApp deployed on our flagship EVM subnet. This subnet would directly support any EVM-based applications as soon as it is opened up and available to third-party developers. But regardless of which path Ren and the community ultimately takes, Catalog deployment is not directly dependent on any subnet being live on mainnet, and if Ren goes with the Subnet model, Catalog would be deployed before the EVM subnet would be available to third-party developers.

We believe this vision of Ren 2.0 is the most sustainable model given its flexibility, and therefore has the strongest chance for success in this competitive landscape; whilst allowing the team to continue to contribute and nurture the Ren 1.0 use-cases. We are very excited to see the community’s contribution in this area and look forward to your participation and feedback.

Implementation

  • We will have a considerable period of open discussion regarding the proposal, to collect sentiment, feedback, ideas, and suggestions.
  • Depending on what the community dictates, Ren Labs will follow up with how this model could impact the protocol and explore various technical and organizational frameworks to facilitate the transition.
  • If the community is in favor of the proposal or a modified version of the proposal, we will publish a RIP with more worked out details which would be subject to a governance vote.
16 Likes
2

Thank you for putting this together. It sounds fantastic

Apart from community support is there anything else that you require? Specifically are funds required?

Many thanks fRen

1 Like
3

Thanks Max, very interesting proposal :+1:

I’m still trying to wrap my head around the concept as I’m not super technical, but here are some initial questions that come to mind:

  1. How would Ren define and maintain a secure balance of subnet vs. core Darknodes? Would there be a limit say, to how many subnet nodes could be operating at one given time? How would these loads be balanced to prevent all core nodes joining subnets?

  2. Would nodes need to somehow ‘qualify’ to be eligible for subnet status?

  3. What is meant by the subnet nodes having ‘access’ to other Blockchains? Are they just reading the state of other chains, or are they actively taking part in the consensus/execution of those Blockchains that they can access?

  4. Where (if any) do incentives come in? Why would a non-subnet node want to join a particular subnet?

  5. How are subnets conceived and created? Does a third-party application or developer request a custom subnet within Ren for their purpose?

  6. Will subnet nodes have additional responsibilities/expectations to core nodes? Will they be compensated differently?

  7. Will introducing subnets of nodes have an impact on Ren’s ability to be byzantine fault tolerant? (if >1/3 nodes go offline)?

  8. Could core nodes vote to override/remove certain subnets in emergency situations?

8 Likes
4

Bearing in mind, I’m not a technical person; if I’m reading this right: this subnet model offloads an amount of the security and UX and design concerns to devs who launch projects on RenVM?

The Ren L1 gets to keep a tight, more manageable focus on the base layer, keeping it simple and thusly, more easy to secure, while builders are responsible for ensuring their dapps and projects have the necessary security apparatus.

If so, I think I agree that it is a great model to build out. I’m not particularly a fan of the model of being all things to all participants- we can do fewer things exceedingly well and builders can retain the lift of building carefully.

I have a question re: the nature of the subnets. The proposal states Catalog will be the 1st Dapp deployed on our flagship EVM subnet. So, this means all EVM compatible Dapps will be on one subnet; the EVM subnet? And if so, how much more friction is introduced communicating ACROSS subnets, or will it pretty much be the same experience for 2 EVM Dapps on the EVM subnet communicating, as it would be for Catalog to communicate with a Dapp on a non-EVM Subnet?

Pardon all the questions built on unconfirmed premises. Regardless: With the rationales put forth in the proposal, I’m in favor of the subnet structure.

Oh, one last question not built on top of conjecture: Approximately how long after a confirmation vote does the Team speculate it will take to build this out fully?

4 Likes
5

Thank you Max and team for putting this proposal together.

I am still wrapping my head around but initially I have the following questions:

Who are the set of “dynamic validators”? Are you referring to DNOs or Greycore or a new type of validators? If DNs are the validators, why does it need to be dynamic ? Why not all DNs can be working in all subnets?

In the post there’s really not mentioning how is the fee structure apart from mentioning classical fees (mint/mint&burn/burn) will remain whenever these functionalities are required. For the new set of responsibilities, how are the darknodes being rewarded?

Is there a maximum set of validators for subnet? If yes, is there a risk a set of validators earns more that the rest of nodes (if validators=Nodes). Also, Is there a minimum # of validators for subnet? If yes, how many? And as Shilliam mentioned, how are they chosen?

It is being said that Catalog will launch already on a EVM subnet. It seems this subnet model is been decided regardless of this RFC, how would catalog be affected if this RFC decides on a different path?

If Catalog is already in a subnet who are the set of validators for that subnet?

There is no mention of DNs in the post, have they changed their role?, do they have new responsibilities added? Could you please elaborate how DNOs work look like?

These are some of the questions that come to mind just by reading the post.

Thank you

6 Likes
7

Thanks @MaxRoszko for the RFC, very nice update and the subnet approach totally makes sense to me.

One thing that I think should be further clarified:

In my understanding the core layer would expose only a few operations to users/subnets, such as:

  • lock (deposit asset from native chain into renvm custody)
  • mint (mint ren asset on a chain while keeping underlying in renvm custody)
  • burn (burn ren asset on a chain while keeping underlying in renvm custody)
  • burn&mint (switch ren asset’s chain while keeping underlying in renvm custody)
  • release (withdraw asset from renvm custody back to native chain)
  • transfer (move asset between renvm accounts)

Is that a correct understanding of the main layer ‘minimal’ capability? Any major operation missing?
Given above list of operations, currently only mint/burns currently have fees… however some subnets like Catalog do not require mint/burns, mostly lock and release, would it make sense to update fee model as soon the full list of core operations is confirmed?

3 Likes
8

Thanks for the proposal.

I think it’s critical to understand the use of the Ren token in any proposed model before deciding if the model is best for present-day DNOs. DNO’s have only the context of the current node model in which to understand any potential use of the Ren token.

The reality is: What questions could we possibly ask in order to protect our best interests as DNOs without proper understanding of how the Ren token would be used in a sub-net model with it’s accompanying node environment?

For that reason, my questions are as follows:

  • Will any nodes in the future, whether assumed DNO’s or Greycore nodes, validating nodes or block-producing nodes, dynamic nodes or otherwise, be granting governance rights and/or voting capabilities for the Ren chain including but not limited to any potential future DAO for Ren chain and the Ren ecosystem? If so, what for and do any of those governance and/or voting rights supersede the current governance rights and voting weight of present-day DNOs?

  • What has the team imagined thus far in terms of Ren token utility in a sub-net model with its accompanying node environment?

  • Will there be block-producing nodes and/or validating nodes, and if so, what is the distinction between the two, if any, in terms of staking Ren?

  • Will there be block-producing nodes and/or validating nodes, and if so, what is the distinction between the two, if any, in terms of bonding Ren?

These questions seem pre-mature, but without a working understanding of how the Ren token will be utilized in any environment, whether sub-net or otherwise, it’s nearly impossible for DNO’s to have any assurance that we are voting in Ren’s self-interests, and not those of some other project, entity, organization, chain, token, etc.

Please understand that from DNO perspective, we cannot know if sub-net is optimal for the Ren token without knowing if the token will be used solely for bonding darknodes (as is under the current model) or something more. If we assume the sole utility of the token remains the same, can you provide us context in which the sub-net nodes differ from current darknodes, such as amount required for bonding, staking, etc.?

Thank you, and please advise.

7 Likes
9

Will we hear about alternative pathways if we ultimately reject the Subnet model? If we are only to discuss one approach, I am pretty sure that approach will be favored as the alternative is essentially nothing.

I believe we can’t have a productive conversation about “Ren 2.0” if we are only being presented with one “pathway.” I personally think it would be beneficial to hear about other possibilities discussed by the dev team so we can weigh pros & cons of each. Ideally the dev team would also weigh in w.r.t. time, complexity, preference, limitations, etc.

6 Likes
10

+1 to all the questions above. Core assumption for me is the community can and will create a correct model of incentives for subnet and DNOs. I have no worries here—we’ll hash it out once more info is available. As long as we keep DNO incentives a priority (DNO>subnet) in this kingdom, we good (and DNO are the endpoints so we are last mile gatekeepers in a way). The key is the sentence above about subnets having to compete in incentives for DNOs to participate in their subnet.

The bigger questions are more strategic and fundamental to the future of crypto interop apps and the market:

  • Are there other major multichain competitors taking a similar approach? (And if not, why?)
  • Do we have any defensible advantages? (With numerous multi chain players providing ‘good enough’ alternatives)
  • Do any assumptions change in a post ETH2 world?
  • Which assumptions can we test with Catalog? (Does it’s success or failure support or disprove any of our assumptions?)
  • Is there a demand for projects who actually want to build such subnets? Examples? (What other alternatives do they have vs our solution?)
  • Do we have the marketing and dev community building resources dedicated to make this happen? (“Build it and they will come” is not quite enough in the competitive landscape ahead)
  • Do we have a potential early core customer? (Ie powering the Alameda research empire, or a major defi platform that wants us to build this)
7 Likes
11

I just read the Ren 2.0 proposal, and I am stoked so far. However, I was wondering, if DNOs can chose which subnets they wish to validate and how much overhead do you expect from this model?

So far, DNs are comparably lightweight (hardware-wise). How seamless do you expect these subnets to work together?

Will there be a fee to move assets between subnets?

Do I have to move assets between subnets at all?

This would defeat the whole purpose of RENs (and Catalogs) vision of having a single solution for all multichain purposes.
?

13

Thanks @BlockchainBard for your questions.

As a general disclaimer, the spec has not been finalized as we wanted to make sure the community was onboard before doing so, and some things might change between now and actual implementation depending on what features our community wants to see in the system. Will be answering your questions based on our current design.

  1. A Darknode can participate in a specific subnet by running a subnet node on a different instance, and is able to participate in any number of subnets (if the subnets allow it, based on the security assumptions of each subnet). So for a DN to participate in a subnet they have to run both a core Darknode and a subnet node, and the bond is used to protect both networks. A subnet can have an additional bonding requirement on top of the 100k REN staked to run the DN.

  2. Subnets have to pick them. For ex, any DN can join a queue to join a subnet, and every epoch the subnet validator selection logic picks nodes from the queue and the current nodes using some selection algorithm. This could be as simple as selecting random n nodes out of all interested participants, to creating a DN scoring algorithm that picks Darknodes based on how long they have been a part of the network/how many subnets they are currently running/etc. to guess how likely is this DN to try to cheat.

  3. This statement means that all the Ren subnets can bridge assets in and out of their subnet from any supported chain and pay the expected fees.

  4. The subnet gives validator rewards for all the subnet participants. The subnet would be charging tx fees from its users (as the subnet has full control on the fee model) and these fees go to the nodes participating in the subnet.

  5. Yep, anyone can build their own subnet following the Ren subnet requirements (which would be very lean), and ask Darknodes to participate in the subnet.

  6. This is already answered above – let me know if any extra clarification is required here.

  7. No, as the subnet sytem is built on top of the existing system, it will not impact or reduce the current security of Ren.

  8. The Darknodes can choose to opt out of a subnet, and the subnet halts and can be removed on the next epoch if it has no members. Even though this is conceptually possible, as in any other blockchain such as Ethereum, even if one miner is mining the blockchain can continue.

3 Likes
14

It is up to the developers to decide which subnet their Dapp gets deployed to, but we believe all EVM compatible Dapps should exist on the same EVM subnet, to take advantage of the network effect. Since it is decentralised, teams can build multiple EVM subnets with different requirements/assumptions if needed.

There would be a Ren inter-subnet communication standard, which will be used to communicate between subnets. In saying that, it would be simpler to commuicate with those on a single subnet than between subnets.

The timeline would depend on the final design that gets agreed upon and will be part of the RIP.

4 Likes
15

Thanks for the questions, @Maggie.

Who are the set of “dynamic validators”? Are you referring to DNOs or Greycore or a new type of validators? If DNs are the validators, why does it need to be dynamic ? Why not all DNs can be working in all subnets?

The validators are Darknodes. The reason they are dynamic is because subnets may have different requirements with regards to decentralization or computational bandwidth. We cannot expect every Darknode to run a high performance machine.

In the post there’s really not mentioning how is the fee structure apart from mentioning classical fees (mint/mint&burn/burn) will remain whenever these functionalities are required. For the new set of responsibilities, how are the darknodes being rewarded?

The subnets have their own incentives for the participating Darknodes.

Is there a maximum set of validators for subnet? If yes, is there a risk a set of validators earns more that the rest of nodes (if validators=Nodes). Also, Is there a minimum # of validators for subnet? If yes, how many? And as Shilliam mentioned, how are they chosen?

Yep, there would most likely be minimum and maximum number of validators, but these will be defined by the subnets themselves. The nodes are chosen using a selection algorithm used by the particular subnet – this could be as simple as a random node selection or something based on how long the node has been participating in the network for/how many subnets it is participating in, etc.

It is being said that Catalog will launch already on a EVM subnet. It seems this subnet model is been decided regardless of this RFC, how would catalog be affected if this RFC decides on a different path?

This was provided as an example. Catalog will most likely be deployed to another EVM compatible chain that Ren supports, until the EVM solution is finalised on Ren itself.

There is no mention of DNs in the post, have they changed their role?, do they have new responsibilities added? Could you please elaborate how DNOs work look like?

DNOs will have more things to do with the new system. Not only do they get to participate in the current bridging through RenVM, but also can actively participate in other subnets and earn substantially higher fees.

4 Likes
16

How is the team approaching the rollout of Greycore to mainnet? To me it seems like this is crucial b/c Ren needs to be at least somewhat decentralized for the launch of Ren 2.0 to have the largest impact.

Otherwise, how is Ren going to hit the ground running in attracting users and a dev community when the network is still completely controlled by the team?

4 Likes
17

@Susruth who controls the subnet requirements for validators? Say an EVM subnet launches and 1 project wants to live on it, does it decide the validator requirements? If another EVM project wants to launch there do they decide collectively?

I’ll be frank, the “can have additional bonding requirement” part worries me. I’ve been carrying my REN and DNs throughout the years now to learn that a big, juicy EVM subnet might launch on Ren and I can be left sitting on the sidelines due to another potential paywall? Feels like I misunderstood something.

For example I personally, as a DNO with multiple nodes from before day 1 (chaosnet, remember?), want to participate in everything that RenVM supports and be able to reap rewards accordingly, can you clarify if I’ll be able to with current Ren 2.0 vision? And if not, than how is that a good thing?

3 Likes
18

Thank you @Susruth for detailed responses. I have however further observations.

For what you have shared, I can see the system will create an uneven distribution of rewards between nodes. Some nodes participating in juicy subnets will receive more income than others and there will be a cap so not all nodes will be able participate in those. The process of how nodes are selected in a subnet is somehow not clear and will, among other things, depend on specs of subnet nodes. This leave the non technical or small node operators in disadvantage against the more technical/whale DNOs.

It seems the arm race that was rejected by the community when Renex is brought back.

In your response you mentioned “we cannot ask all DNOs to run high specs” why not? I think this will level the playing field and it would mean all darknodes will be able to participate on all subnets and it will be up to each node to decide in which particular subnet they want to participate.

How much are we talking in terms on specs? When Renex we were paying $50 -$60 a month for higher specs with no real income. We are at a different stage of the project where much higher income will be produced and this certainly can be absorbed. I believe this way all nodes will have same opportunities

Just to be clear, I am advocating for the model to not have caps in subnet nodes and for nodes to update to the highest spec in any given time.

Additionally, I would like to ask what is the purpose of further bonding requirements from subnets? Is this bond in ren or in the project token?

4 Likes
19

I have some concerns that’s partly have been addressed above but still there is some clarification needed from your answers @Susruth.

  1. A Darknode can participate in a specific subnet by running a subnet node on a different instance, and is able to participate in any number of subnets (if the subnets allow it, based on the security assumptions of each subnet). So for a DN to participate in a subnet they have to run both a core Darknode and a subnet node, and the bond is used to protect both networks. A subnet can have an additional bonding requirement on top of the 100k REN staked to run the DN.

Does this mean that as a DNO with few DNs I have to choose to which subnet I will actually deploy my node(s)? The rationale would be to deploy to the subnet that generates the most income. What would be the incentive to stay on other subnets (like core net if that exists as a concept) etc.?

  1. Subnets have to pick them. For ex, any DN can join a queue to join a subnet, and every epoch the subnet validator selection logic picks nodes from the queue and the current nodes using some selection algorithm. This could be as simple as selecting random n nodes out of all interested participants, to creating a DN scoring algorithm that picks Darknodes based on how long they have been a part of the network/how many subnets they are currently running/etc. to guess how likely is this DN to try to cheat.

With this in mind would the maximum limit for darknodes still be 10000?

  1. This statement means that all the Ren subnets can bridge assets in and out of their subnet from any supported chain and pay the expected fees.

And finally where would a fee be collected if there is a burn’n’mint event between subnets. Which DN on which subnet would get the mint fee, burn fee etc.?

4 Likes
20
  1. The subnet gives validator rewards for all the subnet participants. The subnet would be charging tx fees from its users (as the subnet has full control on the fee model) and these fees go to the nodes participating in the subnet.

The current rewards for DNO are not very high. So joining a new subnet might not have a huge impact on rewards. How can we ensure there are enough DNO securing a subnet? In the past it was always mentioned TVL in REN should not be higher than DNO bonded value.

  1. Yep, anyone can build their own subnet following the Ren subnet requirements (which would be very lean), and ask Darknodes to participate in the subnet.

Which parameters can be changed per subnet? Can you give some examples for different subnets and usecases?

  1. No, as the subnet sytem is built on top of the existing system, it will not impact or reduce the current security of Ren.

Isn’t the security guarantee splitted when introducing subnets? 1000 DNOs securing REN. When each subnet has 100 DNOs securing it, the security of each subnet is just 1/10 of the REN mainnet.

2 Likes
21

Thanks team for putting together the proposal, and for responding to the questions posted.

First, I think it’s important to try to provide a visual representation of the potential subnet architecture, so I put together a rough overview (all inaccuracies are mine) to help guide the conversation.

subnets

Assumptions/questions I have after putting this together, that I’d like to confirm.

  1. Standard burn/mint burn-mint fees: Those fees would remain, so anyone entering the RenVM network (and supported subnets) from an outside blockchain would have to pay fees to DNOs, correct?

  2. Fees between subnets: How would those fees be managed? Would these be the standard burn-mint fee required for host2host transfers?

  3. Subnet: Customized validator specs: Would these subnets run similarly to AVAX where, potentially all validators would be required to not only meet technical requirements, but regulatory ones as well? Could we see “permissioned subnets” make up the bulk of subnets with high volumes where only certain darknodes would be able to participate (based on location, identity, etc.)? Would such a structure harm decentralization?

  4. Additional bonding requirements: I worry, like others here that adding additional bonding requirements to participate in subnets would make it economically infeasible for DNOs with less means to participate. How would/could this be prevented? What’s your response to this concern?

  5. As we’ve seen with Solana, huge technical requirements can harm network robustness and decentralization. Would it be possible for DNOs to vote on a set of standard technical specs for subnets that support broad participation and increases network robustness?

  6. What is the ultimate role of the Ren token in this model? It’s utilized to bond Darknodes, but what about being used as a bond for subnets? Requiring DNOs to make purchases of dozens of tokens to bond their darknodes to specific subnets is not an optimal solution imo.

Overall, I think the subnet idea is interesting, but worry about lower robustness of subnets due to potentially infeasible economic, technical and regulatory requirements, and the potential to lock out DNOs with fewer economic resources from the most promising opportunities in subnets, which could have a negative impact on the overall network imo.

6 Likes
22
  1. Confidentiality, Availability, Integrity of assets
  • How private is the ecosystem?
  • How many nodes are needed to keep a subnet running? How about an EVM?
  • Assets are protected between separate subnets and EVMs?
  • Could EVMs within the same subnet modify, use assets, fake txs of other EVMs?
  1. TPS
  • Which nodes control TPS?
  • What is the theoretical TPS that could be achieved in this model?
  1. Dev time
  • ETA of RnD to production?
  • Would resources be taken away from current tasks like h2h, graycore, stables, ect.
  • Would this delay current tasks?
  1. TVB
  • Theoretically, how would a L1 subnet model affect/depend number of nodes needed to secure the network?
1 Like