A Hybrid, self-accounting blockchain system
Author: Hrwsy
Summary
This paper proposes an innovative hybrid, self-accounting blockchain system architecture, which aims to break through the “impossible triangle of blockchain” limitation and achieve the unity of decentralization, security and high throughput. The system adopts a two-tier structure of Account Chain (AC) and Service Chain (SC), each account maintains an independent chain, and the service chain is responsible for global consensus and state coordination. Combining zero-knowledge proof (ZKPs), asynchronous processing and improved PoW-PoS hybrid consensus mechanism, the system significantly improves transaction processing capacity while ensuring security. This paper describes the system architecture, consensus mechanism, transaction process, economic model and anti-attack strategy in detail, which provides a feasible technical path for the next generation of high-performance blockchain system.
Key words: blockchain; self-accounting; zero-knowledge proof; hierarchical consensus; account chain; service chain; dynamic fragmentation; data availability; Anti-quantum cryptography
1. First principles
1.1. The essential characteristics of blockchain.
1.1.1. Decentralization;
1.1.2. Point-to-point;
1.1.3. Non-tampering;
1.1.4. Freedom and openness;
A trusted system should have the characteristics of extreme decentralization, peer-to-peer technology, data tamper-proof, free and open, etc.
1.2. The limitations of blockchain
Impossible triangle: It is difficult for blockchain to achieve decentralization, security and high throughput at the same time;
State explosion problem.
1.3. Basic principle of the system
1.3.1. Trust assumption: nodes and environments are trusted by default unless they can be proved to be evil (based on cryptography and economic incentives);
1.3.2. Self-bookkeeping right: each account maintains its transaction history independently and has full control;
1.3.3. Verification efficiency: The validity verification does not rely on the repeated computation of the whole network, but realizes lightweight verification through ZKPs and state commitment;
1.3.4. Asynchronous processing: Decouple transaction processing and consensus, support concurrent and asynchronous submission, and significantly improve TPS;
1.3.5. Zero-knowledge proof reliability: ZKPs for transaction integrity, state transition correctness, and privacy protection.
2. System architecture
2.1. Account chain
2.1.1. Account classification
a. External account
User control, requiring private key signature transaction;
b. Internal account
Smart contract account, controlled by code;
The contract is also an account chain.
2.1.2. Account chain
a. Each account chain is a one-way hash chain, which only records the transactions related to the account;
b. Support Recursive ZKPs to realize fast state verification;
c. Metadata space: to be determined, shared by account chain and service chain;
d. Hybrid Vector Clock: Combines logical timestamps (vector clocks) with service chain physical timestamps to address cross-chain transaction sequencing and consistency.
e. Account chain registration
When the account is traded for the first time, it needs to register with the service chain and assign a unique sequence code, that is, there is a fixed sequence for the whole network account.
To prevent spam and improve resource utilization, each account must have a token lock of N X.
f. Storage of the account chain
The service chain data is permanently in the chain;
Account chain data is stored in decentralized storage, and data is stored in cold and hot storage.
2.2. Service chain
2.2.1. The service chain does not process each specific transaction;
2.2.2. The service chain ensures the integrity and traceability of the block;
2.2.3. The service chain maintains the global state;
2.2.4. Service chain ensures the effectiveness of consensus;
2.2.5. The service chain maintains the world state tree composed of the metadata space of each account chain.
2.3. Node
The node is free to join and quit;
Nodes need to self-lock N Dtokens to participate in computing power competition;
N Kis weighted and dynamically adjusted according to the number of nodes, transaction costs and the total amount of coins.
In the era, the node cannot exit or go offline at will. The node can apply for exit. It will not participate in POW in the next era. After the current era status is determined, it will exit completely. After exit, there will be a cooling-off period.
2.4. Transaction
2.4.1. Deal Build:
a. Account A → Account B, operation status X;
b. Sender identification and signature;
c. Nonce (vector clock version, replay-proof and concurrency support);
d. Details of estimated expenses;
e. Optional data field.
2.4.2. Transaction process
Step 1: Transaction Initiation and Construction
a. The client (wallet) initiates the transaction;
b. Broadcast to nearby nodes, and the nodes forward to the hosting node;
c. The managed node verifies the validity of the operation status X;
d. Execute action X;
e. Generate ZKPs;
f. And sen that data to the marked macro node;
Step 2: Service chain consensus and ranking
g. Packed into Slot;
h. Pre-consensus of the improved avalanche protocol: The large nodes in the network pre-confirm the transaction list based on the improved avalanche protocol. Nodes do not pass specific transaction data, but pass the vote of “transaction list hash” and the corresponding ZK proof batch verification results.
i. Physical timestamp anchoring: The list of transactions that have reached pre-consensus and their hashes are given a service chain physical timestamp and wait to be included in the next POW epoch.
Step 3: Final confirmation and state root snapshot
j. POW epoch confirmation: Every 10 minutes, the POW big node completes mining and generates a new service chain checkpoint block. The block contains:
-Merkle root hash of all account chain state roots.
-Hashes of multiple transaction lists produced by the previous pre-consensus phase and their physical timestamps.
-New account registration information.
k. Global Status Update: The validation of this service chain block means that all transactions referenced in the block have achieved absolute finality. At this point, the global status is officially updated.
Step 4: Asynchronous bookkeeping of account chain
l. Book-to-account chain: After the transaction is finalized, the relevant escrow node or the node run by the user itself asynchronously appends the transaction to the personal account chain of the sender and receiver.
m. Update the hybrid vector clock: Each account chain will update its own hybrid vector clock to associate the logical timestamp of this transaction with the physical timestamp of the service chain block, so as to establish a globally understandable timing relationship for all transactions.
n. Update metadata: The metadata of the account chain (such as the state root) is updated, and the new state root will be synchronized into the world state tree of the service chain through the next POW.
2.5. POW-POS Consensus
2.5.1. POW
a. POW every 10 minutes, called epoch;
b. POW elects the first 20% of computing power as large nodes and the last 80% as small nodes;
c. POWPOW is responsible for global state check and fragment allocation, and generates a checkpoint block every 10 minutes, which contains the state root snapshot of all account chains;
d. POW is used to verify the layering;
e. Timing and method of POW campaign: start POW campaign when the time slot reaches 80%;
f. Introduces “finality tools” to ensure cross-epoch state consistency.
2.5.2. POS
a. POS is carried out every 6s, which is called time slot;
b. Every 100 time slots is an epoch.
2.5.3. Separation of execution, consensus, and validation
Large and small nodes do different things efficiently;
At the end of each POW, publish the number of size nodes and the list to each node.
2.6. Block
2.6.1. Service chain block
To be determined
2.6.2. Account chain block
To be determined
3. Other components
3.0.1. Decentralized hosting network
a. The user can self-host or entrust the node to host the account chain;
b. The contract chain is automatically accompanied by hosting and supports stateless clients;
c. Seamless handover is realized through state transition proof when the node is switched.
3.0.2. Parallel Virtual Machine Based on ZK
a. Support for WASM and ZK-Friendly instruction sets;
b. Execute the transaction in parallel to generate a state transition certificate;
c. ZK-Rollups and Validium modes are introduced to improve throughput.
3.0.3. Network and communication
a. LibP2P is used for node communication, and gossip protocol and state synchronization are supported;
b. The delay network model is introduced to adapt to the asynchronous network environment.
3.0.4. World state tree
a. Use Verkle Tree to reduce proof size and verification cost;
b. Supports state history archiving and snapshot download.
3.0.5. Improved PoW mechanism
a. A hybrid algorithm of Ethash + and RandomX is introduced to resist ASIC centralization.
b. Support green mining and encourage the use of renewable energy.
3.0.6. Anti-quantum computing
a. Integrating post-quantum cryptography algorithms such as NTRU and Kyber;
b. The account signature and ZK proof system support quantum security.
3.0.7. Storage optimization
a. Use Erasure Coding and Data Availability Sampling (DAS) to ensure data availability;
b. Support state expiration and archiving to reduce node-wide storage stress.
3.0.8. Anti-censorship mechanism
a. The transaction is broadcast via Dandelion + + protocol, confusing the source;
b. Support privacy transactions and stealth addresses.
3.0.9. Special Zero Knowledge Proof (SZK)
a. Support recursive proof systems such as Plonky2 and STARK;
b. The Proof Carrying Data (PCD) architecture is introduced to implement cross-chain state verification.
3.0.10. AI Agent and Oracle
a. AI Agent for Dynamic Cost Market and Incentive Adjustment;
b. Decentralized oracle provides off-chain data input, supports conditional execution and complex contracts.
4. Incentives
4.0.1. Token economics
A fixed total of 1 trillion;
The release is periodic, with a period of every 1000 days.
4.0.2. Economic Protection
Large nodes get 20% -40% of the coins and 80% -60% of the transaction costs.
Small nodes get 80% -60% of the coins and 20% -40% of the transaction costs.
Adjust dynamically according to that fix time of the network state;
Specific token economics to be determined.
5. References
5.1. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
5.2. Buterin, V. (2014). Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.
5.3. Rocket, K., et al. (2018). Scalable and Probabilistic Leaderless BFT Consensus through Metastability. arXiv:1906.08936.
5.4. WebAssembly Community Group. WebAssembly Specification.
5.5. Ben-Sasson, E., et al. (2014). Zerocash: Decentralized Anonymous Payments from Bitcoin. IEEE S&P.
5.6. Buterin, V. (2021). An Incomplete Guide to Rollups.
5.7. Matter Labs. (2022). zkSync: The Missing Piece of the Blockchain Puzzle. zkSync Documentation.
5.8. Buterin, V. (2021). Verkle Trees. Ethereum Research.
5.9. The Ethereum Foundation. (2018). Ethash: Ethereum Proof-of-Work Algorithm. Ethereum Wiki.
5.10. Techet, J., et al. (2019). RandomX: Proof-of-Work for General Purpose CPUs. arXiv:1910.10334.
5.11. National Institute of Standards and Technology (NIST). (2022). Post-Quantum Cryptography Standardization.
5.12. Al-Bassam, M., et al. (2018). Fraud Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. arXiv:1809.09044.
5.13. Celik, A., & Yu, X. (2022). Data Availability Sampling in Ethereum. Ethereum Protocol.
5.14. Fanti, G., et al. (2019). Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees. Proceedings of CCS.
5.15. Polygon Zero. (2022). Plonky2: Fast Recursive Arguments from Plonk and FRI. GitHub Repository.
5.16. Ben-Sasson, E., et al. (2018). STARKs: Scalable Transparent Arguments of Knowledge.
5.17. Chiesa, A., et al. (2020). Proof-Carrying Data from Accumulation Schemes. TCC.
5.18. Szabo, N. (1997). Formalizing and Securing Relationships on Public Networks. First Monday.
5.19. Tschorsch, F., & Scheuermann, B. (2016). Bitcoin and Beyond: A Technical Survey on Decentralized Digital Currencies. IEEE Communications Surveys & Tutorials.
5.20. Hearn, M., & Spilman, J. (2016). The Bitcoin (XT) Thin Block Protocol.
5.21. Micali, S. (2017). ALGORAND: The Efficient and Democratic Ledger. arXiv:1607.01341.
5.22. Yin, M., et al. (2019). HotStuff: BFT Consensus with Linearity and Responsiveness. PODC.
5.23. Golan Gueta, G., et al. (2019). SBFT: A Scalable and Decentralized Trust Infrastructure. DSN.
5.24. Gentry, C. (2009). Fully Homomorphic Encryption Using Ideal Lattices. STOC.
5.25. Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM.
5.26. Eyal, I., et al. (2016). Bitcoin-NG: A Scalable Blockchain Protocol. NSDI.
5.27. Wood, G. (2014). Ethereum: A Secure Decentralised Generalised Transaction Ledger (Yellowpaper).
5.28. King, S., & Nadal, S. (2012). PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake.
5.29. Kiayias, A., et al. (2017). Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. Crypto.
5.30. Buterin, V., et al. (2022). Combining GHOST and Casper. Ethereum Research.
5.31. Protocol Labs. (2017). Filecoin: A Decentralized Storage Network. Filecoin Whitepaper.
5.32. Kokoris-Kogias, E., et al. (2018). OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding. IEEE S&P.
5.33. LibP2P Team. (2022). LibP2P Specification. https://libp2p.io/
5.34. Dwork, C., Lynch, N., & Stockmeyer, L. (1988). Consensus in the Presence of Partial Synchrony. Journal of the ACM.
5.35. Ellis, S., Juels, A., & Nazarov, S. (2017). Chainlink: A Decentralized Oracle Network. Chainlink Whitepaper.
5.36. Bentov, I., Gabizon, A., & Mizrahi, A. (2016). Cryptocurrencies Without Proof of Work. FC.
5.37. Teutsch, J., & Reitwießner, C. (2017). A Scalable Verification Solution for Blockchains. TrueBit Whitepaper.