Ethereum Essence: Complex Consensus Agreement Operation

Background introduction

The most important part of a distributed system is its consensus layer. But what does “consensus” mean? By definition, it is the opinion or position reached by a group as a whole. This may mean that most of the people involved agree or make a judgment.

 

A consensus agreement can usually be considered to have:

 

• DApp's "AARRR" User Operation Strategy (on) | PANews Report Interpretation
• Market Analysis: BTC slowly climbed the resistance level, and it was a long and short matchup.
• Google zooms in and builds a hybrid cloud blockchain application using ChainLink Oracle

1. A group of supporters who make suggestions.
2. Mark the suggestion as a valid set of tests.
3. A group of voters who voted for each proposal.
4. A voting mechanism that determines whether a proposal is accepted or rejected.
5. A set of actions that are triggered when a decision is made.

The voting mechanism can:

 

1. Formulate rules about who can vote and whether voters need to pass the knowledge test.
2. There is an algorithm for calculating the weight of each vote.
3. Set a voting score or time threshold to trigger a vote or during a voting operation.
4. Formalization: We have a consensus function, input parameters: proposal, voting mechanism, time stamp score, voting pool. The output will be a snapshot of the decision at the time stamp: depending on the voting mechanism used and the voting data up to that point in time, whether the proposal is considered accepted at some point in time.

 

The voting pool is the total number of voters with voting rights, regardless of whether they vote.

Consensus engine

Ethereum currently uses work certificates as its consensus agreement. We will briefly explain how it works.

The first phase itself can be considered a consensus agreement:

The user can propose a transaction that is actually a chain state transition. They use their own Ethereum client to add transactions to the transaction queue and further propagate to their connected peers. These peers follow the same process, and the transaction eventually arrives at the Ethereum client that can also mine the transaction. At this point, each miner acts like a "elector" and decides whether to include the transaction in the next block. They have their own voting mechanism based on the associated natural gas prices and the cost of natural gas traded. They also need to pass a hard password test in order to have the right to make a block. Decisions are in the form of transaction arrays that can be grouped into the next block.

The second stage is the customer's consensus on which chain versions should be further expanded with blocks. Miners propose blocks, and due to network propagation delays, multiple chain forks coexist at the same time. According to the greedy most important observation subtree (GHOST) protocol currently used by Ethereum, each client node "votes" to select which fork is valid.

But Ethereum has Turing's full expressiveness, which means it can be a platform for building a higher level of consensus.

Boolean Boolean Consensus Engine

In the following sections, we will only discuss Boolean decisions (similar to binary consensus). This means that voters can specify false or true for the proposal.

In order to establish a common (Boolean-based) consensus protocol, you should consider fine-grained voting on:

• Function execution
• type of data
• Data type and record
• address
• Permission mix

Consensus Memoization

Consensus means that a group of people agree on something. In order to be effective, the agreed results must be registered. In order to avoid going through the voting process again and again, you must write it down.

Consensus results can be stored on the chain as decisions, permissions, and statements. Additional information about the results can also be appended – for example, adding a swarm hash of a file containing voting statistics and data.

We can further say that the voting process can be continuous (on the chain or under the chain) – if opinions or assumptions change, people can change their minds. Therefore, permission can be seen as a result of memory at a certain point in time.

Function execution permission

Such permissions are not limited to who (EOA) and which contracts can enforce a single contract function consensus: there can also be permissions that control which functions can call/execute a given function.

You can also define function classes with similar type permissions. For example, the update() and remove() functions may have the same permissions, based on the insert() executor.

If you want to build an interoperable consensus engine on top of Ethereum, you might want to distinguish between EVM and non-EVM environments. Imagine you want to use a function in the EVM protocol: such a function needs to be public. However, you may not want to call this function from a non-EVM environment – for example from JavaScript dapp.

Data type and record permissions

