Understanding AMC (Accepting the Maximum Condition)

Why is Mina an excellent settlement layer?

Mina stands out as an ideal settlement layer in many respects. A settlement layer in a blockchain ecosystem is the foundational layer where the accuracy and reliability of transactions are guaranteed, and on-chain states are finalized and recorded. Mina’s unique features position it as an exceptional choice for this critical role.

First and foremost, Mina operates as a lightweight blockchain. But what exactly does “lightweight blockchain” mean? In traditional blockchain networks, the chain size grows cumulatively as the number of transactions increases over time, which raises hardware requirements for participants running a full node. Vitalik Buterin highlighted this issue in the “Storage” section of his 2021 article, “The Limits to Blockchain Scalability.” Mina addresses this challenge at its core by using zkSNARKs and recursive proof techniques to keep the chain size fixed at 22 KB. Thanks to this innovative approach, all users can operate the network as a full node, even from a browser or a mobile device. Those interested can test OpenMina’s web node directly through their web browser. This decentralized and lightweight structure enhances both security and user experience. Additionally, zkApps running locally in the browser ensure that users maintain privacy without relying on centralized servers and users can verify the chain without a need to download gigabytes of data.

From a security perspective, Mina leverages zkSNARK technology to validate the accuracy and security of every transaction. This ensures data privacy while confirming the validity of all on-chain activity. Mina’s decentralized nature further strengthens its appeal, offering high accuracy and reliability without dependence on centralized authorities, which enhances user trust. Additionally, Mina is environmentally friendly due to its low energy consumption, positioning it as a sustainable blockchain solution. Its lightweight structure also enables low transaction costs, ensuring fast and cost-effective processing.

Mina also excels as a settlement layer for Layer-2 solutions due to its recursive SNARK-based proof mechanism, isomorphic architecture, and modular infrastructure. The fixed 22 KB chain size ensures transaction efficiency and low latency even during periods of high demand. Moreover, Mina’s isomorphic structure allows seamless compatibility between L1 and L2, enabling zkRollups and zkApp chains to integrate effortlessly. This structure simplifies data sharing between L1 and L2 and ensures composability.

All these features make Mina a reliable, scalable, privacy-focused, and sustainable settlement layer. With its innovative architecture and robust security, Mina provides a strong foundation for modern blockchain applications, making it an ideal choice for both developers and users seeking efficient and trustworthy solutions.

Mina’s zkApp Architecture

Many of us are already familiar with smart contracts on Layer 1 chains like Ethereum and Solana. Similarly, zkApps are the name given to smart contracts on Mina, supported by a user interface (UI) that allows users to interact seamlessly.

zkApps are built using zkSNARK, a type of zero-knowledge proof, and they focus on privacy, scalability, and low costs. Unlike traditional decentralized applications, zkApps enable users to execute transactions without revealing their data. This provides significant advantages in various fields. For instance, you can verify that your income qualifies for a loan without disclosing your income details on-chain. Similarly, zkApps can be used to create an application that verifies a student’s graduation status without revealing their GPA or other private details. This capability is achieved through zkApps performing computations off-chain and only recording the results on-chain using zkSNARKs. This reveals that zkApps function in a manner similar to zkRollups on Ethereum, while significantly reducing the data load on Mina. But how exactly does Mina’s zkApps architecture function? Let’s explore.

1. A user interacts with a zkApp through a compatible wallet and provides the necessary information. This data can be either public or private, where private data is not visible to the blockchain. For example, a user may specify their intention to purchase one NFT from the X collection for 0.1 ETH.
2. The prover function within the zkApp processes the user-provided data locally to generate a zero-knowledge proof. A list of state updates associated with this proof is then created.
3. The user selects the “Submit to Chain” option in the zkApp UI. They confirm the transaction, sign it with their wallet, which includes the proof and the associated state update details, and send the wallet to the Mina network.
4. The Mina network receives this transaction and verifies that the proof successfully passes the verifier method listed on the zkApp account. If the Mina validates the proof and the requested state updates, the zkApp state is updated accordingly.

