RFC-000-036: Ren 2.0

[Wake_222]

@Sabobi

Decentralization is imo of outmost priority.

I also agree that decentralization must be top priority.

@Sabobi

I am not a big fan of creating a separate team

I see it differently that the main ren vm team should work on the sub-net model. Two workers from the ren vm team should take over the management of the sub-net model with construction and maintenance….

But the rest of the ren vm team should continue to take care of ren.

As max said, the ren vm team should take care of further researching the functions of ren and take care of new applications.

@Sabobi

I would rather see the team focus on decentralization first and tick off that box before any other focus.

Do we have so much time that we can always say focus on one thing first @Sabobi ?
I think it’s now time to build an L1 platform, at the moment we won’t really get many applications with ren JS either.

I don’t see any major advantages over the competitors.
Would you like to convince me,
what advantages and areas of application with demand do you see with ren js?

As I understand it, the biggest advantage of the sub-net model compared to ren JS is:

-it is safer

-it’s all much easier and less complicated to build (much better UX) which in my view makes the difference in the end.

only with ren JS i see our chances of becoming the all-in-one solution as very slim, with a complete L1 sm platform the chances are much better.

Maybe @MaxRoszko can make a short table with 5 advantages of the sub-net and 5 disadvantages if there are any at all😅

@Sabobi

Tbh I’m not fully convinced any existing big project (Curve, Aave, Compound, Maker etc) will move over to Ren subnets, mainly attractive for new projects (like Catalog).

Don’t think that existing protocols like curve and so on will change to ren no matter how good the sub-net model gets.

The subnet model is for new applications as you said, like catalog the defi area hasn’t even started means there is enough space to build Apps for all areas of application.

The users will decide whether the app on ren is the right solution or curve on eth.

@Sabobi

So then my main concern would be, how do we compete with upcoming protocols like CCIP/LayerZero? Will an EVM subnet provide same messaging capabilities as projects like CCIP, LayerZero?

I don’t see messaging protocols (ccip/multichain…) as real competition to the sub-net model because it is far too complicated and a messaging protocol can never execute smart contracts itself and you always have to rely on the other chain.

For security reasons alone, a messaging protocol already has many disadvantages.

@Sabobi

Just to emphasize my general tone in this post. I would like the subnet model to be a good solution to integrate with all of DeFi and existing established projects.

Max himself said on Monday that decentralization has top priority and that the sub-net model should be worked out in parallel, which I think is a very good idea.

He also said that they want to present a more precise proposal for the sub-net model.

The good thing is, that if you want to build something with ren JS, you can do it at any time & ren labs can still build the L1🔥 in the background.

[Sabobi]

@Wake_222

at the moment we won’t really get many applications with ren JS either.

I think the main reason for that is because we are not decentralized, but yes thats just a guess from my side. In past many projects have expressed that to be the main problem for them.

[Wake_222]

@Sabobi

I think the main reason for that is because we are not decentralized, but yes thats just a guess from my side. In past many projects have expressed that to be the main problem for them

Yes, I also meant after decentralization, i don’t think we will get really big and many applications with ren JS.
Think that people will build a lot with ren js, we need a lot of liquidity and incentives, this will also be the case with ccip and layer zero.
Ccip has a lot of resources and could create a lot of incentives with it, with ren and layer zero I can not judge it exactly.
As a general rule i think, no matter how good the product is, ren labs needs to have a good plan to incentivize the builders.
Marketing and a good dao alone will not be enough.
It also requires a lot of liquidity and lots of incentives.

[Wake_222]

@Sabobi

I would like the subnet model to be a good solution to integrate with all of DeFi and existing established projects.

Basically all projects are mostly focused on their own success first and are rarely keen on moving over to another platform, how can we unite all of DeFi without requiring anyone to move over anywhere? Upholding the original Ren ethos of becoming the infrastructure layer of all of crypto.

wouldn’t that be the case with the sub-net model?
You can act with your app with all blockchains that ren has connected and have a great ux and top security.

[Wake_222]

@Sabobi

Ren already has a working product so delaying subnets is no issue in my mind

