leaf

Introduction#

Since the launch of Bitcoin in 2009, marking the beginning of the blockchain era, distributed applications (dapps) based on blockchain have surged in the past decade, supported by the development of technology and ecosystems. The underlying technology that supports dapps is "blockchain + smart contracts." The combination of smart contracts and blockchain is widely regarded as a milestone upgrade in the blockchain world. The birth of Ethereum, the first platform to integrate blockchain and smart contract technology, is considered the start of the "Blockchain 2.0" era.

What is a Smart Contract#

In 1996, Nick Szabo introduced the concept of smart contracts in his paper "Smart Contracts: Building Blocks For Digital Markets." A "contract" refers to documents or agreements that record the conditions and corresponding execution terms to support operations like rights confirmation; "smart" implies automation and programmability. Therefore, a smart contract is a programmable contract, which can also be understood as a piece of self-executing contractual text. In computing, it is a segment of code that executes automatically. It is easier to preserve contracts and operates under defined algorithms, providing corresponding outputs for given inputs, greatly ensuring the enforceability of contracts. Using a vending machine as an analogy helps us better understand the core features of smart contracts. When a user selects a product and completes payment, the dispensing logic is triggered, and the user receives the desired product without human intervention, saving labor costs for the seller. To disrupt this contract, one would need to physically damage the vending machine. Similar analogies can be drawn with POS card machines and EDI (Electronic Data Interchange).

Smart Contracts and Blockchain#

Smart contracts were proposed in the last century, while blockchain was born in 2009. By definition, smart contracts and blockchain are not closely related. So why have smart contracts and blockchain developed such a close relationship over the past decade? Because blockchain ensures the immutability of smart contracts; not only is the contract content immutable, but each invocation record is also immutable. The most basic prerequisite for a smart contract to generate value is a strong underlying medium for storage, making it physically indestructible. However, the essence of a smart contract is a piece of code, which is very easy to tamper with. Thus, providing a strong storage medium for it becomes a challenge. This is precisely where blockchain excels—through the practice of Bitcoin, it has been proven that blockchain can make electronic records immutable in a distributed environment. At the same time, smart contracts also feed back into blockchain, greatly expanding its business scenarios. After combining with smart contracts, blockchain no longer serves only single currency payments but can extend to all aspects of life. The rich application scenarios also pose new challenges to blockchain's capabilities.

Blockchain 2.0: The Birth of Ethereum#

Bitcoin, born in 2009, utilized blockchain technology to ensure its ecosystem, marking the beginning of the Blockchain 1.0 era. Users can customize certain content through script code, such as how to unlock a fund. These script codes are saved along with transactions, enjoying the characteristic of immutability and determinism. Therefore, from a certain perspective, these scripts can also be seen as smart contracts. However, they are not very user-friendly. Firstly, these script codes are not Turing complete, limiting their functionality; secondly, the development threshold is high, and the experience of writing complex logic is poor, akin to writing programs in JVM bytecode.

In 2013, a young man named Vitalik Buterin proposed Ethereum, which is centered on updating and verifying blockchain data through a global state. The biggest difference between Ethereum and Bitcoin is that Ethereum can execute complex logical operations through smart contracts. On Ethereum, the language for smart contracts is Solidity, which is Turing complete and a higher-level language, greatly expanding the capabilities of smart contracts and reducing the difficulty of writing them. Because of this, the birth of Ethereum also marks the beginning of the Blockchain 2.0 era. Subsequently, smart contract technology gradually penetrated various business scenarios such as traceability, evidence preservation, and supply chain management.

Current Status and Prospects of Smart Contracts#

From a programming perspective, a smart contract is a piece of code. Compared to conventional code, smart contracts have many differences and limitations, such as:

• Single-threaded execution
• Code execution consumes resources and cannot exceed resource limits
• Currently difficult to obtain off-chain data, such as weather information, game results, etc.
• Other limitations, such as TPS

These characteristics make the current smart contract ecosystem centered around the governance of on-chain resources. Just like the various ERC standards and governance schemes on Ethereum; EOS has various resource models, such as CPU, RAM, economic models, Rex, Bancor protocol, etc. Clearly, in the current ecosystem, the influence of smart contracts on the real world is limited. However, things are always evolving. Currently, there are many studies aimed at breaking these limitations, with typical examples being Oracles (often referred to as "oracles"), which allow smart contracts to interact with off-chain data, greatly enhancing the use cases for smart contracts, as if a computer has connected to the internet; and attempts to break the performance bottlenecks of the chain itself, such as payment channels, cross-chain solutions, plasma, and rollup, all of which break the shackles of security and performance from different angles. Undoubtedly, smart contracts will play an increasingly important role, and with the implementation of Ethereum 2.0 in the future, it may usher in a new blockchain era.

Smart Contract Technology#

Ethereum uses Solidity as its smart contract language, which is a high-level programming language created for implementing smart contracts and can run on Ethereum program nodes. This language incorporates features from C++ and JavaScript, such as being a statically typed language that supports inheritance, libraries, etc. Besides Solidity, the smart contract technology of each platform varies, and the following will introduce the technologies used by other platforms from the perspective of public chains and consortium chains.

Public Chains#

First, let’s get to know the smart contract technologies of the three major public chains.

Bitcoin System#

Bitcoin is a digital currency invented by Satoshi Nakamoto in 2009, primarily to resist the centralized banking system. Due to its ingenious system design and security, its value has been rapidly increasing. At the same time, because it is not tied to real-world identities, it possesses strong anonymity, which has also led to its use in illegal transactions, money laundering, extortion, and other malicious activities, causing some controversy. As a decentralized blockchain system, anyone can access it and maintain a local node to participate in the Bitcoin network. The following will also apply the Bitcoin Core client to maintain a local node.

Nodes are divided into full nodes and light nodes. In the early days, all nodes were full nodes, but as the data volume increased, Bitcoin clients running on devices like mobile phones or tablets do not need to store the entire blockchain information and are called Simplified Payment Verification (SPV) nodes, also known as light nodes. The Bitcoin Core client is a full node, which will be discussed in detail later. Full nodes are always online and maintain complete blockchain information; because they maintain a complete UTXO set in memory, they validate the legality of transactions by verifying the blocks and transaction information of the entire blockchain (from the genesis block to the latest block); they also determine which transactions will be packed into blocks; validating transactions is mining, which can decide which chain to continue mining along; when there are equal-length forks, they will also choose which fork to follow; at the same time, they listen to blocks mined by other miners and validate their legality.

Light nodes do not need to be online all the time and do not need to retain the entire blockchain (which has a large data volume); they only need to keep the block headers of each block; they only need to save blocks related to themselves and do not need to save all transactions on the chain; because they do not save all information, they cannot validate the legality of most transactions and the correctness of newly published blocks online; they can only verify blocks related to themselves; they can verify the existence of a transaction through Merkle Proof but cannot confirm that a transaction does not exist; they can verify the mining difficulty because it is saved in the block header.

The following is an example to explain the transaction validation methods of full nodes and light nodes. Suppose we want to validate a transaction T located at block 300,000, a full node would check all 300,000 blocks (up to the genesis block) to establish a complete UTXO database to ensure that this transaction has not been spent; while a light node would link all blocks related to transaction T through the Merkle Path and then wait for blocks 300,001 to 300,006 for confirmation, thus validating the legality of the transaction.

Blockchain Structure#

A blockchain is a data structure composed of blocks linked in sequence, which can be stored in a single file or database. The Bitcoin Client uses Google's LevelDB database to store data. Each block points to the previous block, and if any block is modified, all subsequent blocks will be affected. Therefore, to tamper with a block, one must tamper with all subsequent blocks simultaneously, which requires a large amount of computing power, often making the cost greater than the benefit, thus greatly ensuring security.

The blockchain structure includes several core components: Block Size (4 bytes), Block Header, Transaction Counter (1-9 bytes), and Transactions. The block header size of the blockchain is 80 bytes, storing Version (4 bytes), Previous Block Hash (32 bytes), Merkle Tree Root (32 bytes), Timestamp (4 bytes), Difficulty Target (4 bytes), and Nonce (4 bytes). The hash value of each block is obtained by performing a double hash operation on the block header, i.e., SHA256(SHA256(Block Header)), and does not exist in the blockchain structure but is calculated by each node after receiving the block, making it unique; additionally, Block Height can also serve as a block identifier.

