Skip to main content
Front cover of 区块链实战

Book · 2020-06

区块链实战:从技术创新到商业模式

冒志鸿, 陈俊

A Chinese-language book connecting blockchain mechanisms with application design and business models.

中信出版集团 · ISBN 9787521717853

《区块链实战:从技术创新到商业模式》 is a Chinese-language book by 冒志鸿 (Robert Mao) and 陈俊, published by 中信出版集团 in June 2020. It connects blockchain mechanisms with decentralized identity, applications, smart contracts and the question of when a business needs a blockchain.

Read the corrections

Publication details

FieldDetails
Original title区块链实战:从技术创新到商业模式
Authors冒志鸿, 陈俊
Publisher中信出版集团
PublishedJune 2020
ISBN9787521717853
Original languageChinese

The Douban book record provides bibliographic information and reader discussion in Chinese. This page introduces the Chinese edition; it is not an English edition of the book.

Continue with the questions

The book’s distinction between resistance to tampering and absolute immutability remains a useful starting point. Reading it today also requires separating the original discussion from subsequent protocol changes.

From records to evidence develops questions from Chapters 1, 6, 10 and 11 into five short lessons. They identify their source and use current protocol references to explain boundaries. These are companion lessons, not excerpts.

The book preserves the judgments made at the time of writing and publication. Its companion lessons can develop further, with specific protocol and product claims checked against their corresponding sources.

Return to Publications or explore Blockchain Learning.

Continue with identity and applications

Identity, permission and a way out develops eight questions from Chapters 4–5 about eligibility, privacy, delegation, recovery and data migration.

Corrections

These notes use the author’s final review copy, located by chapter, passage heading and a short quotation rather than page number. They correct concepts and clarify conditions; the quoted wording may differ between printings. Later technical developments will be covered separately.

Updated 2026-09-29. 11 entries. This update adds Fabric, DID and DAO corrections, and expands the hashing explanation.

Entry and chapterCorrection
BIP-E001
Chapter 1 · Concept correction
Byzantine agreement and the two-generals problem
BIP-E002
Chapter 1 · Scope clarification
Full validation and historical storage
BIP-E003
Chapter 2 · Model correction
Fabric uses a ledger and world state
BIP-E004
Chapter 3 · Classification correction
Staking requirements and permissioned admission
BIP-E006
Chapter 4 · Concept clarification
DIDs, keys and identity claims are distinct
BIP-E008
Chapter 6 · Scope clarification
The limits of majority hash power
BIP-E009
Chapter 6 · Mechanism correction
The DAO fork changed state, not past blocks
BIP-E012
Chapter 7 · Concept correction
UTXOs include more than change
BIP-E016
Chapter 12 · Scope clarification
Retention and deletion in IPFS
BIP-E017
Chapter 12 · Terminology correction
Signing and verifying use different keys
BIP-E019
Chapter 16 · Terminology correction
What ERP stands for

BIP-E001

Byzantine agreement and the two-generals problem

Chapter 1 · Byzantine fault tolerance discussion. Original Chinese locator:

这个难题也被称为“拜占庭将军问题”或者“两军问题”。

The passage treats the two names as aliases.

Correction: These names refer to different problems. Byzantine agreement asks how participants following a protocol can agree when others may behave maliciously or send conflicting messages. The two-generals problem concerns guaranteed coordination over unreliable communication. The original passage uses the latter concern as the definition of the former. The 1982 paper should also credit all three authors: Leslie Lamport, Robert Shostak and Marshall Pease.

Source: The Byzantine Generals Problem (1982);Halpern & Moses · Knowledge and common knowledge in a distributed environment. Continue learning: Shared records.

BIP-E002

Full validation and historical storage

Chapter 1 · Distributed ledger discussion. Original Chinese locator:

每个“健康”节点上的数据库里都有着完整的区块链上的所有数据和历史信息。

The passage says every healthy node holds all blockchain data and history.

Correction: Validation and retention are separate responsibilities. A pruned Bitcoin Core node can remove old block files after processing them and updating its state, while continuing to validate subsequent transactions and blocks. It cannot directly serve history that it has deleted. A functioning node therefore does not necessarily provide every historical record locally. Pruning was available before this book was published.

Source: Bitcoin Core 0.11.0 · Block file pruning. Continue learning: Shared records.

BIP-E003

Fabric uses a ledger and world state

Chapter 2 · Hyperledger Fabric introduction; account-model comparison in Chapter 7. Original Chinese locator:

Hyperledger Fabric 利用了和比特币相同的 UTXO 加脚本语言的交易处理模式

Meaning: Fabric uses the same UTXO-and-script transaction model as Bitcoin.

Correction: Fabric 1.4 keeps both transaction history and a “world state”: the current values of business objects, such as who holds a piece of equipment. The history records how those values changed. Bitcoin’s UTXOs are unspent transaction outputs; spending consumes old outputs and creates new ones. That model does not directly describe Fabric. Fabric’s chaincode (smart-contract code) proposes business-data updates, and only transactions that pass the network’s validation rules update the world state. Chapter 7 already explains that account models can hold varied data. For Fabric, the more specific description is a world state containing current business-object values. This model was documented in Fabric 1.4 before the book was published.

Source: Hyperledger Fabric 1.4 · Ledger. Learn more: Related concept.

BIP-E004

Staking requirements and permissioned admission

Chapter 3 · How blockchains are classified. Original Chinese locator:

权益证明类公链和联盟链 / 私链则属于许可链的范畴。

The passage classifies proof-of-stake public chains as permissioned.

