SLP process proposal to encourage participation from ecosystem

[anupsdf]

what

Added SLP process proposal where anyone in the ecosystem can propose changes to the network limits.

why

To encourage participation from ecosystem. To clarify the SLP process. To empower Tier-1 organizations to govern the network.

[Copilot]

Pull request overview

Adds an SLP contribution/process section to limits/README.md to formalize how ecosystem participants can propose and advance Soroban resource limit changes through a committee + validator workflow.

Changes:

• Documented an SLP-specific contribution process modeled on the CAP contribution process.
• Introduced an “SLP Committee” concept and a draft-to-final progression for SLPs.
• Added guidance for drafting and iterating on SLPs (naming, assets, discussion venues, and status transitions).

[MonsieurNicolas]

we should not merge this until we've good rough alignment with tier-1.
let's get more feedback from people --> it's also an opportunity to simplify things

also, left some comments (in addition to Copilot comments that are also relevant)

[rice2000]

Two quick notes

[rice2000]

I tagged 3 spots for the same reason: we may want to consolidate discussion and SLP committee approval to Github rather than offering the mailing list as an option. That way, all the relevant info is in one place, which might make it easier to follow and participate.

[magofox]

Interesting proposal. I like the idea of more transparency and quicker action, particularly around the ledger key freeze component of SLP.

1. I am curious about how many of these SLP evaluation and votes are likely to occur in a month and the expected turn around time. Clearly a ledger key freeze proposal would need to be executed quickly, but how about a more generic request to increase transaction limits.
2. I'm also curious about the qualifications someone would ideally have that is representing the Tier 1 voting org. Ledger freeze actions seem more like a jury role, where any community member can make a call based on the facts presented to them. But a transaction limit feels very technical where hardware engineering knowhow would likely be needed. Or is this more like an elected board member of a public utility, where the people making the decision are just normal citizens being presented cases to decide by the general manager and staff at the utility (in this case, SDF).
3. While I agree decentralized governance is important, I cannot help but call out the elephant in the room. Stellar already asks a lot from its Tier 1 Validators with no inherent incentive to run a validator. We've seen a lot of Tier 1 validators come and go already, many times due to financial circumstances. The list of T1 validators is quite small with a pretty sizable barrier to entry for new entrance - technical knowhow, available capital and human resources, and, most importantly, trust. One way to view this proposal is placing another responsibility (requirement?) on the entities that are already the backbone of the network. This proposal, combined with some added incentive from the network to the validators, would feel like a more balanced and rounded proposal that would incentivize more robust and sustainable participation in running and governing the network.

[earrietadev]

I like the idea of trying to encourage participation, but I think that most of the projects building on the network are not part of the validators, and that's also because of what @magofox says about the lack of incentives.

So if people building aren't part of the validators, then it will be difficult to know what might be their blockers and what we could increase for that. On my side, I've made multiple contracts that are now in mainnet, and I have found that most of the time it's easier to just try to optimize or change the whole logic than to think about increasing the limits of the network, so it's going to be difficult to get feedback from builders about what to increase unless we face the issue ourselves.

That being said, I'm ok with it.

[MonsieurNicolas]

answering questions from @magofox above. Thank you for helping shape this!

1. I am curious about how many of these SLP evaluation and votes are likely to occur in a month and the expected turn around time.  Clearly a ledger key freeze proposal would need to be executed quickly, but how about a more generic request to increase transaction limits.

emergency situations aside, based on historical votes, I would expect at most 1 vote/month. From a turnaround time point of view, the faster the better. I'd say the goal would be for the group to decide over a couple weeks, which probably means surfacing issues (if any) upstream from the informal vote. For CAPs, we try to get a few people from the group engaged during the early presentation for that reason (with a few days turnaround time), so that by the time a proposal gets to the "voting phase", there is enough data to make an informed decision.

2. I'm also curious about the qualifications someone would ideally have that is representing the Tier 1 voting org.  Ledger freeze actions seem more like a jury role, where any community member can make a call based on the facts presented to them.  But a transaction limit feels very technical where hardware engineering knowhow would likely be needed.  Or is this more like an elected board member of a public utility, where the people making the decision are just normal citizens being presented cases to decide by the general manager and staff at the utility (in this case, SDF).

Do note that this vote already happens today, but at a later stage. The difference here is that we make it possible to discuss before the official on-chain vote, and have an informal vote before changes get finalized.

The author of the SLP should be the one providing as much information as possible to justify it.
The tier-1 group should have enough information to debate.

From an impact/assessment point of view, this is where having a more diverse group at that layer will help: while SDF can help with evaluating impact of technical proposals, others will likely require thinking about business impact over their org and balance that with a best guess at overall ecosystem impact.

3. While I agree decentralized governance is important, I cannot help but call out the elephant in the room.  Stellar already asks a lot from its Tier 1 Validators with no inherent incentive to run a validator.  We've seen a lot of Tier 1 validators come and go already, many times due to financial circumstances.  The list of T1 validators is quite small with a pretty sizable barrier to entry for new entrance - technical knowhow, available capital and human resources, and, most importantly, trust.   One way to view this proposal is placing another responsibility (requirement?) on the entities that are already the backbone of the network.  This proposal, combined with some added incentive from the network to the validators, would feel like a more balanced and rounded proposal that would incentivize more robust and sustainable participation in running and governing the network.

Yeah it's an area where it's worth experimenting. Actively participating at that layer allows entities to actively protect their interests so it looks a lot more like a perk than a burden from that point of view.
The topic of "how much should it cost" to participate at that layer is a good one, is orthogonal to this proposal and should continue in a different discussion.

[MattBlockdaemon]

I largely agree with what has already been raised so far, though I do have a separate concern. having a single nominated point of contact for SLPs could cause bottlenecks in the process, particularly for emergency cases.
There are not many Tier 1 organisations, and depending on the timezones they are primarily located in, this could introduce frequent gaps where not enough of the committee are available to make a fast decision.

I think higher Tier1 involvement is sensible if addressed properly with the other concerns above addressed appropriately. I would suggest that each Org is able to appoint multiple decision makers to weigh in though, to help prevent spots with no coverage. I'd also be curious to know what the protocol is for if an urgent decision is required, but those involved are unable to agree on a path forward.