What I consider important is that ren completely connects things like xmr, mina, cosmos, arda, xrp, near, dot, ksm, because then it makes a lot more sense to build on ren because ren has really connected all important destinations as of today.
Then we are really talking about cross chain

Not many projects will be able to connect ada/monero/cosmos.

[sotashinokomata]

What are your thoughts in terms of MEV resistance for subnets?
Is it possible to handle this at core layer, or each subnet would be responsible for it?
If each subnet is responsible for it, hopefully the “flagship EVM subnet” (as planned for Catalog) would handle this gracefully, what techniques are you planning to use?

imo MEV resistance is a critical component to get right from the start on new chains, perhaps the most similar to inspire from for Ren L1 would be deterministic transaction ordering (like Arbitrum), does that make sense?

[Ben.L]

Have read through a few things. What is definitely strange is that @Sabobi where he has a special status and gets a lot of attention tries to delay the L1 start.
-Without ren having its l1 chain ready, catalog can never run on ren and it was said that catalog should help ren develop the platform how will that work?
-This only works if ren starts with the l1 construction and is not stopped as by certain people.
-What is the point if catalog is launched on another chain and then at some point it is to be moved completely to a ren subnet again.
-Then you can just leave it or wait with the catalog launch, because if catalog is built on another evm chain it helps ren nothing more in building the platform.

The team comes across with a good proposal and most of the community members only arrive with criticism and nagging.

-According to the recorded community call,
the team has put a lot of research into the subnet model and are working hard to deliver everything. But then community members arrive who have far too little experience and think that perhaps the demand is not high. -Do you think anyone has asked before building bnb or sol if one wants to build on it?
no definitely not.
-Bnb got its use because runs quite well and is simply much cheaper than eth.
You can’t plan and clarify everything in advance.

-But you can also wait until project xyz comes along and builds a cross chain SM platform.
The ren team also has to find people who want to build the subnet model before they can start.
Probably a team will be searched only after the proposal has been accepted by the government.
Right @MaxRoszko ?

If other solutions come, which is only a matter of time or even Chainlink with their cross chain thing coming which is very promising according to the whitepaper. I am already looking forward to the crying some here.

Cheers everyone

[Christoph]

To many comments I can only say that it is definitely wishful thinking. You will never really know if the demand for your product (subnets) is there. Because it simply depends too much on the implementation. Maybe 2-3 will say it looks interesting, but saying it is no guarantee that it will be built afterwards. In addition, everything would have to be disclosed, which would be a fiasco by the time it was completed. In the competition you have at the moment, it’s the worst thing you can do, unless you have a model that’s so bad that no one wants to copy it.

[MaxRoszko]

@Wake_222

Can you also build apps that are not cross-chain with the sub-net model?

Of course, you could deploy any kind of application, which includes not using a particular feature.

[MaxRoszko]

@Sabobi

Would it make sense to create an EVM subnet that has a very generic (easy) way to plug into other projects on other EVM chains without them having to deploy on Rens subnet? This is what I was trying to allude to on the community call @MaxRoszko but I dont think I articulated that very well. So basically competing with CCIP/LayerZero type of protocols directly and the EVM subnet becomes a “better/easier” plugin route than RenJS.

I’m still not sure on your question. For applications to get cross-chain support, if they are deployed on some chain already, they can integrate RenJS or renASSETS, as well as be copied and deployed on a subnet. If the project is not deployed yet, they could go to a subnet from the beginning and not have to worry about cross-chain support at all anymore.

@Sabobi

Whatever model we move forward with, how can we include the smaller REN holders out there? Make pooling solution easier? Has the team thought of any cool ideas around this topic @MaxRoszko ? Can running subnet node include bonding of REN in any way?

Ren Labs is not focused on pooling solutions, but all the tools for building one is out there, and we’ve made updates based on previous feedback on making it easier to build one and will continue to do so.

For now, we are thinking that to run a subnet node you absolutely need to be running a darknode anyway, so REN has to be bonded to run one. But that doesn’t help smaller holders.

[jumanji]

