CIP-0061? | Stake-based Protocol Governance Restrictions #284
Conversation
|
Today although Cardano stake is liquid there is essentially two sets of problems
The current rewards scheme is mainly meant for stake to be delegated such that it maximizes rewards. For example I love poolX because it gives me maximum rewards but i dont probably agree with the pool operator's view on parameter. So I would probably diverge on parameters. Now I dont want to move my stake because I am a player according to the rewards paper whose main goal is to maximize rewards. Stake decentralization is the key. |
| Decentralized governance is a hard topic and it is likely to take some time to get to a point where Cardano has a fully working decentralized governance. In the meantime, while tolerated until now, the current status quo is judged unacceptable by many. As of today, the number of entities that can control the current set of governance operations is limited. Those operations include: | ||
|
|
||
| - Protocol parameters updates | ||
| - Protocol versions updates |
There was a problem hiding this comment.
technically the protocol version is a protocol parameter, but probably nice to spell this out. maybe mention the redundancy, though?
There was a problem hiding this comment.
Yes, they are indeed part of the same structure, but I thought they were usually quite separate events in nature and thus, worth separating (same goes for MIR actually, which I have separated but are technically the same operation).
|
Few things I am thinking
I think Pledge to delegation ratio is a must. Currently there is no other parameter to quantify "skin in game" |
|
|
||
| ## Rationale | ||
|
|
||
| - By doing this, we force any sensitive operation such as update proposals or MIR transfers to be endorsed by a majority (by stake) of block producers. Indeed, only nodes that have endorsed the operation in their configuration will produce and recognize chains containing the operation. This also means that in a situation of no consensus, the network will inevitably fork between those who endorse the update and those who don't. Ultimately, the longest chain rule will apply and the chain that can produce the most blocks will eventually be adopted. That chain will be the one which is endorsed by the most stake (since the block production is roughly proportional to the stake). |
There was a problem hiding this comment.
Ultimately, the longest chain rule will apply and the chain that can produce the most blocks will eventually be adopted.
We should reword this to make clear the points that you address below. Namely, there is an asymmetry depending on who wins the longest chain. In one case (the governance item is not adopted) consensus will bring the chain back together. In the other case (the governance item is adopted), there will be a split network (as you explained below).
|
|
||
| Over the past months and years, this topic has been at the centre of many vigorous debates. We thus think that the current status quo has to change. | ||
|
|
||
| > \* This ratio is currently configurable via a protocol parameter. |
There was a problem hiding this comment.
the quorum number is not a protocol parameter (at least in the sense that we use that term in the ledger). it cannot be updated by the protocol parameter update system. it's set once in the genesis config.
There was a problem hiding this comment.
Ho, my bad. Is it a global one?
There was a problem hiding this comment.
indeed, it is a global variable (and hence requires a hardfork to change).
|
meanwhile over on the Cardano Forum: Lets have a discussion about the Governance (BFT) keys |
|
It's probably worth mentioning that SPOs are incentivized to be on the winning side. For as long as they are on the losing fork, they are not making blocks. This effects their reward payout and also the current ranking in Daedalus. |
The IOG governance team is currently working on voting delegation for Catalyst/Voltaire - the idea is to have separate representative groups for different voting purposes, as well as direct voting if preferred. That proposal allows representatives to declare their Ada holdings (via stake keys) to demonstrate "skin-in-the-game" if that is an issue for voters. We expect this to be available from Fund10 (needs wallet support, for example). Be careful with pledge to delegation ratios - you can end up giving some "whales" significant influence (as we discovered with a0) |
|
Note that this proposal gives a veto to the SPOs on all governance decisions. This is not necessarily a good thing, and I would argue that it is a bad direction to go in. In my view, in principle, governance should be controlled by the stake holders (directly or indirectly). While the stakeholders do delegate to SPOs for block production, their interests are not perfectly aligned with the interests of SPOs, so it is not (in my view) appropriate to delegate governance decisions to them too. The SPOs necessarily have a veto on protocol upgrades that involve software changes, since the SPOs must deploy the software, but I would not give them a vote or a veto on other governance decisions. |
|
How do the SPOs publicly signal their support for a given future proposal? There has to be a way to measure "overwhelming support" for a proposal before the key-holders choose to submit it. |
|
I voiced a similar concern on the Twitter thread. I don't feel comfortable giving SPOs so much power, especially since exchanges are also staking their user's funds. Indirectly related to this proposal I think the very first and easiest step should be for CF to take back control over their two genesis keys. While it is probably more difficult to implement, I would very much prefer a direct vote by ADA holders on update proposals and treasury/reserve Tx (why is it possible to manipulate the reserve at all by the way?). I think it is important to make it an active process in which each stake holder can vote with yes or no, weighted by their stake. During this transition time I could also imagine a process, similar to what's described in the CIP where SPOs can signal their approval AND Ada holders can cast their vote on the Catalyst side chain. The signal and vote wouldn't have any technical effect, but would still send a strong signal to the genesis key holding entities if the community is d'accord with the upgrade. |
This is a good point. Currently, the only thing that a SPO can publicly signal support for is a hardfork, via the major protocol version listed in the block header. The pre-authorization of txids actually undermines this mechanism: a node operator could update their software before a hardfork (and hence start producing blocks promoting the new major protocol version), and chose to not pre-authorize the transaction which includes the major protocol version update. Hence the metric is lest trustworthy. |
|
I wanted to share and discuss a few thoughts: This effectively drops the MAV of Cardano from 23 to 5. The US Government does issue/use thousands of National Security Letters per year to force businesses/ISP's/ect to secretly comply [with force]. The US Government will/has use secret courts and secret court proceedings to force power. I hope the genesis keys are divided to 7 different people, each protected with a different password, and the QR code encrypted recovery keys are engraved into teflon sheets and buried all over Charles' vast property (no metal detectors). Imagine CIP-61 succeeds. We don't want a situation where a cabal of sybil-multipool-operators, exchanges, hedge funds, and wealth managers decide to collect 51% and vote themselves the $500M treasury. We don't want a cabal to decide to set a0 of the current equation to 10.0. a0=10.0 in the current RSS equation would totally destroy self-custodial non-pledged staking. We don't want a cabal to set the minimum pool fee to 1000 because that would destroy the majority of small pools. We need to make sure the MAV keeps growing for Voltaire governance to be safer (CIP-50 topic space). There could be a stake pool operator 'house' and 'senate' where the 'house' votes are weighted by stake and the 'senate' is 1 pool 1 vote composed of every pool with at least 36 blocks on-chain more than 72 epochs old. This would prevent any 'quick' attempt at a governance attack. The consensus threshold cannot be configurable and should likely be set to a super-majority: 66% house && 66% senate? There would be no construct for a judicial (Code is already law) or executive (No president figure) branches. This construction could be incorporated into Charles' recommendation of a crypto users' constitution and bill of rights. This governance mechanism needs to be as solid as an embedded device firmware updater, allow for safe bootstrapping of Cardano Governance. The network should be hard-coded to reject parameters which would cripple it, such as setting the maximum transaction size equal to 0 or setting the minimum UTxO amount to 1e6. Parameters should be configurable within a sane range. Should we hard-code an automatic rejection to transactions which attempt to spend more than 10% of the treasury every 5 epochs? I agree that it would be wise to have a mechanism where operators could broadcast support for one or more competing proposals. |
|
|
||
| - This change can be implemented by adding extra validations to the ledger. This would consequently _diminish_ the number of blocks that are considered valid and thus, do not require a hard fork. In fact, a hard fork is required when the number of valid blocks is made _greater_. The proposal also does not change any of the existing binary formats or even, any of the existing procedures when it comes to updates. This seemingly means that updates can still only be issued by the founding members. Yet, it forces them to bring them for discussion and approval before. | ||
|
|
||
| - While this proposal makes it slightly more complicated for the founding entities to create updates (as they are now required to (a) coordinate with the community and (b) pre-create the transaction in a deterministic manner), the technical complexity of endorsing an update for SPOs boils down to adding a line in a configuration file. It is also easy to verify that the added line indeed corresponds to the update since it is a mere transaction id. |
There was a problem hiding this comment.
Other thought: this also makes it harder for these entities to submit these kinds of transactions across era boundaries because the tx format (and therefore the hash) may change. Slightly awkward, but not a deal breaker and doesn't happen often
|
I will, for now, close this PR as I have not enough time to allocate to this right now and, from what I could grasp from the community feedback, it seems that there's still a majority of people that trust the founding entities to not do anything reckless and therefore, need not the safeguards that this proposal would offer. While closing this, I would just like to address one of the recurring concern that came in response to this CIP which was, I believe, misunderstood by many. This proposal does not grant additional power to SPOs, it only makes it easier for them to apply something they already have. Although, as we've seen with the Vasil (1.35.3) upgrade, SPOs does not seem to be needing this proposal to already enforce this power 🙃. I am also hopeful for CIP-0047? which pursues a similar goal. |
Abstract
The Cardano journey was divided into several phases, the last of which relates to the decentralization of the network governance. We call this last phase: 'Voltaire'. While Voltaire is in the making, some aspects of the protocol remain relatively centralized and under the control of a few entities. This proposal improves on the current status quo by adding a layer of control to the Stake Pool Operators (a.k.a. SPOs) and by extension, to delegators. This proposal is fairly lightweight and can be implemented without a hard fork.
Motivation
Decentralized governance is a hard topic and it is likely to take some time to get to a point where Cardano has a fully working decentralized governance. In the meantime, while tolerated until now, the current status quo is judged unacceptable by many. As of today, the number of entities that can control the current set of governance operations is limited. Those operations include:
At this stage, any such operation can be performed if and only if a quorum of 5 out of 7* genesis members is reached. Genesis members represent here keys that were assigned to the three founding entities: Input Output, Emurgo and the Cardano Foundation. Because the current quorum limit is 5 and because of the current distribution of the genesis key (3 - 2 - 2), it suffices for only 2 out of the 3 funding entities to perform such an operation.
Over the past months and years, this topic has been at the centre of many vigorous debates. We thus think that the current status quo has to change.
Specification
We propose to modify the current ledger rules and node configuration to, by default, reject any update proposal or MIR transfer unless they have been explicitly referenced in the node configuration. We propose to make this behaviour optional and only enforced on block-producing nodes (so that, downstream applications such as full-node wallets are not affected unless they desire to).
More concretely, the node's configuration will be extended to contain a list of pre-authorized transaction ids. Upon validating transactions in blocks, containing either:
the ledger will check for the existence of the carrying transaction in the pre-authorized set. Unless present, the transaction will be deemed (phase-1) invalid.
Rationale
By doing this, we force any sensitive operation such as update proposals or MIR transfers to be endorsed by a majority (by stake) of block producers. Indeed, only nodes that have endorsed the operation in their configuration will produce and recognize chains containing the operation. This also means that in a situation of no consensus, the network will inevitably fork between those who endorse the update and those who don't. Ultimately, the longest chain rule will apply and the chain that can produce the most blocks will eventually be adopted. That chain will be the one which is endorsed by the most stake (since the block production is roughly proportional to the stake).
This mechanism means that it'll be impossible to endorse an update unless accepted by the majority of nodes (weighted by the stake they "control"). It is important to remark that this mechanism is highly asymmetric:
If the majority of the nodes are NOT endorsing an update, then the network will fork until the majority successfully produce a longer and denser chain than the minority. Then, since that chain would still be valid from the point of view of the minority, it'll eventually be adopted following the longest chain rule. This effectively prevents the founding entities from rolling out updates by themselves, without the endorsement of the majority of the network.
However, if the majority of the nodes are endorsing an update, then, in the case where there exists a minority, it will be impossible for the minority to ever adopt the longest chain produced by the majority unless they also in turn accept the update. In case they don't, they would seemingly be unable to produce new blocks; resulting in a segregated network being formed. If the minority is too large (e.g. 40% vs 60%), this may also drastically reduce the active stake for the rest of the network maintained by the majority and decrease the overall efficiency of the network.
It'll be therefore ill-advised for the founding entities to push an update that isn't endorsed by a crushing majority.
An immediate consequence of this is that power is also implicitly given to delegators. Because the block production is ultimately determined by stake; should there be a disagreement between an SPO endorsement and its delegators', they would have the opportunity to re-delegate and move their stake away from the SPO, and effectively reduce its influence in the network.
This change can be implemented by adding extra validations to the ledger. This would consequently diminish the number of blocks that are considered valid and thus, do not require a hard fork. In fact, a hard fork is required when the number of valid blocks is made greater. The proposal also does not change any of the existing binary formats or even, any of the existing procedures when it comes to updates. This seemingly means that updates can still only be issued by the founding members. Yet, it forces them to bring them for discussion and approval before.
While this proposal makes it slightly more complicated for the founding entities to create updates (as they are now required to (a) coordinate with the community and (b) pre-create the transaction in a deterministic manner), the technical complexity of endorsing an update for SPOs boils down to adding a line in a configuration file. It is also easy to verify that the added line indeed corresponds to the update since it is a mere transaction id.
In particular, Catalyst funds distribution is done through MIR transfers, and this proposal would require every ada-holder (through their SPO) to endorse every MIR transfer coming from Catalyst. In practice, the full list of transfers can be pre-constructed by the founding entities and shared as one configuration file which can be verified manually at first, and automated afterwards.
Backward Compatibility
Path To Active