On-chain governance

On-chain governance refers to the process by which individuals directly initiate community proposals and make decisions on the blockchain. The first requirement here is that the blockchain supports a basic governance protocol, which can stipulate or enforce proposals; on-chain governance directly determines the development direction of the blockchain itself.

The participants in on-chain governance include four groups: investors, users, developers, and miners.

The difference between on-chain governance and off-chain governance lies in whether the blockchain itself provides a mechanism for enforcing the majority's will over the minority. In on-chain governance protocols, participants can engage in governance through voting, while off-chain governance typically involves reaching consensus through various offline and online interactions, such as proposals and community meetings. The three rounds of consensus in the scaling debate are a typical example of off-chain governance.

Various types of on-chain governance

Bitcoin BIP and Block Voting: Although Bitcoin does not provide a complete on-chain governance mechanism, it does support a simple voting mechanism. For example, miners can write consensus information in a block to indicate support for a proposal, such as filling in NYA in a block to show support for the New York Consensus. However, all of this is based on Bitcoin's BIP; there must be a BIP to initiate a vote. The organizational structure of BIPs is relatively community-oriented, mainly composed of some developers and core community members on GitHub. All actions by miners are also non-mandatory; when a mainnet upgrade occurs, miners can still choose not to upgrade, which could lead to a fork, something everyone wishes to avoid.
Ethereum Gas Limit Voting: Ethereum provides a parameter for the upper limit of gas consumption—Gas limit. Miners vote to increase or decrease the Gas limit, which determines the number of smart contracts that can be processed in a single block. However, this only pertains to this specific function and does not determine the overall development of the blockchain. In fact, Ethereum's development is significantly influenced by Vitalik himself, and the driving forces behind Ethereum governance are the core members and early capital.
BitShares BTS and EOS On-chain Governance: We previously introduced the on-chain governance structure of the EOS blockchain—the blockchain constitution. In reality, the constitution does not have mandatory binding force, but it has become a form of community binding force, similar to an oath-taking process. The governance structure of EOS and BitShares comes from the voting process provided by the DPoS algorithm, where voting is weighted based on the amount of coins held. Among the four roles of users, investors, developers, and miners, miners and investors are combined, which poses a significant risk due to capital coercion.

Based on the above governance structures, we categorize Bitcoin and Ethereum as one type, which tends to lean towards off-chain governance, while EOS and BitShares lean towards on-chain governance.

Several issues with on-chain governance: Whether on-chain or off-chain governance methods, there are some issues. The actual executors of upgrades, the miners, are always rational, meaning they pursue their own maximum benefit. There is also lazy voting, where only a small portion of people actually vote. Voting rights are overly concentrated, with large holders often having more influence.

Off-chain governance is closer to the way we operate in real society compared to on-chain governance. On-chain governance is not a design issue; it is a community institutional issue. "How to better develop the blockchain" ranks second compared to "What development goals should blockchain projects set." In the process of pursuing their own goals, communities will spontaneously find the best governance structure. Artificial designs may have many loopholes and defects, limiting their developability.

For example, on-chain governance has at least the following issues.

Tragedy of the Commons: When everyone thinks someone else will vote, no one votes. A typical case is the Brexit referendum. On-chain voting on the blockchain may encounter similar issues.
Witch Attacks: Currently, it is difficult for the blockchain to map real-world identities. On-chain governance refers to the process by which people directly initiate community proposals and make decisions on the blockchain. The first requirement here is that the blockchain supports a basic governance protocol, which can stipulate or enforce proposals; on-chain governance directly determines the development direction of the blockchain itself.

The participants in on-chain governance include four groups: investors, users, developers, and miners.

Various types of on-chain governance