Merkle Tree#

The Merkle Tree is a crucial data structure in blockchain, primarily used to verify large datasets (also through double hashing, SHA256(SHA256(Block Header))). The structure is shown in the image below:

Using the Merkle Tree method allows for quick verification of whether a transaction exists in a certain block (with an algorithmic complexity of LogN). For example, to verify whether a transaction K exists in a block, only a few nodes need to be accessed.

Due to the large number of transactions in the Bitcoin network, this method can significantly improve efficiency, as shown in the image below:

Since light nodes (such as Bitcoin wallets on mobile phones) do not store the entire blockchain data, they can conveniently find transactions through the Merkle Tree structure. Light nodes will construct a Bloom filter to obtain transactions related to themselves:

1. First, initialize the Bloom filter to an empty value, obtain all addresses in the wallet, create a retrieval pattern to match addresses related to this transaction output, and add the retrieval pattern to the Bloom filter;
2. Then, the Bloom filter is sent to each node (via the filterload message);
3. After receiving it, the node will send a merkleblock message containing the block headers that meet the conditions and the Merkle Path of the transactions, along with a tx message containing the filtering results.

During this process, light nodes will use the Merkle Path to link transactions with blocks and use block headers to form the blockchain, thus being able to verify that transactions exist in the blockchain. Using the Bloom filter will return results that meet the filtering criteria, but there may also be some false positives, thus returning many irrelevant results, while also protecting privacy when light nodes request related addresses from other nodes.

Bitcoin Network#

The Bitcoin system operates on a P2P (peer-to-peer) network where nodes are equal, with no distinction in identity or authority; there is no centralized server, and the network has no hierarchical distinction. Each node must maintain a collection of transactions waiting to be added to the chain, with each block size being 1M, thus requiring several seconds to propagate to most nodes. Suppose a node listens to a transaction from A to B; it will write it into the collection. If it simultaneously detects a double-spending attack from A to C, it will not write it again. However, if it listens to the same transaction from A to B or a transaction from A to C with the same coin source, it will delete the transaction from A to B in that collection.

Bitcoin Consensus Protocol#

As a development system that anyone can participate in, Bitcoin needs to address the threat of malicious nodes. The solution is the Proof of Work mechanism, which is a computational voting mechanism. When a new transaction is generated, it broadcasts the new data record, and the entire network executes the consensus algorithm, i.e., miners mine to verify the record by solving a random number. The first miner to solve the problem gains the right to record, generates a new block, and then broadcasts the new block. Other nodes verify it and add it to the main chain.

Wallet#

As a digital currency system, Bitcoin has its own wallet system, mainly consisting of three parts: private key, public key, and wallet address. The process of generating a wallet address is as follows:

1. Using ECDSA (Elliptic Curve Digital Signature Algorithm), generate the corresponding public key from the private key.
2. The public key is long and difficult to input and remember, so it is hashed using SHA256 and RIPEMD160 to obtain a public key hash value.
3. Finally, it is processed with Base58Check to obtain a more readable wallet address.

Transaction Process#

With a wallet (and assets), one can start trading. Let’s understand this process through a typical Bitcoin transaction: A and B both have a Bitcoin wallet address (which can be generated using the Bitcoin Client, as described above). Suppose A wants to transfer 5 BTC to B; A needs to obtain B's wallet address and then sign the transaction of transferring 5 BTC from A to B with their private key (since A's private key is known only to them, possessing the private key means having ownership of the wallet assets); then the transaction is published. Initiating a transaction in the Bitcoin system requires paying a small miner fee as a transaction fee; miners will begin to verify the legality of this transaction, and after receiving six confirmations, the transaction can be accepted by the Bitcoin ledger, with the entire verification process taking about 10 minutes.

Why do miners consume a lot of computing power to verify transactions? Miners can earn block rewards and miner fees during the verification process, with block rewards decreasing every four years, so the main incentive later on is miner fees.

Why does verification take 10 minutes? Bitcoin is not absolutely secure; new transactions are vulnerable to malicious attacks, and controlling the mining difficulty to keep the verification process around 10 minutes can greatly prevent malicious attacks, which is merely a probabilistic guarantee.

How does the Bitcoin system avoid double spending? Bitcoin employs a concept called UTXO (Unspent Transaction Outputs). When a user receives a BTC transaction, it is accounted for in UTXO. In this example, if A wants to transfer 5 BTC to B, A's 5 BTC may come from two UTXOs (2 BTC + 3 BTC). Therefore, when A transfers to B, miners need to check whether these two UTXOs have been spent before this transaction; if they have been spent, the transaction is invalid.

The following diagram illustrates the flow of multiple transactions and the related concepts of UTXO.

Additionally, UTXOs have an important characteristic: they are indivisible. If A has 20 BTC and wants to transfer 5 BTC to B, the transaction will first use the 20 BTC as input, then produce two outputs: one transferring 5 BTC to B and one returning the remaining 15 BTC to A. Thus, A will have a UTXO worth 15 BTC again; if a single UTXO is insufficient for payment, multiple UTXOs can be combined to form the input, but the total must exceed the transaction amount.

How do miners verify that the transaction initiator has sufficient balance? This question seems simple at first; the first thought is to check the balance like in Alipay. However, Bitcoin is based on a transaction ledger model and does not have an account concept, so it cannot directly check the balance. To know the remaining assets of an account, one must review all previous transactions and find all UTXOs and sum them up.

Transaction Model#

Having discussed how a transaction occurs, what components make up a Bitcoin transaction?

As shown in the diagram, the initial part is the Version, indicating the version. Then comes the Input-related information: Input Count indicates the number, Input Info represents the input content, which is the Unlocking Script, mainly used to verify the input source, whether the input is usable, and other input details.

• Previous output hash: all inputs can trace back to an output, pointing to the UTXO that will be spent in this input, with the hash value of this UTXO stored here in reverse order.
• Previous output index: a transaction can have multiple UTXOs referenced by their index numbers, with the first index being 0.
• Unlocking Script Size: the byte size of the Unlocking Script.
• Unlocking Script: the hash of the Unlocking Script that satisfies the UTXO Unlocking Script.
• Sequence Number: defaults to ffffffff.

Next is the Output-related information, Output Count indicates the number, Output Info represents the output content, which is the Locking Script, mainly used to record how much Bitcoin is output, the conditions for future expenditure, and output details.

• Amount: the output Bitcoin quantity expressed in Satoshis (the smallest Bitcoin unit), where 10^8 Satoshis = 1 Bitcoin.
• Locking Script Size: the byte size of the Locking Script.
• Locking Script: the hash of the Locking Script, specifying the conditions that must be met to use this output.

Finally, there is Locktime, indicating the earliest time/block a transaction can be added to the blockchain. If it is less than 500 million, it directly reads the block height; if greater than 500 million, it reads the timestamp.

Bitcoin Script#

In transactions, the Unlocking script and Locking script are mentioned; what is the Bitcoin script? Bitcoin script is a list of instructions recorded in each transaction that can verify whether a transaction is valid and whether Bitcoin can be used. A typical script is as follows:

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Bitcoin script is executed from left to right based on a stack, using Opcodes to operate on data. In the above script language, <> contains data to be pushed onto the stack, while those without <> and prefixed with OP_ are operators (OP can be omitted). The script can also embed data permanently recorded on the chain (not exceeding 40 bytes), and the recorded data does not affect UTXO.

In transactions, is the Unlocking script, while OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG is the Locking script. Compared to most programming languages, Bitcoin script is non-Turing complete, lacking loops or complex flow control, making it simple to execute. Regardless of where it is executed, the result is deterministic, and it does not save state, with scripts being independent of each other. Due to these characteristics, although Bitcoin script is relatively secure, it cannot handle very complex logic, making it unsuitable for processing complex business scenarios. The smart contracts provided by Ethereum have achieved innovative breakthroughs in this regard, leading to the birth of many decentralized applications.

