[Upgrade Proposal] – Slow Soul Upgrade Mechanism

[lisa_akselrod]

For the initial inputs, assumptions, and goals, please, refer to the RFP.

Summary (TL;DR)

The “Slow Soul Upgrade Mechanism” offers a mechanism for upgrades both for node software and the chain smart contracts updates. It starts with covering general assumptions as well as all the affiliated parties that are interested in the upgrade solution making and upgrade execution. It continues with the mechanism for deciding whether to upgrade or not. The mechanism is split into two cases: “Node software upgrade” and “Smart contracts and bridge upgrades.” The mechanism relies on Soul Bound Voting, an open stage for community discussions and improvements, and efforts to align all the interested parties while preserving options for critical disagreements in the forms of forks or exits. In Part 2, we describe the voting mechanism in detail. In Part 3, we describe the specific upgrade execution mechanism. In Part 4, we cover different fork scenarios, ensuring the community has an opportunity to move forward with a forked chain whenever and in any configuration they want. At the end, we cover questions that suggest further work and research to handle them.

Comparisons

Below, in the “Details” section, I tried to explain the choice of each decision and why it fits. In this section, I’ll briefly compare the chosen option, SBT, with the most obvious.

The first, most obvious option – is using a governance token. But then, firstly, we depend on token allocation and future token flow. Secondly, we can’t manage the token ownership. That is, for example, be sure that there are different interested parties behind different entities. Both issues will make the upgrade mechanism less robust and predictable.

The second most obvious option – is going in a more centralized way, where upgrade decisions are made by the chain team or the chain team + some committee of trusted representatives (that can be selected by the community or assigned in another way). The part of the community that disagrees with the update will still have an opportunity to fork or just not upgrade. However, this approach contradicts the chain’s chosen path of decentralization (as I can assume from sticking to decentralized sequencing and proving discourse). Furthermore, it will increase the probability of chain splits as a chain fork will be the only option for the community to stick to their needs and values without the opportunity to discuss and collaborate. As an advantage of this solution, it operates faster as less coordination is required.

These two options are easier to implement and manage in a short-term perspective. However, from a long-term perspective, they seem less robust than the one proposed below and are not aligned with the Aztec values.

There are also plenty of other options that didn’t come to my mind. However, I can’t compare them because they didn’t come to my mind.

Details

General Assumptions

• There is a forced exit mechanism;
• There exists a forum for discussing protocol/network changes (e.g., AZIPs);
• There is a reliable Soul Bound Token protocol that allows one to prove belonging to the organization without revealing identity.
• There are enough participants in the network to make the governance mechanism sustainable. Check the section “Questions” for further ideas on what is “enough” in this context.
• We prioritize decentralisation over speed.

Affiliated parties

Assumptions about parties

• Dapps are the heart of the ecosystem. That is what makes the chain unique. No dapps – no users. That is, dapps’ opinion should have substantial weight, tho none of them should be able to have too huge influence (even if it has a large share of chain activity).

• By infrastructure providers, we mean RPC providers, oracles, indexers, interoperability layers, and other tools and pieces that help dapps to operate.

• Users (dapps users) should have an opportunity to express their opinions. However, it shouldn’t be mandatory or play a core role in general mechanism sustainability.

• Dapps and infrastructure providers, if they wish to support the upgrade, are ready to take some actions, such as upgrading the software they run on a node, updating UI, etc.

• No specific actions are required from users for the upgrade.

Part 1: How do we agree that we want to upgrade to {X-release-of-software}

Disclaimer 1: Two types of upgrades take place in the rollup: (i) node software upgrade, that is, to upgrade node operators should upgrade the software they run, and (ii) smart contracts and bridge upgrades, which are executed on the chain side using multi-sig or other mechanisms. Below, we cover both cases, starting with “Smart contracts and bridge upgrades” and then modifying the scheme for node software upgrades.

Disclaimer 2: We assume that most proposals are reasonable and the proposed mechanism “Slow Soul” is aimed at their improvement, stimulating open discussion and collaborative work. However, in case of unreasonable or malicious proposals, the mechanism will provide a solution to decline the upgrade, empowering the community to decide.

