Replicated Security Reimagined: Jeonse and Package Differentiation Proposal

Greetings Cosmos Community, The author of this post is Taron, a researcher at A41 , an APAC based organization specializing in blockchain infrastructure services with particular strengths in ecosystem growth and technical understanding of protocols. Abstract This paper critically analyzes the challenges of replicated security in the Cosmos ecosystem, particularly the financial sustainability of smaller validators. Replicated security, viewed as a type of Service Level Agreement (SLA), presents certain obstacles, such as time lag and uncertainty of payments. Existing strategies, including Conditional Basic Income and Soft opt-out, are evaluated for their effectiveness and potential side effects. While these strategies provide relevant solutions, they do not fully address fundamental problems. To mitigate these problems, we propose novel solutions inspired by real-world models, such as the South Korean ‘Jeonse’ leasing system and a differentiated package system for validators based on their risk profiles. The ‘Jeonse’ model suggests a sizable upfront deposit from consumer chains, redistributed among validators to offset their operational burdens. The Package Differentiation…

Excerpt (1199 of 20617 characters). Read the whole post on the forum ↗

Hello and thank you for that very interesting post.

I have just 2 questions:

How “Jeonse” differs from the model Polkadot is applying to its Parachains slot acquisition? Even if DOT are locked and not redistributed to validators, wouldn’t this kind of deposit create the same barriers to entry than this eco knew (hence why they are currently pivoting to another model)

How to determine the “property’s value” of a consumer chain before its launch?