Mining#

In the previous discussion of the entire transaction process, mining was mentioned, and now we will elaborate on it. Some nodes mine to earn block rewards and miner fees, thus generating revenue, which is called mining. The block reward is created by coinbase and decreases every four years, from 25 in 2009 to the current 6.5.

Mining is essentially a process of continuously attempting random numbers to reach a set target value, such as being less than a certain target value. This difficulty is artificially set to adjust verification time and enhance security, rather than solving mathematical problems. Miners continuously attempt this value, with a low success rate, but the number of attempts can be high. Therefore, nodes with strong computing power have a proportional advantage and are more likely to solve the problem.

Why is the mining difficulty adjusted? Because in the Bitcoin system, if the block time is too short, forks may occur. If there are too many forks, it will affect the system's ability to reach consensus, endangering system security. The Bitcoin system stabilizes the block speed at around 10 minutes through difficulty adjustments, thus preventing transactions from being altered.

How is the mining difficulty adjusted? The system adjusts the target threshold every 2016 blocks (approximately two weeks), which exists in the block header. All nodes in the network must adhere to the new difficulty for mining. If malicious nodes do not adjust the target in the code, honest miners will not recognize it.

Target Threshold = Target Threshold * (Actual time taken to produce 2016 blocks / Estimated time to produce 2016 blocks)

At the beginning of Bitcoin's birth, there were few miners, and the mining difficulty was low, with most using home computers (CPU) for mining. As more people participated in the Bitcoin ecosystem, the mining difficulty increased, gradually transitioning to more powerful GPUs for mining, and specialized ASIC (Application Specific Integrated Circuit) mining chips and mining machines emerged with market demand. Now, many large mining pools have appeared, aggregating a large amount of computing power for centralized mining.

In such large mining pool systems, the Pool Manager acts as a full node, while a large number of miners compute hash values together, ultimately distributing rewards through the proof of work mechanism. However, excessive concentration of computing power can lead to centralization risks, such as if a large mining pool reaches over 51% of the total network computing power, it can roll back transactions or resist certain transactions.

Forks#

In the Bitcoin system, there may also be situations where consensus is not reached, known as forks. Forks can be mainly divided into two types: state forks, which are often intentionally created by some nodes; and protocol forks, which indicate some divergence in the Bitcoin protocol.

Protocol forks can be further divided into two types: hard forks, which involve incompatible modifications to parts of the protocol, such as changing Bitcoin's block size from 1M to 4M. This type of fork is permanent, resulting in two parallel chains developing from a certain node, such as Bitcoin Classic, forming two different currencies.

The other type is soft forks, such as adjusting Bitcoin's block size from 1M to 0.5M. After this adjustment, new nodes will mine smaller blocks while old nodes will mine larger blocks. Soft forks are non-permanent, with typical examples being modifications to coinbase content and forks generated by P2SH (Pay to Script Hash).

Bitcoin Core Client#

Bitcoin Core is the implementation of Bitcoin, also known as Bitcoin-QT or Satoshi-client. This client can connect to the Bitcoin network, verify the blockchain, send and receive Bitcoin, etc. It has three networks: Mainnet, Testnet, and Regnet, which can be switched.

It provides a Debug Console for direct interaction with the Bitcoin blockchain, with common operations as follows:
Blockchain

• getblockchaininfo: Returns various status information about blockchain processing.
• getblockcount: Returns the number of blocks in the blockchain.
• verifychain: Verifies the blockchain database.
  Hash
• getblockhash: Returns the hash value of the provided block.
• getnetworkhashps: Returns the network hash rate per second based on a specified number of recent blocks.
• getbestblockhash: Returns the hash value of the best block.
  Blocks
• getblock: Returns detailed information about the block.
• getblockheader: Returns information about the block header.
• generate: Immediately mines a specified number of blocks to a wallet address.
  Wallet
• getwalletinfo: Returns an object containing various information about the wallet's status.
• listwallets: Returns the list of currently loaded wallets.
• walletpassphrasechange: Changes the wallet password.
  Mempool
• getmempoolinfo: Returns detailed information about the activity status of the memory pool.
• getrawmempool: Returns detailed information about all transactions in the memory pool.
• getmempoolentry: Returns memory pool data for a given transaction.
  Transaction
• getchaintxstats: Calculates statistics about the total number of transactions and rates in the chain.
• getrawtransaction: Returns raw transaction data.
• listtransactions: Returns a list of transactions for a given account.
  Signature
• signrawtransaction: Signs the inputs of a raw transaction.
• signmessage: Signs information using the private key of the address.
• dumpprivkey: Retrieves the private key.
  Network
• getnetworkinfo: Returns status information about the P2P network.
• getpeerinfo: Returns data about each connected network node.
• getconnectioncount: Returns the number of connections of the node.
  Mining
• getmininginfo: Returns an object containing mining-related information.
• getblocktemplate: Returns the data needed to construct a block.
• prioritisetransaction: Accepts transactions into the mined block with higher or lower priority.

Conclusion#

The above is an interpretation of some core technologies of Bitcoin, mainly providing an in-depth understanding from its basic principles and data model perspective. Through studying Bitcoin, one can well understand the design philosophy and operational mechanism of blockchain. Next, we will study and analyze Ethereum, known as Blockchain 2.0, so stay tuned!

References#

1. COMP7408 Distributed Ledger and Blockchain Technology, Professor S.M. Yiu, HKU
2. Udacity Blockchain Developer Nanodegree, Udacity

Ethereum Core Technology Interpretation#

Introduction#

Bitcoin, as a decentralized digital currency, is extremely successful, but limited by Bitcoin script (non-Turing complete, can only handle simple logic), it cannot handle very complex business. Ethereum introduces smart contracts, allowing the concept of decentralization to be applied to richer application scenarios, thus also being referred to as Blockchain 2.0. This article will interpret the core technologies of Ethereum, and any errors or omissions are welcome for discussion and correction.

Ethereum System#

In January 2014, Russian developer Vitalik Buterin released the Ethereum white paper and formed a team aimed at creating a blockchain platform integrated with a more general scripting language. One of the members, Dr. Gavin Wood, published a yellow paper covering the technology related to the Ethereum Virtual Machine (EVM), marking the birth of Ethereum.

In simple terms, Ethereum is an open-source decentralized system that uses blockchain to store changes in system state, thus also being referred to as the "world computer." It supports developers to deploy immutable programs on the blockchain, known as smart contracts, thereby supporting a wide range of application scenarios. It uses the digital currency Ether to measure system resource consumption, incentivizing more people to participate in the construction of the Ethereum system.

Decentralized Applications (DApp)#

In a narrow sense, a DApp is an application that integrates a user interface, supports smart contracts, and runs on the Ethereum blockchain.

As shown in the image, Ethereum application instances are deployed on the blockchain network (smart contracts run in the blockchain virtual machine), while web programs only need to perform RPC remote calls to the blockchain network through Web3.js, allowing users to access decentralized service applications through browsers (DApp browsers or plugins like MetaMask).

Ledger#

The Ethereum blockchain is a decentralized ledger (database) where all transactions in the network are stored on the blockchain. All nodes must locally save a copy of the data and ensure the credibility of each transaction; all transactions are public and immutable, and all nodes in the network can view and verify them.

Accounts#

When we need to log into a website or system (like email), we often need an account and a password, with the password stored in a centralized database in encrypted form. However, Ethereum is a decentralized system, so how are accounts generated?

Similar to the Bitcoin system's principles:

1. First, generate a private key known only to oneself, assumed to be sk, and use the ECDSA (Elliptic Curve Digital Signature Algorithm) to generate the corresponding public key pk.
2. Hash the public key pk using the keccak256 algorithm.
3. Take the last 160 bits as the Ethereum address.

The user's private key and address together form the Ethereum account, which can store balances, initiate transactions, etc. (In Bitcoin, the balance is obtained by calculating all UTXOs, rather than being stored in accounts like in Ethereum).

In fact, Ethereum accounts are divided into two types: the aforementioned method generates Externally Owned Accounts (EOA), which are accounts owned by regular users mainly used to send/receive Ether tokens or send transactions to smart contracts (i.e., call smart contracts).

