RFC-000-036: Ren 2.0

[Susruth]

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.

[Wake_222]

-Does the subnet model offer more options in areas of application to the other 4th models that you briefly presented?

• which model do you prefer in terms of interacting with other blockchains?

-Are all models also suitable for multiparty computation?

[DavidPerkins]

Considering the range of applications that Ren is suited for, I’m in favor of subnets. In fact, there’s already precedent for this in Ren’s own history.

In 2018, Republic Protocol evolved from a singular dark pool for all to a protocol for custom third-party dark pools with “adjustable fee structures, generalizable KYC procedures [for traders], and specific regulatory requirements.” I’m sure that was an educated decision. Perhaps the best version of a decentralized dark pool — or a multichain, institutional lending product like Aave Arc and Maple Finance — would have different fee and regulatory requirements than a permissionless DECEX like Catalog, despite all of them benefitting from programmable MPC.

Fees

Inter-subnet fees make sense, but intra-subnet fees remain an open question. What are the possibilties? Percentage of transactions, compute, and TVL?

Additional Bonding Requirements

A subnet can have an additional bonding requirement on top of the 100k REN staked to run the DN.

I’d like to present an argument against giving subnets the option to require additional REN from Darknodes. If this refers to third-party tokens or other requirements, then ignore the below.

First, TEEs nullify the argument that wealthier operators are more likely to act honestly. If Darknodes are continuously attesting their binary in RenVM, then there would be no safety differences between Darknodes of different bond sizes.

Second, bond size is not a determinant of performance or liveness. Allowing subnets to exclude good operators could disincentivize those operators from securing the main chain and other subnets by lowering their relative ROI.

Third, it could not only disincentivize good operators, but actually reduce their participation outside of the subnet. If a Darknode needed 200K REN to participate in a high-revenue subnet, I assume the operator would only contribute — and earn rewards for — one node’s worth of security on the main chain and other subnets, adversely affecting decentralization outside of the subnet and forcing an opportunity cost on operators. And because secret shares can’t be variably sized, it wouldn’t make sense to reward one node for any more than one node worth of security on the main chain, even if it bonded 200K REN. If I’m missing something here, do let me know!

I’m all for providing maximum flexibility to subnets, as long as that flexibility cannot adversely affect anything outside of their own subnet. It might make sense to disallow the kinds that do at the protocol level.

[Susruth]

The 100k REN requirement is compulsory. On top of that the team that builds the subnet can decide upon and add more requirements – this flexibility is required to incentivize people to build interesting solutions.

The general subnet selection algorithm (which is based on the number of epochs the DN is running for) would choose DNs like yours, as people who have been running the DNs for the longest are less likely to act against the Ren protocol than people running DNs for a shorter amount of time.

[sotashinokomata]

This keeps the core system simple and secure.

I also find the subnet approach elegant while more open to innovation, but can you confirm what are the core operations you have in mind? as per RFC-000-036: Ren 2.0 - #7 by sotashinokomata

Also, given a list of core operations, is the added complexity of transferring renvm-custodied assets between subnets necessary? As in, couldn’t each subnet directly interact with assets at the renvm core layer without having additional transfer ops, might also help with composability between subnets.

[MaxRoszko]

@sotashinokomata

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?

With a subnet model, the main layer would have just a basic functionality as you say. Exact feature set is to be determined, there would probably be more than what you listed, related for instance to validator selection/rotation and stuff like that, maybe some governance related features, cross-subnet communication.

Catalog will not be a subnet, important distinction, it’s an app that has to live somewhere, like a subnet.

The fee model in relation to Catalog is not determined, has to be discussed and worked out and proposed.

[MaxRoszko]

@Janky_Eyebrow

• 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?

We are not proposing any governance changes, as usual darknodes (who bond REN) are those with governance rights.

@Janky_Eyebrow

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

The core token utility would still be to bond a validator. If we introduce subnets, there are potentially more ways REN could be utilized, such as bonds for deploying a subnet to Ren, or used for paying transaction fees in subnets, but this is a completely open design-space which we invite more discussion to.

@Janky_Eyebrow

• 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?

I’m not sure on your question, the general use of the term ‘validator’ entails them being block-producers as well. For the Ren core layer there is just the darknodes like before. Subnets might look different though, they are meant to be flexible in how they can be designed while being deployed to Ren.

