区块链算法关系图,区块链算法关系模型
请查看相关英文文档
❶ What is the relationship between artificial intelligence and blockchain?
Blockchain and artificial intelligence have been very popular in recent years
First of all, blockchain is Establish a decentralized network. The so-called decentralization means that this network does not belong to you nor to me.
It belongs to everyone.
Artificial intelligence refers to a new technical science that researches and develops theories, methods, technologies and application systems for simulating, extending and expanding human intelligence. In other words, "machine self-learning"
In this way, we can think about the combination of blockchain and artificial intelligence.
First of all, we need to understand that blockchain can currently be simply divided into three stages.
In the first three stages, there are problems: the inability to truly achieve decentralization, low scalability, incentives for block producers and the best of the entire network. Problems such as revenue mismatch and the network always running at maximum capacity. A serious waste of resources and reduced efficiency.
So can we combine artificial intelligence into the underlying public chain technology to solve these problems?
The answer is yes! And there is already a team developing it and has made certain progress.
Velas is a public chain that uses artificial intelligence (AI) optimized neural networks to enhance its consensus algorithm, perform self-learning and self-optimization, and is committed to improving the security and interoperability of the transfer process and smart contracts. flexibility, and high scalability. Velas uses AI-enhanced DPoS consensus to achieve complete decentralization without reducing security and transaction speed. Not only that, AI chooses who to mortgage tokens based on the needs of the blockchain; Velas only produces blocks when needed; between every 1 second and every 2 minutes; scalability (scalable to 30,000 TPS); block producers are selected through artificial intuition.
❷ Blockchain --- Consensus Algorithm
The PoW algorithm is a mechanism to prevent the abuse of distributed service resources and denial of service attacks. It requires nodes to perform complex operations that consume a moderate amount of time and resources, and the operation results can be quickly verified by other nodes, using time and energy as a guarantee to ensure that services and resources are used according to real needs.
The most basic technical principle in the PoW algorithm is the use of hashing algorithms. Assume that the hash value Hash(r) is found. If the original data is r (raw), the operation result is R (Result).
R = Hash(r)
The characteristic of the hash function Hash() is that for any input value r, the result R is obtained, and r cannot be deduced from R. When the input original data r changes by 1 bit, the result RThe value changes completely. In the Bitcoin PoW algorithm, the algorithm difficulty d and the random value n are introduced, and the following formula is obtained:
Rd = Hash(r+n)
This formula requires filling in the random In the case of value n, the first d bytes of the calculation result Rd must be 0. Due to the unknown nature of the hash function results, each miner has to do a lot of calculations to get the correct result. After the calculation result is broadcast to the entire network, other nodes only need to perform a hash operation to verify it. The PoW algorithm uses this method to make calculations consume resources, and verification only needs to be done once.
The PoS algorithm requires node verifiers to pledge a certain amount of funds to be eligible for mining and packaging, and the regional chain system uses a random method when selecting packaging nodes. When the node pledges The more funds there are, the greater the probability of being selected to package the block.
In POS mode, each coin generates 1 coin age every day. For example, if you hold 100 coins for a total of 30 days, then your coin age will be 3000 at this time. At this time, if you verify a POS block, your currency age will be cleared to 0, and the corresponding digital currency interest will be obtained from the block.
The process of a node producing blocks through the PoS algorithm is as follows: To become a block producing node, an ordinary node must first pledge its assets. When it is its turn to produce a block, it packages the block and then broadcasts it to the entire network. , other verification nodes will verify the legitimacy of the block.
The DPoS algorithm is similar to the PoS algorithm and also uses shares and equity pledges.
But the difference is that the DPoS algorithm uses a delegated pledge method, which is similar to the method of universal election of representatives to select N super nodes to record and produce blocks.
Voters cast their votes for a certain node. If a certain node is elected as an accounting node, then the accounting node can often use any method to reward its voters after obtaining the block reward.
These N accounting nodes will take turns to produce blocks, and the nodes will supervise each other. If they do evil, the pledge deposit will be deducted.
By trusting a small number of honest nodes, unnecessary steps in the block signing process can be removed, increasing the speed of transactions.
Byzantine problem:
Byzantium was the capital of the ancient Eastern Roman Empire. For defense, an army led by a single general was stationed in each fiefdom. Between the generals The message could only be delivered by messenger. In a war, all generals must reach a consensus and decide whether to go to war together.
However, there may be traitors within the army, and these people will influence the generals to reach a consensus. The Byzantine Generals Problem refers to the problem of how the remaining generals can reach a unanimous decision when one of the generals is known to be a traitor.
BFT:
BFT is Byzantine fault tolerance. Byzantine fault tolerance technology is a type of fault tolerance technology in the field of distributed computing. The Byzantine hypothesis is a modeling of the real world, where computers and networks may behave unpredictably due to hardware errors, network congestion or outages, and malicious attacks. Byzantine fault tolerance techniques are designed to handle these abnormal behaviors and meet the specification requirements of the problem to be solved.
Byzantine fault-tolerant system:
The failed node is called a Byzantine node, and the normal node is a non-Byzantine node.
Assuming that the distributed system has n nodes, and assuming that the entire system has no more than m Byzantine nodes (n ≥ 3m + 1), the Byzantine fault-tolerant system needs to meet the following two conditions:
In addition, the Byzantine fault-tolerant system needs to achieve the following two indicators:
PBFT is the practical Byzantine fault-tolerant algorithm, which solves the problem of inefficiency of the original Byzantine fault-tolerant algorithm. The time complexity of the algorithm is O(n^2 ), so that Byzantine fault tolerance problems can be solved in actual system applications
PBFT is a state machine copy replication algorithm. All copies operate in the process of a view (view) rotation. The master The node is determined by the view number and the set of node numbers, that is: main node p = v mod |R|. v: view number, |R| number of nodes, p: primary node number.
The consensus process of the PBFT algorithm is as follows: the client (Client) initiates a message request (request) and broadcasts it to each replica node (Replica), and one of the master nodes (Leader) initiates a proposal message pre -prepare and broadcast. Other nodes obtain the original message and send prepare messages after the verification is completed. Each node receives 2f+1 prepare messages, that is, it is considered ready and sends a commit message. When the node receives 2f+1 commit messages and the client receives f+1 identical reply messages, it means that the request initiated by the client has reached a network-wide consensus.
The specific process is as follows:
Client c sends a
When the master node receives the client's request, it needs to conduct the following verifications:
a. Whether the signature of the client's request message is correct.
Illegal requests are discarded. For a correct request, a number n is assigned. The number n is mainly used to sort the client's requests. Then broadcast a <
When replica node i receives the PRE-PREPARE message from the master node, the following verification is required:
a. Whether the signature of the master node's PRE-PREPARE message is correct.
b. Whether the current replica node has received a PRE-PREPARE message under the same v and also numbered n, but with different signatures.
c. Whether the abstracts of d and m are consistent.
d. Whether n is within the interval [h, H].
Illegal requests are discarded. Correct request, replica node i sends a
When the master node and replica node receive the PREPARE message, they need to conduct the following verifications:
a. Whether the signature of the replica node's PREPARE message is correct.
b. Whether the current replica node has received n under the same view v.
c. Whether n is within the interval [h, H].
d. Whether d is the same as d in the currently received PRE-PPREPARE
Illegal request is discarded. If replica node i receives 2f+1 verified PREPARE messages, it sends a
When the master node and replica node receive the COMMIT message, they need to conduct the following verifications:
a. Whether the signature of the COMMIT message of the replica node is correct.
b. Whether the current replica node has received n under the same view v.
c. Whether the abstracts of d and m are consistent.
d. Whether n is within the interval [h, H].
Illegal requests are discarded. If replica node i receives 2f+1 verified COMMIT messages, it means that most nodes in the current network have reached a consensus, run the client's request operation o, and return
If the master node does evil, it may assign the same sequence number to different requests, or not allocate sequence numbers, or make adjacent sequence numbers discontinuous. The backup node should have the responsibility to actively check the validity of these sequence numbers.
If the master node goes offline or does something evil and does not broadcast the client's request, the client sets a timeout mechanism. If the timeout occurs, the request message is broadcast to all replica nodes. The replica node detects that the master node has done something evil or is offline, and initiates the View Change protocol.
View Change protocol:
The replica node broadcasts
When the master node p = v + 1 mod |R| receives 2f valid VIEW-CHANGE messages, it broadcasts
The replica node receives the NEW-VIEW message from the master node and verifies that it is valid.property, if valid, enter v+1 state, and start the PRE-PREPARE message processing process in O.
In the above algorithm process, in order to ensure that the previous request can be restored during the View Change process, each replica node records some messages to the local log. When the request is executed The replica node needs to clear the record messages of the previous request.
The simplest way is to execute the consensus synchronization of the current state again after the Reply message. This is relatively expensive, so it can be executed after executing multiple requests K (for example: 100). A status synchronization. This status synchronization message is the CheckPoint message.
Replica node i sends
This is an ideal situation. In fact, when the replica node i sends a CheckPoint message to other nodes, the other nodes have not completed K requests, so they will not respond to i's request immediately. It will also follow its own rhythm, moving forward, but the CheckPoint issued at this time does not form stable.
In order to prevent i from processing requests too quickly, set a high and low water level interval [h, H] mentioned above to solve this problem. The low water level h is equal to the number of the previous stable checkpoint, and the high water level H = h + L, where L is the value we specify, which is equal to an integer multiple of the number of requests processed in the checkpoint cycle K, and can be set to L = 2K. When the request processed by replica node i exceeds the high water mark H, it will stop and wait for the stable checkpoint to change before continuing.
In blockchain scenarios, it is generally suitable for private chain and alliance chain scenarios that require strong consistency. For example, in the IBM-led blockchain Hyperledger project, PBFT is an optional consensus protocol. In Hyperledger's Fabric project, the consensus module is designed as a pluggable module and supports consensus algorithms such as PBFT and Raft.
Raft is based on a leader-driven consensus model, in which an outstanding leader (Leader) will be elected, and the LeaderWill be fully responsible for managing the cluster, and the Leader is responsible for managing the replicated logs between all nodes of the Raft cluster.
In the figure below, the Leader (S1) of the cluster will be selected during the startup process and serve all commands/requests from clients. All nodes in a Raft cluster maintain a distributed log (replicated log) to store and submit commands (log entries) issued by clients. The Leader accepts log entries from clients and replicates them among all followers (S2, S3, S4, S5) in the Raft cluster.
In a Raft cluster, a minimum number of nodes is required to provide the expected level of consensus guarantee, which is also called a quorum. The minimum number of votes required to perform an operation in a Raft cluster is (N / 2 +1), where N is the total number of members in the group, that is, at least more than half of the votes, which is why cluster nodes usually have an odd number of nodes. So, in the example above, we need at least 3 nodes to have consensus guarantees.
If the legal quorum node is unavailable for any reason, that is, the votes do not exceed half, the negotiation will not reach an agreement and new logs cannot be submitted.
Data storage: Tidb/TiKV
Log: Alibaba's DLedger
Service discovery: Consul& etcd
< p> Cluster scheduling: HashiCorp NomadCan only accommodate faulty nodes (CFT), not evil nodes
Sequential voting, only serial apply, so high concurrency Poor performance in scenarios
Raft solves the distributed consensus problem by solving the three main sub-problems surrounding Leader election and managing the security functions of distributed logs and algorithms.
When we start a new Raft cluster or a leader is unavailable, a new leader will be elected through negotiation among all member nodes in the cluster. Therefore, in a given instance, a node of a Raft cluster can be in any of the following states: Follower, Candidate, or Leader.
When the system first starts, all nodes are followers. If they do not receive the leader’s heartbeat signal within a period of time, the followers will be converted into candidates;
If a Candidate node receives votes from the majority of nodes, the Candidate can be converted into a Leader, and the remaining Candidate nodes will return to the Follower state;
Once a Leader discovers that there is a Leader in the system If a node has a higher term than itself, it will be converted to a Follower.
Raft uses a heartbeat-based RPC mechanism to detect when a new election starts. During normal times, the Leader will regularly send heartbeat messages to all available Followers (in practice, the log and heartbeat may be sent together). Therefore, the other node starts in the Follower state and remains in the Follower state as long as it receives periodic heartbeats from the current Leader.
When the Follower reaches its timeout, it will start the election process in the following way:
Based on the responses that the Candidate receives from other nodes in the cluster, the three steps for the election can be derived result.
The implementation of consensus algorithms is generally based on replicated state machines. What is a replicated state machine:
In simple terms: the same initial recognition state + the same input = Same end state. Different nodes should use the same and deterministic function to process input, rather than introducing uncertain values, such as local time, etc. It is a good idea to use replicated log. Log has the characteristics of persistence and order preservation, and is the cornerstone of most distributed systems.
With the Leader, all concurrent requests from the client can form an orderly log (status) sequence on the Leader's side to represent the order in which these requests are processed. The Leader then sends its log sequence to the Followers to maintain the global consistency of the entire system. Note that this is not strong consistency, but eventual consistency.
The log consists of log entries with a sequential number (log index). Each log entry consists of the term when it was created, and the data contained in the log, which can be of any type, from simple types to blocks of the blockchain. Each log entry can be represented by a [term, index, data] sequence pair, where term represents the term, index represents the index number, and data represents the log data.
The Leader attempts to execute replication commands on a majority of the nodes in the cluster. If the replication is successful, the command is submitted to the cluster and the response is sent back to the client. Similar to two-phase commit (2PC), but the difference from 2PC is that the leader only needs the consent of more than half of the nodes (in a working state).
Both leader and follower may crash, so the log maintained by the follower may have the following situations compared with the leader
When the leader and follower are inconsistent, the leader forces the follower to copy its own log, the Leader will try from back to front. Each time AppendEntries fails, it will try the previous log entry (decrementing the nextIndex value) until it successfully finds the consistent position point of each Follower's log (based on the two guarantees mentioned above), and then moves backward one by one. Overrides the Followers entry after this position. So missing or extra entries may persist for multiple terms.
Requires the candidate's log to be at least as up-to-date as other nodes. If not, the follower node will not vote for the candidate.
Means that each submitted entry must exist in at least one of these servers. If a candidate's log is at least as up-to-date as the other logs in the majority, it will save all committed entries, avoiding a log rollback event.
That is, at most one leader can be elected in any term. This is very important, there can only be one leader in a replica set at any time. There is more than one leader in the system at the same time, which is called brain split. This is a very serious problem and will cause data coverage loss. In raft, two points guarantee this property:
Therefore, there must be only one leader in a certain term.
When the status of nodes in the cluster changes (the cluster configuration changes), the system is vulnerable to system failure. So, to prevent this, Raft uses something called a two-phase approach to changing cluster membership. Therefore, in this approach, the cluster first changes to an intermediate state (called federated consensus) before implementing a new membership configuration. Federated consensus enables the system to be used to respond to client requests even when transitioning between configurations, and its main purpose is to improve the availability of distributed systems.
❸ Analysis of the relationship between distributed and blockchain
We have talked about the discussion of blockchain technology many times in previous articles, and also Introducing to you which programming development languages to use to implementNow for the realization of blockchain insight chain technology, today we will take a look at how to analyze and understand the structure of the blockchain from a distributed perspective.
Blockchain is the underlying technology in Bitcoin and is used to implement a centerless peer-to-peer cash system. Because there is no central organization involved, Bitcoin uses blocks Organize transaction data in the form of a chain to prevent "double spending" and reach transaction consensus.
Digital assets in the traditional sense, such as game currency, are managed in a centralized manner and can only be transferred in a single system, coordinated by a centralized organization. , usually stored in a database. From a macro perspective, blockchain and database are both used to store data, but the form of data access is different.
The blockchain is essentially a distributed database that is active in different places. The idea of multi-activity in different places was originally to solve the disaster recovery problem of the system. It has been a direction explored in the field of distributed databases for many years, but with little success because multi-activity in different places needs to solve the problem of data conflicts. This problem is actually Not easy to solve. However, the blockchain born in Bitcoin has realized the world's largest remote multi-active database in a completely new way. It is completely open, has no boundaries, supports tens of thousands of nodes and can join and exit at random.
The problem of data conflicts is even more prominent in the blockchain. Each node in the blockchain is a completely peer-to-peer multi-active architecture, and tens of thousands of nodes must reach an agreement. , who should the data be based on? The method used by Bitcoin is POW. Everyone calculates a puzzle. Whoever calculates it first will have the right to keep accounts. In this cycle, the account he keeps shall prevail in the next cycle. Everyone recalculates. Nodes competing for accounting rights decide which Quanlu transactions are packaged into blocks and synchronize the blocks to other nodes. Other nodes still need to verify the transactions in the block based on local data, unlike the master-slave nodes of the database. This is the consensus algorithm in the blockchain. Although POW consumes a lot of computing power, the advantage is that in the process of competing for accounting rights, POW only needs to calculate hashes in its own nodes and does not need to go through network voting for election. The cost of network communication is small, and it is suitable for consensus among large-scale nodes. Shahe Computer Training believes that POW is a complete, simple and crude method in the current public chain and can stand the test, but the problem is that the efficiency is too low.
So PoS and DPoS were developed later. Whoever has more assets will have the right to bookkeeping, or everyone will vote, but this also introduces economic problems. For example, the so-called vote-buying issue is difficult to control. In traditional distributed databases, it is not called a consensus algorithm, but a consistency algorithm, which is essentially the same thing. However, the number of nodes in a distributed database is generally very small, and the network is trustworthy. Usually the nodes are safe and reliable. We can basically trust every node. Even if it fails and does not respond, it will never respond. False response. Therefore, in traditional company distributed data,Raft or Paxos protocols are used to do this consensus algorithm.
❹ What is the relationship between blockchain and digital renminbi
1. my country’s digital renminbi only draws on blockchain technology
Digital RMB has the same characteristics as blockchain technology such as traceability and non-tamperability, but digital RMB only draws on blockchain technology. As a legal currency, one of the main features of digital renminbi is a centralized management model, while one of the core features of blockchain is decentralization.
Countries that have issued digital currencies based on blockchain technology include Iran, Ecuador, Uruguay, Senegal, etc., but these digital currencies have not become popular. In September 2020, executives of major European central banks stated that if central banks around the world want to issue central bank digital currencies, they do not actually need to use blockchain technology. In the case of central bank digital currencies, central banks provide " Trust”, so there is no need to use blockchain technology when the central bank steps in.
In the financial field, blockchain technology is currently used experimentally or on a small scale in digital currency, payment and settlement, digital bills, bank credit management, etc.
2. The core elements of the digital renminbi system framework are "one currency, two treasury, and three centers"
According to the "Prototype Concept of China's Legal Digital Currency", the core elements of the digital renminbi system framework The elements are "one coin, two treasury, three centers". Among them, "one currency" refers to the central bank's digital currency; "two libraries" refers to the digital currency issuance library (the database where the central bank's digital currency issuance fund is stored) and the digital currency bank library (the database where commercial banks store the central bank's digital currency); "three libraries" "Center" refers to the certification center (responsible for identity information management), registration center (responsible for digital currency ownership registration) and big data issuance center (responsible for analysis of anti-money laundering, payment behavior, etc.).
3. The characteristics of blockchain are distributed and decentralized
Digital RMB is often compared to cryptocurrencies such as Bitcoin and Ethereum that use blockchain technology. Broadly speaking, blockchain technology uses block chain data structures to verify and store data, uses distributed node consensus algorithms to generate and update data, uses cryptography to ensure the security of data transmission and access, and uses automated scripts to A new distributed infrastructure and computing method that uses smart contracts composed of codes to program and operate data.
❺ The two algorithms in blockchain DNA are
X chain and Y chain.
Two strands are introduced here, (in fact, there are no strands). These two also satisfy the corresponding relationship between DNA double strands.
For the convenience of research, these two chains are recorded as X chain and Y chain respectively. Y chain is responsible for recording transaction information. X is responsible for verifying the correctness of Y chain records. There is a certain relationship between X chain and Y chain.
Define the first block data on the X chain. Stringdata="IloveMaxwell", let M=hash(data, 10), M is the hash value of data represented by a decimal number. Search the prime number table to find a prime number P that is the smallest.
❻ Six cores of blockchain technology Algorithm
Six core algorithms of blockchain technology
Blockchain core algorithm 1: Byzantine Agreement
The story of Byzantium probably goes like this: The Byzantine Empire had huge wealth. The surrounding 10 neighbors have been around for a long time, but the Byzantine wall stands tall and is impregnable. No single neighbor can successfully invade. Any invasion by a single neighbor will fail, and it is also possible that it will be invaded by the other 9 neighbors. The Byzantine Empire's defense capabilities are so It is so strong that at least half of the ten neighbors must attack at the same time to be able to break through. However, if one or several of the neighbors agree to attack together, but betrayal occurs during the actual process, then the invaders may all be annihilated. . So each party acts cautiously and dare not trust neighboring countries easily. This is the Byzantine Generals Problem.
In this distributed network: each general has a message ledger that is synchronized with other generals in real time. The ledger contains The signature of each general can verify the identity. If there are inconsistent messages, you can know which generals have inconsistent messages. Although there are inconsistent messages, as long as more than half agree to attack, the minority obeys the majority, and a consensus is reached.
Therefore, in a distributed system, although there are bad people, bad people can do anything (not restricted by the protocol), such as not responding, sending wrong information, sending different decisions to different nodes, different wrong nodes joining together to do bad things, etc. etc. However, as long as the majority of people are good people, it is entirely possible to achieve consensus in a decentralized manner
Blockchain Core Algorithm 2: Asymmetric Encryption Technology
In the above Byzantine Agreement, if 10 generals Several of them initiating messages at the same time will inevitably cause chaos in the system, causing each to have its own attack time plan, making it difficult to coordinate actions. Anyone can initiate an attack message, but who will send it? In fact, this only requires adding a cost. That’s ok, that is: only one node can spread information within a period of time. When a node sends a unified attack message, each node must sign and stamp the message from the initiator to confirm their identity.
Today It seems that asymmetric encryption technology can completely solve this signature problem. The encryption and decryption of the asymmetric encryption algorithm use two different keys. These two keys are the "public key" and "private key" that we often hear. .Public keys and private keys generally appear in pairs. If a message is encrypted with a public key, the private key corresponding to the public key is required to decrypt it; similarly, if a message is encrypted with a private key, the public key corresponding to the private key is required to decrypt it. .
Blockchain Core Algorithm Three: Fault Tolerance Issue
We assume that in this network, messages may be lost, damaged, delayed, sent repeatedly, and the order received is inconsistent with the order sent.In addition, the behavior of nodes can be arbitrary: they can join and exit the network at any time, they can discard messages, forge messages, stop working, etc. Various human or non-human failures may also occur. Our algorithm provides excellent fault tolerance for a consensus system composed of consensus nodes. This fault tolerance includes both security and availability, and is applicable to any network environment.
Blockchain core algorithm 4: Paxos algorithm (consensus algorithm)
The problem solved by the Paxos algorithm is how a distributed system can reach agreement on a certain value (resolution). A typical scenario is that in a distributed database system, if the initial state of each node is consistent and each node performs the same sequence of operations, then they can finally obtain a consistent state. In order to ensure that each node executes the same command sequence, a "consistency algorithm" needs to be executed on each instruction to ensure that the instructions seen by each node are consistent. A general consensus algorithm can be applied in many scenarios and is an important issue in distributed computing. There are two models for node communication: shared memory and message passing. The Paxos algorithm is a consensus algorithm based on the message passing model.
Blockchain Core Algorithm Five: Consensus Mechanism
The blockchain consensus algorithm is mainly proof of work and proof of equity. Taking Bitcoin as an example, in fact, from a technical point of view, PoW can be regarded as reused Hashcash. Generating proof of work is a random process in terms of probability. To mine a new confidential currency, when generating a block, all participants must agree, and the miner must obtain PoW proof of work for all data in the block. At the same time, miners must constantly observe and adjust the difficulty of this work, because the network requirement is to generate a block every 10 minutes on average.
Blockchain Core Algorithm 6: Distributed Storage
Distributed storage is a data storage technology that uses the disk space on each machine through the network and combines these dispersed storage resources into a virtual Storage devices, data are stored dispersedly in every corner of the network. Therefore, distributed storage technology does not store complete data on each computer, but splits the data and stores it in different computers. It's like storing 100 eggs, not in the same basket, but in different places. The total sum is 100.
❼ The relationship between digital currency and blockchain
1. Blockchain and digital currency complement each other and are inseparable. Blockchain is one of the means of digital currency circulation.
2. Blockchain is the theoretical basis of digital currency. Digital currency is established on the basis of blockchain technology. Blockchain has certain guarantees for the security of digital currency. At the same time, digital currency is a block chain. The most successful application of chain technology.
Extended information: 1. Digital currency is an unregulated, digital currency, usually issued and managed by developers, and accepted and used by members of specific virtual communities. The European Banking Authority defines virtual currencies as:A digital representation of value that is not issued by a central bank or authority and is not tied to a legal tender, but because it is accepted by the public, it can be used as a means of payment and can be transferred, stored or traded electronically.
2. Digital currency can be considered as a virtual currency based on node network and digital encryption algorithm. The core characteristics of digital currency mainly reflect three aspects: ① Because it comes from certain open algorithms, digital currency has no issuing entity, so no person or institution can control its issuance; ② Since the number of algorithm solutions is determined, the digital currency The total amount of currency is fixed, which fundamentally eliminates the possibility of inflation caused by excessive issuance of virtual currency; ③ Since the transaction process requires the approval of each node in the network, the transaction process of digital currency is safe enough.
3. The blockchain shared value system was first imitated by many cryptocurrencies, and improvements were made in proof of work and algorithms, such as the use of proof of equity and SCrypt algorithms. Subsequently, the blockchain ecosystem continued to evolve around the world, with the emergence of initial coin offerings (ICO); the smart contract blockchain Ethereum; the asset tokenization sharing economy with “light ownership, heavy usage rights”; and blockchain countries. People are using this shared value system to develop decentralized computer programs in all walks of life and build decentralized autonomous organizations and decentralized autonomous communities around the world.