Smart contracts and bridge upgrades

The core “problem” of the smart contracts upgrade is that 100% consensus is almost unachievable. There always will be at least a tiny share of interested parties that do not agree with the upgrade. However, smart contract updates will enforce the outcome supported by the majority. That is, our goal is to ensure that the proposed updates meet the expectations and needs of the vast majority.

We consider “the vast majority” to be 90%+, as for the general chain health, it is reasonable to stay a single chain without breaking into smaller parts, as it affects a number of participants of the network while the last is closely affiliated with network security, censorship resistance, and liveness (e.g., if half of Decentralized Sequencer Operators stick to the old chain, and a half of them jump into a new version, the decentralization is decreased exactly twice).

However, we also want to provide a reasonable opportunity to fork the chain the community wants, so in the second iteration of the Review Stage in “Node software updates,” we decrease this barrier to 70%.

1. Initial Proposal: An upgrade is proposed in full by the Aztec team on the community forum. The forum is available for anyone both to read and to comment. All interested parties (dapps and infrastructure providers) are notified about the proposed update.

2. Initial Review: There is a 1-2 month period for everyone to review, comment, and offer suggestions. The specific period length is defined based on the update size. The larger the size, the more time is provided.

3. Community Call #1: After the initial review stage is over, that is, everyone who was interested had enough time to review and comment on the proposal, Community Call #1 takes place. Community Call (i) covers questions discussed in the forum (discussion is continued, or if it is over in the forum, the solution is confirmed and shared with everyone), and (ii) opens the stage for other questions and suggestions that were not discussed before. Community Call is facilitated by an Aztec team member or a community volunteer.

4. Improved Proposal #1: Based on the forum discussion and Community Call, the Initial Proposal is improved and published on the forum.

5. Voting #1: 7 days after the Improved Proposal was published, Voting #1 takes place. For the specific voting mechanism, check the next section, “Part 2: voting mechanism”. If the update is supported by 90%+, the upgrade is accepted.

6. Repeated Review #1: If the update is supported by less than 90%, the process goes back to the forum for the Repeated Review. Its goal is to discuss the issues that the community disagrees with and find solutions to handle them. After one week of forum discussion, Community Call #2 takes place. Improved Proposal #2 is published on the Community Forum. Voting #2 takes place a week after Improved Proposal #2 was proposed. The whole Repeated Review stage takes nearly two weeks.

7. Repeated Review #2: The mechanism for Voting #2 and its outcomes is exactly the same as for Voting #1. If the protocol was supported by less than 90%, the Repeated Review can have one more round.

8. Rejected Upgrade: However, if in Voting #3, the upgrade was supported by less than 90%, the upgrade is rejected. A new version of the upgrade covering the same issues can be proposed not earlier than in 6 months.

9. Exit Opportunity: Independently of the iteration at which the solution on the upgrade was made, the community should have not less than two weeks before the upgrade will be implemented to have enough time to bridge their assets back to L1 or anywhere else if they do not want to stay on the upgraded chain.

Node software updates

In the case of a node software update, each node operator should voluntarily update the software to a new version. That is why no Voting stage takes place in this update mechanism. Instead, our goal here is to provide a platform for discussion and improvements and allow to upgrade anyone who supports the upgrade. At the same time, the rest of the node operators will have an opportunity to have a fork. More on fork mechanisms in “Part 4: fork mechanisms”.

• Initial Proposal > Initial Review > Community Call > Improved Proposal: Points 1 to 4 from the previous section should be repeated.

• Temperature Check Voting #1: After the Improved Proposal, Voting takes place as well. However, its role is to conduct a “temperature check” and figure out if the community is aligned about the upcoming update or if more discussions and collaborative work are required.

• Repeated Review: If less than 90% supported the upgrade, the Repeated Review takes place, followed up by the Temperature Check Voting #2. The rules are exactly as in the previous section.

• Temperature Check Voting #2: If more than 70% support the update, the new version of the software is released, and supporters upgrade it while those who disagree have an opportunity to fork the chain (more on forks in “Part 4: fork mechanisms”).