The other type is Contract Accounts, which differ from external accounts in that they do not have corresponding private keys and are generated when deploying contracts, storing smart contract code. Notably, contract accounts must be called by external accounts or other contracts to send or receive Ether and cannot initiate transactions on their own.

Wallet#

The software/plugin that stores and manages Ethereum accounts is called a wallet, providing functions such as transaction signing and balance management. Wallet generation mainly has two methods: non-deterministic random generation or generation based on random seeds.

Gas#

Operations on the Ethereum network also require "transaction fees," known as Gas. Deploying smart contracts and transferring funds consume a certain amount of Gas, which is also an incentive mechanism to encourage miners to participate in the Ethereum network, making the entire network more secure and reliable.

Each transaction can set the corresponding amount of Gas and the price of Gas. Setting a higher Gas fee often results in miners processing your transaction faster, but to prevent excessive Gas fees from being consumed by multiple executions of the transaction, a Gas Limit can be set. Gas-related information can be found at Ethereum Gas Tracker.

Smart Contracts#

As mentioned above, the Ethereum blockchain not only stores transaction information but also stores and executes smart contract code. Smart contracts control application and transaction logic. The smart contracts in the Ethereum system use the dedicated Solidity language, which has syntax similar to JavaScript. In addition, there are programming languages like Vyper and Bamboo. Smart contract code is compiled into bytecode and deployed to the blockchain, and once on-chain, it cannot be edited. The EVM, as a smart contract execution environment, ensures the determinism of execution results.

Example of a Smart Contract: Crowdfunding#

Let’s imagine a more complex scenario: suppose I want to crowdfund 10,000 yuan to develop a new product. Using existing crowdfunding platforms incurs significant fees and makes it difficult to solve trust issues, so a crowdfunding DApp can address this problem.

First, set some rules for the crowdfunding:

1. Each person wishing to participate can donate an amount between 10 and 10,000 yuan.
2. If the target amount is reached, the funds will be sent to me (the crowdfunding initiator) via smart contract.
3. If the target is not reached within a certain time (e.g., one month), the funds will be returned to the crowdfunding users.
4. Additional rules can be set, such as allowing users to apply for refunds if the target amount is not reached after a week.

Because these crowdfunding terms are implemented through smart contracts deployed on a public blockchain, even the initiator cannot tamper with the terms, and anyone can view them, solving the trust issue. The complete code can be viewed here: Demo.

Transactions#

In Ethereum, what does a typical transaction look like?

1. The developer deploys the smart contract to the blockchain.
2. The DApp instantiates the contract and passes in the corresponding values to execute the contract.
3. The DApp digitally signs the transaction.
4. The transaction is verified locally.
5. The transaction is broadcast to the network.
6. Miner nodes receive the transaction and verify it.
7. Miner nodes broadcast the new block to the network after confirming it is trustworthy.
8. Local nodes synchronize with the network and receive the new block.

Architecture#

Ethereum adopts an Order - Execute - Validate - Update State system architecture. In this architecture, when a new transaction occurs, miners perform PoW (Proof of Work) calculations; after verification, the block is broadcast to the network via the gossip protocol; other nodes in the network also verify the block upon receiving it; ultimately, it is submitted to the blockchain, updating the state.

Specifically, the Ethereum system has core components such as consensus layer, data layer, and application layer, with the interaction logic as follows:

As shown in the image, Ethereum data consists of Transaction Root and State Root. Transaction Root is a tree composed of all transactions, containing From, To, Data, Value, Gas Limit, and Gas Price; while State Root is a tree composed of all accounts, containing Address, Code, Storage, Balance, and Nonce.

Conclusion#

The above is an interpretation of some core technologies of Ethereum. The introduction of smart contracts brings more possibilities for blockchain applications, but there are still many issues regarding security, privacy, and efficiency that need to be considered. For complex enterprise-level application scenarios, consortium chains are a better choice. In the future, we will conduct a detailed analysis of Hyperledger Fabric, so stay tuned!

References#

1. COMP7408 Distributed Ledger and Blockchain Technology, Professor S.M. Yiu, HKU
2. Udacity Blockchain Developer Nanodegree, Udacity

EOS#

Pomelo Coin EOS Introduction
Pomelo Coin EOS is a blockchain architecture platform developed by blockchain wizard BM (Daniel Larimer) that resembles an operating system, aiming to achieve performance scalability for distributed applications. EOS provides accounts, authentication, databases, asynchronous communication, and program scheduling across hundreds of CPUs or clusters. The ultimate form of this technology is a blockchain architecture that can support millions of transactions per second, with ordinary users not having to pay usage fees.

EOS.IO White Paper#

EOS.IO software introduces a new blockchain architecture design that allows decentralized applications to scale horizontally and vertically. This is achieved by building an operating system-like structure on which applications can be built. The software provides accounts, authentication, databases, asynchronous communication, and application scheduling across hundreds of CPU cores or clusters. The resulting technology is a blockchain architecture that can scale to handle millions of transactions per second, eliminate user transaction fees, and allow for the rapid and easy deployment of decentralized applications.

The EOS.IO white paper also discusses several key goals at the design inception of EOS.IO:

• Support for hundreds or thousands of users
• Free usage
• Simple upgrades and bug fixes
• Low latency
• Temporal performance
• Concurrent performance

Among these, the most attractive is the ability to process millions of transactions per second, as such processing capability is essential for the true large-scale application of blockchain. In contrast, Ethereum's initial test network had a processing capacity of 25 transactions per second, which, after gradual optimization, could reach 50-100 transactions per second. However, this 50-100 transactions per second is clearly insufficient for large-scale applications, as evidenced by the explosive popularity of Cryptokitties in 2017, which clearly exposed this issue.

Supporting millions of transactions per second is also the core and essential revolution of EOS.IO compared to Ethereum. However, let’s not celebrate too early; whether this can be achieved will be explored later.

Consensus Algorithm#

EOS.IO adopts a delegated proof of stake algorithm, abbreviated as DPOS. DPOS was first applied in the cryptocurrency BitShares, which was ByteMaster's first blockchain product, initially aimed at creating a decentralized exchange and decentralized blockchain bank, leading to a platform called BitShares internal trading. For those interested, you can check out what BitShares internal trading is at this address.

It is worth mentioning BitShares internal trading because it is a good embodiment of ByteMaster's ideas, and it is precisely because of the staking model that EOS.IO has recently faced significant skepticism. We will discuss this later.

Let’s briefly introduce DPOS, and later we may consider writing a separate article to introduce various consensus algorithms.

DPOS, as the name suggests, delegates the consensus mechanism to corresponding individuals for decision-making. Taking BitShares as an example, DPOS allows each holder of BitShares to vote, producing 101 representatives, each with equal rights, and the validity of which chain is the true chain is determined by the situation of these 101 representatives.

Does this sound a bit like a people's congress or parliamentary system? A majority elects a minority, and this minority then votes to make the final decision. The ultimate goal of such voting is to ensure that no one can tamper with history.

For specific reasons why this model can achieve this, you can refer to the article "DPOS Consensus Algorithm - The Missing White Paper" published by dantheman on Steemit in June 2017.

If you want to see the Chinese translated version, you can refer to the translation published by Xi Haifeng on Wanyun BaaS, where you can find the specific content at that time.

Returning to the consensus algorithm of EOS.IO, based on DPOS, EOS.IO produces a new block every three seconds, which must be produced in turn by 21 producers elected by votes. After completing one round, 21 producers will be re-elected. In the selection process, the top 20 candidates with the most votes are automatically selected, while the remaining producer is chosen based on the voting ratio.

This may be difficult to understand just by saying it simply, so we can analyze it further based on specific code.

Other Features#

• Transaction Confirmation: 15/21 (meaning a node can wait for 15 confirmations from the 21 producers to confirm the legality of existing transactions).

• EOS.IO allows custom names between 2 to 32 characters as indexes. Accounts support namespaces (simply put, they support @). At the same time, accounts support permission management, allowing permission mapping and evaluation. Notably, it supports recovering stolen keys: the principle is very similar to how you recover your password on WeChat by requiring multiple active friends to send messages for verification.

