Table of contents:
Comprehensive overview
1. New ecological research based on MOVE language
Aptos
Sui
Linera
2. Modular Blockchain with Celestia
What is "modularity"?
Architecture layering of blockchain
Data Availability Issues
Celestia's Blockchain Scaling Solution
Fully Modular Stack --- Cevmos and Recursive Rollups
3. A new generation of privacy public chain
Aztec
Aleo
secondary title
AltLayer
----------------------
Comprehensive overview
Recently, the star public chain Aptos has just launched its main network and its market value has exceeded 1 billion US dollars. Privacy public chains (Aztec, Aleo) and blockchain scaling solutions (AltLayer) to explore potential new opportunities in new public chains.
In "Public chain ecology based on Move language", we first analyze the characteristics of Move language, comparison with solidity, and application, and then discuss the introduction, characteristics, and ecology of Aptos, Sui, and Linera public chains.
In "Modular Blockchain and Celestia", we introduced what is "modularity", the layering of blockchain architecture and data availability issues, and then discussed the blockchain expansion scheme and fully modular stack for the Celestia public chain , and concluded that shareability, simplicity, shared security, and sovereignty are more advantageous than traditional solutions.
In the "New Generation of Privacy Public Chain", first of all, around the motivation, bills, interaction, anonymity, efficiency analysis and future of the Aztec protocol, it shows that the AZTEC protocol can provide the tools developers need to create the next generation of private decentralized financial services facilities to build digital assets with absolute privacy and private governance, followed by the brief introduction of the Aleo public chain, core technology, consensus mechanism, token economics and future elaboration for one of the leading projects in the Web3 privacy track with high financing. Users bring privacy protection and privatization of data.
secondary title
1. New ecological research based on Move language
Features of the Move language
The Move language is a safe and reliable smart contract programming language invented by the Diem project to express digital assets. It is specially designed for digital assets and is used to issue digital currency, process transactions on the blockchain and manage verification nodes.
Currently, the Move language can only be used in built-in smart contracts. It first appeared in Facebook's blockchain project Libra (abandoned), and its biggest feature is that Resource is a first-class citizen of Move. Unlike Solidity, Ethereum's development language, Move's resources can never be copied or implicitly discarded, they can only be moved between programs.
Move vs solidity
Currently, the main player in the blockchain language space is Solidity. As one of the first blockchain languages, Solidity was designed to implement basic programming language concepts using well-known data types (e.g. byte arrays, strings) and data structures (e.g. hashmaps). However, with the development of blockchain technology, it can be seen that the main purpose of blockchain language is to operate on digital assets, and the main qualities of this language are security and verifiability.
Move is designed to solve two problems: the representation of digital assets and their safe operation. A fundamental difference between EVM and Move is the data model of assets, EVM assets cannot be passed as parameters, returned from functions or stored in another asset. Whereas Move assets are arbitrary user-defined types, assets can be passed as parameters, returned from functions, and stored in other assets.
One of the main strengths of MOVE is data composability. It is always possible to create a new asset Y which contains the initial asset X. What's more, by adding generics, it is possible to define a generic wrapper Z(T) capable of wrapping any asset, providing additional properties to the wrapped asset or combining it with other assets.
Applications of the Move language
Both Aptos and Sui public chains are developed based on the Move language, but they have more in common:
The co-founders are both Diem and Novi teams from meta;
Both are Layer1 public chains;
They all try to use a chain to solve the "impossible triangle" of decentralization, security, and high performance.
Although linera did not expressly express that it was developed with Move, it only clarified that it was developed based on rust, but logically there is not much difference between the two, and it has the same origin as Aptos and Sui. The founder was also an infrastructure engineer of Diem and Novi. Therefore, these three public chains are also called meta public chains.
introduce
Aptos
introduce
Aptos is the earliest and best-developed project among the three meta public chains. The Aptos blockchain aims to create a high-throughput, low-latency underlying blockchain network that provides underlying network support for all participants in the ecosystem.
The founders of Aptos are all from the Diem and Novi teams of meta. Aptos is also built based on the open source technology and development experience accumulated in the Diem project. Among them, the two founders of Aptos, Mo Shaikh and Avery Ching, were deeply involved in the development of the Meta encryption wallet Novi.
features
features
MOVE language development
Aptos Move follows the original design principles of the Move language:
resource priority
In the blockchain, we need to access digital assets through programs. The resource of the Move language is specially defined for digital assets. The resource cannot be copied or destroyed implicitly. It can only be moved between different users. The module of the Move language is similar to the smart contract in Ethereum, and the module declares the resource type and process. The types and procedures defined in a module can be called by other modules.
flexibility
flexibility
Move language can freely combine various transactions to achieve different functions through transaction scripts, and one Move script can call multiple transactions.
The relationship of module/resource/procedure in Move language is similar to the relationship of class/object/method in object-oriented programming language.
safety
safety
After the bytecode compiled by Move is submitted to the chain, it will be verified by the bytecode verifier and then executed by the bytecode interpreter.
To help write more credible code, Move includes a type verifier, Move Prover, which can verify the functional correctness of Move programs according to a given specification. This type verification function has been integrated into the Move language.
The Move encoding system provides targeted security protection for resources. Move resources cannot be copied, reused or destroyed. A resource type can only be created or destroyed by the module that defines its type. The Move virtual machine will pass static bytecode verification and refuse to run programs that have not passed bytecode verification to ensure its security.
Verifiability
The Move language has multiple authentication methods. Usually, the best verification method is to submit the bytecode to the chain for real verification, but this will obviously increase the burden on the chain and affect the speed of transactions. Therefore, in Move, we do as much lightweight verification on the chain as possible, and do offline static verification at the language level.
Aptos Status Sync
State synchronization is a protocol that allows non-validating nodes to distribute, verify and persist blockchain data and ensure that all nodes in the ecosystem are in sync. Nodes in the Aptos network, including validators and full nodes, must always be synchronized to the latest Aptos blockchain state. The state sync component running on each node is responsible for this synchronization. To achieve this synchronization, state synchronization identifies and fetches new blockchain data from peers, verifies and persists the data to local storage.
Aptos state sync mode
Aptos Status Sync operates in two modes. All nodes will bootstrap at startup (bootstrap mode) and then keep syncing (continuous sync mode).
There are three boot modes:
Executes all transactions since genesis
Apply transaction outputs since genesis
Download the latest status directly
There are two continuous sync modes:
Execute the transaction
Apply transaction output
Aptos State Synchronization Architecture
The Aptos Status Sync component consists of four subcomponents, each with a specific purpose:
Driver: Synchronization progress. It is responsible for validating all data the node receives from peers. Data is forwarded from peers via data streaming services. After the data is verified, the Driver persists the data to local storage.
Data Streaming Services: Create data streams for clients that stream new chunks of data from peers without worrying about which peers own the data or how data requests are managed.
Aptos Data Client: The data client is responsible for processing data requests from the data streaming service. For a data streaming service that streams all transactions, multiple requests are made, one for each batch of transactions, and sent to peers. The data client accepts the request, determines which peers can handle the request and sends the request to them.
Storage service: The storage service is a simple storage API provided by each node, and peers obtain data through API calls.
Aptos Parallel Execution Engine
To achieve high throughput and low latency, the Aptos blockchain employs a pipelined and modular approach at key stages of transaction processing. Specifically, transaction propagation, block metadata ordering, parallel transaction execution, batch storage, and ledger verification all run concurrently. This approach makes full use of all available physical resources, improves hardware efficiency, and enables highly parallel execution.
Aptos blockchain realizes parallel processing from two aspects of data model and execution engine. Since the Move language data model itself supports global addressing of data and modules, Aptos uses the Move language to implement parallel execution of transactions. At the same time, a high-efficiency, multi-threaded, in-memory parallel execution engine Block-STM was designed and implemented, relying on Rayon, Dashmap and ArcSwap crates to achieve concurrency.
Parallel Data Model
The Aptos blockchain introduces a new concept, delta writes, which describe modifications to the account state rather than the modified account state (e.g. incrementing an integer rather than simply determining the final value). All transaction processing can be done in parallel, and then delta writes to conflicting values are done in the correct order to ensure deterministic results.
Over time, the Aptos blockchain will continue to enhance the data model by increasing concurrency (e.g., utilizing read/write hints) and improving the developer experience, allowing developers to create, modify and combine on-chain values more naturally . Move provides flexibility for language-level and platform-specific feature enhancements.
parallel execution engine
The Block-STM parallel execution engine detects and manages conflicts in ordered transactions, while performing optimistic concurrency control to achieve maximum parallelism in a specific order.
Batch transactions are parallelized using optimistic locks and verified after execution. Validation failures will result in a re-execution. Block-STM uses multi-version data structures to avoid write-write conflicts. All writes to the same location are stored with their version, which contains their ID and the number of times they were optimistically retried. When the transaction tx reads the memory data, it will obtain the transaction with the highest block height appearing before tx from the multi-version data structure in the preset order, and write the value of the transaction and its related version.
Block-STM has been integrated into the Aptos blockchain. To understand the performance potential of Block-STM, we use an in-memory database and treat meaningful (non-trival) peer-to-peer Move transactions (eg: 8 reads and 5 writes per transaction) as independent, execution-only (non-trival) end-to-end) benchmarks.
Aptos Consensus Protocol
Aptos implements the consensus mechanism through the Aptos BFT consensus algorithm. Aptos BFT follows Diem BFT and has carried out the fourth iteration based on it.
introduce
Sui
introduce
Sui is the earliest project in the Meta public chain, developed by the Mysten Labs team, and Evan Cheng, the founder of the Mysten Labs team, also left the Diem and Novi projects.
Sui aims to create an environmentally friendly, low-cost, high-throughput, low-latency permissionless blockchain. Compared with traditional blockchains, Sui's most critical innovation lies in Sui's data model and transaction processing channels.
features
features
1. Sui Move based on Core Move transformation
Sui object-centric global storage: In Core Move, global storage is part of the programming model and can be accessed through special operations such as move_to, move_from, and more global storage operators. There are no operations related to global storage in Sui Move, the storage only happens within Sui, and Sui explicitly passes all objects that need to be accessed to Move.
Addresses represent object IDs: In Move, there is a special type of address. This type is used to represent addresses in Core Move because Core Move needs to know account addresses when dealing with global storage. In Sui Move, the address type is used to represent the object ID.
Sui objects have globally unique IDs: in Core Move, keys can be used as global storage keys. Sui requires that any key-capable structure must start with an id field with an ID type. Sui uses a bytecode verifier to ensure that the ID field is immutable and cannot be transferred to other objects.
Sui's module initialization: The initialization function is executed by the Sui runtime when a module is published, with the purpose of pre-initializing module-specific data. The initialization function must have the following properties to be executed at publish time: the function name is init; the function must be of single-argument type; no return value; private function.
Sui takes object references as input: Sui provides entry functions that can be called directly from Sui, as well as functions that can be called from other functions.
2. Sui's data model and transaction processing channel
The founder of Sui pointed out: Sui's approach is to distinguish and organize data through "objects". A certain NFT, the balance of a certain token, and a certain smart contract are all different objects (which can be understood as types), which means that transactions on the Sui chain can be grouped and processed according to different objects.
All transactions in the conventional blockchain need to be sorted collectively and then executed. For Sui, all transactions will be distinguished, sorted and sorted according to a certain logic, and then executed. The data model can make the dependencies between different transactions clearer. Only the transactions of shared objects need to be sorted collectively, and the transactions of specific objects do not need this consensus negotiation process.
To sum up, although transactions of specific object types can be executed in parallel, transactions of shared object types can also be executed in parallel with each other, but each shared object needs to be executed sequentially. This architecture can simultaneously solve the following product problems:
Horizontal scalability: On Sui, each set of transactions is processed in parallel.
Composability: passing assets as arguments to functions, returning some kind of asset from the function, storing the asset in a data structure, or directly in another asset.
On-chain storage: asset-like data, such as game race, level, experience, etc., can be stored in Sui objects.
Partial replay capability: The blockchain provides a history of all transactions, and Sui's architecture allows these projects to only focus on the evolution of the objects they care about, ie partial replay.
3. Sui's two transaction consensus mechanisms
Sui's consensus mechanism is split into two parts: Narwhal (memory pool protocol) and Tusk (asynchronous consensus protocol), but in August 2022, Bullshark replaced the Tusk component of the consensus protocol as the default to reduce latency and support fairness. So it can be understood that Narwhal and Bullshark or Tusk constitute the Sui consensus engine.
Features of the Sui consensus engine (provided by Narwhal mempool)
A high-throughput data availability engine with cryptographic proof of data availability on a master node
A structured graph data structure for traversing this information
A scalable architecture that distributes disk I/O and network requirements to several workers
The consensus component provides a consensus algorithm with zero information overhead, using graph traversal
Sui Consensus Engine Architecture
A Narwhal instance sets up a messaging system consisting of stake units distributed among a set of nodes, and assumes that there is a computationally constrained adversary controlling the network that can disrupt parties holding f stake units. Validators cooperate to form a leaderless graph of batches of transactions - which the literature (in the context of DAG-based consensus) designates as blocks, which we label as sets - to emphasize that we are in a world where mempool data is unspecified The environment in which the consensus algorithm is used.
The vertices of the graph consist of authentication sets. Every valid set signed by its verifier-author must contain an integer and must itself be signed by a quorum of (2f+1) verifier stakes. We call these 2f+1 signatures availability certificates. Furthermore, this set must contain hash pointers to valid certificates from the previous round (i.e., certificates from validators with 2f + 1 units of stake), which form the edges of the graph.
Each set is formed in the following way: each validator reliably broadcasts each round's set. Under the stated validity conditions, if validators with 2f+1 stake receive a set, they will confirm it with their respective signatures. Signatures from 2f+1 validators form an availability certificate, which is then shared and possibly included in the set in rounds r+1.
The figure below represents five rounds (1 to 5) of such a DAG construction, in which authorities A, B, C and D participate. For simplicity, each validator holds 1 unit of stake. In A5, the set confirmed by A's latest round is represented by a full line in the figure.
Working Mechanism of Sui Consensus Engine
Graph structure allows more transactions to be inserted into the system per institution and per round
Certificates attest to data availability for each collection or block at each round
Their contents form a DAG that can be traversed identically on every honest node
While Bullshark or Tusk consensus selects a particular DAG traversal within a few posteriors, both they and external consensus algorithms can add more complexity in choosing blocks/sets to reflect priority issues.
Sui Consensus Engine Summary
Sui divides transactions into two types, one is a simple transaction, that is, the transaction has no complex interdependence with any other part of the blockchain state, and the other is a complex contract, that is, under this kind of transaction, the contract may benefit from Shared objects, where multiple users can alter these objects.
In simple transactions, Sui uses a simpler algorithm based on Byzantine consensus broadcasting, taking the approach of locking only for relevant data rather than the entire chain. In this case, the only information required is the sender address, and then only one transaction can be sent at a time.
text
4. Scalability of Sui
text
Linera
introduce
text
features
features
payment system. "The Linera blockchain aims to generalize and put this approach into production, enabling most account-based operations to be confirmed within a fraction of a second," linera's public information states. It can be seen that the positioning of linera is actually a payment system, not a general-purpose public chain.
low latency. Linera is committed to making web3 applications have the ultimate silky experience like web2 applications, and will no longer be troubled by network delays.
Linear scaling. The Linera project will develop and promote a new execution model suitable for linear scaling, so that operations of different user accounts can be executed in parallel in different threads. (temporarily unfinished)
Summarize
Summarize
first level title
2. Modular Blockchain with Celestia
What is "modularity"?
Modular blockchain is an innovation of blockchain architecture and an innovative solution to the problem of blockchain expansion. Before understanding the modular blockchain, we need to understand: what is "modular"?
In software engineering development, "modularization" refers to decoupling the code in the program, so that the functions of each module are independent, and the coupling between modules is low, so as to achieve the purpose of module reuse. The essence of "modularization" is a kind of "division of labor", and the program is an "organization"; different modules can be combined to form different programs.
For the blockchain, "modularization" is an alternative to the "monolithic" blockchain architecture. The architecture is layered according to the functions of each part of the blockchain; emerging blockchains only need to implement a certain layer functions to provide services for blockchains of other layers, without including the functions of all layers like a "monolithic" blockchain. The advantage of realizing "modularity" is to increase the decentralization of the blockchain and improve the throughput and capacity of the blockchain.
Architecture layering of blockchain
Regarding the layering of the modular blockchain, we can define it from the following aspects:
Security module: to ensure the security of the blockchain.
Execution layer: In the execution layer, a single transaction is executed and a state change occurs; for transactions of the same batch, the state root of the batch is calculated. The current mainstream execution layer solution is Rollup, which is known to us as StarkNet, zkSync, Arbitrum, and Optimism.
Settlement layer: the process of settling out state commitments, such as the Rollup contract on the main chain to verify the validity of the state root (zkRollup) or fraud proof (Optimistic Rollup).
Execution environment layer: Provides the execution environment of the blockchain.
Consensus layer: The consensus layer is to reach agreement on something in a distributed system, that is, to reach a consensus on the validity of state transitions. On the consensus layer, verifiers will reach a consensus on the order in which transactions occur, but verifiers do not care whether the transactions themselves are valid.
Data availability layer: This layer needs to solve the problem of "data availability", that is, to ensure that after a new block is generated, all the data of the new block is published on the blockchain. If it is impossible to prove that the data of the block is published on the blockchain, malicious transactions hidden in the block cannot be detected, and the blockchain is not secure.
The most representative product in the modular blockchain is Celestia, a POS (Proof of Stake) blockchain that provides a "pluggable" consensus layer and data availability layer. Before understanding Celestia in depth, let's take a look at the possible problems of "data availability".
Data Availability Issues
In a blockchain, each block consists of two parts.
Block header: This is the metadata of the block, including some basic information about the block, including the Merkle root of the transaction.
Transaction Data: This makes up the bulk of the block and consists of actual transactions.
There are generally two types of nodes in a blockchain network.
Full nodes (also known as fully validating nodes): These are the nodes that download and check the validity of every transaction in the blockchain. Setting up such a node requires a lot of resources and hundreds of gigabytes of disk space, but these are the most secure nodes because they cannot be tricked into accepting blocks with invalid transactions.
Light Client: If your computer doesn't have the resources to run a full node, then you can run a light client. Light clients do not download or verify any transactions. Instead, they only download block headers and assume blocks contain only valid transactions, so light clients are less secure than full nodes.
secondary title
proof of fraud
text
text
text
text
text
Using DAS allows light clients to verify that all data in a block is actually downloadable, so full validating nodes will be able to produce fraud proofs in case of any invalid transactions. Combining these techniques, we can rely on weaker security assumptions, leading to three situations:
Full nodes: Still the most secure solution, full nodes cannot be tricked into accepting invalid blocks.
Standard Light Clients: Because they don't validate blocks, they assume the majority consensus is honest.
Light Client + Fraud Proofs: We can now replace the honest majority assumption of state validity with a weaker honest minority assumption. You now only need a minimum number of light clients making enough sample requests so that together they can reconstruct the entire block.
text
text
text
text
text
text
text
text
text
In this new stack, Cevmos will serve as an optimized settlement layer, built on top of the Cosmos SDK, running a constrained EVM. It will be based on Evmos and host EVM's recursive Rollup (Rollup in Rollup) on top of it. This settlement layer itself will be a Rollup, so we can call it"Settlement Rollup"text
text
The current problem is that the Ethereum main chain is not optimized for Rollup settlements only, so Rollup settlements must always compete with other applications, which becomes expensive and unscalable. Cevmos' settlement Rollup will instead be subject to greater restrictions, only allowing:
Rollup smart contract: it has to handle verification of validity proofs and necessary disputes in order to host ZK and optimistic Rollups contracts on top of it
Simple transfer between Rollups
Because Cevmos settlement Rollups will be fully equivalent to EVM, you will be able to easily port and run your favorite EVM Rollups on top of it (Fuel, Optimism, Arbitrum, StarkNet, etc.).
In short, a complete Cevmos stack can include:
Celestia - Provides data availability at the bottom.
Cevmos Settlement Rollup - This Evmos based chain will sit on top of Celestia. It will be fully optimized as a settlement layer for EVM-based Rollup and placed on top of it.
text
Summarize
Celestia has several advantages over traditional solutions:
Scalability: By decoupling execution from consensus and data availability, Celestia is able to specialize and scale linearly as the number of nodes on the network increases, and the execution environment is free to optimize on top of it.
Simplicity: Celestia is a pluggable solution that aims to make deploying application-specific blockchains as easy as clicking a button. Potentially many blockchains will have a natural home on top of Celestia.
Shared Security: No more need for a separate chain to start its own security and validator set. Whether this is for an otherwise independent chain, or for Validium, which needs to start a data availability committee, the choices are far more difficult and the security concerns are fragmented.
first level title
text
Aztec
text
secondary title
text
text
text
text
secondary title
text
AZTEC gave up the bookkeeping method of account balance, and adopted the form of bill ownership conversion to ensure the confidentiality of transactions, in which the transaction value contained in AZTEC bills was encrypted. An AZTEC ticket consists of a set of elliptic curve coefficients and three scalars: a view key, a consumption key, and the ticket value. The view key can decrypt the ticket, revealing the transaction information, which can be used to create efficient zero-knowledge proofs based on discrete aggregation. These proofs are then signed by the consumption key, thereby enabling the transfer of value.
The discrete aggregate processing algorithm is used by the AZTEC protocol to achieve transaction confidentiality
The algorithm uses the destruction and reconstruction of a series of transactions to generate a new set of transactions that are very different from the original transaction value, and put them into the discrete aggregation transaction pool to confuse the true value of each transaction. For example, split 10E into 10 transactions of 1E within the AZTEC network\100 transactions of 0.1E within the AZTEC network\1,000 transactions of 0.01E in the AZTEC network and some combinations of above.
Of course, in order to realize this anonymization process, there needs to be enough assets in the AZTEC network to support the hypothetical transaction scenario. The AZTEC protocol needs to generate a set of total transactions far greater than the original demand transaction scenarios. The AZTEC protocol describes how to construct and verify the validity of discrete aggregation processing in zero-knowledge proofs, and guarantees that the address for decrypting the value of the note is not exposed, and the address for proving the "ownership" of the note will not be exposed.
Aztec Connect
The aforementioned AZTEC’s private transaction processing mode can only support Layer2-based transaction transfers. In order to realize the DeFi privacy interaction on Layer1, AZTEC has developed Aztec Connect to aggregate transactions on Layer2 to Layer1 through a gateway. When an Aztec user wants to transact with the protocol, the transaction will interact with the first-layer protocol on the Ethereum mainnet through Aztec Connect in a completely anonymous manner.
The interaction between AZTEC protocol and traditional public digital assets such as ERC20 token standard
The AZTEC protocol can interact with traditional digital assets of the same underlying blockchain as the AZTEC protocol. This protocol can be used to define two different types of digital assets: fully anonymous assets (represented only by optimized AZTEC notes) and public\private assets. The AZTEC protocol can convert public ERC20 values into AZTEC bills, or transfer AZTEC bills back to ERC20.
Anonymity of the AZTEC protocol
The AZTEC protocol supports confidential transactions, where the information of a single note is encrypted. At the same time, by combining confidential zero-knowledge transactions with address anonymity algorithms, complete anonymity of transactions can be provided.
Efficiency Analysis of AZTEC Protocol
In AZTEC's current technical paradigm, the cryptographic system known as UltraPlonk (an optimized Plonk algorithm developed by AZTEC that enables efficient lookup commands in Plonk logic circuits) costs about 550,000wei to issue proofs to Ethereum, About 30% cheaper than when AZTEC’s original product, zk.money, was first launched. The current system's single transaction summary has also expanded from 112 to 896, and the throughput has achieved an 8-fold increase.
The working method of AZTEC when the single throughput is 112 items is:
The browser client generates a proof
Then aggregate the 28 client proofs into one internal Rollup proof
Then aggregate the 4 inner Rollup proofs into one outer Rollup proof
This "external" rollup proof is then verified in the logic of the root rollup - the logic that ensures the validity of all underlying work.
Put the final proof on the chain.
AZTEC officially believes that its Aztec Connect software development kit can save up to 100 times the cost of Ethereum DeFi services while providing complete privacy protection. Moreover, with the reduction of verification costs and the further expansion of zkRollup aggregation scale, data communication costs will account for nearly 100% of transaction costs in the future.
The future of AZTEC
The AZTE protocol provides good privacy for private transactions, and at the same time has the characteristics of low cost. At the same time, AZTEC also achieves good auditability and compliance through programmable private systems.
AZTEC is still working hard to explore the extended functions of the protocol, such as trying to provide private decentralized exchanges, private weighted voting, and anonymous identity sharing schemes. Combined with the above extended functions, the AZTEC protocol can provide the tools developers need to create the next generation of private decentralized financial service facilities, and build digital assets with absolute privacy and private governance.
Aleo
Aleo is a platform for fully data-private applications that aims to build a private user experience based on zero-knowledge cryptography. Aleo achieves this by utilizing a decentralized system and zero-knowledge encryption to protect user data on the network. At its core, Aleo is to provide computing services with absolute privacy for users and application developers.
Specifically, based on zero-knowledge cryptography, Aleo can help users own data privacy instead of companies controlling data to obtain benefits. This not only allows users to have ownership of data, it is also defining the user's digital identity so that users can decide the application and sharing of data to obtain more private and personalized services.
Aleo core technology
LEO language
The Aleo team has developed Leo, a statically typed programming language inspired by Rust, which emphasizes the readability and ease of use of the language. The Leo language can intuitively express logic with zero knowledge, allowing developers to intuitively build applications with privacy and decentralization properties on the Aleo public chain.
AleoStudio
AleoStudio is an IDE developed by Aleo specifically for zero-knowledge proofs, which mainly provides development environment support for privacy track developers.
zkCloude：
The Aleo development team built a component that forms the basis for a more secure, private and personalized paradigm for Aleo applications. The point-to-point, decentralized private computing model established by Zkcloud can even ensure that shielded identities can interact directly (such as in asset transfers) or programmatically (through smart contracts) to interact with decentralized private computing, thereby achieving privacy protection the goal of. It is only necessary to be clear in the research:
zkCloud is the cornerstone of a new model of peer-to-peer, decentralized, private computing that can be run locally or delegated to a dedicated prover.
zkCloud enables programmatic interaction between protected identities, such as users, organizations, DAOs, etc.
These interactions occur through shielded transactions that provide cryptographic proofs that a given program was executed correctly.
These transactions are submitted to the Aleo blockchain which updates the global state and anchors the activity on zkCloud and provides decentralized and censorship-resistant data availability guarantees
Among them, the shielded transaction is a basic form first created by Zcash. But shielded transactions in Aleo are more than just asset transfers. They describe various user-to-user or program interactions, including liquidity provisioning, governance voting, authentication, decentralized notifications, and more. Because only the interacting parties know the details of the transaction, third parties cannot learn the details of that interaction or exploit it in any way when doing evil.
4. AleoBFT
AleoBFT is a new consensus hybrid architecture. During the operation of Aleo Testnet 3, Aleo will transform its consensus model into a hybrid architecture for provers and verifiers, called AleoBFT. First, AleoBFT guarantees instant finality for each block. Second, AleoBFT ensures that the network remains fully decentralized. Third, AleoBFT incentivized proofs will expand the proof capacity of the Aleo ecosystem over time.
Aleo Consensus Mechanism——PoSW
Aleo's blockchain network consensus mechanism is provided by SNARK-based Proof-of-Succinct Work. PoSW is a variant of Bitcoin's mining difficulty adjustment mechanism based on SHA. The main difference is that its underlying calculation is not a hash function, but a proof of knowledge.
POSW principle:
Aleo Token Economics
When considering token economics, the Aleo team has strict requirements for the following attributes:
The network's native token represents meaningful value
The system incentivizes participants on the network to contribute to its security
Incentives do not encourage dishonesty or any mischievous behavior
It facilitates the development and use of an ecosystem of useful applications
It facilitates decentralization so that no single party can control the entire system
The name of Aleo's token is called Aleo credits, and the total amount of tokens: 1 billion. The two images below show Aleo's token distribution and mining output schedule.
The figure below shows the inflation curve of the Aleo token. It can be seen that the Aleo team is trying its best to find a balance so that the token can maintain the normal operation of the Aleo chain without causing infinite inflation.
Aleo's future
first level title
secondary title
AltLayer
secondary title
Introduction to AltLayer
Project and team introduction
Altlayer is mainly aimed at the staged high scalability requirements of dApps. It is a pluggable, on-demand loading, and customized execution layer system for a single application. AltLayer is a temporary extension layer based on Optimistic Rollups, which can meet the needs of one-time use and share the security of Layer 1 or Layer 2, bringing engineers a highly flexible execution environment and achieving a high degree of resource optimization.
AltLayer is led by Dr. Yaoqi Jia, former director of Parity Asia, co-founder and CTO of Zilliqa. Announced on July 1, 2022 that it has completed a $7.2 million seed round of financing led by Polychain Capital, Breyer Capital and Jump Crypto. At present, AltLayer's test network has been prepared, and it is planned to launch a test network that fully supports EVM in Q3 this year.
Project features
Altlayer can obtain its security directly from Layer 1 or recursively from Layer 2. It is regarded as a Layer 3 protocol. The main features are as follows:
Meet the personalized needs of dApp
High resource optimization
modular design
high elasticity
secondary title
Why do we need AltLayer - the pain point of NFT mint scene
Pain points
One of the applicable scenarios of AltLayer is NFT mint event. Since NFT is usually limited in supply, each NFT mint event will have a short-term surge in high TPS demand, and at the same time bring a large number of transaction failures and network congestion. In the past, Universal Chain provided a model of shared block space, which often resulted in a popular dApp consuming too much block space, while users of other dApps suffered from poor user experience due to high fees and settlement time. good.
solution
solution
In fact, many NFT projects do not need a long-term dedicated block space, but only need to occupy block space for a short time. Therefore, AltLayer's elastic expansion solution can better meet the network needs of the NFT project Mint period, and will not bring long-term sustainable burden. It effectively avoids the problem that frequently used dApps will compete with a large number of unused dApps for block space.
AltLayer meets the more specialized and customized needs of dAPPs and helps them choose resources more flexibly, instead of competing with other dApps for limited resources in the layer network, thereby providing a better user experience.
Realize
When dApp expects to have a very large access demand and Layer 1 cannot undertake it, Flash Layer will be called. Once the demand gradually decreases, the dApp will migrate back to the first-tier network. This highly elastic solution makes the resources of the entire system highly optimized. Flash Layer assigns each NFT item a Mint-specific execution layer. Since the block space is reserved for the project, it means that the mint event can be completely isolated from any other on-chain activities, so that it will not cause network congestion, and the NFT project will not generate GAS during the mint process. In addition, Flash Layer comes with a high-throughput execution environment capable of delivering 2000 TPS of dedicated throughput and low latency of 1-2 seconds for a smooth experience.
The specific path is as follows:
1) Quickly launch a Rollup solution that is secured by a layer of network (such as Ethereum);
2) Make reasonable use of the Rollup solution to prevent space congestion in the first-tier network;
3) End the invocation of the Rollup solution by performing an "end-of-life" settlement procedure on the first-tier network.
Project Benefits
Automatic expansion: When the NFT mint event ends, the system will settle all assets on the Base-chain. Unlike solutions that require users to manually bridge assets, automated settlement ensures that all NFTs are moved to the Base-chain without any user intervention, eliminating any security risks associated with bridging
Multi-chain support: EVM and WASM are supported by default
Full Liquidity: All NFTs are transferred to the Base-chain at the end of Mint, thus ensuring that secondary market participants do not have to hop from chain to chain to find the NFT they wish to buy
References:
References:
The Arrival of Stealth Trading: A Deep Dive into the AZTEC Protocol
Realization of Private Transactions: Introduction to Aztec Privacy Architecture
Introduction to the AZTEC Agreement
Privacy for Pennies: Scaling Aztec's zkRollup --- How Aztec Reduces Transaction Fees
UTXO VS. ACCOUNT MODEL
Digital Privacy and Zero-Knowledge Proofs
How Zero Knowledge is Rebalancing the Scales of the Internet
What does Transparency Cost You?
The Future of Zero Knowledge with Aleo
Aleo core technology
Zero Knowledge Primitives by Aleo
zkCloud: Decentralized Private Computing
Aleo Introduction and Token Distribution
Discover Aleo
Aleo Token Economics
Introduction of Aleo, the popular privacy public chain
Aleo - The Future of Privacy Tracks
Multi-Aspect Analysis - Aleo Value and Future
Celestia — The Foundation of a Modular Blockchain World
Foresight Ventures: "Combined for a long time must be divided" modular blockchain and data availability layer
IOSG Weekly Brief | Dismantling the Data Availability Layer: An Overlooked Lego Brick in a Modular Future #136
-------------------------------
Disclaimer: Readers are requested to strictly abide by local laws and regulations. The above content does not constitute any investment advice.
Author: Medici Larissa Ken Mindy
Proofreading: Medici Typesetting: Teacher Qiu