Bitcoin BIP and Block Voting: Although Bitcoin does not provide a complete on-chain governance mechanism, it does support a simple voting mechanism. For example, miners can write consensus information in a block to indicate support for a proposal, such as filling in NYA in a block to show support for the New York Consensus. However, all of this is based on Bitcoin's BIP; there must be a BIP to initiate a vote. The organizational structure of BIPs is relatively community-oriented, mainly composed of some developers and core community members on GitHub. All actions by miners are also non-mandatory; when a mainnet upgrade occurs, miners can still choose not to upgrade, which could lead to a fork, something everyone wishes to avoid.
Ethereum Gas Limit Voting: Ethereum provides a parameter for the upper limit of gas consumption—Gas limit. Miners vote to increase or decrease the Gas limit, which determines the number of smart contracts that can be processed in a single block. However, this only pertains to this specific function and does not determine the overall development of the blockchain. In fact, Ethereum's development is significantly influenced by Vitalik himself, and the driving forces behind Ethereum governance are the core members and early capital.
BitShares BTS and EOS On-chain Governance: We previously introduced the on-chain governance structure of the EOS blockchain—the blockchain constitution. In reality, the constitution does not have mandatory binding force, but it has become a form of community binding force, similar to an oath-taking process. The governance structure of EOS and BitShares comes from the voting process provided by the DPoS algorithm, where voting is weighted based on the amount of coins held. Among the four roles of users, investors, developers, and miners, miners and investors are combined, which poses a significant risk due to capital coercion.

Based on the above governance structures, we categorize Bitcoin and Ethereum as one type, which tends to lean towards off-chain governance, while EOS and BitShares lean towards on-chain governance.

For example, on-chain governance has at least the following issues.

Tragedy of the Commons: When everyone thinks someone else will vote, no one votes. A typical case is the Brexit referendum. On-chain voting on the blockchain may encounter similar issues.
Witch Attacks: Currently, it is difficult for the blockchain to map real-world identities. If voting is based on identity, large holders can impersonate multiple fake identities to vote. Before the emergence of blockchain digital identities, on-chain governance could only rely on the quantity of coins for weighted voting. This leads to a situation where one coin equals one vote, giving voters with more coins greater influence.
Vote Buying: This is actually an extension of witch attacks. On-chain governance nodes can promise to share the profits they receive with other nodes. This form of vote solicitation is essentially vote buying. If malicious nodes can bribe their way into becoming accounting nodes, they can influence the blockchain upgrade process, leading to very dire consequences. Currently, controlled governance by founding teams is the most common practice. After the community becomes strong, the founding team exits and lets the community operate itself, which is a typical "Satoshi Nakamoto model." On-chain governance is indeed a hot topic; it focuses on the development of the blockchain itself and could be an important research method for blockchain. However, this is not something that technology can solve, so the outlook is not very optimistic.

The rapid development of blockchain across various industries has brought new opportunities. From digital currency to digital assets, digital currency serves as the settlement layer for digital assets, and the economic activities of digital assets depend on digital currency. Digital currency is generally limited to public chain projects, while digital assets rely on the ecosystem provided by public chains. This supportive structure determines that there will not be many types of digital currencies, while there will be a vast number of digital assets. Currently, a large number of digital currencies will eventually disappear by more than half, leaving only a few with rich ecosystems to support a multitude of digital assets. These public chains will complete intercommunication and exchange through some large centralized trading platforms, while smaller trading platforms will mostly serve vertical digital assets.

Bitcoin itself is the most successful digital currency project and also the most successful blockchain project. The application ecosystem of Bitcoin mainly focuses on global borderless payment settlements. Since Bitcoin itself is a native asset, it is not anchored to any other asset, so the application ecosystem of Bitcoin depends on people's consensus, which Bitcoin has already achieved. As long as there is no major turmoil in the Bitcoin community, its status is difficult to surpass, even with many new blockchain technologies emerging, such as improving consensus efficiency and increasing network capacity.

However, Bitcoin's consensus has gone through nearly a decade of historical development, forming a mature and stable ecological structure that cannot be replaced technically. Therefore, Bitcoin will continue to serve as the primary payment method in the internet domain and extend to offline scenarios. In addition to Bitcoin, there are also stable digital currencies like Tether and bitCNY, which are characterized by being anchored to fiat currencies. They can also be anchored to physical assets, but we have not reached that point yet. In summary, we can categorize digital currencies into two main types: native digital currencies and anchored digital currencies.