• EOS.IO supports block producers using concurrent algorithms to schedule transactions.

EOS EVM Overview#

EVM refers to the Ethereum Virtual Machine. In the Ethereum ecosystem, it is a series of smart contracts that allow developers to deploy and run decentralized applications (dApps) written in Solidity. EOS EVM is a simulation of the Ethereum EVM and resides within EOS smart contracts.

EOS EVM will provide functionality equivalent to other EVMs in the field but with unparalleled speed, performance, and compatibility advantages. These advantages stem from the architectural design of EOS EVM and the powerful features of the EOS native system.

Role of EOS Native in Large-Scale Adoption#

Although the current focus is on EOS EVM, the EOS Native Layer remains the flagship product of the ecosystem. With the upcoming release of Leap v4.0.0, EOS Native will continue to innovate alongside EOS EVM.

EOS Native is written in C++, a language that is very popular among traditional developers, with speed and powerful library advantages. It is often used in technology projects with strict performance requirements, such as operating systems and games.

Due to this underlying architecture, smart contracts built on EOS Native are more efficient and powerful, and they are often favored by developers transitioning from Web2 or other traditional computer science fields to the Web3 space. With the rise of GameFi, EOS Native remains a powerful platform for achieving large-scale adoption, enabling game developers who have already built in Web2 environments to seamlessly integrate Web3 elements as needed.

As the optimization work for the EOS Native infrastructure continues, and with the current launch of tools from the Ethereum ecosystem on EOS EVM, it is foreseeable that the EOS ecosystem will present innovative opportunities that cannot be found in any other ecosystem. Based on this, EOS is positioning itself as a positive and collaborative development environment.

Technical Details of EOS EVM#

A lot has happened in the behind-the-scenes development of EOS EVM to ensure it maximizes performance and usability. Below, we will introduce some innovative design choices implemented over the past year.

Architecture of Silkworm#

Initially, the development of Silkworm focused on creating and testing separate stages. Erigon was used to prepare the database state for these stages. Later, work began on implementing two stages, depending on interactions with peers (through the Sentry component provided by Erigon), and assembling the Silkworm StageLoop, converting different binaries (one for each stage) into a usable product, with all stages integrated into one binary.

As shown in the image, work is currently being done on the stage responsible for downloading blocks and maintaining the state root hash.
Erigon's execution time vs Silkworm's execution time

References#

Want to learn more? Check out the Erigon blogs:
https://erigon.substack.com/p/current-status-of-silkworm-and-silkrpc
https://erigon.substack.com/p/staged-sync-and-short-history-of?s=w

Consortium Chain#

In addition to public chains, consortium chains are also an important type of blockchain. Compared to public chains, the complexity of consensus in consortium chains is greatly reduced, resulting in higher execution efficiency. Consortium chains are favored by enterprise-level institutions. Generally, relevant institutions form alliances to share data through consortium chains. Consortium chains can cover various scenarios such as supply chain finance, judicial evidence preservation, traceability, etc., and will integrate with technologies like IoT and AI in the future. In today's consortium chain ecosystem, apart from platforms using chaincode like Fabric, most platforms use Solidity as the smart contract language, and FISCO BCOS is one of them.

A consortium chain is a blockchain that is partially decentralized, initiated by several institutions, and jointly maintained by allies. It is only open to members of a specific group and limited third parties.

What is a Consortium Chain#

A consortium chain is a type of blockchain. Simply put, a consortium chain is a blockchain composed of multiple institutions or organizations that jointly control it. Individuals or organizations wishing to access a consortium chain must obtain authorization.

Currently, when discussing blockchain, people usually classify blockchains into three types based on their openness: public chains, private chains, and consortium chains. Public chains, like Bitcoin and Ethereum, allow anyone to access them at any time, obtain data on the chain, or submit new data to the chain. Of course, one can also exit the network at any time. Private chains are blockchains controlled by a single institution or organization. These blockchains are not open for others to participate in and are used internally.

Consortium chains lie between public and private chains, with members composed of multiple institutions or organizations. Therefore, it does not have the sole control of a single organization like a private chain; however, it is not as open as a public chain, where anyone can access it.

The English term for consortium chain is "Consortium Blockchain," and I believe the term "consortium" translates very well. Even without any explanation, we can understand its characteristics from the name "consortium chain."

Solidity occupies a central position in smart contracts, and mastering Solidity is an important part of learning smart contracts and blockchain. The following series will also provide in-depth introductions and analyses on how to write, run, and test smart contracts using Solidity, so please stay tuned. In addition to Solidity, other smart contract languages like WebAssembly and Libra's Move are also in development, which can be monitored.

In 2016, consortium chains were very popular, while public chains were still in the exploratory stage, and Ethereum was not mature enough, which provided many opportunities for consortium chains to emerge. Therefore, from a technical perspective, consortium chains are indeed very strong and are not inferior to well-known blockchain projects. Below, let’s take a look at consortium chain technology.

Introduction#

The concept of consortium chains originated from Vitalik's classification of blockchain concepts, where he first proposed the term consortium chain. The English term for consortium chain is Consortium Blockchain.

Let’s review consortium chains. A consortium chain is a blockchain that has access permissions, unlike public chains, where anyone can enter at any time. Access permissions mean that candidate nodes need to obtain permission from nodes already in the network when entering the blockchain.

Thus, consortium chains are also called permissioned chains, which is a more common term abroad. The number of nodes in a consortium chain is usually not large, and the maintenance cost is lower compared to public chains.

Regarding the conceptual differences between consortium chains and public chains, their distinction lies solely in whether new nodes joining require permission from other nodes in the entire network, which determines whether a blockchain is open. The degree of openness determines the size of the project ecosystem, which is the most intuitive difference.

The technical frameworks of consortium chains are numerous, with the Hyperledger project being the most well-known and widely used, representing consortium chains. Therefore, today we will focus on introducing the Hyperledger project.

Hyperledger#

Hyperledger was initiated at the end of 2015 and has attracted many heavyweight companies to join, including well-known companies like IBM, Intel, Accenture, Hitachi, JP Morgan, Digital Asset Holdings, and others.

The code and organizational structure of Hyperledger are clear and hierarchical. It can be said that in terms of momentum and strength, it can surpass public chains.

For example, the Hyperledger organization is membership-based, and joining Hyperledger requires paying a membership fee, which determines your membership level. Additionally, the architectural design of Hyperledger Fabric is textbook-level, clean and neat, with clear modules, making it almost flawless.

Hyperledger is hosted by the Linux Foundation, with the aim of building an open-source distributed ledger technology platform for enterprise application scenarios.

Due to the diversity of enterprise application scenarios, Hyperledger includes more than one project; it consists of multiple projects. There are a total of nine projects, five of which are major technical frameworks, and the other four are auxiliary tools.

The main technical frameworks are as follows:

1. Hyperledger Fabric: No Chinese name, temporarily translated as "Fabric," is provided by IBM and is the first project of Hyperledger. Fabric aims to use a modular architecture as the foundation for developing blockchain programs or solutions, allowing some components—such as consensus algorithms and member management—to become plug-and-play services.
2. Hyperledger Sawtooth: Chinese name "Sawtooth," provided by Intel, is the second project of Hyperledger. Sawtooth is a modular platform for creating, deploying, and running distributed ledgers, based on hardware-dependent PoET consensus, suitable for large distributed validator groups while being low-power.
3. Hyperledger Iroha: No Chinese name, temporarily translated as "Iroha," provided by Soramitsu. Iroha is designed to easily integrate distributed ledger technology with infrastructure projects.
4. Hyperledger Burrow: No Chinese name, temporarily translated as "Burrow," provided by Monax. Burrow offers a modular blockchain client with a permissioned smart contract virtual machine, partially based on the Ethereum Virtual Machine (EVM) specification.
5. Hyperledger Indy: No Chinese name, temporarily translated as "Indy." Indy is a distributed ledger specifically built for decentralized identity. It provides tools, code libraries, and reusable components for creating and using independent digital identities based on blockchain or other distributed ledger interoperability.