• Repeated Review: If less than 70% supports the upgrade after the Temperature Check Voting #2, the Repeated Review takes place again, repeating the stages of Forum discussion > Community Call > Improved Proposal > Temperature Check Voting. If less than 70% supports the update, the new software version is not released. A new version of the upgrade covering the same issues can be proposed not earlier than in 6 months.

Note: We assume that most participants are aligned with the chain mechanism and philosophy and advocate for chain health at the current chain version. That is why the goal of the pre-voting stage of both upgrades described above is to help the community come to the majority alignment (if it is not there at the first Voting Round) or to reject the upgrade and allow to propose it again in 6 months as a substantially improved and reviewed version of the previous one according to community expectations and needs.

Part 2: Voting mechanism

• We propose using Soul Bound Tokens for Voting to provide the following demographics: 1 Vote = 1 Network Participant (Organisation). By Network Participant, we mean dapp or infrastructure provider. To make it real, we refer to the first General Assumption, saying that for this proposal, we assume we have a reliable SBT Protocol that (i) allows one to prove belonging to a specific organization without identity disclosure, (ii) allows us to conduct Voting without identity or organization disclosure with custom rules (such as 1 Vote = Organisation), (iii) and it is impossible to prove if one voted for or against the proposal (to prevent possible bribery attacks).

• The Soul Bound Token can be claimed in 2 months after the dapp was deployed on the network or the infra provider integrated the network. However, to participate in either Voting or Temperature Check Voting, the SBT should be claimed 6+ months ago. It softly prevents the voting mechanism from Sybil Attacks. Additional conditions on specific dapp characteristics to be legible to claim and SBT might be added to strengthen this mechanism.

• Dapps users can also have their votes counted, however, in a limited form: one user’s vote counts for 0.01 SBT vote. To vote, the user can delegate their vote to the dapp. One user can delegate their vote only once and only to one dapp. The total number of votes dapp users can delegate to the dapp is limited. This limit depends on the total number of organizations that claimed SBTs: the total number of votes of each organization should be no larger than 5% of all claimed votes.
  That is, for example, if there are 100 organizations in the network, each of them can claim one SBT, 100 votes is the total amount of all claimed votes. 5% = five votes. That is, if one vote belongs to the organization, four votes can get delegated from its users. 4 votes / 0.01 vote = 400 users can delegate their votes to each organization. This mechanism assumes that dapps users are softly counted. However, the dapp can’t use their userbase to affect the Voting results substantially.
  The user vote should be delegated for each proposal separately to prevent the organization from exploiting users’ laziness or forgetfulness.

• The Aztec team doesn’t have any SBT tokens and doesn’t vote. Its goal is to facilitate the process and prepare and improve proposals based on the community feedback, needs, and expectations while staying neutral.

Part 3: How do we actually perform the upgrade to {X-release-of-software}

• For Node software updates, each node operator is responsible for updating their software to a new version. The protocol used for a new software version delivery to each network participant should meet integrity security requirements. That is, the node operator can be sure that the new version of the software wasn’t tampered or modified. The specific mechanism for software distribution security is out of the scope of this proposal, but as a raw example, some MAC standards (such as CMAC or HMAC) can be used as we care about data integrity (tampering possibility) without caring about data secrecy (data eavesdropping).

• For Smart contracts and bridge upgrades, the multi-sig can be used. As a reliable multi-sig mechanism, the following is proposed:
  • High signers rate: 10/12 should sign the contract to upgrade it;
  • For each update signing, 12 signers are chosen pseudorandomly from the pool of potential signers (there should be at least 36 potential signers in the pool, check the questions section for more thoughts about this number);
  • Potential signers pool allows any organization with claimed SBT (dapp, infrastructure provider, and Aztec) to have one representative in the pool. That is, the principle of 1 organization = 1 representative is preserved;
  • Using a reliable SBT protocol (General Assumption one), each representative in the pool proves that he is a unique representative of the organization without revealing their identity or organization. That is, both potential and actual signers don’t know each other and can’t coordinate.

Part 4: fork mechanisms