Native digital currencies have the following characteristics:

Non-profit community autonomy;
Reliance on social consensus recognition;
Super settlement tools;
Can be used to support digital assets.

Anchored digital currencies have the following characteristics:

Commercial autonomy;
Reliance on a wide range of accepting merchants;
Stable payment settlement tools;
Can be used to support digital assets.

I classify digital assets, and the financial activities generated by digital assets are referred to as digital finance, which is also known domestically as tokens and token economies, with similar meanings. Token is the most direct manifestation of digital assets, and the ecological structure of tokens is spontaneous and native, which can be roughly divided into several types.

One type is infrastructure-type ecosystems, another is financial-type ecosystems, and another is commercial vertical application ecosystems. All three types of ecosystems have great potential.

Infrastructure-type tokens generally refer to the equity tokens of public chains. Many public chains are researching this field, and this is also the most urgent area that needs to be broken through. With mature infrastructure, blockchain applications can be widely popularized. A typical example of this type of token is Ether on Ethereum. Besides Ethereum, there are also EOS, NEO, etc. It can be said that any public chain capable of supporting token issuance has high potential value. They are currently in a warlord period, and it is difficult to determine whether they will later be vertically segmented or unified. Additionally, infrastructure-type tokens themselves also possess the functions of digital currencies.

Financial-type tokens are typified by stable digital currencies like Tether, bitCNY, and tokens from trading platforms, such as Huobi's HT, OKEX's OKB, and Binance's BNB. The typical characteristic of these tokens is that they create liquidity for native digital assets, which is an inevitable result of the development of digital finance.

Financial-type tokens are somewhat akin to securities and can only generate in places with high liquidity, such as digital asset exchanges and accepting platforms. Commercial vertical ecosystem-type tokens have significant commercial potential and release the greatest energy. This does not refer to a single token but rather a class of tokens formed by a specific commercial ecosystem. For example, a game streaming platform can create a type of token.

The designers of these tokens face two challenges. First, practitioners need to understand blockchain, which means understanding not only the technical principles of blockchain but also the thinking inherent in blockchain. I categorize this thinking into two types: the first type is open product forms, and the second type is community co-governance. Secondly, practitioners may easily get stuck in traditional internet-era business models, such as content or traffic-based apps, where the performance is limited to advertisements and memberships, making it difficult to think outside the box. It is important to note that future commercial vertical tokens will almost certainly be native digital assets, so following Alibaba or Tencent's model may not lead to the right direction in blockchain. The future of these tokens will certainly be new versions of Alibaba and Tencent.

I predict that these tokens will greatly change the operational model of internet products. Under the token model, product operations will bring users and operators closer together; they will no longer be in opposition but will form a symbiotic community governance relationship in a blockchain manner. The governance model of blockchain will also influence the operational model of products. Finally, let's summarize that the dependency relationships among the above three types of tokens are:

Commercial vertical ecosystem-type tokens depend on infrastructure-type tokens;
Financial-type tokens depend on infrastructure-type tokens;
Commercial vertical ecosystem-type tokens may depend on financial-type tokens.

The liquidity size of tokens is ranked as follows: infrastructure-type tokens > financial-type tokens > commercial vertical ecosystem-type tokens.

The distribution of the number of token types is ranked as follows: commercial vertical ecosystem-type tokens > financial-type tokens > infrastructure-type tokens.

From this perspective, there are only two types of tokens. Ordinary tokens:

Point-type Tokens: These tokens may be quite common, as we often encounter them, such as supermarket points, product points, etc. This may represent a change in the form of product operations, and compared to the original points system, liquidity may be improved.
Membership-type Tokens: Most membership marketing methods essentially involve pre-selling usage rights, such as pre-selling Apple phones, which do not have to be limited to a specific distributor and can be pre-sold through token issuance. This type of token can also be mapped to current real-world scenarios.
Dividend-type Tokens: A typical example of this type of token is Binance's BNB. Profit buybacks are a common method for dividend-type tokens, but due to insufficient transparency in operations, they may encounter issues.