[MaxRoszko]

@dripdrop1

• 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)

We are not aware of any other interop project attempting something similar. Which is part of the advantages of the protocol we already have built out and can extend on. And no changes post ETH2, we continue to support Ethereum naturally.

Catalog is the early customer that has demand for this capability, and which would test and advance our designs as we go along. Catalog could be deployed on another EVM-platform and still use Ren, but it wouldn’t benefit DNOs as much we expect, and Catalog would likely fare much better in a subnet if other applications also were present, so it’s a symbiotic relationship.

[MaxRoszko]

To address points and questions brought up by @Arviee , @Maggie , @davoice321 at once:

Whenever there is a mint, burn, or burn-and-mint by any application on any chain or subnet, those fees go to the darknodes, doesn’t matter if the application is on a subnet. So the concept of missing out on a ‘juicy’ subnet doesn’t make sense because you are still earning from its cross-chain activity. The extra subnet incentives are for the computational resources that occur as applications on it are interacted with users causing state changes, like a gas fee, and could in practice be much smaller than what the regular darknodes earn with the 5-20 BPS on cross-chain transfers we have currently.

In theory we want the costs for running multichain apps on Ren (through subnets in this example) to be low, to support as many applications as possible. It shouldn’t be an aim to extract as much money as possible from those deploying apps on Ren in the form of the computational costs, since then they will just go somewhere else. We should aim to make it as easy as possible for them to settle cross-chain transactions using Ren, as that brings the cross-chain volume, which rewards DNOs.

[Wake_222]

@Susruth

used

How do the various models differ in terms of the effort involved in creating the L1 platform?

Can you use the sub-network model to create a simple fee model where you don’t have annoying gas costs?

[Maggie]

Hi @MaxRoszko thank you for your answers.

About this: [quote=“MaxRoszko, post:30, topic:1185”]
we introduce subnets, there are potentially more ways REN could be utilized, such as bonds for deploying a subnet to Ren, or used for paying transaction fees in subnets, but this is a completely open design-space which we invite more discussion t
[/quote]

If ren is requested to deploy a subnet or pay for transaction, is this implying that there will be inflation in Ren token?

@MaxRoszko

The extra subnet incentives are for the computational resources that occur as applications on it are interacted with users causing state changes, like a gas fee, and could in practice be much smaller than what the regular darknodes earn with the 5-20 BPS on cross-chain transfers we have currently.

Thank you for clarifying I am happy with this however how can this be anticipated? In theory, apps building in Ren would use the crosschain functionalities but wouldn’t it be possible that designs are made within an app in a way the bulk of the profitability comes from functions other that cross-chain type activities? In this scenario, regular DNs would receive marginal profit and subnet DNOs running subnets nodes in this subnet will have significant more income. Is there a way to prevent this? I am not sure whether this is one of those “possible but unlikely scenarios”.

@MaxRoszko

It shouldn’t be an aim to extract as much money as possible from those deploying apps on Ren in the form of the computational costs, since then they will just go somewhere else.

I agree with this. That should not be the aim however a balance should also be sought for subnets not to request additional bonding. Specially when, as per explanations from Chico’s post, there is no real advantage for REN chain. So a balance is required.

About the comment “they will just go somewhere else” I always get triggered when this statement is thrown around as a justification to defend an argument. It almost implies we are not my bringing any uniqueness to the the table or functionalities that are supposed to be only unique to Ren. If this is true then, there is an interest to build on ren and that has a value in itself. If they can go somewhere else, where?

Would it be possible to clarify if possible additional bonds requirements from subnets are thought to be on Ren or on any other token?

Thank you

[Wake_222]

@MaxRoszko

. It shouldn’t be an aim to extract as much money as possible from those deploying apps on Ren in the form of the computational costs, since then they will just go somewhere else. We should aim to make it as easy as possible for them to settle cross-chain transactions using Ren

max you said if we(ren) are too expensive then they go somewhere else and build they apps there.

But I thought that ren will add some functionality that is not possible with any other system and it only works with ren.
Then there’s nowhere else you can go if the features are unique to ren?

If you are unique you can also be more expensive from my point of view.
Would like to know what special functions that Susruth has already explained will exist with the subnet model?