I’ve been looking into Celestia, and it seems like Ren is capable of having a damn good Data Availability layer at the core, sMPC layer, that is secured by darknodes. Ren’s sMPC framework, which allows for true rng, could allow for DA sampling where blocks are published using erasure coding. This would allow for only a very small subset of the block data to be randomly sampled to ensure that all the data is available, as opposed to downloading everything, helping to keep darknode hardware requirements light and inexepensive.

Ren essentially could be a hybrid of Avalanche and Celestia; a modular blockchain where Consensus and Data Availability are handled at core darknode layer and execution/sequencing(for L2 rollups) is done at subnet layer. This also ensures that every subnet is forced to pay fees to darknodes in order for their transaction blocks to be published.

Avalanche is looking into supporting L2s and having them settle on their C Chain, but doesn’t seem like that will scale. Without rng, DA Sampling won’t be possible, so Data Availability will be a hindrance.

[Sabobi]

@MaxRoszko

I’m still not sure on your question. For applications to get cross-chain support, if they are deployed on some chain already, they can integrate RenJS or renASSETS, as well as be copied and deployed on a subnet. If the project is not deployed yet, they could go to a subnet from the beginning and not have to worry about cross-chain support at all anymore.

When you say “and not have to worry about cross-chain support at all anymore”, thats because launching on a subnet directly gives them cross-chain support inherently (?) and there is no need to worry about RenJS, am I understanding correctly?

So in that scenario, let’s say project X is launched on a subnet and its purpose is to connect projects on Ethereum, lets say project Y, to a subnet which also has access to all interop capabilities the subnet has. (maybe I’m misunderstanding what interop capabilities the subnet will have, subnets won’t use RenJS right?)

So project Y could 1) use RenJS like you say to get access to interoperability or 2) connect to project X and get access to interoperability that way. You with me?

[MaxRoszko]

There is no simple answer to this because we can imagine subnets and applications on subnets to take many shapes and forms. Maybe some applications will want to live on a chain-like subnet where the classical minting/depositing from native chain makes sense, as well as utilising tokens already minted on that chain. Maybe some applications run on a subnet but are only focused on cross-chain interactions. Maybe some applications are more like arbitrage bots or doing some exotic actions using the MPC stack, not user-facing at all.

User-facing applications always need a frontend, and depending on which user is served they might have to help them bridge assets into Ren, using some JavaScript SDK like RenJS or some version of it. They could perhaps also make use of the plugins that would be developed for the subnet <> Ren communication. We maybe shouldn’t enforce that subnets must follow particular requirements when it comes to Ren communication, but it could probably be made so that subnets have native functions for cross-chain minting and burning, so developers don’t need to build out specific contracts for it.

[Sabobi]

@MaxRoszko

but it could probably be made so that subnets have native functions for cross-chain minting and burning, so developers don’t need to build out specific contracts for it.

Yea this is what I was referring to mostly, so that interoperability can be shaped in any way the subnet project desires and not constrained by RenJS framework. Thinking it can go beyond mint/burn/bridge actions for assets and also act as intermediary for any actions, hence my wording around “messaging”.

Anyway, good stuff, no more comments from my side

[S_rank]

When will people be able to see a whitepaper on the new chain or github of it ?

[Wake_222]

That would be perfect and would help us a lot.
Max is there a chance that we get it?
@MaxRoszko

Blockquote

@S_rank

When will people be able to see a whitepaper on the new chain or github of it ?

[MaxRoszko]

We want to make a whitepaper on this, but it’s all in the early stages still.

[Stanzorz]

This thread is quite long, so I’ve done my best to summarize (and sometimes highly paraphrase) its content. There are three sections: Team Comments from Max and Susruth, Community Suggestions, and Unanswered Questions. I have not included any discussion from Discord; only posts in this thread.

Team Comments

Proposing subnet model a la AVAX.^[1]

EVM subnet would be deployed first with Catalog getting first dibs.^[1:1]

Benefits

Subnet design is customizable based on developers’ intentions, including fee models.^[1:2]

Minimize attack vectors on main Ren chain.^[1:3]

Better dev UX.^[1:4]

Team is 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. ^[2]

Re: Advantages of Ren2.0 vs RenJS – native support for cross-chain and multichain functionality; flexibility in programming framework; less dependence on confirmation times and wrapped liquidity.^[3]