The other four auxiliary tools are: Cello, Composer, Explorer, and Quilt. These auxiliary tools can manage the above five frameworks; for example, Composer can be likened to Composer in Docker, and Explorer is a block explorer.

We do not rule out the possibility that new technical frameworks will join as Hyperledger develops, and of course, existing frameworks may be eliminated by the market. However, these are not the focus of this article, so we will not elaborate further. You can find more content by checking the official Hyperledger website.

1. Fabric#

Fabric is provided by IBM and is based on the Go language. The predecessor was the Openchain project. At the inception of Hyperledger, the code volume of Openchain had already reached 40,000 lines. As the project progressed, project members restructured Openchain, resulting in the Fabric 1.0 version.

Fabric provides a relatively complete modular component, as shown in the image below.

Its architecture is divided into three major modules: member relationship management, blockchain services, and Chaincode services.

Member relationship management is equivalent to an account and permission management system. Blockchain services provide a blockchain-like ledger structure, while Chaincode services are equivalent to smart contracts.

Member relationship management is based on PKI for member permission management, allowing the platform to restrict the capabilities of accessing nodes and clients.

Blockchain services provide a distributed ledger platform where multiple transactions can be packaged into a block, and multiple blocks are linked unidirectionally to form a blockchain. The blockchain represents the historical process of changes in the ledger state machine, which is not much different from public chains.

Chaincode contains core business processing logic and provides interfaces externally. External parties can change ledger data by calling Chaincode interfaces. In Fabric, Chaincode runs in an isolated environment, which is Docker.

A possible working model of Fabric is shown in the image below.

If Chaincode runs in Docker, we can analyze it according to the classic IT architecture and find that Fabric is essentially an upgraded version of a classic distributed system. It can provide fault tolerance, and the pluggable consensus module allows users to choose whether to require Byzantine fault tolerance.

2. Sawtooth#

Sawtooth is also a highly modular blockchain technology framework based on the Python language. After version 1.0, it has become a stable framework like Fabric and has practical applications.

It is the first truly meaningful Hyperledger project to provide Byzantine fault tolerance consensus options, with the following four characteristics:

1. On-chain governance: Using smart contracts for voting to manage the relationships between members.
2. Advanced transaction execution engine: Capable of parallel processing of transaction creation and verification, with considerable performance.
3. Supports Ethereum smart contracts: Compatible with the Ethereum smart contract technology stack.
4. Supports mainstream languages for writing smart contracts: Writing smart contracts is not limited to Solidity; it can be in Go, JavaScript, Python, and other languages.

Among these four characteristics, the most noteworthy is that Sawtooth provides a new consensus algorithm called PoET (Proof of Elapsed Time), which translates to "time elapsed proof" in Chinese.

If you are familiar with the Raft consensus algorithm, you know that Raft is a strong leader consensus algorithm. When electing a leader, each node counts down (CountDown), and the first to finish counting becomes the candidate.

This process is called election timeout. Each node receives different countdown times in each round of elections, which are randomly generated, usually between 150 milliseconds and 300 milliseconds.

PoET is similar to the above rules, but the countdown time is generated based on hardware dependency, with the hardware currently provided by Intel's SGX (Software Guard Extensions), which can provide a trusted program execution environment.

SGX provides a mechanism called Enclave, which supports two functions: "CreateTimer" and "CheckTimer." CreateTimer is used to generate a timer from the Enclave.

CheckTimer verifies whether this timer was generated by the Enclave and checks if it has expired. If both conditions are met, a proof is issued to that node, which can be verified by other nodes. If verification passes, it indicates agreement for that node to become a bookkeeping node.

We can see that the Byzantine fault tolerance of the PoET consensus algorithm is guaranteed by SGX, which has a certain hardware dependency.

The official Sawtooth project provides four working modes: development mode, PoET mode, PoET simulation mode, and Raft mode.

It can be seen that Sawtooth is essentially a variant of the Raft protocol, and choosing the Raft mode allows Sawtooth to degrade to a classic distributed system.

3. Burrow#

Burrow is also a blockchain technology framework based on the Ethereum EVM (Ethereum Virtual Machine) for executing smart contracts. The initial project was named Eris and was constructed based on the Go language.

Burrow mainly consists of the following components:

• Consensus engine: Provides a high-performance Byzantine fault tolerance consensus algorithm based on the Tendermint PBFT algorithm.
• Application Block Chain Interface (ABCI): Provides interface specifications for the consensus engine and smart contract engine.
• Permissioned Ethereum Virtual Machine (EVM): Permissioning can be enforced through local security interfaces bound to smart contracts, similar to other Ethereum smart contracts.
• API Gateway: Provides REST and JSON-RPC API interfaces.

Burrow is also a modular distributed ledger technology that provides a permissioned smart contract execution environment, based on the EVM specification. Apart from the Tendermint PBFT consensus algorithm, there are no significant differences from Fabric.

4. Iroha#

The above technical frameworks are generally universal technology frameworks that do not involve business concepts. Iroha is the first blockchain platform focused on asset creation and management, and it is led by a Japanese company.

Iroha has the following features:

• It can help people create and manage diverse complex assets, such as currencies, indivisible rights, product serial numbers, patents, etc.
• Provides a domain-based account management mechanism, similar to a "sub-ledger" system.
• Provides permission management.
• The system itself provides verification of business logic rules and transaction query interfaces.
• Compared to Fabric and Burrow, which are developed in Go, Iroha is developed in C++14.

5. Indy#

Indy is also a technology framework built to construct a distributed economic system starting from identity.

Indy has the following characteristics:

• A consensus algorithm based on redundant Byzantine fault tolerance (RBFT) called Plenum.
• Aims to create a distributed ledger through decentralized identity.
• Global uniqueness of identity without centralized authorization.
• Identity attributes and formats based on W3C standards.
• Provides zero-knowledge proof methods.

Indy is very different from other universal technology frameworks, and its research on identity may become a breakthrough point for Indy, similar to digital identities in the metaverse.

BaaS and BTaaS#

Many of the Hyperledger technical frameworks can rely on cloud computing to help enterprises quickly build, and IBM and Microsoft have already started doing this, referring to it as BaaS (Blockchain As A Service).

We can further think about whether the global payment function provided by Bitcoin can be embedded into cloud services. The answer is yes. For many applications with payment needs, setting up a Bitcoin node and structuring blocks into a database is a very painful process, as the APIs provided by Bitcoin full nodes are limited, while our query needs may be detailed down to transaction outputs and script signatures.

Thus, transforming Bitcoin into a PaaS service is another approach to BaaS.

Therefore, we can break down the original BaaS concept into two types:

• BaaS refers to the process of transforming services provided by public chains into PaaS services in cloud computing.
• BTaaS refers to the process of transforming blockchain technology frameworks into PaaS services.

Challenges of Consortium Chains#

The series of Hyperledger technical frameworks well illustrates what it looks like when distributed ledger technology reaches its peak.

Here, it can also be seen that almost all Hyperledger projects are technology-driven, and the strength of the technology has led them to overlook the real needs of the market.

Consortium chains involve activities between a few nodes, often degenerating into games in microeconomics. Therefore, using consortium chains to build collaborative systems between a few nodes is not a technical issue but rather how to construct a stable microeconomic model that allows collaborators to achieve Pareto improvements, where technology becomes secondary.

No matter how good the technical tools are, if they are not combined with effective incentive and feedback mechanisms, the application landing process of consortium chains seems to become exceptionally difficult. It is likely to end up as an ordinary distributed system, which remains centralized.

Public Chains, Private Chains, and Consortium Chains#

Public Chains#

Public chains are a type of blockchain that is completely decentralized, such as BTC and ETH. Transaction information is open and transparent, and anyone can trade and read information, as well as join/exit nodes. Privacy is maintained, and the true identities of participants cannot be known. The downside is that transaction costs are high, requiring a majority of nodes to verify a transaction.

The top ten public chains globally include BTC, ETH (Ethereum), ICP, ADA (Cardano), VET, TRX, NEO (Antshares), EOS, XTZ, and ETC (Ethereum Classic, the main chain before the ETH hard fork).

Consortium Chains#

