To the comparisons with avax and dot… who says that ren wants to be like that?
i don’t remember avax or dot being able to interact directly with other chains with a smart contract.
Prove me wrong!
but acting directly with other chains with a super ux and acting directly with everyone, ren could create something like that.
which opens a whole new scope and is much safer and cheaper.
their comparisons with dot and avax and many more resources is pointless.
we don’t know how many resources ren has
don’t you know how many people work on avax and how many people ren will hire…
And finally, I hope that ren doesn’t compete with avax and dot because both have not so great ux and the fee model has potential for improvement.
dot and avax compete with ftm/sol/near and eth and as you can see eth is clearly the better solution and more popular.
and why is the eth 2.0 update taking so long, because a lot of apps are running on eth and it is already quite decentralized, which makes it very difficult for a large update.
That’s why you can still change almost everything at ren as long as it’s still central…
and as mentioned before, the blockchain area is still in research and areas of application for banks/companies and so on are still in research.
What does it mean that avax/sol/dot may not be suitable for the right use or will be outdated at some point.
That’s why, as sabobi said, to develop new things if necessary instead of sticking to a shitty roadmap.
Thank you for the screenshot however this is just another example of the communication problem. If questions and discussions are happening in an RFC, responses should be provided there and then shared in discord. The forum is the place where organised conversation occur and also a place where responses can be clearly connected with the questions.
Because I do not want to assume the answer to my points are responded in a random response from Max which I do not know what triggered it, I will wait for the responses from the team here.
@Maggie please don’t make it so complicated if you want the best for ren.
It is a great suggestion from Maximilian that ren vm takes care of other assets and destinations so that ren can connect all blockchains in the future.
And ren takes care of the decentralization together with the community can decide what is best for ren and what happens to greycore.
In the meantime, a completely separate team is building a complete L1 platform in style of a sub-net in 6-18 months, enabling unique applications with the best UX… where all messaging protocols are at a disadvantage.
What do you want more, are you just about principle?
we shouldn’t waste so much time either, day after day goes by and we are now discussing completely different topics than the subnet.
There must be a reason why the team suggested the sub-net, as we saw in Suruth’s listings for the other models.
and if there is a separate team then @Maggie and @DeFi_Whiskey don’t have to worry about other things being neglected and at the same time you also have a ren L1:fire: in addition to the original ren
The community and ren vm can take care of the decentralization together which is just as important for integrations and for everything. After the L1 is built ren has to be completely decentralized so that all kinds of applications will be built.
We all want the best for Ren, there is no doubt about it however the way we do things matter specially if we want a growing organised community and DAO. The forum was actually designed by the team and is part of the process required to propose changes to REN and Max has actively asked people on discord to present points in here for the same reason so I do not expect anything less from them.
Please be careful when reading posts from the team and making assumptions that later are repeated as true. Max did not say in his post that there is currently a separate team building the L1, he said “we could potentially hired a new team to only focus on the L1 framework…” so this is something that may or may not happen in the future. He is talking about possibilities not facts that are happening.
I get you don’t care about organisation or how things are done however this is the framework of work in REN community when changes are required. Nothing less nothing more. Therefore is not “me make it complicated” for the team.
I have tried to remain on point about Subnet too as it can be seen in all my posts.
I read things carefully, you only read what you want to hear.
The community first has to agree to the subnet model, of course no people are hired beforehand.
Max said we could hire a separate team for it, then that’s also an option if the community agrees.
If it’s not possible, Max wouldn’t even mention it.
[quote=“Maggie, post:88, topic:1185”]
I get you don’t care about organisation or how things are done however this is the framework of work in REN community when changes are required. Nothing less nothing more. Therefore is not “me make it complicated” for the team.
Sure thats why i am active here…
You’re already complaining when you have to search the discord for news or statements from max.
Again, you clearly don’t comprehend the difference between “will” and “would” together with “can” in the context of Max’s post on the discord. Please stop with your sort of pushy behavior.
I speak my mind when I think I’m right.
Your first statement doesn’t change anything.
In such a technical area, you can never promise everything 100% in advance.
If Max were say to 100% that it will be like that, then maybe it would fall on his feet like the one with greycore.
Just because some people here with little idea and principles cling to things that have been announced
That’s one way of putting it.
I think by Maggie and the others there is a lot of frustration, that settles with the success of ren.
Let’s leave it at that
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.
Exactly right @Thomm. Because we consider security the most important aspect when R&Ding, the subnet model became especially interesting because it doesn’t change the core layer that has proved to be safe now, and because re-architecting the core layer while it’s already running and on mainnet means if something breaks it can have serious financial repercussions.
But if we go down the subnet path, we would still need to introduce a few low-level updates to support strong and secure interfacing between the core layer <> subnets and subnets <> subnets, although those changes would be minor and easier to reason about from a security perspective, and test.
Exactly how this will look like is very much up in the air at the moment, we cannot say yet which design/relationship would work the best for the system to ensure there are enough subnet nodes available to power applications.
Subnet nodes deployment would roughly be open to DNOs from the get-go (some testing will be done early as always just to make sure everything works as expected).
@MaxRoszko in the main post you mention that subnets interface with the core layer in a stronger sense than current chains:
Can you elaborate more on the technicals? Is this consensus related because there can be higher trust assumptions between core layer <> subnet layer than between core layer <> external blockchain, or is it more on a technical level how they are able to connect and communicate?
Not sure of forum etiquette here but I’d like to bump my previous post from 13 days ago that I think got lost in the Greycore discussions (RFC-000-036: Ren 2.0 - #36 by DryOracle).
Would Subnets be able to create their own native assets similar to how L2’s today can create assets native to their chains (without a base asset / token on L1)? If so, how would value accrue to DNO’s on non-native Ren assets being created and transacted? I see it as those assets being stuck in that Subnet and couldn’t be sent to other Subnets or withdrawn from the Ren ecosystem - ultimately those assets would be sold for Ren-supported assets to move within the ecosystem. It’s probably a non-issue but thought I’d voice it anyway for other viewpoints.
I am with @DeFi_Whiskey regarding the difficulty that this confusion generates in terms of thinking of a previsible business model - economic vision - horizon.
This does not mean that the road map should be an unchangeable stone (we all know that flexibility and the ability to adapt to change is the number 1 asset in any disruptive economic phase), but for example that the long-announced updates (H2H burn&mint, Catalog) and apparently imminent to be deployed, come to light before any other discussion. It is the only way to give confidence and credibility to future debates on new alternatives.
About Greycore: I don’t understand the “apparently” recent turnaround. Assuming its dissolution, we will continue to be a non-regulated - non (semi) decentralized hybrid for months and months. Do we have a chance to compete in those conditions? Surely not for one side, not for the other.
To be completely honest, here’s my deduction: The previous assumptions about the degree of progress (not a single news about it or its members), were gigantic reading in this space. Everything leads me to believe that the project has already been declared a failure and I am forced to wonder if the main members of the project have long since retired. Common sense, I can’t imagine the people at Ren Labs suddenly saying to the Curve team “hey guys, we don’t need you anymore. Greycore is over”. Maybe @Sabobi is the beachhead of the team to install the theme and vote the dissolution in a democratic way. In that case, why not directly appeal to transparency, report the real situation, resolve the issue. Don’t waste time arguing about what seems to have been ruled out, discuss the alternatives.
Deployment of what was announced.
Transparency about Greycore and discussion of alternatives.
Debate about Subnets (I would be in favor in principle, especially if we think that the coming time of rising interest rates and falling markets could be the ideal scenario to build in the winter. Personally I assume 6 to 18 = 24
I say this with the greatest respect and gratitude for everything done. Just a humble pinch of critical spirit.
I will let Susruth provide detail when he can, but in general I believe with plugins it’s referred to something needed to be included in the subnet protocol so it can efficiently communicate with core layer.
Whether there should be one native asset for each subnet (aside from the cross-chain assets), or if it can be up to each subnet, is a detail that can be discussed at this stage, as there is no preliminary requirement for either or. It could be REN if the community wants as an example.
Subnets should be able to create their own tokens, since this is a basic functionality of DeFi, but it could be done in a way where token creation makes the tokens native to Ren as well so that they could be bridged to other platforms. And any computation still rewards node operators.
Can you also build apps that are not cross-chain with the sub-net model?
So if someone only trusts one chain and says he doesn’t want to build a cross chain, it is then possible to build like e.g. with eth or avax where you are only on the chain where you build (in the case of ren with ren)
or is it automatically always cross chain with ren?
or just as an example, the future is not cross-chain…
Whether it would then be just as possible to build as with all other L1 and not to act with any other chain.?
After reading this thread a couple of times and listening to Max’s comments in the community call I have a few comments/questions (to both community and team).
Decentralization is imo of outmost priority. Not only to gain legitimacy in the wider DeFi space but also to remove risks from the team. I am not a big fan of creating a separate team for maintaining L1/Subnets as it will still require quite a bit of effort from the current team to set that up and support the new team. I would rather see the team focus on decentralization first and tick off that box before any other focus. Ren already has a working product so delaying subnets is no issue in my mind, as soon as things are decentralized the community can go out there and focus on things like marketing, strengthening the DAO, expansion and integration of RenJS, all while team works on subnets/L1 in background. Right now is a bit of a deadlock since we are seen as centralized and most dependencies are on the core team.
Lets say we move forward with subnets, would it make sense to only focus on one subnet (an EVM subnet) and let Catalog be the showcase for other projects? So basically only allowing one EVM subnet with very specific rules that benefits both projects on the subnet as well as DNO. Then from there see if the model makes sense to allow other protocols to create their own subnets, maybe it doesn’t make much of a difference and creating one subnet is same amount of work as many subnets (maybe team can clarify this). If supporting many different kinds of subnets is more work than one I rather see just one first to gauge interest by other projects.
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). 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 would be more interested to find a way to integrate and unite current DeFi more than creating Ren DeFi (too many projects out there focus on their own ecosystem and not enough on uniting all ecosystems imo, Thorchain good example, recently abandoned ThorFi).
If I understood correctly the downside of RenJS is the waiting for confirmations (speed), subnets will solve this as they can communicate more directly with RenVM. 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.
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? If the issue is that it would reduce the possible 10k nodes for RenVM then maybe limiting to only one subnet can be good solution? So you have the regular DNO that receive interop fees as well as subnet fees, while at the same time you have stakers who receive only subnet fees. To accommodate this maybe bonding REN generates a new gastoken gREN for the subnet. I realize this last point is not well thought through, which is another reason I think decentralization (first point) should be main focus for now all while we flesh out ideas to find good solutions serving smaller holders as well as optimizing the subnet model.
EDIT: Sweet I got the 100th post!
EDIT2: 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.
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.
in addition to the original ren