Impact on Core Ren Layer

Main Ren layer will have basic mint/burn/mint-and-burn/lock/release/transfer functionality but may include others i.e. validator selection/rotation, governance, cross-subnet communication, etc. ^[4]

Subnet Validator Participation:

DNOs can participate in any number of subnets but must run subnet nodes on a different instance. Bond is used to protect both networks, but subnet may have additional requirements.^[5]

Subnets have to pick validator nodes from all eligible nodes (using some criteria).^[5:1]

One design possibility is that subnet deployers would need to bond REN to spin up a subnet. DNOs would not have to bond any additional REN to run validators on subnets.^[3:1] (contradictory to Susruth at: ^[5:2])

Fees and Incentives:

Mint/burn/mint-and-burn fees would be kept as is for entering Ren ecosystem.^[1:5]

Subnets would have their own fee models.^[5:3]

Re: ‘juicy’ subnets – they hypothetically wouldn’t be that ‘juicy’ because gas fees should be competitively priced (and therefore lower margin on computational costs). Any mint/burn/etc are still earned by DNOs. ^[6]

Subnet Lifecycle

Anyone can build a subnet subject to Ren subnet requirements, which will be lean.^[5:4]

One design possibility is that subnet deployers would need to bond REN to spin up a subnet. DNOs would not have to bond any additional REN to run validators on subnets.^[3:2] (contradictory to Susruth at: ^[5:5])

As long as there is at least one subnet node participating, the chain would continue.^[5:6]

Network Security & Governance

Subnets are built on top of the existing system; it will not impact or reduce the current security of Ren core layer.^[5:7]

DNOs will continue to be the only entities with governance rights.^[7]

Subnet Communication

There would be a Ren inter-subnet communication standard, but it will be simpler to communicate within the same subnet.^[8]

Time-to-Market

TBD.^[8:1]

REN Token Utility

Core REN token utility is still to bond a validator, but may be expanded to include other uses.^[7:1]

Misc

Other alternatives to subnet model that were discussed by the team include:

• Have a single programmable environment.^[9]

• Split Ren into a storage layer, compute layer and validation layer.^[9:1]

• A multichain payment channel network.^[9:2]

• Optimistic cross-chain communication.^[9:3]

Subnet model summarized nicely by @Thomm at: ^[10].

Team wants to make a whitepaper, but it’s still in early stages.^[11]

---

Community Suggestions

Hybrid of Avalanche and Celestia; a modular blockchain where Consensus and Data Availability are handled at core darknode layer and execution/sequencing(for L2 rollups) is done at subnet layer.^{[12] [13]}

Line up Beta launch partners and get their feedback so Ren2.0 can be scoped adequately.^[14]

Scrap the Greycore initiative for privacy and faster decentralization.^[12:1]

Scrap TVL/TVB security ratio.^[12:2]

DNs be involved in every subnet by default (as long as they meet minimum specs), with a (random) rotational system.^[12:3]

xREN tokenomics update where xREN is a gas token.^[12:4]

Big push for Greycore and decentralization before Ren L1. ^{[15] [16] [17] [18] [19]}

---

Unanswered Questions

Which assumptions can we test with Catalog? Does its success or failure support or disprove any of our assumptions? ^[20]

Is there a demand for projects who actually want to build such subnets? Examples? What other alternatives do they have vs our solution? ^{[20:1] [15:1]}

How would subnet model be better dev UX? (Source: me)

Do we have the marketing and dev community building resources dedicated to make this happen? ^[20:2]

Would resources be taken away from current tasks like h2h, greycore, stables, ect? Would Ren2.0 delay these goals? ^[21]

How long would development take (R&D to Production)?

if Ren 1.0 were secured by an expanded Greycore today, how would it affect the security of Ren 2.0? Would 2.0 need to be secured by the Greycore upon launch, or would Ren2.0 be decentralized from the start?^[22]

What are the pros and cons if the community chose to decentralize Ren first, then deploy Ren2.0 afterward? There is significant migration effort either way, so could DNOs spin up a separate instance to run Ren1.0 and Ren2.0 at the same time during the migration (similar to a DNO running a main chain node and a separate subnet validator at the same time)? (Source: me and ^[17:1])

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? ^[23]