Value-type tokens will inevitably touch upon changing existing production relationships. Just as it is difficult to explain what equity corresponds to when someone first encounters the concept of equity, tokens are in a similar situation. Tokens have programmable properties, which can bring together multiple attributes.

Usage rights indicate that tokens can deliver products or services;

Tradability: liquidity is a basic demand for digital assets;

Appreciation: this is an additional attribute brought about by the second point, which is appreciation.

Token technology stack comparison: Token implementations already have Ethereum's ERC20-based ecosystem, BitShares' SmartCoin ecosystem, NEO's NEP-5 ecosystem, Quantum Chain's QRC20 ecosystem, and the Metaverse's MST ecosystem.

Centralized exchanges are the mainstream application, so today I mainly introduce digital currency trading platforms under centralized models. Two sets of ledgers

The technology of digital currency trading platforms basically follows the system architecture of financial trading technology, only replacing the parts originally aimed at fiat currencies and securities (or platform tokens), which we usually refer to as the fund management system, entirely with a digital currency management system aimed at digital currencies. In other words, it is just a change of internal ledgers. However, we know that the blockchain itself is also used for accounting, which can be considered a type of financial ledger. Therefore, there are two sets of ledgers: how to manage these two sets of ledgers is the primary task of the fund management system.

Digital Currency Exchange

This image illustrates that the left side represents multiple blockchain ledgers, while the right side shows that the digital currency exchange has its own internal ledger. These two ledgers are independent. The internal ledger of the exchange records trades, which are generated by user orders being matched by the matching engine, while transactions on the blockchain ledger occur only when users initiate deposit or withdrawal requests and they are executed.

Both types of transactions use the Chinese term "交易" (transaction) to represent them, but they belong to different contexts. The former transaction refers to asset exchange in the context of financial transactions, which is a Deal; the latter refers to a technical concept on the blockchain, representing a record-keeping process of asset transfer. The above is intentionally expressed in English to highlight the distinction, and I hope you can differentiate between them.

What systems does a digital currency exchange include? The backend of a digital currency exchange actually consists of at least four parts: Web business logic system, trading matching system, operational backend management system, and fund management system. The fund management system is actually the internal ledger mentioned earlier.

System Modules of Digital Currency Exchange

Web Business Logic System: This module typically includes user account modules, login gateways, account security management, KYC verification, market data push, etc. This module is more user-oriented and is very similar to typical e-commerce account systems.

Trading Matching System: This module is the core module of an exchange, providing order matching for all users.

Operational Backend Management: This module is a system used by exchange operators, accessible only to internal personnel.

Fund Management System: The fund management system actually consists of three parts: the first part is the fiat payment gateway, which may need to connect to banks or third-party payment institutions; the second part is digital currency wallet management, which provides payment functions for most mainstream digital currencies; the third part is user holding information, which records how much digital currency a user holds. This is stored in the database and does not need to be consistent with the blockchain, but the exchange's general ledger must balance.

Characteristics of each module: The web business system is no different from our common e-commerce systems, mainly focusing on user accounts and simple business logic, with an emphasis on scalability and flexible business requirements. The trading matching system is essentially a high-concurrency computing system, characterized by high system performance and good stability. The order queue can be a data container in programming languages or an in-memory database.

The operational backend system does not highlight its importance in the early lifecycle of the exchange, but it becomes the core system for the later development of the exchange, focusing on data accuracy, requiring high network security and good scalability. The fund management system includes user holding status and digital currency wallet services, making it the system with the highest security requirements in a trading platform. The fund management system often needs to be paired with an in-memory database, and the digital currency wallet service can also be separated into an independent subsystem or even transformed into the company's internal blockchain explorer, as the wallet service needs to be designed with multiple wallet instances and unify all currency wallet interfaces.