There are several fork mechanisms that we need to cover: soft fork, strictly expanding hard fork, and bilateral hard fork.

By soft fork, we mean strictly reducing the valid set of transactions.
By strictly expanding hard fork, we mean strictly expanding the valid set of transactions.
By bilateral hard fork, we mean that the two rulesets are incompatible.

Starting with Node software updates:

• If an upgrade is a soft fork, nodes following the old rules will still get on the new chain. So, both forks can efficiently operate further without any barriers.

• If an upgrade is a strictly expanding hard fork, the old rules are a soft fork with respect to the new rules. Both forks can efficiently operate further without any barriers as well.

• If an upgrade is a bilateral hard fork, there should be enough participants to maintain the previous chain as, strictly speaking, it will be split into two separate chains. For Aztec, with decentralized sequencing/block building operators and provers (as intended), there should be enough fork participants to run each type of node software to provide the intended rate of decentralization.
  However, in the case of a bilateral hard fork, the minority fork has to take care of all necessary infrastructure on their own. If there are not enough participants to decentralize the network enough, another mechanism can be chosen by participants on a temporal or permanent basis, such as the temporal usage of the centralized sequencer.
  The core point is that nothing prevents the community from running previous node software and building the necessary infrastructure.

With Smart contracts and bridge upgrades, as contracts are upgraded either for everyone or for no one, the only option to maintain the previous version of the contracts is to fork the previous version and deploy it on their own, also taking responsibility for its maintenance. As the social consensus defines the “real” bridge or contract, as long as there are enough fork participants to define the fork as a “real” thing, there are no barriers for the community to fork any parts of the chain and use them further.

In the case of the Aztec bridge, the bridge fork is even easier as each dapp has its portal contract and can decide on whether to upgrade it (similar to how node operators make a solution on node software upgrade acceptance or rejection).

Questions

• What is “enough amount” in the network participants context as we assume using 10/12 multi-sig for upgrades execution? In fact, it means we require at least 12 organization representatives who self-volunteered to be in the signer pool. However, to make this multi-sig more reliable, we’d assume having at least 36 potential signers in the pool (the smallest number larger than 30 such that number % 12 = 0, where 30 is the minimal sample size to approximate a normal distribution acc. to the Central Limit Theorem).
  Should we have a spare mechanism in case fewer than 36 representatives are in the pool? What mechanism should it be?

• What specific encryption mechanism should be used to distribute a new version of software to provide integrity? Are there any other security parameters that matter for this specific case?

• Can this design benefit from any time delay mechanism? From the first view, the suggested mechanism seems already slow enough to prevent the chain from any unexpected executions or actions. However, if working on this mechanism further, I’d watch at the edge cases of its components to check for any social vulnerabilities.

[smallsizechad]

I thought the team has already advanced the B52 and the Fernet proposals to the ‘finals’ and it was too late to make own proposal… Would be happy if someone from the team confirmed that it’s not late yet.

[jaosef]

To date there have been two RFP’s:

1. Sequencer selection, of which B52 and Fernet are finalists, and a decision will be made shortly. This RFP is closed.
2. Upgrade mechanics, this determines how the network will upgrade for critiical bugs, new features etc. This RFP is live and accepting proposals, you can read more here.

[smallsizechad]