Please clarify whether a validator node could be subject to additional bonding requirements (there is a contradiction between Max and Susruth on this). If yes, 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? ^{[23:1] [24]}

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? ^[25]

Can you define the overall lifecycle of a Subnet?^[25:1]

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? 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? ^[25:2]

Would there be fees to move assets between subnets? ^[23:2]

How will subnets be able to interface with the core layer in a stronger sense than current chains? Is this consensus related or more on a technical level? ^[26]

Any plans for MEV resistance? Would this be handled at core layer or each subnet responsible for it? Suggestion for deterministic transaction ordering (like Arbitrum). ^[27]

---

1. Original Post - RFC-000-036: Ren 2.0 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

2. RFC-000-036: Ren 2.0 - #31 by MaxRoszko ↩︎

3. RFC-000-036: Ren 2.0 - #47 by MaxRoszko ↩︎ ↩︎ ↩︎

4. RFC-000-036: Ren 2.0 - #29 by MaxRoszko ↩︎

5. RFC-000-036: Ren 2.0 - #13 by Susruth ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

6. RFC-000-036: Ren 2.0 - #32 by MaxRoszko ↩︎

7. RFC-000-036: Ren 2.0 - #30 by MaxRoszko ↩︎ ↩︎

8. RFC-000-036: Ren 2.0 - #14 by Susruth ↩︎ ↩︎

9. RFC-000-036: Ren 2.0 - #23 by Susruth ↩︎ ↩︎ ↩︎ ↩︎

10. RFC-000-036: Ren 2.0 - #95 by Thomm ↩︎

11. RFC-000-036: Ren 2.0 - #121 by MaxRoszko ↩︎

12. RFC-000-036: Ren 2.0 - #51 by Sabobi ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

13. RFC-000-036: Ren 2.0 - #115 by jumanji ↩︎

14. RFC-000-036: Ren 2.0 - #58 by DeFi_Whiskey ↩︎

15. RFC-000-036: Ren 2.0 - #48 by DeFi_Whiskey ↩︎ ↩︎

16. RFC-000-036: Ren 2.0 - #52 by Ebin ↩︎

17. RFC-000-036: Ren 2.0 - #54 by shiny ↩︎ ↩︎

18. RFC-000-036: Ren 2.0 - #56 by Maggie ↩︎

19. RFC-000-036: Ren 2.0 - #60 by jumanji ↩︎

20. RFC-000-036: Ren 2.0 - #10 by dripdrop1 ↩︎ ↩︎ ↩︎

21. RFC-000-036: Ren 2.0 - #22 by James ↩︎

22. RFC-000-036: Ren 2.0 - #76 by chicobermuda ↩︎

23. RFC-000-036: Ren 2.0 - #21 by davoice321 ↩︎ ↩︎ ↩︎

24. RFC-000-036: Ren 2.0 - #17 by Arviee ↩︎

25. RFC-000-036: Ren 2.0 - #36 by DryOracle ↩︎ ↩︎ ↩︎

26. RFC-000-036: Ren 2.0 - #98 by Thomm ↩︎

27. RFC-000-036: Ren 2.0 - #110 by sotashinokomata ↩︎

[Stanzorz]

I’d also like to add something about Greycore that many seem to be overlooking: one of the most important functions of Greycore as a stepping stone to decentralization is network security. REN at the time of this writing is hovering around $0.12, so a >33% stake in the total possible nodes costs only ~$41M. Greycore are the trusted third parties or “training wheels” until it becomes MUCH MUCH more expensive to compromise the network. Only once it becomes economically infeasible can we think about full decentralization.

[Stanzorz]

Last thing: since this discussion has been open for over a month, it is probably time for some sentiment checks via the polling options once the team has had an opportunity to address the remaining questions. A couple polls I’d like to see would be:

1. Are you in favor of transitioning Ren to a subnet model at some point in the future as described in this RFC?

2. Should Ren Labs deliver Greycore and/or full decentralization before shifting resources to Ren2.0?