System Architecture of Digital Currency Exchange

In the image, MatchingGroup corresponds to the trading matching system; Web-Group corresponds to the web business logic system; Backoffice corresponds to the backend management system; AssetsManagement corresponds to the fund management system.

Involved technology stack: If we further break down the modules mentioned earlier, we will see the following functions.

Technology Stack of Digital Currency Exchange

According to the detailed functions in the above image, we can clearly see which technologies support them. First, the server needs a database as support, followed by Restful API as the basic communication protocol, and integration of wallet-related technologies, with the matching engine providing matching services to the server. For example, an SMS system may be needed, so cloud service SMS components can be used; these can all be mature general component technologies. We can find that the technologies used in centralized trading are not different from internet technologies. By placing these general components into the various layers and major modules in the diagram below, the final detailed architecture of a trading platform may look like this:

Detailed Architecture of Trading Platform

First, for storage, persistent storage can typically choose MySQL. The matching-related modules need to avoid disk IO, so they require Redis-type in-memory storage, and both need to ensure eventual consistency. The matching and market data parts are almost identical to traditional technologies, with market data push comparable to other push systems, just at a higher frequency, generally preferring WebSocket technology. The biggest difference from traditional internet applications lies in digital currency wallet management, which presents significant challenges regarding security and usability. This is also fundamental to the custody of funds in exchanges, so managing a large amount of digital currency often requires combining operations, internal management systems, and hot/cold wallet technologies to effectively manage the funds of the exchange.

So how do users place orders, and how do blockchain transactions occur? Let's take a look.

Transaction Process#

So, what does the process look like when User A exchanges 0.01 BTC for 10 ETP from User B? Let me give an example.

User A places a buy order for 10 ETP at a price of 0.01 BTC, which enters the matching system's order book ETP-BTC buy order queue through the web business system, waiting to be matched. Meanwhile, the fund management system freezes 0.01 BTC.
User B places a sell order for 10 ETP at a price of 0.01 BTC, which enters the matching system's order book ETP-BTC sell order queue through the web business system. This successfully matches with User A's order from step 1, generating a trade. At the same time, the fund management system settles the corresponding assets, with User B's assets changing to an increase of 0.01 BTC and a decrease of 10 ETP, while User A increases by 10 ETP and decreases by 0.01 BTC.
The completed trade and asset changes are written to the RDB database by the fund management system, forming a transaction record, while also updating the market data database for user and operational backend management system queries. It is important to note that this step is not recorded on the blockchain.
User B initiates a withdrawal request through the web business system, requesting to withdraw 10 ETP into their digital currency wallet. This request enters the fund management system, and exchange operational personnel can observe this request through the operational backend. They review User B's information, such as whether real-name authentication is normal.
After the withdrawal request enters the operational system, if it passes the review, the fund management system will freeze User B's 10 ETP and send the withdrawal request to the digital currency wallet service system, which is the WalletGroup. The subsystem initiates a blockchain transaction x (Transaction), waiting for the transaction to be packaged and updating the withdrawal review status for user viewing.
The digital currency wallet service checks whether transaction x has been packaged based on the block information. If it has been packaged, the fund management system will completely wipe out the 10 ETP frozen for User B, updating the withdrawal status to complete and providing the block transaction ID for user and operational backend system queries.

In step 3, we can see that the assets held by the user are essentially the exchange's liabilities to the user, but this is only in the database and not true on-chain assets.

In step 6, we see that the "transaction" on the blockchain is completely different from the "transaction" in step 3. Whether the user's assets are secure entirely depends on whether the technology of the trading platform is secure and whether there is trust in the exchange.

Now let's look at the deposit phase. In simple terms, depositing is the opposite process of withdrawing. The difference is that deposits do not require review. Generally, the principle of digital currency exchanges is "easy in, strict out." During the deposit process, trading platforms typically do not directly use digital currency wallets to check whether the user has deposited, but instead use a method called "block scan" to detect user deposits.