The current operational design of zkApps provides an innovative foundation by combining Mina’s lightweight blockchain structure with zkSNARK technology. However, building upon this foundation with additional features and developments can make the user experience even more flexible and powerful. For instance, introducing more complex validation workflows or multi-step transaction models could expand zkApps’ functionality. Systems that link user interactions to specific conditions or triggers could further enhance their utility. All these advancements would make zkApps an even more effective tool for both developers and users.

zkVot Protocol and the Role of Censorship Resistance

zkVot stands out as a protocol where the functionality of o1js and specialized mechanisms are implemented among zkApps. zkVot is an innovative protocol on Mina that enables censorship-resistant, anonymous, reliable, and transparent voting processes.

zkVot fundamentally eliminates dependency on central authorities, ensuring the security of elections and the privacy of users. The protocol has a modular structure consisting of five layers: Voting Layer, Communication Layer, Aggregation Layer, Settlement Layer, and Storage Layer.

• Voting Layer: This layer is based on the principle that voters generate zero-knowledge proofs (ZKPs) for their votes on their own devices. This ensures privacy, as it is impossible to determine who cast which vote. Additionally, having voters generate their own proofs improves the scalability of the system.
• Communication Layer: In this layer, votes are securely transmitted to the network. Instead of using a centralized server, zkVot relies on a distributed data availability (DA) layer. The protocol primarily uses Celestia and Avail as DA layers but can integrate others. The use of a DA layer ensures that all votes remain available to everyone until the election is completed.
• Aggregation Layer: This layer ensures the validity, accuracy, and total count of votes through zk-SNARKs. The counting process is entirely transparent and resistant to manipulation. For instance, no vote can be altered or falsely added during this process.
• Settlement Layer: In this layer, all votes and results undergo one final check for accuracy and validity. This step finalizes the election results and confirms their reliability. zkVot has designated Mina as the settlement layer to ensure compliance with all requirements.
• Storage Layer: The layer where all static data, such as election questions, candidates, and other related information, is stored. Voters retrieve this static data from the storage layer before casting their votes.

The modularity and flexibility of these layers make zkVot unique. The layered and modular architecture of zkVot ensures efficient performance even in large-scale elections. But how exactly does zkVot function in a sample election?

1. Voters read election data from the settlement layer with EID (Election ID)
2. Voters get election details from the storage layer with election data
3. Voter generate votes as a ZKP. Thanks to ZKP, each vote is anonymous and takes approximately 15 seconds to generate. The generated ZKP verifies the validity of the vote and provides the nullifier and candidate result.
4. Voters send individual votes to the communication layer
5. Aggregation layer read votes from the communication layer
6. Aggregation layer generate aggregated ZKP with parallel parallel aggregation
7. Aggregation layer send the aggregated ZKP to settlement layer for settlement
8. Settlement layer enforces AMC for censorship resistance

Censorship resistance is a critical feature for decentralized voting systems like zkVot because it protects the integrity and fairness of the voting process. Without censorship resistance, malicious actors could manipulate the system in several ways: they might hide specific votes, alter or omit them, or even prioritize certain votes over others to skew the election results. Such actions could undermine the legitimacy of the election, erode trust in the system, and potentially disenfranchise voters. For instance, if some votes are excluded due to censorship, the final tally would not represent the true will of the participants. Additionally, the lack of censorship resistance could enable vote suppression, where voters might be discouraged from participating due to fears of their votes being invalidated or ignored. In extreme cases, this could lead to systemic manipulation, where malicious aggregators or intermediaries bias the outcomes to serve their interests, completely undermining the purpose of a decentralized and transparent election process.

zkVot commits to censorship resistance by utilizing a specialized mechanism developed for zkVot called Accepting the Maximum Condition (AMC). This mechanism ensures that only valid transactions containing the maximum number of votes are accepted, preventing malicious behavior. AMC evaluates processed votes in the Aggregation Layer, verifying only the necessary minimum data. With AMC in place, even a single honest vote aggregator is sufficient to ensure the system operates correctly.