Consortium chains are partially decentralized, requiring verification and authorization for nodes to join. These nodes coordinate work based on consensus mechanisms. This is a partially decentralized blockchain, where the public can view and trade, but verifying transactions requires internal decisions from the consortium. It is suitable for scenarios involving multiple institutions, such as supply chain finance and cross-border clearing.

Typical representatives include the blockchain consortium R3, which involves more than forty banks, and the Hyperledger project under the Linux Foundation, which is a consortium chain architecture. Taking Hyperledger Fabric as an example, the system introduces a PKI system, providing member management, authentication, authorization, monitoring, auditing, and other security management functions. At the same time, Fabric offers a modular distributed accounting solution, providing high confidentiality, elasticity, flexibility, and scalability, such as pluggable consensus mechanisms. Its purpose is to support flexible selection of different components to suit various application scenarios.

Private Chains#

Private chains are blockchain systems that are open to individual persons or entities. The permissions of each node within the system need to be allocated by the organization, and the amount of data open to each node is determined by the organization as needed. The advantages are low transaction costs and fast speeds, as not every node needs to verify transactions; a small number of nodes can complete the task. Additionally, there is better privacy, as the reading permissions of data are restricted, and participants cannot read data unrelated to themselves (suitable for scenarios requiring regulation). To some extent, private chains do not differ much from traditional applications; they merely utilize distributed ledger technology, with accounting rules, nodes, and permission controls all determined by the enterprise itself.

The value of private chains mainly lies in providing a secure, traceable, immutable, and automatically executable operating platform within enterprises, while preventing internal security attacks on data, which traditional platforms find difficult to achieve. Suitable scenarios include internal audits, database management, etc.

Core Differences Among the Three Types#

The core difference among the three types of blockchains lies in the degree of openness of access permissions, or the degree of decentralization. Essentially, consortium chains also belong to private chains, differing only in the degree of privacy.

Generally speaking, the higher the degree of decentralization, the higher the trust and security level, the lower the transaction efficiency.

Since nodes in consortium chains and private chains require certification and authorization to join, they are also referred to as permissioned chains.

Technical Introduction#

Blockchain is more like an interdisciplinary field, combining P2P network technology, distributed ledgers, cryptography, consensus mechanisms, macroeconomics, and economic games to construct a new domain—exploring the value internet.

Distributed databases are the physical carriers of blockchain, while blockchain is the logical carrier of transactions. All core nodes should contain a complete copy of the data of that blockchain. Blockchain serializes blocks by time, and the blockchain is the main body of the entire network's transaction data. The blockchain is only effective for adding and querying, and ineffective for other operations!

Blockchain is a set of protocols, a group of specifications, rather than specific code or projects. Understanding this set of protocols allows you to implement it based on existing technologies in different languages.

Metaphors#

• People in the financial industry might say that blockchain is a distributed ledger, a distributed banking accounting system.
• Cryptographers might say that blockchain is a trustless network built using cryptography.
• Programmers might say that blockchain is a distributed database that ensures eventual consistency.

Iteration of Blockchain Technology (1.0 -> 2.0 -> 3.0)#

The 1.0 era refers to the era of virtual digital currencies represented by Bitcoin, characterized by the fact that only data related to digital currency transactions is stored on the blocks. At the same time, other digital currencies, such as Litecoin, Dogecoin, and Ripple, have emerged.

The 2.0 era refers to the era where digital currencies combine with smart contracts, with Ethereum being a typical representative. The characteristic is that it has virtual machines, smart contracts, and distributed applications (DApps), where smart contracts are the key feature. In the 2.0 era, people attempted to create shareable blockchain technology platforms and provide developers with blockchain and services (BaaS), making it very easy to develop DApps such as distributed identity authentication, distributed domain name systems, and decentralized autonomous organizations. At the same time, the deployment and implementation of smart contracts also promote the development of automated transactions, significantly improving transaction efficiency and reducing transaction costs.

The 3.0 era is the exploration ideal of building a value internet with blockchain, which has not yet arrived. The core of the value internet is to construct a global distributed accounting system with blockchain, which can not only record transactions in the financial industry but also record almost anything of value that can be expressed in code: the usage rights of shared cars, the status of traffic lights, birth and death certificates, marriage certificates, educational qualifications, financial accounts, medical processes, insurance claims, voting, and energy. Therefore, with the development of blockchain technology, blockchain will transcend the financial field and enter social notarization.

To enter the 3.0 era, blockchain technology must solve the following problems:

• Scalability: Currently, both Bitcoin and Ethereum have low transaction processing efficiency, far below traditional enterprise applications.
• Privacy Protection: The open and transparent nature of blockchain allows people to view other users' data through blockchain explorers.
• Although projects like Dash, Monero, and Zcash have made significant efforts in this area, they are still limited to the digital currency field and are far from sufficient.
• The 3.0 era allows users to store more diverse data, such as medical data and personal credit information. No one wants their privacy exposed to the public eye.
• Legitimacy and Compliance: The openness and anonymity of blockchain pose severe challenges for regulatory oversight by governments. The healthy development of blockchain technology in the future requires compliance with government regulatory requirements. Without regulation, there can be no constraints, and when user interests are harmed, there is no way to seek redress.

Core Technologies#

The P2P network communication technology used by blockchain may provide us with another choice: all people are born equal; no one is inherently a server or a client. Each node is equal, serving as both a producer and a consumer.

Some may ask whether a P2P network can guarantee no malice, no downtime, and data integrity. Not so fast; the P2P network merely provides a means for all nodes to exchange information. The consensus algorithm and encryption algorithm still do the work.

1. Distributed Ledger#

DLT (Distributed Ledger Technology) is essentially a decentralized, new type of distributed data storage technology that allows data sharing, replication, and synchronization across multiple nodes in a network. Compared to traditional distributed storage systems, DLT has the following characteristics:

• High Efficiency
  Traditional distributed storage systems adopt a data management mechanism controlled by a central institution, facing enormous challenges when dealing with explosive data growth, necessitating continuous investment in building large data centers, leading to increasing system scale and complexity. This not only brings issues related to building large resource pools for computing, networking, and storage but also poses severe system reliability problems.

DLT, based on certain consensus rules, adopts a multi-party decision-making and joint maintenance approach for data storage, replication, and other operations. Its decentralized data maintenance strategy effectively reduces the burden of system bloat and can even effectively utilize the vast resource pools accumulated by numerous scattered nodes in certain application scenarios.

• High Security
  Data in traditional distributed storage systems is controlled by a single organization, and this management mechanism's shortcomings in data credibility and network security have gradually attracted people's attention. Users cannot determine whether their data has been stolen, tampered with, or illegally used by service providers, and they are powerless in the event of hacker attacks or data breaches.

In DLT, each node has its independent, complete data backup, and the nodes do not interfere with each other, with equal permissions. Through periodic or event-driven consensus, they achieve final consistency in data storage. Any modification by any node or a small cluster cannot affect the majority of global copies. In other words, whether it is the intentional modification by a service provider without authorization or malicious attacks by network hackers, it requires simultaneously affecting most nodes in the distributed ledger cluster to modify the data.

2. P2P Network#

Also known as a peer-to-peer network, it has no central server, with each user acting as both a client and a server. This technology has been applied for many years, such as in BT downloads, Thunder, and P2P chat. Its unique advantages over traditional B/S architecture systems include:

• Fast and Privacy-Ensured: Users can communicate directly without a so-called server intermediary, ensuring that communication data does not pass through others.
• Data Fault Tolerance: In a P2P network, resources are distributed across nodes, providing sufficient redundancy. In the Bitcoin blockchain system, even a single node can store all data. This advantage eliminates single points of failure.
• Stability: The system will not collapse due to the exit/failure of certain nodes.

3. Consensus Algorithm#

In a decentralized system, to maintain data consistency among nodes, a consensus algorithm is required. In blockchain systems, all ledgers are connected through hash pointers, and the longest chain is chosen as the main chain (excluding DAG blockchains). Each node adds blocks at the end of the main chain, and when receiving blocks sent by other nodes, they also verify and update the blockchain based on the latest block of the main chain. Therefore, the core issue of consensus mechanisms in blockchain is how to select the bookkeeping nodes for each round and which node has the right to create blocks in that round.