Correction: Proof of stake alone does not make a blockchain permissioned. A staking requirement is a protocol condition; permissioned admission concerns whether a designated party must approve participants. Reading, submitting transactions, validating and proposing blocks also have different requirements. On Ethereum today, validators enter through the protocol’s deposit and activation process rather than individual institutional approval. Capital, hardware and operational requirements still exist.

Source: Ethereum · Proof of stake. Continue learning: Whether a blockchain is needed.

BIP-E006

DIDs, keys and identity claims are distinct

Chapter 4 · Technical implementation of decentralized identity. Original Chinese locator:

去中心化身份标识包括两个部分:地址和密钥。

Meaning: A decentralized identifier consists of an address and a key.

Correction: An address-and-key analogy helps explain some systems, but it is not a general definition of a DID. A DID is a string identifying a person, organization or another subject. Keys can help produce and verify proof of control; they are not a required second part written into the identifier. A “DID method” supplies rules for creating, looking up and updating these identifiers, distinct from a particular signature-verification method. Proving control of a DID does not by itself establish a name, age or other real-world attribute, or grant access to a service. The recipient must evaluate the relevant claims and decide whether to authorize access. W3C DID Core formalized these roles and relationships in 2022. That later standard clarifies the book’s analogy; it was not already finalized in 2019.

Source: W3C DID Core 1.0 (2022) · Identifier, verification relationships, proving control. Learn more: Related concept.

BIP-E008

The limits of majority hash power

Chapter 6 · Attacks on blockchain systems. Original Chinese locator:

这样攻击者就得到了整个网络的控制权

The passage says the attacker gains control of the entire network.

Correction: In Bitcoin, sustained majority hash power makes it more likely that an attacker can build a valid competing branch with greater accumulated work. This can enable reorganizations, double spending or interference with transaction confirmation. Nodes enforcing the existing rules still check validity. Hash power alone cannot forge another person’s signature or make an invalid transaction valid. Reorganizations can also succeed with less than half the hash power; 50% is not an absolute boundary for whether an attack can occur.

Source: Bitcoin Developer Guide · Block Chain. Continue learning: Finality.

BIP-E009

The DAO fork changed state, not past blocks

Chapter 6 · Discussion of the claim that blockchain data can never be lost. Original Chinese locator:

即回滚到丢失以太币之前的数据

Meaning: The data was rolled back to before the ether was lost.

Correction: The DAO hard fork did not rewind the entire chain to before the attack or delete the intervening transaction history. At block 1,920,000, Ethereum nodes adopting the fork applied a special state change that moved ether balances from specified DAO-related accounts to a designated withdrawal contract. Earlier blocks and transactions remained. The example illustrates how adopting new rules can change the subsequent evolution of state; it does not establish that historical data was erased or rolled back wholesale. The similar wording in Chapter 2 needs the same distinction.

Source: EIP-779 · DAO Fork. Learn more: Related concept.

BIP-E012

UTXOs include more than change

Chapter 7 · UTXO and cash-change analogy. Original Chinese locator:

它并不是“零头”本身,而是一个“找零”记录。

The passage describes a UTXO as a change record.

Correction: UTXO means unspent transaction output. Both a payment to a recipient and change returned to the payer can be UTXOs. In an illustrative transaction, an input worth 10 produces a recipient output of 6 and change of 3.9, leaving 0.1 as the fee. Both outputs can remain unspent. The adjacent claim that Bitcoin records transactions but no resulting state also needs qualification: validating nodes maintain the current set of unspent outputs from the transaction history.

Source: Bitcoin Developer Guide · Transactions. Continue learning: Shared records and transaction conflicts.

BIP-E016

Retention and deletion in IPFS

Chapter 12 · Tamper-resistant data records. Original Chinese locator:

IPFS 目前和区块链一样是不支持删除操作的

The passage says IPFS does not support deletion.

Correction: An IPFS content address identifies content; it does not promise permanent storage. A node can unpin content and remove unneeded data through garbage collection. Unpinning alone does not immediately delete it. Removing a local copy cannot ensure that other nodes remove theirs. Retention, availability and withdrawal of every copy are different questions, so “deletion is unsupported” is too broad.

Source: IPFS · Pin files. Continue learning: Application exit and data retention.

BIP-E017

Signing and verifying use different keys

Chapter 12 · Issuing verifiable digital certificates. Original Chinese locator:

也可使用私钥验证签名的真伪

The passage says a private key can verify a signature.

Correction: For the public-key digital signatures discussed here, the signer creates a signature with a private key and the verifier checks it with the corresponding public key. Verification does not require access to the signer’s private key. A successful check establishes that the signature matches the supplied message and public key; identifying a real-world signer also requires a trustworthy binding to that key. Signing should not be described generically as encrypting and decrypting with the two keys.

Source: NIST CSRC · Private key. Continue learning: Hashes and signatures.

The same chapter’s tamper-resistant-records discussion also uses “借由哈希加密” (“through hash encryption”). Replace that description with using content hashes to identify and check data. Hashing produces a digest for comparison; encryption transforms content so that reading it requires the appropriate key. In IPFS, content addressing does not itself conceal a file, and encrypted transport between nodes does not mean the stored content is encrypted. Sensitive files need separate content encryption and access-key management.

Sources: IPFS · Hashing; IPFS · Privacy and encryption.

BIP-E019

What ERP stands for

Chapter 16 · Information-silo discussion. Original Chinese locator:

ERP(网络公关系统)

The passage expands ERP as an online public-relations system.

Correction: Replace the expansion with “ERP (Enterprise Resource Planning), 企业资源计划系统.” This corrects the abbreviation only; it does not establish the implementation outcomes of the surrounding case study.

Source: SAP · What is ERP?.