Voting for ledger alteration

Massa Improvement Proposals
1

Voting for ledger alteration

Rationale

In all permission-less blockchains, if a majority of the power (eg. stake in PoS, hashrate in PoW…) decides to fork the blockchain by changing some values (for example the balance of an account) or even break consensus, they can already do it (see 51% Attack: Definition, Who Is At Risk, Example, and Cost ). Proof-of-X algorithms therefore already provide an approach to vote on-chain through hard forks (see Ethereum Classic).

The idea behind this proposal is to streamline voting so that it can be achieved through PoS majority voting without hard forks.

How it would work

A new “ChangeBatchProposal” operation is introduced and contains a batch of proposed ledger changes. Each proposed change within the batch has the following payload fields:

  • [target_address]
  • type of change:
    • BALANCE_UPDATE [new_balance] to change the MAS balance of an account
    • DATASTORE_REMOVE [key] to delete a datastore entry of an account
    • DATASTORE_UPDATE [key] [value] to update a datastore entry of an account
    • BYTECODE_UPDATE [value] to update the bytecode of an account

When this operation is executed, it registers a proposal in the state that expires 15 days later and gets a unique ID for the proposal.

Block headers contain an extra field: proposal_votes that lists all the active proposal IDs for which the block producer wishes to cast a vote. A maximum of 5 votes (for different proposals) can be cast per block.

Two counters are added to the state for each proposal:

  • total number of blocks since the proposal started
  • number of blocks that voted for the proposal since it started

At the end of the slot at which a proposal expires (or if it expired before because of a network restart):

  • look a the counters: if the majority of the blocks voted for the proposal, apply its changes to the ledger
  • delete the proposal from the state

Node runner interface

TODO: how to notify node runners of proposals and show them their contents so that they can choose or not to cast a vote ?

Applications

This system is useful for:

  • content moderation
  • state fixes for example after a major hack
  • preventing hard forks
3 Likes
2

I am against this for multiple reasons:

  • Most of the stackers won’t participate in the vote, mostly big or regulated actors will. This could lead to censorship of the DeWeb by any gov knocking on Massa Labs/Foundation door.
  • Even though this is a legitimate voting process, regularly altering the ledger could erode trust in the immutability and reliability of the chain. Users expect blockchain data to be permanent and tamper-proof. This proposal could undermine that perception.
  • The ability to alter ledger records easily could attract regulators. Authorities might view the blockchain as less immutable and therefore more similar to traditional financial systems, leading to stricter regulation.
  • The proposal could discourage smaller node runners from participating if they feel their votes don’t count or if the complexity of understanding and voting on proposals becomes too burdensome. This could reduce the overall decentralization and security of the network.

If there is a major hack, the majority of stackers can agree to fork, and it would be preferable to the proposed solution, the same for content moderation.

1 Like
3

All good points. Pardon my ignorance but my question is, can we prevent (within the current structure) an ASC to go rogue, i.e. an autonomous SC that runs for illegal or harmfull reasons such a virus and can we do it fast enough to prevent damages?
Perhaps we need a mechanisms that allow illegal material.

4

Hello @0xpatcha and thanks for the feedback!

Most of the stackers won’t participate in the vote, mostly big or regulated actors will. This could lead to censorship of the DeWeb by any gov knocking on Massa Labs/Foundation door.

This depends on how the vote quorum is defined. Here we were thinking of a vote based on the percentage of blocks voting for the proposal out of all blocks, and not the percentage among voters. Basically this matches the current security level of Massa: if 51% of blocks want something, it will happen even today. The only difference is that if you don’t explicitly agree with something but 51% of the whole stake does, it will be applied to you.

A possible amend to take “disagreement” into account would be to allow node runners to choose between:

  • Explicit “Force Agree”: this means that the node runner will agree with the proposal and apply it at term even if others reject it. In that case, the node runner will end up in a hard fork in case of proposal rejection through votes.
  • Explicit “Agree”: this means that the node runner will agree with the proposal but only apply it if there is more than 50% of the total stake agreeing with it
  • (no response) aka “Disagree”: this is the default and means that the node runner is saying “I vote against either by choice or by default because I don’t care, but if the majority of all blocks including non-voting and Disagree ones yields an absolute majority (> 50%) of Agree, I will automatically comply and avoid a hard fork”
  • Explicit “Force Disagree”: this means that the node runner will explicitly disagree with the proposal, which means that if the majority of all blocks votes Agree, this node runner will ignore the decision and end up in a hard fork

Even though this is a legitimate voting process, regularly altering the ledger could erode trust in the immutability and reliability of the chain. Users expect blockchain data to be permanent and tamper-proof. This proposal could undermine that perception.

With the amend above, non-participants soft-reject every proposal by default, and can choose to hard fork on strong disagree. This would perfectly replicate and enrich the already present PoS voting system. The rest is about educating users about this change not affecting the pre-existing security and immutability model.

The ability to alter ledger records easily could attract regulators. Authorities might view the blockchain as less immutable and therefore more similar to traditional financial systems, leading to stricter regulation.

It’s kind of the opposite. If we do not implement anything in the ways of moderation, especially for DeWeb, we might very quickly end up in trouble according to our lawyers. By enhancing the PoS implicit voting to cover moderation, we solve this issue without harming the pre-existing security and immutability model of the blockchain.

The proposal could discourage smaller node runners from participating if they feel their votes don’t count or if the complexity of understanding and voting on proposals becomes too burdensome. This could reduce the overall decentralization and security of the network.

This is something to be tackled through education + independent audits of proposals, and is already a real question. What happens if github gets hacked and the bitcon Core client people download is compromised ? What happens if some Ethereum dev account gets hacked and proposes a fake urgent security update ? The answer is always 2-part:

  • independent audit of proposals
  • educating node runners for basic safety practices
1 Like
5

The proposed voting mechanism covers this case: ASC could be stopped by altering the target of the call.

6

I like the idea of Force Agree/Disagree. But we have to find a way to notify node runners when a vote takes place and where the discussion about the proposal is, otherwise most of them will automatically “(Force) Disagree” each proposal.
Thanks for addressing all the points :+1:

7

Then we must have that mechanism. One way or another, we must control the potential harmful user cases.

8

Sounds good to me in general.
Then there are all the details to imagine :slight_smile:

We could also consider the simpler alternative (or maybe as a v1) of just a smart contract based proposals and voting, and when a proposal passes, it’s included in the next release of the node. In that case we could also give nodes an expiration date like in testnet, to push node runners to follow what is happening and run the new version or a fork of it.

9

No, please.
I will not invest in something where a 10 people can wipe out my investment in 1 minute .
The blockchain must remain immutable. If someone makes a mistake or gets hacked, it is their responsibility.
Why shall someone can change my balance , or freeze my account.

10

It doesn’t change from today, if 10 entities hold 51% of the supply and collude to wipe out your balance, your balance will be wiped out.

In this scenario, honest node runners would fork the chain and slash those malicious node runners, it would be the same with this proposal. As the time proposed is 15 days, they would also need 51% to pass such a proposal.

It’s why we need more decentralization on most chains.

3 Likes
11

Agree on this, a 51% threshold on proposals (to legitimate it) would mimic the possibility of this guys forking the network to implement the feature.