Currently, there are various solutions to this problem, such as PoW, PoS, and DPoS. Consensus algorithms can be classified into proof-based, random-based, and consortium-based. Among them, common proof-based algorithms include PoW and PoS, where the former proves the computing power of bookkeeping nodes, and the latter proves the rights of bookkeeping nodes to the system's virtual resources. Random-based algorithms commonly rely on random numbers to select packaging nodes, such as Algorand and POET. Consortium-based algorithms, represented by delegated proof of stake (DPoS), are democratically centralized and take turns obtaining bookkeeping rights.

3.1 PoW Algorithm#

This is the consensus mechanism adopted by the BTC system. Its core idea is that when a new block is about to be added to the BTC system, each node in the blockchain system competes to solve a mathematical problem to gain the bookkeeping rights for that block, while also receiving rewards given by BTC. Since high-computing nodes are more likely to win in solving problems, they have a greater chance of obtaining bookkeeping rights and rewards than low-computing nodes.

The core of the PoW algorithm is to find a Nonce value that satisfies the conditions of a hash calculation problem given by the system. The process involves continuously changing the Nonce value for hash calculations. In the network of nodes, whoever calculates faster obtains the bookkeeping rights for that round, so this algorithm is essentially a competition of computing power (which consumes computational resources and is not environmentally friendly, so it will gradually be replaced by other solutions).

3.2 PoS Algorithm#

To address the resource waste issue of the PoW algorithm, a new proof-of-stake-based PoS algorithm has been designed. It is a consensus mechanism that relies on the economic interests of bookkeeping nodes in the network. In PoS, bookkeeping nodes gain rights based on the number of tokens they hold and the duration of holding those tokens. The higher the token rights, the easier it is for the node to solve problems and gain bookkeeping rights.

In simple terms, this algorithm assumes that the wealthiest individuals in the system will not act maliciously, as it would lead to their own greatest losses. Thus, the concept of coin age is introduced: one coin stored for one day equals one coin age. The node with the highest coin age has more bookkeeping rights, so its essence is a competition of coin age.

Advantages: It shortens the time to reach consensus, and the bookkeeping efficiency is much higher than PoW. Mining is simple and does not require consuming enormous computing power.

Disadvantages: Nodes obtain bookkeeping rights based on virtual currency rights, which may lead to monopolization of virtual currency at the beginning of the system's operation, resulting in monopolization of bookkeeping rights.

3.3 DPoS Algorithm#

This algorithm's mechanism is somewhat similar to a people's representative assembly system, where the coins in users' hands serve as votes. Users can vote for capable and reputable nodes, and the nodes with the most votes will represent the rights holders in bookkeeping. Taking EOS as an example, the entire network votes to select 21 super nodes, who take turns bookkeeping. Essentially, it is an extension of PoS, still competing based on the number of coins.

Advantages: It significantly reduces the number of participating verification and bookkeeping nodes, improving efficiency to achieve second-level consensus verification.

Disadvantages: Bookkeeping rights are more concentrated in the hands of a few nodes.

3.4 PBFT Algorithm#

TODO

4. Cryptographic Algorithms#

4.1 Asymmetric Encryption Algorithm#

First, let’s talk about symmetric encryption, where both encryption and decryption use the same key. In contrast, asymmetric encryption uses a pair of public and private keys. Theoretically, the public and private keys complement each other; one can encrypt with one key and decrypt with the other. However, in practical use, there are usually agreements based on the scenario: for example, in encryption and decryption scenarios, the public key is used for encryption, and the private key is used for decryption (verification). The core purpose of digital signatures is not to decrypt data but to verify the integrity and authenticity of the data. Most blockchain systems currently use the elliptic curve cryptographic algorithm based on secp256k1.

4.2 Hash Algorithm#

Also known as a digest or hash function, it is an algorithm that compresses data of variable length into a fixed-size string, characterized by irreversibility and low collision probability. A good hash algorithm has a lower collision rate. Its main uses include data verification and data summarization. Common hash algorithms include MD5, SHA-1, RIPEMD-160, SHA-256, SHA-512, etc.

4.3 Encoding and Decoding Algorithms#

The purpose of encoding is to make a long, unstructured string concise and readable. It does not involve encryption; depending on the encoding and decoding algorithm used, it can be directly decoded. Bitcoin uses Base58 encoding, which is derived from Base64, removing characters that are easily confused with others, such as the number 0, uppercase O, lowercase L, and uppercase I.

5. Embedded Databases#

Traditional applications generally use relational databases to store data, such as MySQL, which typically stores logs, user data, and indexes. In blockchain systems, whether in Bitcoin's UTXO model or Ethereum's account model, the database stores transaction logs. For example, in the UTXO model blockchain, only user address accounts and their balances are saved in a key-value database; projects like Hyperledger also include modules similar to state storage. Currently, almost all blockchain systems do not have modules for index storage. Overall, the storage structure of blockchain is relatively simple.

To minimize latency, blockchain systems generally use embedded databases to store data. For instance, early Bitcoin used BerkeleyDB, later adding LevelDB; Hyperledger uses LevelDB, which also supports CouchDB.

Embedded databases refer to lightweight databases that run on the local machine without starting a server. They are tightly integrated with the app, starting and stopping with the app. Common examples include SQLite, BerkeleyDB, LevelDB, and CouchDB.

Advantages of embedded databases:

• Higher efficiency: No need to run a data engine; the app directly calls APIs to operate on data.
• Appropriate size: Since they were originally designed for embedded systems, they are relatively small, occupying minimal ROM, RAM, and CPU resources.
• Comprehensive functionality: They have logging, data compression, backup, and recovery functions.
• Portability: They far exceed relational databases in this aspect, generally applicable across different software and hardware platforms.

6. Smart Contracts#

Smart contracts are a piece of code that runs on the blockchain, representing a contract that has been agreed upon through consensus. When preconditions are met, it can automatically enforce the terms of the contract. Smart contracts were first introduced by the Ethereum platform. Currently, Ethereum and Hyperledger Fabric are the more mature and representative smart contract platforms.

The workflow of smart contracts is as follows:

1. Multiple users jointly participate in specifying a smart contract.
2. The contract is broadcast through the P2P network and stored on the blockchain.
3. Wait for external events to trigger contract execution.

Characteristics:#

• Once the contract is on-chain, it cannot be tampered with: it is stored in a block.
• Code executes securely: once conditions are met to trigger contract execution, all full nodes in the blockchain platform will execute the contract code in a secure sandbox environment, unaffected by external environments. Only when all nodes execute the results consistently is it considered successfully executed.
• Results are transparent and public: the execution results of the contract are recorded on the blockchain, ensuring fairness, justice, and transparency.

Currently, there are issues with human vulnerabilities. Contracts are written by programmers, and there will inevitably be vulnerabilities, such as floating-point overflow, access control, incorrect return values, denial of service, etc. Even intentional vulnerabilities can occur. Due to the immutable nature, the risks and consequences of such vulnerabilities are significant, as seen in the 2016 Ethereum DAO incident.

Ethereum smart contracts run in the Ethereum Virtual Machine (EVM), which provides a Turing-complete scripting language: Ethereum virtual machine code, allowing anyone to create smart contracts and their decentralized applications, freely defining ownership rules, transaction methods, and state transition functions. Ethereum smart contracts consist of eight parts: accounts, transactions, Gas, logs, instruction sets, message calls, storage, and code libraries. These contracts are mainly applied in public chains.

Hyperledger Fabric smart contracts are essentially distributed transaction programs running on verification nodes, used to automatically execute specific business rules and ultimately update ledger states. Once deployed, the contract is packaged into a Docker image, and each node starts a new Docker container based on that image and executes the initialization method in the contract, then waits to be called externally. These contracts have Turing completeness and are divided into public, confidential, and access-controlled types, initiated by members with different permissions, mainly applied in consortium chains, as well as enterprise-level digital payments, financial asset management, supply chain finance, etc.

Trends in Blockchain Technology Development#

4. Technical Iteration and Updates#

One of the main issues preventing