Wanted to reply on twitter under Cooper’s tweet, since it attracted some attention and the activity is higher there, but you know, character limit…
I’ve read it but I don’t understand some details. If, say, the sequencer selection path proposed in the B52 is chosen, which means that provers must stake native tokens to participate in block production, which means the network already has a native token, but for governance you go the tokenless way (i think we can say that governance via SBT is a ‘‘tokenless’’ way)?
I would assume some teams want to avoid issuing a token for various reasons (it may bring some problems i reckon), but since there will be a native token, why not go traditional aka veTOKEN (staked token) governance (it may have downsides but it’s a safe and well researched way.
some addition of SBT-governance, like with ZK-Badges by Sismo (What is Sismo? - Sismo Docs) issued for valuable onchain/offchain protocol controbutions would be somewhat pioneering, and i already suggested that in another thread (guess i should toughen up and try to write a full proposal) but for safety, especially on the first stages, i reckon the protocol should go more traditional, proven way of governing a huge network.

[LasseAztec]

Hi, thanks for the proposal.

Looking through it, I got a couple of notes and/or questions:

1. Getting a hold of the SBT seems very easy to sybil if you are fine with receiving delayed voting power.
   • Together with the 90% supports, seems really easy to keep the network hostage with only a few SBTs.
2. 90% for being supported seems similar to saying it cannot be upgraded.
3. Much of the review process seems not to be enforced beyond good behaviour? What stops it from practically having infinite rounds or just skipping all the communication parts of it?
4. In part 3, you mention “The multisig can be used” which sounds like you practically have a multisig and the SBT is only used as a temperature check.
   • What stops that multisig from doing whatever they want and not caring about the votes?
   • If the execution is enforced based on the votes, why have this multisig?

[lisa_akselrod]

Hey, Lasse!

Thank you for awesome questions! Happy to think about each of them:

1. If you have 6 months delay in getting voter power, while the total upgrade review process is ~3 months – you can’t foresee in advance what exactly will be proposed, what will be its shape and conditions – so it’s not so easy to be prepared with voting power by the right moment.
   I also assume that this kind of upgrades happens around core network questions – that is, there are not so many proposals happening. That is, for potential malicious party there is no sense in putting much efforts in getting voting power if they don’t know if there will be any proposals where they want to strongly win.
   I also assume that even though ideas and improvements are accepter from anyone through the forum or any other channels – the first version of the upgrade and improves versions are still shaped by the core network team (similar to EIP system on Ethereum). So, for malicious party it is not the case to propose whatever they want and to accept it just because they have enough voting power that they prepared in advance.

Together with the 90% supports, seems really easy to keep the network hostage with only a few SBTs.

Can you explain this issue please? – I am not sure why.
As I’d advocate for the opposite: as SBT gives one vote to each participant (who is interested) regardless of how huge their presence is – it encourages network participants to show up to votings and be engaged in the process as their vote matters (comparing to token-based voting when if one has a tiny share of all token volume they are not interested in spending efforts on voting process as their impact on the result is almost negligible).

2. I should clarify that by 90%+ I mean 90% of those who participates in the current voting, not 90% of everyone who is an SBT holder. As it can be seen from historical cases, the showing up to voting might be pretty low but it goes up when people know that their vote has real impact on final result. As can be seen from early Ethereum days votings – one of the option often got more than 90% tho it is not guaranteed of course. For case of misalignment, this proposal introduces the downgrade to 70% if through the discussion and collaboration process it doesn’t work to achieve 90% alignment.

As I explained in the proposal, one of the goals of this mechanism is to maintain the network community aligned, that is to avoid chain splits and parties leaving the chain as much as possible. This is why I put this 90% number. This is my personal view on L2 path today, as the cross-chain communication for different L2s still works pretty poor and doesn’t look promising (I can separately explain this issue if needed), so the less the L2 environment the better for Ethereum ecosystem in general. But this is my personal view.
Maybe Atzec Philosophy is different and it wants all the participants to go their ways and express their preferences as much as possible and splitting network into number of networks within say 5 years is an acceptable or even desirable solution – I don’t know anything about it but might easily assume it is the case.

3. There is the max amount of voting rounds – 3, that is why this loop can’t be infinite. When it comes to skipping communication part – I think it can be done. There are at least two scenarios: (i) network participants are absolutely indifferent to what is happening then they don’t participate in communication stage and voting stage, so the upgrades are declined because no one showed up, (ii) network participants have zero desire to collaborate and discuss and just want to strictly express their preferences in the voting.
   I assume that Aztec community is kind of tend to discuss to collaborate and discuss based on my external view of the project (I can easily be wrong), but what I see – (i) Aztec is playing a long-term game of slowly building legitimate community: no rush growth (airdrops, etc.), long time on the market with very legitimate reputation, good support for the ecosystem projects (grants, presence at the hacks); (ii) this is a pretty special rollup in terms of how it differs from competitors (at least privacy feature and Noir). Assuming these two issues, I hardly ever can imagine that all network participants are indifferent to what is happening – but can assume that this share might be huge (50%?), I don’t see reasons why 50% indifference will break the mechanism if the total network participants set is say 100+?
   The second case can also take place, where some network participants don’t want to communicate but want to show up to the voting. But again it will be a share of all participants.
   All in all, all network participants = indifferent (No communication, no voting) + only voting + communication & voting. The last group will contribute to the proposal improvement – so will have more space to express their needs and expectations. While the first two groups will get what they get.
   The problem might be if the second group (only voting) is large enough and collude to vote for a specific option. I don’t know a good solution for it right now, I can think more about it.

4. This is a very good and right question. I think it can be used on SBT only and this will be a more robust mechanism, however, I wouldn’t start right with SBT upgrades signing as I’d first ensure that SBT is robust enough in terms of possible sybil and other attacks. As from my perspective we don’t have any battle-tested SBT protocols that can be applied for such a crucial thing as upgrades signing from the very beginning. However, switching to fully SBT-programmable signing mechanism in 1-2 years looks like a good option to me.
   Going to robust multi-sig mechanism, I slightly explained it in Questions section but will try my best here:
   Assume, we have “multisig doing whatever they want and not caring about the votes”. Then we have at least 10/12 specific representatives in current upgrade signing whose goal is “doing whatever they want and not caring about the votes”. To make it successful – they need to want the same thing, otherwise the upgrade won’t be signed successfully. To coordinate, they need to know each other – but according to the assumptions of this proposal, SBT doesn’t disclose the identity. And if all of them do what they want, the result is 10/12 are aligned and it contradicts with the voting results – then the voting results doesn’t express the majority choice that is almost impossible with the 90% number.

To strengthen multi-sig further, (i) anyone can be a representative in the pool of potential signers, 12 signers for signing each specific upgrade are chosen pseudo-randomly. If we have a total pool of 36 potential signers and 12 are chosen pseudo-randomly and they don’t know each other – the probability of accident collusion is already pretty negligible.
But going further… I am definitely not the best multi-sig mechanism designer, but to push a robustness level even further – we can have a “placebo” mechanism where all representatives in the pool of potential signers, but only 12 are assigned to signing a real upgrade, while other are assigned to sign some empty whatever (I have no idea about implementation details but I think it’s somehow possible tho i can be wrong). In this case, the coordination is impossible at all as even signers themselves don’t know if they sign the upgrade or “placebo”.

But this question can be addressed then to any multi-sig. Imagine you have a multi-sig recovery for your smart wallet and forgot your password. And you want to get recovery. Assume your guards are 2 cold wallets, mom, friend, and special guardian service. To make a recovery you need 3/5 but 3 of 5 (mom, friend, and special guardian service) do whatever they want because nothing prevents them from it.

Thank you for reading my answers!

I enjoyed thinking about it!

[LasseAztec]

• I don’t think it matters that you have a 6 month delay if you don’t lose your voting power. Amass voting power, wait, then make a proposal yourself.
• If you cannot get a proposal through with enough voting power. Then what is the purpose of having the vote, it seems like just a signalling tool that core team could then use or ignore, up to them.
• If you need 90% support, >10% against can veto anything.
• How do you figure out “who is interested”? e.g., many people are somewhat interested in who is the leader of their country, but I don’t think you see 90% of citizens vote in any country even so. Also, if there are many voters, I don’t see how that changes the users impact on the vote from negligible.
• The point of max numbers where more me being a pain in the ass hence I did not see how this was to be enforced, so more of a desire without power to back it up.
• For 4, I’m not sure how SBT will be battle-tested if it never hold any real power but signalling that a multisig then enforces.
• The point about that being the case for all multisigs is exactly the point. The signers can do whatever they want. In the case of the recovery, I myself chose the signers because I might trust them. In the rollup case if you are able to steal all funds with the multisig you might get 10/12 to agree for the small price of a couple hundred millions or billions - or for free if bad opsec. My point were that trusting a multi-sig to not do bad things is really dangerous.

[lisa_akselrod]

• Assume, we have this case: someone amasses voting power and makes a proposal. To approve the proposal, he’ll need at least 70% of votes. Then assume we have a case when all the participants are honest, claiming 1 SBT per “real” entity but there is one participant who deployed a lot of dapps (enitities) and claimed a lot of SBTs.

I think you’re absolutely right that this is a possible outcome. Thinking about what mechanism can be used to strengthen the SBT claim fairness, for example, we can use something similar to Proof of Humanity, where to claim the token, (i) you make a deposit that will be refunded when the token is claimed (it won’t solve the issue, it will just make an attack more expensive), (ii) randomly picked SBT token holders should approve that the applying entity is real (it will make the system more complex and slow, but will provide us with some mechanism to filter fake entities.

• I think it’s a bit of open question for me if anyone can make a proposal or not. I’d advocate for everyone can make a proposal for specific ideas, features, whatever, but not everyone can write code for the update and offer the whole chain to continue with this code. As it forces everyone to be technically advanced enough to be able to make conclusions about code quality that is very unrealistic.
  But it’s not just “signalling”, the system is designed to enforce the SBT voting solutions (first time in a form of randomly shuffled and picked multi-sig and later with purely SBT).

• The 90% can be decreased to lower number after one or two rounds of voting, if the alignment is not reached. I assumed maintaining the chain without split as a priority (I am repeating, I mentioned it above). But it was my personal assumption that can be changed to lower barrier.

• What do you mean by "How do you figure out “who is interested”? First, there are entities who claim SBT – they are somehow interested. Then, there are some entities who show up at the voting. The number might vary from voting to voting. And I don’t expect 90% of SBT holders showing up. 90% of those who voted in a specific round. To stick to the reality, 30% (or less) show up to the protocol voting.

• What do you mean by “The point of max numbers where more me being a pain in the ass hence I did not see how this was to be enforced, so more of a desire without power to back it up.”? Numbers of 90%? 10/12 signers? 3 rounds? 36 representatives? Other max numbers?

• “how SBT will be battle-tested” – pretty fair point, however, (i) as the chain is more mature, more entities are on it secured by huger capitals, so they are more interested in maintaining the chain health → more potential SBT holders, (ii) you see how many SBTs were claimed in total, how much people are engaged in the discussions of the upgrades, how many show up for the voting. It’s not perfect but there is huge difference between say 5 SBTs claimed and 0 showing up for the voting and 300 SBTs claimed and 30% showing up for the voting. And these 5 or 300 will depend not on this mechanism but on a lot of different parameters such as general chain health and reputation, developers experience there, etc etc

• “you might get 10/12 to agree for the small price of a couple hundred millions or billions” – fair, that’s why I kind of insist on shuffling and random sampling of the 12 signers for each round where these signers don’t know each other. As well as proof of “one entity-one representative”. And if we go with “placebo” I described in the previous comment where all 36 representatives are signing something but only 12 are signing real upgrade and even those don’t know they are signing a real upgrade, …
  Let’s play with some random number: if a malicious entity controls 25 out of 36 representatives in the signing pool, the probability they will be chosen as 10/36 is 25/36 * 24/35 * 23/34 * 22/33 * 21/32 * 20/31 * 19/30 * 18/29 * 17/28 * 16/27 = 0.01286 (non-negligible, doesn’t work for us). However, if malicious entity controls 20 out of 36 representatives the probability they will be chosen is 0.00072685. That might be enough taking into account that they can’t repeat sampling as much as they want to reach a “right” amount of signers as for each voting round there is only one sampling and it can’t be resampled. Then our question is how to prevent a malicious entity from controlling 20+ representatives in the signing pool.
  As a naive and straightforward solution, 16/36 representatives might open their identities. Then these people should be non-affiliated, geographically decentralized, and have some non-tangible asset (e.g., reputation) at cost.
  Another solution can be increasing the number of 36 to make it more complicated and costly to “kidnap” enough representatives. However, for this option we need enough SBTs claimed (as the number of volunteers to be in the signing committee will be much lower than the number of SBTs claimed).
  If we strengthen the SBT claiming mechanism with what is suggested in the first abstract of this comment – it is a solution as well.