New Blockchain Protocol: Combining DAG Consensus and Non-Consensus Methods to Achieve High Throughput and Low Latency

Blockchain technology has made significant progress since the birth of Bitcoin. With the emergence of new application scenarios such as gaming and NFTs, the industry is actively exploring ways to improve technological efficiency, especially in handling high loads and achieving real-time latency. Currently, L1 blockchains face two main challenges: first, how to achieve high throughput while maintaining low latency, and second, ensuring the long-term stability of the consensus protocol. In addressing these issues, it is also necessary to maintain decentralization through the dynamic participation and reconfiguration of validation nodes.

One way to increase throughput is to adopt a DAG-based consensus protocol, such as narwhale/Bullshark used by a certain blockchain project. Such protocols allow the blockchain to handle a large number of transactions simultaneously, making them very suitable for applications like gaming and NFTs. However, DAG-based protocols often introduce a latency of several seconds, which is a high time cost for ordinary transfers or gaming operations.

On the other hand, consensus-free protocols ( like FastPay ) show great potential in reducing latency and scalability. These protocols allow for fast transaction processing by eliminating the need for consensus, without the need for global ordering of independent transactions that are processed in parallel. However, they are limited to a class of constrained simple blockchain operations, which restricts the achievable smart contract functionalities, and dynamically adjusting the validator set may pose challenges.

Although these methods have potential, they have not yet been widely applied in production-grade blockchains and are limited to presentations at academic conferences. The protocol adopted by a certain blockchain project combines DAG-based consensus and non-consensus methods to achieve the advantages of both: sub-second latency and sustained throughput of thousands of transactions per second. This project has not only accomplished these two tasks but also maintained the ability to execute complex contracts on shared objects, generate checkpoints, and reconfigure the validator set across periods.

The protocol adopts a unique approach that combines the two aforementioned schemes. To ensure the security of the operations of the singular owner asset (, namely the object ), a consistent broadcasting protocol is employed between validators, thereby achieving latency below consensus. The protocol relies solely on consensus to handle complex smart contracts running on shared objects, which are objects that any user can modify. At the same time, it also supports network maintenance operations, such as defining checkpoints and reconfiguring validators. When processing transactions in a replicated Byzantine environment, this innovative strategy provides a solution that balances the advantages of both aspects.

In this protocol, users with private keys create and sign transactions to change their owned objects or a combination of their owned objects and shared objects. Transactions are sent to each validating node ( usually through a full node ). The validating nodes perform a series of validity and security checks, sign the transaction, and return the signed transaction to the client. The client collects responses from the vast majority of validating nodes to form a transaction certificate, at which point the transaction can be considered irreversible ( achieving finality ).

After the certificate assembly is completed, it will be sent back to all validating nodes, which will verify its validity and confirm receipt to the client. If the transaction only involves exclusive objects, the transaction certificate can be processed and executed immediately without waiting for the consensus engine ( direct fast path ). All certificates are forwarded to the DAG-based consensus protocol. The consensus ultimately outputs the total order of the certificates; validating nodes check and execute those transactions that involve shared objects, and the client can collect responses from the vast majority of validating nodes, assemble them into an effect certificate, and use it as proof of transaction settlement. Subsequently, consensus submissions form checkpoints, which are also used to drive the reconfiguration protocol.

In addition to the main trading process, the protocol also offers multiple functions to support production-level Blockchain:

1. Implement checkpoint protocols after achieving finality, generating the causal history of all transactions in the system. This is used for complete auditing and for efficiently keeping full nodes and latency validation nodes in sync.

2. Support reconfiguration at the end of each epoch, during which the set of validators and their voting power may change. To ensure that all final transactions are included in an epoch, each epoch needs to be carefully closed and confirmed for final safety.

3. Safely "unlock" incorrectly locked assets at the end of the period, minimizing damage caused by potential client double-spending vulnerabilities.

This protocol supports the management of a large value Blockchain. The complete technical report details the operational principles of the security and liveness protocols, as well as their security proofs with partially synchronous Byzantine participants in the standard distributed system model.