In the next section, we will delve deeper into how AMC works and its detailed implementation.

How does AMC (Accepting the Maximum Condition) work?

AMC (Accepting the Maximum Condition) is one of the core components of zkVot, designed by the node101 team to enhance censorship resistance in decentralized elections. The primary goal of AMC is to ensure that the presence of even a single honest aggregator in the system is sufficient to include all votes in the final results.

In AMC’s operational principle, the Settlement Layer stores the most recently accepted maximum number of votes as a state variable for each election. When an aggregator submits a new settlement transaction, the system accepts it only if the total number of votes exceeds the previously recorded maximum. For example, consider an election with 1,000 participants. Initially, the previously recorded maximum in the state is 0, as there has been no settlement before. As a result the first aggregator to settle may submit any value, for instance 900. Once the first settlement is done, the second aggregator is forced to exceed this number. If the total number of votes submitted by the second aggregator is less than 900, the transaction is rejected. If it exceeds 900, the transaction is accepted and sets the lower limit for the next accepted total vote count. Ultimately, the transaction with the highest number of votes sent by an aggregator becomes the election result.

As long as there is at least one honest aggregator in the system, the process runs smoothly with 1/N trust assumption, and the risk of censorship is eliminated, as a result with more votes should always be more honest. Note here that the aggregator is essentially a ZK rollup, and it has no chance to lie. This forces all votes that are included in the aggregation to be correct.

Additionally, having votes processed by multiple aggregators would also make it significantly harder for malicious actors to control the election process. To achieve this, this system also incorporates a reward mechanism that incentivizes the contributions of different aggregators, encouraging collaboration among honest aggregators and ensuring the fairness of the voting process.

AMC’s robust design ensures that decentralized elections remain resilient against censorship. By creating a system where even a single honest participant can uphold the integrity of the voting process, AMC not only guarantees the inclusion of every vote but also fosters trust in the system. The collaborative framework between aggregators further strengthens the network’s reliability, making zkVot a powerful solution for secure and censorship-resistant elections.

The Future of AMC

In the case of a voting, the reason that AMC works great is the fact that there is no such thing as an invalid vote: If someone submits a result with 10 votes, then all votes in this result must be valid etc. As a result, in an election with 1000 voters, there may be at most 1000 valid votes. However, this is not the reason why AMC works, and the system idea can actually be adapted into different applications, like a DEX.

Think of a conventional order based DEX system, where users submit orders in each block. Do you think it would be possible to adapt AMC in this system? The answer is yes, and the maximum condition actually works great even with systems where there is no definitive maximum (any amount of orders can happen in a DEX, so there is no result as being fully correct).

There are of course some technical details with this implementation, but the flexibility around the idea of “accepting the maximum” is so strong that it can actually bring censorship resistance to any system. In the case of a DEX, by introducing some additional cryptography to the ordering / aggregating process, it is possible to prevent any MEV attacks from happening.

This is the part where things get really interesting: Think of a world where all rollups use a maximum based accepting condition for a permissionless aggregation layer, where different aggregators may collaborate together to reach the maximum as fast as they can. Then, what is the reason why we actually design this aggregation network as a separate layer? It is actually very possible to make each client responsible for their own aggregation after the submission of a TX. In the case of zkVot, this equals making everyone count their own (or someone else’s) vote after submitting their vote to the system. As a result the costs of sending a vote approach to 0 (and eventually becomes 0 with an election with enough participants), but this is just the tip of the iceberg.

This idea is really interesting, as it actually makes the off chain computation layer disappear and introduces a scalability potential that was impossible before. The system does not only compensate for the performance by making everyone create their own vote, but also forces everyone to contribute with a small extra amount of computation power to help with the aggregation. In short, the system actually gets stronger and stronger exponentially with every participant joining the network.

A scalability of this type has never been possible before, and until now all systems that we have designed got slower and heavier with every new user participating. As a result, for now we have no idea what we can achieve (apart from a fully free to use system) with this new design, but it is for sure really exciting.