Classification of Digital Currency Wallets#

Currently, there are many types of digital currency wallets on the market, which may seem a bit dazzling. However, we can categorize them for a quick understanding. The following diagram shows blockchain wallets distinguished by different attributes.

Classification of Blockchain Wallets

The leftmost wallet is classified according to user-end platforms. This type of wallet actually runs on the server side, and the user-end wallet is merely a proxy, making it very convenient for users as they do not need to care about the wallet's details. A typical example is various online wallets. The second wallet from the left is classified according to currency type, mainly referring to whether this wallet supports multiple currencies. The multi-currency here can be based on multiple currencies on the same blockchain, such as Ethereum ERC20 tokens, or can integrate different blockchains like Bitcoin and Ethereum.

The second wallet from the right is distinguished by how private keys are stored. This mainly involves whether the user's private key is hosted by the platform. If it is not hosted and is directly stored on the user side, such as hardware, terminal devices, or paper records, these can be referred to as on-chain wallets. If the user cannot access the private key and it is hosted on the platform, then this type of wallet is also referred to as an off-chain wallet. The rightmost wallet is classified according to access methods, such as wallets that can be jointly managed by multiple people, which also require multi-signature support; otherwise, they become personal private wallets.

This classification is not absolute; a wallet can possess multiple different attributes. For example, a mobile wallet may provide on-chain functionality, multi-signature support, and multi-currency support. This type of wallet is usually quite popular in the industry. However, for platform providers, the above wallet types may not sufficiently support their platform's needs and achieve optimal effectiveness. After all, as a platform, the requirements for high availability, fork detection, and block confirmation are far higher than those of ordinary wallets. How to solve these issues introduces a new technology: Block Scan Technology.

We previously introduced in-depth blockchain technology that the four core technologies constituting blockchain are: P2P network protocol, distributed consensus algorithm, cryptographic signature algorithm, and account and transaction model. These four technologies correspond to four major modules in digital currency wallets: P2P network, persistent storage, account and private key management, and consensus and transaction verification.

Among them, the persistent storage module is provided by the embedded database that comes with full-node wallets, with various choices such as LevelDB, BerkeleyDB, SQLite3, etc. However, regardless of which embedded database is chosen, there is a severe issue: fine-grained transaction query verification and performance cannot coexist. In other words, no full-node embedded database can compete with server-level databases. For platform development, it is clearly more appropriate to choose server-level databases. This raises the question of how to convert the data in full-node wallets into data in database servers, which requires a scanning block technology, abbreviated as block scan. Block scan, as the name suggests, refers to the process of scanning all blocks in a full-node wallet, parsing them, and storing them in a database server. These databases can be MongoDB or MySQL, depending on your business needs.

We can take the example of the Metaverse blockchain's block structure, which is similar to Bitcoin's, and you can compare it to Bitcoin's blockchain. Below is Python code demonstrating the relational table structure based on MySQL, aimed at scanning blocks from the Metaverse's embedded database and storing them in MySQL.