Imagine a consensus protocol for identity: Users may decide to provide CRUD permissions to a trusted third party through an identity data type. One such third party is able to authenticate only a portion of the user's identity and manage it on the chain on behalf of the user. The second one can manage another identity data type. Consider the management entity that Twitter attaches the user handle certificate to the user's identity contract or additional identity hash.

Therefore, you have fine-grained permissions on the data type and the data record itself.

Address permission

This type of license can be considered a role-based access control mechanism.

An Ethernet address (EOA or contract) can be granted by another address with a higher privilege to provide further privilege in the hierarchy.

Permission mix

The above permission types can be combined. For example, you can grant the Ethereum address only the ability to update the data record attribute value for a particular data type without allowing it to update other attributes or delete the record.

statement

Here are some examples of life:

• The user has the right to be a technical reviewer of the protocol changes.
• The user is over 18 years of age, so the law allows the use of the service.
• Through the voting process, users can gain a certain status, role, and even ownership of digital goods. The statement is a permanent record of this result.

Boolean consensus operation

Let us assume that we have some established permissions. We can define other permissions by agreeing on Boolean operations on existing permissions.

For example, Bob wants to make changes in a public file system folder. He wants to move a file from that folder to another folder. The system needs to check Bob's permissions on the file, change the parent folder's file update function, update the current parent folder and its delete subfiles, update the new folder and its add subfiles.

Bob is allowed to move the file only if the final result of the aggregated permission is true.

The sequence of Boolean operations required to calculate whether Bob can move files can be done by proposal and voting. Once the sequence is accepted, anyone who wants to use it can use it.

Meta-consensus: Consensus chain

We have already talked about some puzzles. The puzzle itself is a universal consensus engine. A protocol that allows you to establish other consensus agreements by using yourself to reach a consensus on the design of the new agreement.

The flow is as follows: Alice proposes a new voting mechanism and submits it to the chain (the mechanism itself can even contain pointers to the swarm storage script file). Alice does not have the right to add voting mechanisms directly to the agreement. Therefore, the system announces the submission and creation of new voting resources. People can now discuss and vote (on the chain or under the chain). Developers can run tests on this new mechanism in the form of submissions.

If the vote is successful, Alice's voting mechanism can be fully registered into the agreement, and Alice can be automatically granted some new permissions – such as "Mechanism Update Reviewer."

and many more. This is a consensus on future consensus.

This is the dependency graph described so far.

Consensus life cycle

The consensus on the facts and opinions is different. There is volatility and erosion in the consensus on opinions.

While the de facto consensus can be achieved (at least in part) in a procedural manner, the consensus on the opinion may require a flexible allow/disallow agreement that can run continuously. Therefore, the life cycle can be:

1. creativity
2. Mutagenicity
3. Corrosive

I have already mentioned that the service life of a privilege is limited. In this sense, if the voting results in progress are changed, they can be changed.

From an ethical perspective, anything that requires consensus should be implemented as a continuous voting process. People should be able to withdraw support for an idea at any time. The system can only be democratic and ethical if:

• Anyone can propose a change and start the voting process.
• Any previously approved reforms can be resumed by voting (background changes, new electors, old voters disappearing, etc.).

Continuous voting on the agreement:

• One can submit a protocol change that contains all the source code and information needed for testing and auditing.
• Votes for protocol changes have been enabled.
• If a positive threshold voting score is reached, the change is automatically accepted.
• Voting can continue, and if a negative voting score is reached, the change will automatically be disabled again.
• At this point, you can continue to vote, or you can propose a proposal to cancel the proposed change.
• There can be a set of automated tests that can be run on the proposed changes, and if the test fails, the proposal can be flagged and the vote suspended. This enables untrusted computing through distributed protocols.

in conclusion

Today we only explored the use of binary consensus in Ethereum. There are more types of consensus to explore.

From this perspective, the Ethereum consensus engine has a lot of room for growth and development. We are in the early stages of exploring different types of consensus. Complex consensus actions will expand and open up new horizons of discovery.

Source: Public Number: Blockchain Research Laboratory

We will continue to update Blocking; if you have any questions or suggestions, please contact us!