[DryOracle]

@Susruth

A subnet can have an additional bonding requirement on top of the 100k REN staked to run the DN.

1. Why would Subnets be allowed to define additional (optional) bonding requirements if the Darknode bond is used to protect both networks (Core and Subnet)? Couldn’t the Darknode be slashed if it misbehaves within the Subnet? (Further questions on misbehaving below)

@Susruth

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.

2. Can you define the overall lifecycle of a Subnet (leads into my next question)?
3. What happens to the assets “stored” on a Subnet if all Subnet nodes leave? I know they’ll still be custodied by the Core Network - would the Core Network have a ledger of where assets live and who they belong to on each Subnet? If so, I assume when a Subnet is removed, assets are assigned to their original owners which could then be able to move to other Subnets / leave Ren?
   a. Real world example: assume I have 1 BTC on Catalog (which would be deployed on an EVM Subnet). For some reason, all Subnet Nodes leave the EVM Subnet and it is removed on the next epoch. Where would my 1 BTC end up? Or rather, how would I access my BTC?

@Susruth

…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.

4. Can you expand on what is means for a Subnet Node to cheat? What actions are considered cheating? What could a Subnet Node gain by cheating?
5. How are Subnets allowed to change their Subnet Node requirements? Couldn’t a bad actor come in and change the requirements such that they are the sole operator and cheat how they want?

[shiny]

A - Can someone please clarify (or point me to where it has been said) if the current pre-subnet goals are still on the table and within the original expected timelines?

For instance -

(1) loading h2h and burnandmint on renbridge/varenX
(2) deploying catalog on Ren
- I read somewhere catalog may be deployed on another EVM chain but still use Ren?
(3) greycore evolution
(4) Migrating the Ren token to Ren itself which would save a ton on gas since Eth is so expensive and thus possibly speed up 3rd party pooling services. (Could Ren be like MIM and be burned/minted when interacting with other chains?)

For each of these 4, will the subnet model delay them in any way?

B - If subnet nodes require additional token requirements, if that requirement is in Ren, this will affect total available Ren for regular darknodes, token price and APR. May not be significant enough but worth clarifying.

C - with Catalog, we were going to discuss how darknodes would profit from internal transactions that were not burns or mints. With the subnet model, burns and mints are still profitable to darknodes, but it has been mentioned that subnet nodes may be the profiteers of internal transactions or computational demands on the subnets. I am a little concerned a subnet may find a way to use primarily TVL in Ren to handle its demands, in which case darknodes do not profit from this subnet only subnet nodes. Perhaps subnet nodes should be required to pay “rent” to darknodes as a small % of their profit so darknodes do not lose out to holding TVL yet not earning from it when used by a subnet, also for potentially being the backbone of large network of subnets and subnet nodes yet only profiting from burns and mints.

[Ben.L]

Hey Susruth,

1. the subnet model, was also suggested as a favorite because of a flexible fee model,
   Is that correct?
2. My only concern is, that the subnet model isn’t as appropriate for things like catalog?
   Is it just as easy to build something like catalog with the subnet model as with your suggestion number 4
   “Optimistic cross-chain communication”.
   Thank you and I look forward to your reply.

[MaxRoszko]

@Maggie

If ren is requested to deploy a subnet or pay for transaction, is this implying that there will be inflation in Ren token?

Subnets from a technical perspective doesn’t imply any change to tokenomics. But a change could be proposed for many reasons coinciding with growing the platform and ecosystem.

@Maggie

Thank you for clarifying I am happy with this however how can this be anticipated? In theory, apps building in Ren would use the crosschain functionalities but wouldn’t it be possible that designs are made within an app in a way the bulk of the profitability comes from functions other that cross-chain type activities? In this scenario, regular DNs would receive marginal profit and subnet DNOs running subnets nodes in this subnet will have significant more income. Is there a way to prevent this? I am not sure whether this is one of those “possible but unlikely scenarios”.

You have to compare against the situation we are now: the volume for an application on a host-chain, using Ren assets, doesn’t have to bring any direct cross-chain volume to Ren. There can be $1B worth of trading on a renBTC pool on Curve, without any volume going through Ren as a result of that trading. And from all of the gas spent on those transaction, none of it goes to Ren, only Ethereum miners. It is only indirectly through the demand to mint or burn Ren assets that DNOs get any kind of reward at the moment.

