Discuss the necessity / priority of implementing an IBC steward role for Namada.
1) What
Namada needs to scale support across an ever-growing set of IBC tokens. Similar to the PGF steward, let’s consider an IBC steward:
is elected (and removed) by voters
makes governance proposals to change IBC token limits
proposals pass by default, unless voted down
is rewarded
Current Configuration
Creating an IBC channel is permissionless, but their tokens cannot enter Namada until limits are increased using a governance proposal. The default_mint_limit (ie. the cap for an IBC token on Namada) and default_per_epoch_throughput_limit (ie. the net amount an IBC token can come/go on Namada) for any new token are both zero. See parameters here.
discuss and propose limit increases or discontinuation
alert stakeholders and operators of emergencies
help coordinate recovery
eg. expired/frozen IBC channel; Namada security vulnerability exploitation; large volume of stolen tokens being deposited into Namada
other tbd elements of IBC token maintenance and development
The role should be rewarded, but let’s please save discussions about these details for implementation.
The Mechanism
Aside from adding a new kind of steward election, Namada would need a new governance proposal type to support key IBC token maintenance parameters. A single proposal could adjust multiple IBC token limits. Anyone could make a proposal with a deposit, but it should fail by default unless it achieves a passing threshold. If the steward makes the proposal, it should pass by default unless voted down. Steward shouldn’t need a deposit.
It’s tempting to ponder details about how we (Namada) could implement this–eg. perhaps IBC steward should have special powers to increase but not decrease limits–but these details aren’t yet relevant for this discussion unless they make/break the decision about necessity/priority to implement it.
I think this is a great idea. We need to make sure that we are clear about creating only one channel per chain, which should be executed only by the steward. They would then manage the coordination of relaying with the use of Namada IBC primitives.
As for a steward, I would like to propose @Daniel! TuDudes, which includes @Veight, myself, and our small team, would be happy to help support their efforts in tooling and primitives. This includes the scripting and documentation of IBC relaying, such the use of a docker image and detailed steps for relayers and chain configs which Daniel happened to share during his testing for various chains.
Thinking of implementation / conceptualization, I feel it may be a better fit to simply have one of the PGF stewards (from a protocol perspective) have a special focus on IBC. So that all stewards of governance would have same powers in this area.
I’m a little wary of creating too many special roles at protocol level, new categories of inflation etc.
pls remember that the purpose of this is topic to discuss the necessity and priority of implementing this. imo that’s Step 1, and jumping the gun invites muddiness to the conversation
not how it will be implemented, eg how it will be rewarded or how powers will be applied, @preto
imo this would be Step 2
not who should fill the role, @sirouk@cryptosj
imo this would be Step 3 or 4
re your comment to my reply, I don’t see how those two are separate. I’m offering feedback on exactly what you are asking, ie if a separate role should be created in protocol (as I understand your initial post). Like I said, I support the idea of having an IBC steward, but also think it would be better to have it under the umbrella of PGF stewards when it comes to systems design.
copy that FWIW, I’ve been known to be biased to action
Yes, this should be a high priority. IBC plays a vital role as the technology contributing to the vision and utility of Namada. Let’s get moving on Step 1!
in this case, existing PGF could fund the role, so a new category of inflation doesn’t seem necessary. but PGF steward as a role is so different than IBC steward as role that i don’t see how these fit in the same bucket
That’s a great idea. IBC-related-decisions should be made fast.
Regarding implementation details - really need to think from the system point of view. But right now the responsibilities of existing stewards are different from those required for IBC stewards. Gavin’s original idea looks good, complicating PGF stewarts is not what we need. It is better to separate functions.
I think having a steward focused on IBC monitoring, infrastructure, and guidance generally makes sense, and I also think that this work should be rewarded using PGF in some fashion. The existing steward mechanism seems to me like it would be sufficient for at least a first version – that would allow an IBC steward to receive some rewards themselves and to make PGF proposals to fund IBC-related infrastructure operations such as relayers.
I’m not yet convinced that we need to add a new kind of proposal or create special permissions for the IBC steward to have IBC-rate-limit-related or IBC-client-related governance proposals pass by default. Although there will likely be a high volume of IBC rate limit increase proposals at first, I think we can expect these to become less frequent over time as the system stabilizes, and they should be manageable by the regular governance system. Special permissions here could come with risks that we haven’t thoroughly considered, including for the IBC steward themselves – it can be dangerous to possess keys which (more easily) allow changes to IBC rate limits or light clients, as an adversary might attempt to compromise these in the kinds of scenarios that rate limits are intended to reduce the risk and contain the potential damage of. I’m not categorically opposed to this idea, either, but I think we should first start with the aspects of this role which don’t require protocol changes or new permissions (which strike me as far more important responsibilities and tasks anyways), and see over time whether we need protocol changes to optimize processes or not (and what precisely those changes might be).
(so in general I think I’m in full alignment with @preto’s expressed preferences above)
If our IBC Steward will not have on in-protocol designation or special powers that enable IBC rate-limit change proposals to pass by default, we can still create this role without implementing a protocol change.
is elected (and removed) by voters
is rewarded
The IBC Steward role could be single person, but given how critical the responsibilities can be, it may be more responsible for more than one person to form a group to be the IBC steward with a multisig.
A PGF proposal can be made as a means of electing the IBC Steward using their multisig to receive cPGF (continuous public goods funding). This effectively redirects a portion of the PGF inflation away from the PGF account and towards the recipient multisig. A new IBC Steward could be elected to replace an existing steward elected with another PGF proposal.
makes governance proposals to change IBC token limits
proposals pass by default, unless voted down
Interfaces (eg. explorers, Namadillo) could perhaps support identifying the designated IBC Steward address(es) so that voters can see the role of address that’s proposing an IBC rate limit change.
The role can still be carried out effectively, just that all voters would be expected to be involved in each IBC rate limit change proposal, and limit changes can be batched within a proposal.
Future
Until we better identify the patterns of fulfilling this role, having the role outside of the protocol is probably the safest route.
If we find it valuable to enshrine the IBC Steward role in Namada’s protocol, ie. we’re confident in our oversight of a steward and it’s necessary to enable our growth, we can revisit this potential implementation in future.
It should be noted that a protocol change / addition would still be required in order to allow a proposal like one that changes IBC rate limits to be executed by default by some steward. Currently, a PGF steward can only make specifically a PGF proposal pass by default.
In general, I’m cautiously open to this idea. I wonder if the existing process we already have will suffice for setting and changing IBC rate limits. If, with some data, we determine that this role would be particularly useful, then I would be more open to it. But I wonder if we’re anticipating a problem that we might not have.
Anyway, I do think some kind of IBC-specific governance proposals in the future would be a nice protocol addition.
It should be noted that a protocol change / addition would still be required in order to allow a proposal like one that changes IBC rate limits to be executed by default by some steward. Currently, a PGF steward can only make specifically a PGF proposal pass by default.
@brentstone to be clear, I’ve backtracked on the idea for a protocol change that creates a special role. I’m saying that we can socially organize a dedicate IBC Steward role. This is independent from my assertion that we should have a dedicated IBC proposal type.
IBC proposal type would ideally minimize the need to introduce wasm to change IBC limits (which i assume we’ll need to do relatively often for the foreseeable future). It reduces the complexity to create them, and reduces the risk of arbitrary wasm be executed.
If I am reading @cwgoes correctly, our preference is to use the PGF steward protocol mechanism as a way to solidify this role and reward the IBC steward. I can’t decide if I think this is better, or better to simply (as I think you suggest now, @Gavin) not have a special system role for the IBC steward but rather reward through continuous PGF. I think I lean towards thinking that making the IBC steward protocol/systems-wise a PGF steward, would underline the importance of the role, and, I think (someone correct me if wrong) also give some special powers in relation to generally making PGF proposals that might be useful for the IBC steward. So I cautiously lean towards using this mechanism. I will not be sad if the cpgf model is employed instead though, but I think the importance of the (organizational) role you are proposing, is significant enough that it could warrant an appointment (protocolwise) as PGF steward, just with a more specialized (organizational) area of responsibility. Let me also say at the risk of being naughty and running too far ahead, that I see also @Daniel as a naturally given part of any IBC steward construction, whether it be a team or an individual. (I would have no qualms with making it Daniel as individual)
(to be clear, I’m also fine with rewarding this role with CPGF, I don’t have a strong opinion on that vs being a steward. what I’m not convinced that we need yet is a new, separate role requiring protocol changes)
FWIW, I’ve been known to be biased to action 