def init_table(conn):
    tables = []
    tb_block = '''
    create table if not EXISTS block (
        number bigint primary KEY,
        hash char(64) not null,
        bits bigint,
        transaction_count INTEGER,
        mixhash VARCHAR (128),
        version char(8),
        merkle_tree_hash char(64),
        previous_block_hash CHAR (64),
        nonce varchar(128),
        time_samp bigint
    ) DEFAULT charset=utf8;
    '''
    tb_tx = '''
    create table if not EXISTS tx (
        id bigint PRIMARY KEY,
        block_height bigint REFERENCES block(id),
        hash char(64) not null
    ) DEFAULT charset=utf8;
    '''
    tb_address = '''
    create table if not EXISTS address(
        id int PRIMARY KEY,
        address VARCHAR (64) UNIQUE
    ) DEFAULT charset=utf8;
    '''
    tb_output = '''
    create table if not EXISTS tx_output(
        id bigint PRIMARY key,
        hash char(64) NOT NULL,
        tx_id bigint REFERENCES tx(id),
        output_index bigint not null,
        output_value bigint,
        address_id bigint REFERENCES address(id),
        script varchar(1024),
        asset varchar(64),
        decimal_number varchar(8)
    ) DEFAULT charset=ascii;
    '''
    tb_output_fork = '''
    create table if not EXISTS tx_output_fork(
        id bigint PRIMARY key,
        hash char(64) NOT NULL,
        tx_id bigint,
        output_index bigint not null,
        output_value bigint,
        address_id bigint,
        script varchar(1024),
        asset varchar(64),
        decimal_number varchar(8)
    ) DEFAULT charset=ascii;
    '''
    tb_tx_fork = '''
    create table if not EXISTS tx_fork (
        id bigint PRIMARY KEY,
        block_height bigint,
        hash char(64) not null
    ) DEFAULT charset=ascii;
    '''
    tb_input_fork = '''
    create table if not EXISTS tx_input_fork(
        id bigint PRIMARY key,
        tx_id bigint,
        belong_tx_id bigint,
        tx_index bigint,
        tx_value bigint not null,
        script varchar(1024),
        address_id bigint,
        asset varchar(64),
        decimal_number varchar(8)
    ) DEFAULT charset=ascii;
    '''
    tb_block_fork = '''
    create table if not EXISTS block_fork (
        number bigint primary KEY,
        hash char(64) not null,
        bits bigint,
        transaction_count INTEGER,
        mixhash VARCHAR (128),
        version char(8),
        merkle_tree_hash char(64),
        previous_block_hash CHAR (64),
        nonce varchar(128),
        time_samp bigint
    ) DEFAULT charset=ascii;
    '''
    tb_output_asset = '''
    create table if not EXISTS tx_output_asset(
        id bigint PRIMARY key,
        hash char(64) NOT NULL,
        tx_id bigint REFERENCES tx(id),
        output_index bigint not null,
        output_value bigint,
        address_id bigint REFERENCES address(id),
        asset_name varchar(64),
        issuer varchar(64),
        asset_type varchar(8),
        description varchar(64)
    ) DEFAULT charset=utf8;
    '''
    tb_input = '''
    create table if not EXISTS tx_input(
        id bigint PRIMARY key,
        tx_id bigint REFERENCES tx(id),
        belong_tx_id bigint REFERENCES tx(id),
        tx_index bigint REFERENCES tx_output(output_index),
        tx_value bigint not null,
        script varchar(1024),
        address_id bigint REFERENCES address(id),
        asset varchar(64),
        decimal_number varchar(8)
    ) DEFAULT charset=ascii;
    '''

Based on the structure of the Metaverse blockchain, we can categorize the tables into four major types: the first type is blocks, the second type is transactions, the third type is transaction inputs and outputs (tb_input, tb_output), and the fourth type is fork handling. Below, I will post a typical block and transaction displayed in JSON format, allowing you to compare their relationships with the above tables.

Block and Transaction Example

From the development of trading platforms, we can summarize the digital currency wallet service.

The digital currency wallet service can provide unified APIs for other modules of the trading platform while structuring different data into database services. Finally, traditional high-availability methods can be used to complete transaction queries and verifications. Of course, this also relates to the scale of the exchange. If it is a small exchange, block scanning may not be necessary, but a unified API is essential. I believe that digital currency wallet services should have a standard wallet service framework that supports mainstream digital currencies, thereby lowering the usage and deployment thresholds for everyone. This aligns with the concept of "Blockchain as a Service" we discussed in the previous article. It can be said that the supporting facilities and technologies of blockchain are still very primitive, with significant room for development and improvement.

Back-end Structure of Metaverse Blockchain

In the back-end part, the Metaverse blockchain undertakes the functions of goods tracking and order matching, and all participants can obtain on-chain order information by building their own Metaverse blockchain node services. In the front-end part, staff can obtain order data through mobile devices, and they can also obtain data about goods through IoT Bluetooth sensors, then upload it to the server, which selects and calculates before registering it on the Metaverse blockchain.

Comparison of both: Public chain solutions have the following advantages compared to DLT technology:

High transparency: For publicly available information, ordinary buyers in the retail sector can query product origins through blockchain explorers.
Immutability: Due to the stronger immutability of public chain consensus algorithms compared to DLT technology and the larger number of participating nodes, the authenticity and reliability of data are better.
Token transfer: Since the blockchain itself supports token registration, logistics bills can be made into tokens and transferred as valuable securities.
Strong participation: Any customer, government, or regulatory agency can participate in the entire supply chain process or a specific segment and track and browse certain public or non-public information related to them.

Sharing the infrastructure of public chains means that participants do not need to build visual web services; they can directly use blockchain explorers, and goods tokens can also participate in secondary trading on trading platforms. DLT technology has the following advantages compared to public chain solutions:

High controllability: DLT technology generally strictly controls participants, ensuring the rights and interests of core enterprises.
Quick implementation: The solutions and ideas extend traditional technologies, making implementation convenient and requiring a low cognitive threshold for participants.
Better anonymity: Generally, public chains do not provide clear permission management and anonymity technologies, so enterprise data must be desensitized before being recorded on-chain, whereas DLT technology does not have this issue.

What is the current state of the industry and the actual talent demand? Let's take a look. The talent demand in the blockchain field can generally be divided into the following categories:

Building distributed ledger applications based on DLT technology according to customer needs, implementing business requirements on DLT, which is very close to traditional solution-type talents.
Companies that already have certain industry experience aim to select a public chain through technology selection and develop blockchain-based applications on that public chain. Currently, projects in gaming and social categories are relatively mature, with gaming projects like CryptoKitties and LeBloc, and content community projects like Steemit, CoinAsk, and CoinHoo. This type of project can integrate well with existing technologies, utilizing the asset digitization characteristics of blockchain at the business level, with significant commercial potential and ample room for technological development, while having a low entry threshold and risk.
Companies that have obtained financing or initiated ICOs overseas aim to develop the next generation of public chains. This type is created to address the shortcomings of existing blockchain technologies, with the greatest potential for technological development but also the highest entry threshold and risk.
Blockchain ecological infrastructure types. Digital asset trading platforms, digital asset management, mobile wallets, hardware cold wallets, digital financial media, blockchain consulting, mining pool operations, etc., all belong to this category. These are currently the most profitable blockchain industries, with considerable room for technological development, low entry thresholds, and low risks.

Currently, the supply of talent in the blockchain field is far from sufficient to support such a vast market. In other words, talent is extremely scarce, and the scarcity of talent sharply contrasts with the excessively high valuations, leading to the formation of bubbles.

Related to the above classifications are the programming languages corresponding to industry demands.

DLT Technology: Due to the popularity of Hyperledger, DLT is primarily based on Golang, but it will also involve issues of application visualization and interaction. After all, when delivering to customers, it is unrealistic to expect them to use command lines, so some front-end technology is inevitably required.
Public Chain Applications: With the existence of smart contracts, the threshold for using blockchain has significantly lowered. The most popular Ethereum smart contracts are written in a JavaScript-like language called Solidity, and there are now smart contract blockchains that do not limit programming languages. In fact, I believe Solidity is much safer than other fully open smart contracts, so I recommend starting with Ethereum if you plan to learn smart contracts.
Developing Your Own Public Chain: Currently, mainstream static compiled languages are most commonly C++ and Golang, with public chains implemented in Rust, Java, and C#. SPV lightweight wallets are often implemented in Java, Python, and JavaScript. It can be said that public chain development almost involves mainstream programming languages.
Commercially Closely Related to Blockchain: This category is the most closely related to blockchain in business but is the least related in technology. The overall technology stack is not much different from traditional internet network technology. For example, building a blockchain financial website may not require any blockchain technology, but it has high requirements for content operation.