With the subnet model, we close that gap considerably by allowing DNs to participate in subnets, offering up computational resources for basic transaction fees. And applications deployed on subnets might also offer up additional incentives to DNOs so to get alignment from Ren governance given that they are deployed on Ren.

@Maggie

About the comment “they will just go somewhere else” I always get triggered when this statement is thrown around as a justification to defend an argument. It almost implies we are not my bringing any uniqueness to the the table or functionalities that are supposed to be only unique to Ren. If this is true then, there is an interest to build on ren and that has a value in itself. If they can go somewhere else, where?

They can deploy on any host-chain and just integrate Ren through RenJS, instead of deploying on Ren, just like the situation is today.

@Maggie

Would it be possible to clarify if possible additional bonds requirements from subnets are thought to be on Ren or on any other token?

From a security perspective it would only make sense if it was the REN token.

[MaxRoszko]

@Wake_222

max you said if we(ren) are too expensive then they go somewhere else and build they apps there.

But I thought that ren will add some functionality that is not possible with any other system and it only works with ren.
Then there’s nowhere else you can go if the features are unique to ren?

If you are unique you can also be more expensive from my point of view.

Yes but not every app needs functionality like that, some apps would do fine integrating Ren through RenJS and being deployed on some host-chain like a popular L2. So if we also want to get them as customers on a Ren subnet, it can’t be too expensive for them.

[MaxRoszko]

@shiny

(1) loading h2h and burnandmint on renbridge/varenX
(2) deploying catalog on Ren
- I read somewhere catalog may be deployed on another EVM chain but still use Ren?
(3) greycore evolution
(4) Migrating the Ren token to Ren itself which would save a ton on gas since Eth is so expensive and thus possibly speed up 3rd party pooling services. (Could Ren be like MIM and be burned/minted when interacting with other chains?)

For each of these 4, will the subnet model delay them in any way?

Subnets doesn’t affect (1). For (2) it depends on what your question is, Catalog deployment “on” Ren depends on what the architecture of Ren will be, but Catalog will be deployed before that and can migrate later.

(3) and in general decentralization is affected by the architecture we ultimately go with, but in the mean time we can make significant progress on decentralization, and we’ll likely make a separate proposal around it soon.

Regarding (4), we have never announced that we will be making this kind of change. But it is potentially something that could be done if governance wanted it, although it would be challenging making that token migration if you consider all the places REN is integrated (centralized exchanges, DeFi protocols, darknode registration contracts etc) where a coordinated migration would have to take place.

[Maggie]

@MaxRoszko

They can deploy on any host-chain and just integrate Ren through RenJS, instead of deploying on Ren, just like the situation is today.

If all the amazing and unique capabilities that Susruth mentioned in Discord can be done by just integrating ren through Renjs, then why would they go to the extra effort and cost of running subnets (fees to deploy and extra payment to nodes) if the same can be achieved for free by “just integration RenJS”? Even more, why are we going through this headache if the same can be accomplished by promoting integration of Renjs and why are we not doing it heavily?

Additionally from your post it sounds like a bad thing that they would “just” integrate Renjs but I was very happy with the integrations and cannot speak for all node operators but we always wanted more integrations. So if the amazing things can be accomplished NOW by integrating Renjs and there is not much demand for those integrations (as per current state) I do not see then why there would be bigger demand for running subnets in Ren that implies higher costs to them.

@MaxRoszko

From a security perspective it would only make sense if it was the REN token

Thank you for clarifying however this really contradicts Chico’s post about this bond adding security to the chain. It would be great if points raised by him are addressed.

@MaxRoszko

applications deployed on subnets might also offer up additional incentives to DNOs so to get alignment from Ren governance given that they are deployed on Ren.

How could this alignment with Ren governance occur when not all DNO are earning the same and there may be strong differences between them as they have different incentives?

[Wake_222]

Thanks for the answer Max

regarding the decentralization it sounds as that greycore will come as it was planned is no longer certain?

and there might be a change to the original greycore plan should it become the subnet model?
Is that correct and can you comment on how the subnet model will affect decentralization?