Blockchain development Guide blocks and transactions for the blockchain base

In a blockchain network, all of the data is recorded as chunks on each node. Each chunk is saved in a separate file on the local disk of the node, and all the chunk information in the Bitcoin (Linux system) is stored under the ~/.bitcoin/blocks/directory and marked with the Blk***.dat file name, as shown in the following image:

Block Structure

As described by Https://en.bitcoin.it/wiki/Block, the structure of the block is as follows:

Field	Description	size
Magic No	"Magic number", Constant 0XD9B4BEF9	4 bytes
Blocksize	Chunk size	4 bytes
Blockheader	Block size	bytes
Transaction counter	Number of transactions, positive integer	1-9 bytes
Transactions	Trade list	-many transactions

The first is a "magic number", according to the description this is a constant of 4 bytes, then 4 bytes of chunk size, then the chunk header 80 bytes, then the number of 1-9 bytes of trade, and finally all the trades. But it's not so defined in the actual bitcoin code,

Class Cblock:public Cblockheader
{public
:
    //Network and disk
    std::vector<ctransactionref> VTX;

    Memory only
    mutable bool fchecked;

    // ...

    Cblockheader Getblockheader () const
    {
        Cblockheader block;
        Block.nversion       = nversion;
        Block.hashprevblock  = Hashprevblock;
        Block.hashmerkleroot = Hashmerkleroot;
        Block.ntime          = ntime;
        Block.nbits          = nBits;
        Block.nnonce         = nnonce;
        return block;
    }

    std::string ToString () const;
};

It can be found that actually only defines the block size and all transactions, perhaps different versions of the difference, but look at GitHub on the previous version of the Bitcoin code also does not define the above table variables, so personally think the actual structure should be defined in the code.

Take a look at the structure of the block head, Https://en.bitcoin.it/wiki/Block_hashing_algorithm

hashprevblock td> time interval from 1970-01-01 00:00 UTC to now, in seconds

Field	purpose	update time	size (Bytes)
version	block version number	upgrade software and specify a new version number	4
The 256-bit hash value of the previous chunk	generates a new chunk	+
hashmerkl Eroot	merkle root 256-bit hash	received new transaction	+
time	per second	4
Bits	when The compressed form of the target hash of the former POW	difficulty adjustment	4
Nonce	32-bit random number	when trying a new hash	4

Each chunk header contains the hash value of the previous chunk, so all chunks are linked as a chain, and the head of the chain is the Genesis block (Genesis blocks). All trades are indexed in the form of Merkle tree, and the root of the Merkle tree is saved in the block header, and if the current number of trades is odd, the last trade will be computed twice. The difficulty of the current POW is stored in compressed form in bits of 4 bytes, and the last Nonce is recorded by the random number found by mining. Trading Structure

For bitcoin transactions, a better reference is the official Bitcoin document Https://en.bitcoin.it/wiki/Transaction, which is explained in detail.

Trading is the most basic data structure transmitted in the blockchain network, and all valid transactions are eventually packaged into chunks and stored in the blockchain, and the data structure of transactions in Bitcoin is as follows.

Field	Description	size
Version No	Version number, currently 1	4 bytes
In-counter	Enter the number of trades, positive integers	1-9 bytes
List of inputs	Input list, the first trade in each chunk is called "Coinbase"	-many Inputs
Out-counter	Output trade quantity, positive integer	1-9 bytes
List of outputs	Output list, the first output trade in each chunk is a reward for miners	-many outputs
Lock_time	Lock time, if not 0 and less than 0xFFFFFFFF, then refers to the block sequence number; If the transaction is terminated, then it means a timestamp.	4 bytes

A simple trade entry is as follows:

Input:
Previous tx:f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
index:0
SCRIPTSIG:304502206E21798A42FAE0E854281ABD38BACD1AEED3EE3738D9E1446618C4571D10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

The first is the hash value of the previous transaction (Previous TX), then the number of outputs (INDEX), and finally the Unlock script (scriptsig), where the unlock script = signature + Public key, only the correct unlock script can be spent to spend the corresponding transaction.

A simple output is as follows:

Output:
value:5000000000
scriptpubkey:op_dup op_hash160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_ Equalverify Op_checksig

The first is the output amount (value), then the lock script, and the locking script includes a series of operators in the scripting system. type of transaction

Bitcoin currently offers two different types of transactions, as shown below. These two types of transactions can be combined to make more complex trades, called contracts.

(1) Pay-to-pubkeyhash

Scriptpubkey:op_dup op_hash160 <pubKeyHash> op_equalverify op_checksig
scriptsig: <sig> <pubkey >

This is also the most common trade, the destination address is the Bitcoin address, the cost of the need to provide a signature and public key.

(2) Pay-to-script-hash (P2SH)

scriptpubkey:op_hash160 <scriptHash> op_equal 
scriptsig:. Signatures <serialized script>

In P2sh, the destination address is replaced by a script hash, which contains the signature and the script content in the unlock script. There are two types of trading comparison, the first is the normal multi-signature script, the unlock script requires only 5 public key of any two private key signature.

Locking Script	2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 Op_checkmultisig
Unlocking Script	SIG1 Sig2

And then the P2sh script,

Redeem Script	2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 Op_checkmultisig
Locking Script	op_hash160 <20-byte Hash of redeem script> op_equal
Unlocking Script	SIG1 Sig2 Redeem Script

You can see that the lock script only needs to include the hash of the redeem script, rather than a long string of public key information, the specific script content is provided by the unlock script, which is equivalent to the majority of the transaction to the transaction cost to deal with, thereby reducing the network transmission of data. As described in Master Bitcoin, the ⽅-phase ⽐,p2sh, which directly enables the ⽤ complex script to lock out the output, has the following characteristics: In the trade output, the complex script is replaced by a short electrical ⼦ fingerprint, which makes the transaction code shorter. The script can be compiled as an address, and the issuer of the ⽀ and ⽀ ⽐ Wallet do not require complex ⼯ sequences to be ⾏p2sh. P2SH will build the burden of the script to transfer ⾄ receive ⽅,⽽⾮ send ⽅. P2sh the burden of ⻓ script data storage from the output ⽅ (stored in the Utxo set, affecting the memory) transfer ⾄ output ⼊⽅ (stored in the blockchain only). P2SH shifts the burden of ⻓ script data storage from the current (⽀) to ⾄ the future (at cost). P2sh the transaction fee cost of the ⻓ script from the sending ⽅ transfer ⾄ receive ⽅, receive ⽅ in order to ⽤ the fund ⾦ must contain the redemption script.