Logical layering |
Bitcoin |
Aether Square |
Application (Contract) layer |
Bookkeeping, transfer |
EVM, Dapp |
Excitation layer |
Mining, trading |
Release, distribution mechanism |
Consensus layer |
Workload |
Pow,pos,dpos,pbft |
Network layer |
P2p |
Peer, communication mechanism, verification mechanism |
Data layer |
Chunk data, chained structure, digital signature hash function, Merkle tree, asymmetric encryption |
Chunk data, chained structure, digital signature Optimization of hash function, Merkle tree, asymmetric encryption, etc. |
Split Fork
Soft fork and hard fork (forward compatible, backwards compatible)
User Balance
The UTXO model unspent the Transaction output, which represents the outputs that were not spent.
Account model records account balances.
Utxo Advantages Privacy is relatively strong, in theory you can set an address for each output. There is no need to maintain status values such as balances. Utxo is an independent data record that can be greatly enhanced by parallel transaction verification speed of the blockchain. No need to worry about transactional issues, just care about the output script. Utxo cannot be split, each transaction requires multiple outputs, respectively, for expenses and change. The advantage of the account model is the ability to quickly get the balance of an account, and Bitcoin needs to integrate the total amount of unused transactions in all Utxo owned by the specified address. Save space because there is only one input per transaction. It is easy to implement a Turing-complete smart contract.
Peer Network Peer principle
NAT Network Address Translation
Nat principle and NAT penetration
Data Validation
SPV Simplified Payment Verification Simple payment Verification
Merkle Tree algorithm
BASE58 based on BASE64 upgrade
SHA256 Secure Hashing algorithm
Asymmetric encryption
consensus algorithm
Pow:power of work indicates workload (public chain)
Pos:proof of Stake, equity certificate (public chain)
dpos:delegated Proof of Stake, certificate of Entitlement to appointment (public chain)
Pbft:practical Byzantine Fault tolerance, practical Byzantine Fault tolerant algorithm (alliance chain private chain)
Raft,paxos protocol
Reference: Consensus algorithms
Bitcoin transaction data structure
The transaction history of the data block details the bitcoin transactions and related details. In the details of bitcoin revenue and expenditure, the Bitcoin address and the value of the Merkle node are recorded, so the details of revenue and expenditure are the most important part of the transaction record.
The complete transaction structure is shown in the following table:
Version Change process
Structure of Bitcoin spending and receiving transactions
In the data block, the Bitcoin expenditure and the received transaction are written together, and the entire revenue and expenditure record includes a lot more than the record. Each record has its own index number for querying.
Each record includes details such as the build time, the hash value of the reference transaction, the transaction index number, the Bitcoin expense address, and the number of expense addresses. Each revenue and expenditure transaction has a Merkle node value, which is part of the entire Merkle tree, which determines that each address cannot be duplicated and forged.
The structure of revenue and expenditure transaction is as follows:
data block Structure Hexdump program to convert the data block file into a hexadecimal +ascii representation, the editor explains: each data block recorded six content: Magic number, chunk size, data block header information, transaction count, transaction details. In this, the hash value of the header information of the data block is the reference target number of the hash value of the next new district block, and the last transaction detail records all the transactions in the block (the editor will elaborate on the structure of the transaction later).
The data block structure is shown below:
Data Block Header structure
The header structure of the data Block records: Version number, record of the previous chunk, root value of Merkle tree, timestamp, target eigenvalue, random number.
The process of mining in a Bitcoin miner is the process of generating a new chunk of data, which requires a comparison of the hash and random numbers in the head of the previous data block, and a new chunk if certain conditions are met. The root value of the Merkle tree is the hash value of the root node of all recorded transactions in the block, and the Nakamoto uses a hash tree to digitally sign each transaction to ensure that each transaction is not counterfeit and does not repeat the transaction, Merkle tree is a hash tree. The head structure of the data block is shown below: