On-chain governance

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 specify 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 participate in governance through voting, while in off-chain governance, the majority reaches consensus through various online and offline interactive methods such as proposals and community meetings. The three consensus events in the expansion debate are typical examples 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 cannot determine the overall development of the blockchain. In fact, Ethereum's development is heavily influenced by Vitalik himself, and the driving force behind Ethereum governance mainly comes from core members and early capital.
BitShares BTS and EOS On-chain Governance: We have previously introduced the on-chain governance structure of the EOS blockchain—the blockchain constitution. In fact, the constitution does not have mandatory binding power, 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 number of coins held. Among the four roles of users, investors, developers, and miners, miners and investors are merged, 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 have some issues. The actual executors of upgrades, the miners, are always rational, seeking to maximize their own interests. There is also lazy voting, where only a small portion of people will 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" is secondary to "What development goals should blockchain projects set." In the process of pursuing their goals, communities will spontaneously find the best governance structure. Artificial designs may have many loopholes and defects, which also limits their developability.

For example, on-chain governance at least faces the following issues:

Tragedy of the Commons: When everyone thinks that others will vote, no one ends up voting. 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 specify 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 cannot determine the overall development of the blockchain. In fact, Ethereum's development is heavily influenced by Vitalik himself, and the driving force behind Ethereum governance mainly comes from core members and early capital.
BitShares BTS and EOS On-chain Governance: We have previously introduced the on-chain governance structure of the EOS blockchain—the blockchain constitution. In fact, the constitution does not have mandatory binding power, 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 number of coins held. Among the four roles of users, investors, developers, and miners, miners and investors are merged, 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 at least faces the following issues.

Tragedy of the Commons: When everyone thinks that others will vote, no one ends up voting. 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 number of coins for weighted voting. This results in one coin one vote, giving voters with more coins greater influence.
Bribery: This is actually an extension of witch attacks. On-chain governance nodes can promise to share the profits they receive with other nodes. This method of soliciting votes is essentially bribery. If malicious nodes can bribe their way into becoming accounting nodes, they can influence the blockchain upgrade process, leading to very serious consequences. Currently, controlled governance by founding teams is the most common practice. After the community becomes strong, the founding team can withdraw and let the community operate on its own, 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, it is not something that technology can solve, so the outlook is not very optimistic.

The rapid development of blockchain in 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 currencies are generally only public chain projects, while digital assets rely on the public chain ecosystem for support. This supporting structure determines that there will not be many types of digital currencies, while there will be a lot of digital assets. Currently, a large number of digital currencies will eventually disappear by more than half, leaving only a few digital currencies with rich ecosystems to support numerous digital assets. These public chains will complete intercommunication and exchange through some large centralized trading platforms, while small trading platforms mainly 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 are no major upheavals in the Bitcoin community, Bitcoin's 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 field 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; it's just that we haven't reached that point yet. In summary, we can categorize digital currencies into two main types: native digital currencies and stable digital currencies.

Native digital currencies have the following characteristics:

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

Stable digital currencies have the following characteristics:

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

I classify digital assets as digital finance, which is also known domestically as tokens and token economies, with similar meanings. Tokens are the most direct representation of digital assets, and the ecological structure of tokens has spontaneity and originality, 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 public chains capable of supporting token issuance have 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 typically represented by stable digital currencies like Tether and bitCNY, as well as 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 most energy. This does not refer to a single token but rather a type of token formed by a certain commercial ecosystem. For example, a game live 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 an open product form, and the second type is community co-governance. Secondly, practitioners are often constrained by traditional internet-era business models, such as content or traffic-based apps, where the performance is limited to advertising and membership, 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 the models of Alibaba or Tencent may not lead to the right direction in blockchain. The future of these tokens will certainly be new Alibabas 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 rather in a symbiotic community governance relationship. The governance model of blockchain will also influence the operational model of products. Finally, we summarize that the dependency relationships among the 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 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: This type of token may be quite common, as we often encounter it, such as supermarket points, product points, etc. This may have changed the form of product operations, and compared to the original points system, liquidity may have improved.
Membership-type: Most membership marketing methods are essentially pre-sales of usage rights. For example, the pre-sale of Apple phones does not have to be limited to a specific distributor and can be conducted through the issuance of tokens. This type of token can also be mapped to current real-world scenarios.
Dividend-type: 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 the original production relationships. Just like when a person first encounters the concept of equity, it is difficult to explain what equity corresponds to; tokens are in a similar situation. Tokens have programmable attributes, which can bring together multiple attributes.

Usage rights indicate that tokens can deliver products or services;

Tradability: Liquidity is a basic requirement for digital assets;

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

Token technology stack comparison: The implementation of tokens already has the ERC20-based Ethereum 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 the centralized model. Two sets of ledgers.

The technology of digital currency trading platforms basically adopts the system architecture used in 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 a change of internal ledgers. However, we know that the blockchain itself is also used for bookkeeping, 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

The left side of the diagram 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 that are matched by the matching engine, while the 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 indicate, but they belong to different contexts. The former indicates asset exchange in the context of financial transactions, which is a Deal; the latter indicates a technical concept on the blockchain, representing a bookkeeping process of asset transfer. The above is specifically expressed in English to highlight the distinction, and I hope you can differentiate between them.

What systems does a digital currency exchange contain? 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 usually includes user account modules, login gateways, account security management, KYC authentication, 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 here 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 position 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 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 in the later stages of the exchange's development, focusing on data accuracy and requiring high network security and good scalability. The fund management system includes user position 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 wallet services need to be designed as multiple wallet instances and unify all currency wallet interfaces.

System Modules Overview

In the above diagram, 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 various modules mentioned earlier, we can see the following functions.

Technology Stack Overview

According to the detailed functions in the above diagram, we can clearly see which technologies support them. First, the server needs a database as support; secondly, a Restful API serves as the basic communication protocol, and wallet-related technologies are integrated. The matching engine provides matching services for the server. For example, an SMS system may be needed, so the SMS component from cloud services can be used. These can all be mature general component technologies. We can find that the technologies used in centralized trading are no different from internet technologies. By fitting 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 the diagram below.

Detailed Architecture of Trading Platform

First, for storage, persistent storage can typically choose MySQL. The modules related to matching 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 no different from traditional technologies. Market data push can be likened to other push systems, just with a higher frequency, generally preferring WebSocket technology. The main difference from traditional internet applications lies in digital currency wallet management, which presents significant challenges in terms of 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 you 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. Meanwhile, the fund management system settles the corresponding assets, resulting in user B's assets increasing by 0.01 BTC and decreasing by 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 through the fund management system, forming a transaction record, and simultaneously 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 operators 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 transaction x (Transaction) on the blockchain, 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 completed 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 trading platform's technology is secure and whether there is trust in the exchange.

Now let's take a 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 usually do not directly use digital currency wallets to check whether the user has deposited, but instead use the method of "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 to quickly understand. The following diagram shows blockchain wallets distinguished by different attributes.

Classification of Digital Currency Wallets

The leftmost wallet is categorized by 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 worry about wallet details. A typical example is various online wallets. The second wallet from the left is categorized by currency type, mainly indicating whether this wallet supports multiple currencies. Here, multiple currencies can refer to multiple currencies on the same blockchain based on Ethereum ERC20 tokens or a combination of different blockchains like Bitcoin and Ethereum.

The second wallet from the right is categorized by the way 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 end, such as hardware, terminal devices, or paper records, these can be referred to as on-chain wallets. If users cannot access the private key and it is hosted on the platform, then this type of wallet is referred to as an off-chain wallet. The rightmost wallet is categorized by access method, 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 have multiple different attributes. For example, a certain mobile wallet may provide on-chain functionality, multi-signature support, and multi-currency capabilities. This type of wallet is usually quite popular in the industry. However, for platform providers, the above wallet types may not be sufficient to meet their platform 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.

As we previously discussed in-depth blockchain technology, the four core technologies that constitute blockchain are: P2P network protocols, distributed consensus algorithms, cryptographic signature algorithms, and account and transaction models. These four technologies correspond to digital currency wallets as four major modules: 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 options like 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 compare 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, referred to as block scanning. Block scanning, 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 block scanning in the Metaverse blockchain, where the block structure is similar to that of Bitcoin, allowing for a comparison to the Bitcoin 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, and the fourth type is fork handling. Below, I provide a typical block and transaction displayed in JSON format, which you can compare with the above tables.

Block and Transaction Example

The digital currency wallet service derived from trading platform development can provide unified APIs for other modules of the trading platform while structuring different data into database services. Ultimately, traditional high-availability methods can be used to complete transaction queries and verifications. Of course, this also depends on 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" that 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.

Digital Currency Wallet Service

In the backend section, 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 frontend section, staff can obtain order data through mobile devices, and they can also obtain goods data through IoT Bluetooth sensors as before, then upload it to the server, which selects and calculates the data before registering it on the Metaverse blockchain.

Comparison: Compared to DLT technology, public chain solutions have the following advantages:

High transparency: For publicly available information, ordinary purchasers in the retail sector can query product sources through blockchain explorers.
Immutability: Due to the stronger immutability of public chain consensus algorithms compared to DLT technology, and with more participating nodes, the authenticity and reliability of the data are better.
Token transfer: Since the blockchain itself supports token registration, logistics bills can be made into tokens, becoming negotiable securities for transfer.
Strong participation: Any customer, government, or regulatory agency can participate in the entire supply chain process or a specific segment, tracking and browsing certain public or non-public information.

Sharing the infrastructure of public chains, for example, 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.

Compared to public chain solutions, DLT technology has the following advantages:

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 put 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 be roughly divided into the following categories:

Based on customer needs, building distributed ledger applications based on DLT technology to implement business requirements is very similar to traditional solution-type talent.
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, leveraging the digital asset characteristics of blockchain at the business level, with significant commercial potential and ample technical development space, 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 technical development space, the highest entry threshold, and the highest 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 sectors in the blockchain industry, with considerable technical development space, low entry thresholds, and low risks. Currently, the supply of blockchain talent is far from sufficient to support such a large market. In other words, talent is extremely scarce, and the scarcity of talent sharply contrasts with the excessively high valuations, which is also 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, it is unrealistic to expect customers to use command lines when delivering to them, so some frontend technologies are 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 also 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 C++ and Golang, with public chains implemented using Rust, Java, and C#. SPV lightweight wallets are often implemented using Java, Python, and JavaScript. It can be said that public chain development almost involves mainstream programming languages.
Commercially Closely Related to Blockchain: This category has the least technical closeness, with an overall technology stack not significantly different from traditional internet network technologies. For example, building a blockchain financial website may not require any blockchain technology, but it has high requirements for content operations.