Thank you again. (:

Just to note that DOT is trying to get away from the auction model by the looks of it

Until now, in replicated security, the consumer chain has only been able to select token rewards. As mentioned in the above proposal, I believe that granting the packaging option to select the ‘jeonse’ model using the ATOM token can bring many benefits depending on which stage of the protocol’s growth phase the consumer chain is in and what level of security (and how it rewards it).

By the way, the article mentioned that this implementation should be done in a way that does not increase the complexity of the protocol, but I wonder how it can be achieved.

Great posting. Thorough consideration under current circumstances and scalability/decentralization of the cosmos ecosystem is quite touching.

Two questions:

taron:

However, it could also contribute to decentralization regarding the DPoS algorithm since the reflection of risk and time on the validator side would be propagated to the delegator side.

Combining Jeonse and package differentiation - and settle them as RS onboarding option can be novel approach, even considering the Polkadot case since it is somewhat different from auction/space in that this kind of approach may propagate ‘preference’ to both directly and indirectly to validator/delegator. But, same question as above, it seems quite complex - so is it really easier than upgrading ICS?

Regarding that - what is your perspective about Opt-in and Mesh Security? Seems like the approach of this paper(as mentioned) does not targeted to coexist with further improvement in ICS.

Thank you for overall summary and fresh insight!

Hi tom, thank you for your questions. tom: How “Jeonse” differs from the model Polkadot is applying to its Parachains slot acquisition? Even if DOT are locked and not redistributed to validators, wouldn’t this kind of deposit create the same barriers to entry than this eco knew (hence why they are currently pivoting to another model) Indeed, the “Jeonse” model and the parachain auction model serve different objectives and are characterized by different elements. While the “Jeonse” model serves as a solution for time lag and uncertainty, aligning with Service Level Agreement (SLA) perspective, the parachain auction model addresses resource scarcity and, given its competitive nature, resembling investment perspective. In the “Jeonse” model, we propose that the consumer chain makes a deposit, which, when redistributed, can help offset additional costs incurred by validators in securing the consumer chain. This approach directly supports the quality of service by enhancing decentralization and economic stability. Nevertheless, such a deposit can present an entry barrier for consumer chains wishing to onboard. Therefore, while imposing a large deposit may not be…

Excerpt (1196 of 2474 characters). Read the whole post on the forum ↗

0xdean-lab:

By the way, the article mentioned that this implementation should be done in a way that does not increase the complexity of the protocol, but I wonder how it can be achieved.

The concern about maintaining protocol simplicity while implementing the changes is valid. In the real-world application, the specific development could deviate from the theoretical plan, adding complexity. Our perspective is that focusing most of the necessary modifications on the Cross Chain Validation (CCV) module could mitigate this.

Thanks a lot!

For the first question, I believe that answer above helps. Feel free to ask if there is any further issue to resolve.

For the other:

vismatoo:

Regarding that - what is your perspective about Opt-in and Mesh Security? Seems like the approach of this paper(as mentioned) does not targeted to coexist with further improvement in ICS.

While our paper primarily addresses the issues that have emerged from the current architecture, it is intended to be adaptable and isn’t incompatible with future enhancements to the ICS protocol. Many of the discussions and refinements happening within the governance forums relate to overall incentives for participants in ICS, making them concurrent with the issues we address.

As for Opt-in and Mesh Security, we see them holding significant potential for a sustainable and scalable future, ultimately strengthening the security and uniqueness of the Cosmos ecosystem. We align with Informal Systems’ perspective that the subset problem needs comprehensive analysis before implementing these security models. It is critical to sidestep temporary solutions that don’t wholly tackle these issues.

Thanks a lot!

taron:

However, one might wonder why issues related to small validators and centralization unique to Replicated Security haven’t surfaced elsewhere. I believe it’s due to Cosmos’ higher degree of decentralization compared to other networks, as the sequencer of most rollups is highly centralized. The issues we’re solving aren’t currently problems in other ecosystems. But for a genuinely decentralized, interconnected ecosystem, it’s crucial to address these challenges and persistently search for solutions.

btw fascinating expression. Thank you again for your analysis!

One of the goals of Replicated Security was to ease the launch of new chains bringing calculatable potential value to ATOM and its stakeholders. The first option somewhat counters that by obliging CC to cover infra costs with its own funds. Should cc apply for a donation from Community Pool, in this case, to be delegated to validators under a special delegation program with periodic revision? 2nd option sounds reasonable, but it needs to have a possibility for the validators to pick the model for themselves and change it once a week (e.g.). That option still has room for opting out for validators who simply cannot scale at the moment, while leaving an option for ready-to-scale small validators to pick the preferred revenue model and take higher risks. In other cases linking the revenue models to voting power leaves no choice for small validators but to opt out, since 10% of fees on new consumer chains doesn’t really look promising. With the current two CCs and their profitability, it may not work perfectly, but it could work in the long run, having more CCs. To work properly 2v requires full automation and regular revision without passing proposals, it can be complicated…

Excerpt (1191 of 2259 characters). Read the whole post on the forum ↗

The issue with most suggestions above (I mean all of them) is that it disregards the “appetite” or rather the costs of a validator in question.

“All small validators spend X on that” - no they don’t. They (the solutions) are trying to take into account spendings and not project economic (which is impossible to do). A project, with 2 people on the team and 2 networks, can easily stay afloat for months, even if it has no revenue streams. A project with 15 people on board - if it monetized via validation. Cannot. Unsure how we plan to randomly incentivize small validators with different sums.

Thank you all for your insightful opinions and ideas. Vadim_Everstake: The first option somewhat counters that by obliging CC to cover infra costs with its own funds. Should cc apply for a donation from Community Pool, in this case, to be delegated to validators under a special delegation program with periodic revision? We agree that our first option may seem to increase the burden for Consumer Chains (CC) by requiring them to cover infrastructural costs. We should stress that this approach is intended as a long-term solution and will be implemented gradually, not instantly. A special delegation program, as suggested, could be an effective interim measure, allowing validators to receive funds while the CC prepares to take on these costs. It can be a bridge solution, offering a more sustainable model compared to the current situation. Vadim_Everstake: 2nd option sounds reasonable, but it needs to have a possibility for the validators to pick the model for themselves and change it once a week (e.g.). That option still has room for opting out for validators who simply cannot scale at the moment, while leaving an option for ready-to-scale small…

Excerpt (1190 of 2530 characters). Read the whole post on the forum ↗

We appreciate the critical view and the emphasis on the heterogeneous nature of validators’ costs. Certainly, the financial reality of a validator operation can vary greatly. Small operations, with minimal staffing and infrastructure, can sustain themselves differently compared to larger ones with multiple networks and a larger team. This diversity is something we should consider when we think about validator incentives and overall ecosystem health. It’s true that estimating each validator’s costs ‘objectively’ is a challenge, given the variables involved. However, our approach seeks to incorporate the ‘subjective’ view from each validator’s perspective. We believe the ‘one-size-fits-all’ model may not necessarily account for the reality on the ground. So, the question becomes: how do we tailor solutions to better meet the diverse needs of validators? taron: Firstly, the establishment of an application process for receiving subsidies. To this end, the refinement we proposed for the Conditional Basic Income approach – an application process for receiving subsidies – is intended to better accommodate validators’ unique circumstances. This process aims not to…

Excerpt (1196 of 1770 characters). Read the whole post on the forum ↗

Thanks for your reply. I don’t mean to be offensive, so apologies if this comes out wrong in writing, but I have re-read your reply about 4 times. I really do not see anything in it that tackles the issues im talking about. It (the reply) is mega generalizing and has roughly 0 to do with reality.

An example: you mention Small operations, with minimal staffing and infrastructure, can sustain themselves differently compared to larger ones with multiple networks and a larger team. what about small operators with large team and projects? What about large validators with 2-3 people (that have been running since inception on old reputation, but have stopped giving 2 years ago to the network?). My point is - you’re reply, as respectful as it is, has no context, or is attempting to solve the issues arisen.

Hope it doesnt come of aggressive (my reply), its not meant to be. Jut pointing out what I see here