├── .github └── FUNDING.yml ├── .gitignore ├── 01_history ├── README.md ├── _images │ ├── 3-hops.png │ ├── Adam_Back.png │ ├── David_Chaum.png │ ├── Nick_Szabo.png │ ├── Wei_Dai.png │ ├── application_circle.png │ ├── blockchain.png │ ├── computing_history.png │ ├── dlt-01.png │ ├── dlt-02.png │ ├── dlt-03.png │ ├── kushim.png │ ├── ledger.jpg │ ├── ledger_history.png │ ├── near_dream.png │ └── simpleBlockchain.png ├── bitcoin.md ├── business.md ├── dlt_problem.md ├── ledger_history.md └── summary.md ├── 02_overview ├── README.md ├── _images │ ├── application_circle.png │ ├── blockchain_example.png │ ├── computing_history.png │ ├── ledger.jpg │ ├── near_dream.png │ ├── simpleBlockchain.png │ └── trust_curve.png ├── challenge.md ├── classify.md ├── definition.md ├── misunderstand.md ├── summary.md └── vision.md ├── 03_scenario ├── README.md ├── finance.md ├── glance.md ├── iot.md ├── logistics.md ├── nft.md ├── others.md ├── ownership.md ├── sharing.md ├── summary.md └── trust.md ├── 04_distributed_system ├── README.md ├── acid.md ├── algorithms.md ├── availability.md ├── bft.md ├── cap.md ├── flp.md ├── paxos.md ├── problem.md └── summary.md ├── 05_crypto ├── README.md ├── _images │ ├── Merkle_tree.png │ ├── basic_flow.png │ ├── bloom_filter.png │ └── tls_handshake.png ├── algorithm.md ├── bloom_filter.md ├── cert.md ├── hash.md ├── history.md ├── homoencryption.md ├── merkle_trie.md ├── others.md ├── pki.md ├── signature.md └── summary.md ├── 06_bitcoin ├── README.md ├── _images │ ├── bitcoin_logo.png │ ├── bitcoin_price.png │ ├── bitcoin_wp.png │ ├── block_example.png │ ├── block_size.png │ ├── coins.png │ ├── pow.png │ ├── sidechain.png │ ├── sidechain_workflow.png │ └── transaction_example.png ├── consensus.md ├── currency.md ├── design.md ├── hot_topics.md ├── intro.md ├── lightning_network.md ├── mining.md ├── sidechain.md ├── summary.md └── tools.md ├── 07_ethereum ├── README.md ├── _images │ ├── dapps.png │ ├── ethereum_logo.png │ └── mist.png ├── concept.md ├── contract_example.md ├── design.md ├── install.md ├── intro.md ├── smart_contract.md ├── summary.md └── tools.md ├── 08_hyperledger ├── README.md ├── _images │ ├── aries.png │ ├── avalon.png │ ├── besu.png │ ├── burrow.png │ ├── caliper.png │ ├── cello.png │ ├── community_growth.png │ ├── composer.png │ ├── explorer.png │ ├── fabric.png │ ├── github.png │ ├── grid.png │ ├── hyperledger.png │ ├── hyperledger_logo.png │ ├── indy.png │ ├── iroha.png │ ├── jira.png │ ├── network_topo.png │ ├── orgnization.png │ ├── patchset-lifecycle.png │ ├── quilt.png │ ├── rocket_chat.png │ ├── sawtooth.png │ ├── top_projects.png │ ├── transact.png │ └── ursa.png ├── community.md ├── contribute.md ├── intro.md ├── project.md ├── summary.md └── tools.md ├── 09_fabric_deploy ├── README.md ├── _images │ ├── docker_images.png │ ├── network_bootup.png │ └── network_topology.png ├── install_docker.md ├── install_local.md ├── intro.md ├── start_docker.md ├── start_local.md └── summary.md ├── 10_fabric_op ├── README.md ├── _images │ ├── ChaincodeInvocationSpec.png │ ├── chaincode_install_flow.png │ ├── chaincode_install_structure.png │ ├── chaincode_instantiate_Envelope.png │ ├── chaincode_instantiate_flow.png │ ├── chaincode_instantiate_signedproposal.png │ ├── chaincode_invoke_Envelope.png │ ├── chaincode_invoke_flow.png │ ├── chaincode_invoke_signedproposal.png │ ├── chaincode_lifecycle.png │ ├── chaincode_list_flow.png │ ├── chaincode_package_Envelope.png │ ├── chaincode_upgrade_flow.png │ ├── channel_create_flow.png │ ├── channel_create_tx.png │ ├── channel_fetch_envelope.png │ ├── channel_fetch_flow.png │ ├── channel_getinfo_flow.png │ ├── channel_getinfo_signed_proposal.png │ ├── channel_join_flow.png │ ├── channel_join_signed_proposal.png │ ├── channel_list_flow.png │ ├── channel_list_signed_proposal.png │ ├── channel_update_flow.png │ ├── channel_update_tx.png │ └── prometheus.png ├── best_practice.md ├── chaincode.md ├── chaincode_v2.md ├── channel.md ├── discover.md ├── events.md ├── intro.md ├── operation.md ├── sdk.md ├── summary.md └── upgrade.md ├── 11_app_dev ├── README.md ├── chaincode.md ├── chaincode_example01.go ├── chaincode_example01.md ├── chaincode_example02.go ├── chaincode_example02.md ├── chaincode_example03.go ├── chaincode_example03.md ├── chaincode_example04.go ├── chaincode_example04.md ├── chaincode_example05.go ├── chaincode_example05.md ├── chaincode_example06.go ├── chaincode_example06.md ├── intro.md └── summary.md ├── 13_fabric_design ├── README.md ├── _images │ ├── dataflow.png │ ├── refarch.png │ └── transaction_flow.png ├── design.md ├── intro.md ├── protocol.md └── summary.md ├── 17_baas ├── README.md ├── _images │ ├── azure_admin.png │ ├── azure_config.png │ ├── azure_deploy.png │ ├── azure_marketplace.png │ ├── bluemix_blockchain.png │ ├── bluemix_chaincode.png │ ├── bluemix_dashboard.png │ ├── bluemix_status.png │ ├── cello.png │ ├── cello_arch.png │ ├── cello_dashboard.png │ ├── cello_dashboard_activechains.png │ ├── cello_dashboard_addcluster.png │ ├── cello_dashboard_addhost.png │ ├── cello_dashboard_hosts.png │ ├── cello_deployment_topo.png │ ├── cello_user_dashboard_chain_code_operate.png │ ├── cello_user_dashboard_chain_code_running.png │ ├── cello_user_dashboard_chain_code_template.png │ ├── cello_user_dashboard_chain_code_template_info.png │ ├── cello_user_dashboard_chain_info.png │ ├── cello_user_dashboard_chain_list.png │ ├── cello_user_dashboard_login.png │ ├── refarch.png │ ├── sv_home.png │ └── sv_smart_contract.png ├── azure.md ├── bluemix.md ├── cello.md ├── intro.md └── summary.md ├── README.md ├── SUMMARY.md ├── _code └── unpack_chaincode.go ├── _images ├── blockchain_book.png ├── blockchain_book2.png ├── coffee.jpeg └── cover.sketch ├── appendix ├── README.md ├── companies.md ├── faq.md ├── golang │ ├── README.md │ ├── _images │ │ └── pprof.png │ ├── ide.md │ ├── install.md │ ├── package.md │ └── tools.md ├── grpc.md ├── resources.md └── terms.md ├── book.json ├── contribute.md ├── cover.jpg ├── evaluation ├── README.md ├── hyperledger.md ├── intro.md └── summary.md └── revision.md /.github/FUNDING.yml: -------------------------------------------------------------------------------- 1 | # These are supported funding model platforms 2 | 3 | github: yeasy 4 | patreon: # Replace with a single Patreon username 5 | open_collective: # Replace with a single Open Collective username 6 | ko_fi: # Replace with a single Ko-fi username 7 | tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel 8 | community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry 9 | liberapay: # Replace with a single Liberapay username 10 | issuehunt: # Replace with a single IssueHunt username 11 | otechie: # Replace with a single Otechie username 12 | lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry 13 | custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2'] 14 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .htaccess 2 | css.php 3 | rpc/ 4 | sites/site*/admin/ 5 | sites/site*/private/ 6 | sites/site*/public/admin/ 7 | sites/site*/public/setup/ 8 | sites/site*/public/theme/ 9 | textpattern/ 10 | 11 | *.swp 12 | *.temp 13 | *.tmp 14 | ~* 15 | node_modules/ 16 | *.graffle 17 | _book/ 18 | book.pdf 19 | 20 | .idea/* 21 | .obsidian/* 22 | -------------------------------------------------------------------------------- /01_history/README.md: -------------------------------------------------------------------------------- 1 | # 区块链的诞生 2 | 3 | **大道无形，链生其中。** 4 | 5 | 认识新事物，首先要弄清楚它的来龙去脉。知其出身，方能知其所以然。 6 | 7 | 区块链（Blockchain）结构首次为人关注，源于 2009 年初上线的比特币（Bitcoin）开源项目。从记账科技数千年的演化角度来看，区块链实际上是记账问题发展到分布式场景下的天然结果。 8 | 9 | 本章将从记账问题的历史讲起，剖析区块链和分布式账本技术的来龙去脉。通过介绍比特币项目探讨区块链的诞生过程，并初步剖析区块链技术潜在的商业价值。 10 | 11 | 通过阅读本章内容，读者可以了解到区块链思想和技术的起源和背景，以及在商业应用中的巨大潜力。 12 | -------------------------------------------------------------------------------- /01_history/_images/3-hops.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/3-hops.png -------------------------------------------------------------------------------- /01_history/_images/Adam_Back.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/Adam_Back.png -------------------------------------------------------------------------------- /01_history/_images/David_Chaum.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/David_Chaum.png -------------------------------------------------------------------------------- /01_history/_images/Nick_Szabo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/Nick_Szabo.png -------------------------------------------------------------------------------- /01_history/_images/Wei_Dai.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/Wei_Dai.png -------------------------------------------------------------------------------- /01_history/_images/application_circle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/application_circle.png -------------------------------------------------------------------------------- /01_history/_images/blockchain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/blockchain.png -------------------------------------------------------------------------------- /01_history/_images/computing_history.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/computing_history.png -------------------------------------------------------------------------------- /01_history/_images/dlt-01.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/dlt-01.png -------------------------------------------------------------------------------- /01_history/_images/dlt-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/dlt-02.png -------------------------------------------------------------------------------- /01_history/_images/dlt-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/dlt-03.png -------------------------------------------------------------------------------- /01_history/_images/kushim.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/kushim.png -------------------------------------------------------------------------------- /01_history/_images/ledger.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/ledger.jpg -------------------------------------------------------------------------------- /01_history/_images/ledger_history.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/ledger_history.png -------------------------------------------------------------------------------- /01_history/_images/near_dream.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/near_dream.png -------------------------------------------------------------------------------- /01_history/_images/simpleBlockchain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/01_history/_images/simpleBlockchain.png -------------------------------------------------------------------------------- /01_history/bitcoin.md: -------------------------------------------------------------------------------- 1 | ## 集大成者的比特币 2 | 3 | 要了解区块链的诞生过程，先要弄清楚比特币的来龙去脉。这要从加密货币数十年的历史说起。 4 | 5 | ### 加密货币的历史 6 | 7 | 上世纪 50 年代计算机（ENIAC，1946 年）出现后，人们就尝试利用信息技术提高支付系统的效率。除了作为电子支付手段的各种银行卡，自 80 年代起，利用密码学手段构建的加密数字货币（Cryptocurrency）也开始成为研究的热门。 8 | 9 | 加密货币前后经历了 30 多年的探索，比较典型的成果包括 [e-Cash](http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/Chaum.BlindSigForPayment.1982.PDF)、[HashCash](http://en.wikipedia.org/wiki/Hashcash)、[B-money](http://www.weidai.com/bmoney.txt)和 Bit Gold 等。 10 | 11 | ![David Chaum](_images/David_Chaum.png) 12 | 13 | 1983 年，时任加州大学圣塔芭芭拉分校教授的 [David Chaum](https://en.wikipedia.org/wiki/David_Chaum) 最早在论文《Blind Signature for Untraceable Payments》中提出了 [e-Cash](http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/Chaum.BlindSigForPayment.1982.PDF)，并于 1989 年创建了 [DigiCash](https://en.wikipedia.org/wiki/Digicash) 公司。ecash 系统是首个尝试实现不可追踪（untraceable）的匿名数字货币，基于 David Chaum 自己发明的盲签名技术，曾被应用于部分银行的小额支付系统中。ecash 虽然不可追踪，但仍依赖中心化机构（银行）的协助，同期也由于信用卡体系的快速崛起，DigiCash 公司最终于 1998 年宣告破产。鉴于 David Chaum 在数字货币研究领域发展早期的贡献，有人认为他是“数字货币之父”。值得一提的是，David Chaum 目前仍活跃在数字货币领域，期待他能做出更重要的贡献。 14 | 15 | ![Adam Back](_images/Adam_Back.png) 16 | 17 | 1997 年，[Adam Back](https://en.wikipedia.org/wiki/Adam_Back) 提出了 [HashCash](http://en.wikipedia.org/wiki/Hashcash)，来解决邮件系统和博客网站中“拒绝服务攻击（Deny of Service，DoS）”攻击问题。Hashcash 首次应用工作量证明（Proof of Work，PoW）机制来获取额度，该机制后来被比特币所采用。类似思想最早曾在 1993 年的论文《Pricing via processing or combatting junk mail》中提出。 18 | 19 | ![Wei Dai](_images/Wei_Dai.png) 20 | 21 | 1998 年，刚大学毕业的华人[Wei Dai](http://www.weidai.com) （戴维）提出了 [B-money](http://www.weidai.com/bmoney.txt) 的设计，这是首个不依赖中心化机构的匿名数字货币方案。B-money 引入工作量证明的思想来解决数字货币产生的问题，指出任何人都可以发行一定量的货币，只要他可以给出某个复杂计算问题（未说明是用 Hash 计算）的答案，货币的发行量将跟问题的计算代价成正比。并且，任何人（或部分参与者）都可以维护一套账本，构成一套初级的 P2P 网络，使用者在网络内通过对带签名的交易消息的广播来实现转账的确认。B-money 是去中心化数字货币领域里程碑式的成果，为后面比特币的出现奠定了基础。从设计上看，B-money 已经很好地解决了货币发行的问题，但是未能解决“双花”问题，也未能指出如何有效、安全地维护账本，最终未能实现。 22 | 23 | ![Nick Szabo](_images/Nick_Szabo.png) 24 | 25 | 同年，[Nick Szabo](http://szabo.best.vwh.net/) 也提出了名为 [Bit Gold](https://unenumerated.blogspot.com/2005/12/bit-gold.html) 的非中心化数字货币设计。系统中将解决密码学难题（challenge string）作为发行货币的前提，并且上一个难题的结果作为下一个难题生成的参数。对方案的确认需要系统中大多数参与者确认。该方案最终也并未实现。 26 | 27 | 这些方案要么依赖于一个中心化的管理机构，要么更多偏重理论层面的设计而未能实现。直到比特币的出现，采用创新的区块链结构来维护账本，使用 1999 年后出现的 P2P 网络技术实现账本同步，并引入经济博弈机制，充分利用现代密码学成果，**首次从实践意义上实现了一套非中心化（decentralized）的开源数字货币系统**。也正因为比特币的影响力巨大，很多时候谈到数字货币其实是指类似以加密技术为基础的数字货币（crypto currency）。 28 | 29 | 比特币依托的分布式网络无需任何管理机构，基于密码学原理来确保交易的正确进行；另一方面，比特币的价值和发行并未有中央机构进行调控，而是通过计算力进行背书，通过经济博弈进行自动调整。这也促使人们开始思考，在数字化的世界中，应该如何发行货币，以及如何衡量价值。 30 | 31 | 比特币也启发了众多数字货币的出现。截至 2018 年底，全球已有超过 2000 种数字货币，既包括以官方为发行主体的法定数字货币（Digital Fiat Currency，DFC）或央行数字货币（Central Bank Digital Currency，CBDC），也包括各种民间数字货币。 32 | 33 | 目前，除了像以比特币这样的分布式技术之外，仍然存在不少中心化代理模式的数字货币机制，包括 paypal、支付宝甚至 Q 币等。通过跟已有的支付系统合作，也可以高效地进行代理交易。 34 | 35 | 现在还很难讲哪种模式将会成为日后的主流，未来甚至还可能出现更先进的技术。但毫无疑问，这些成果都为后来的数字货币设计提供了极具价值的参考；而站在前人肩膀上的比特币，必将在人类货币史上留下难以磨灭的印记。 36 | 37 | *注：严格来说，加密货币并非依赖加密机制，而是使用了密码学中的签名机制。* 38 | 39 | ### 比特币的诞生 40 | 2008 年 10 月 31 日（东部时间），星期五下午 2 点 10 分，化名 Satoshi Nakamoto（中本聪）的人在 [metzdowd 密码学邮件列表](http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html) 中提出了比特币（Bitcoin）的设计白皮书《Bitcoin: A Peer-to-Peer Electronic Cash System》，并在 2009 年公开了最初的实现代码。首个比特币是 UTC 时间 2009 年 1 月 3 日 18:15:05 生成。但比特币真正流行开来，被人们所关注则是至少两年以后了。 41 | 42 | 作为开源项目，比特币很快吸引了大量开发者的加入，目前的官方网站 [bitcoin.org](http://bitcoin.org)，提供了比特币相关的代码实现和各种工具软件。 43 | 44 | 除了精妙的设计理念外，比特币最为人津津乐道的一点，是发明人“中本聪”到目前为止尚无法确认真实身份。也有人推测，“中本聪”背后可能不止一个人，而是一个团队。这些猜测都为比特币项目带来了不少传奇色彩。 45 | 46 | ### 比特币的意义和价值 47 | 48 | 直到今天，关于比特币的话题仍充满了不少争议。但大部分人应该都会认可，比特币是数字货币历史上，甚至整个金融历史上一次了不起的社会学实验。 49 | 50 | 比特币网络上线以来，在无人管理的情况下，已经在全球范围内无间断地运行了 10 年时间，成功处理了千万笔交易，最大单笔支付超过 1.5 亿美金。难得的是，比特币网络从未出现过重大的系统故障。 51 | 52 | 比特币网络目前由数千个核心节点参与构成，不需要任何中心化的支持机构参与，纯靠分布式机制支持了稳定上升的交易量。 53 | 54 | 比特币**首次真正从实践意义上实现了安全可靠的非中心化数字货币机制**，这也是它受到无数金融科技从业者热捧的根本原因。 55 | 56 | 作为一种概念货币，比特币主要希望解决已有货币系统面临的几个核心问题： 57 | 58 | * 被掌控在单一机构手中，容易被攻击； 59 | * 自身的价值无法保证，容易出现波动； 60 | * 无法匿名化交易，不够隐私。 61 | 62 | 要实现一套数字货币机制，最关键的还是要建立一套完善的交易记录系统，以及形成一套合理的货币发行机制。 63 | 64 | 这个交易记录系统要能准确、公正地记录发生过的每一笔交易，并且无法被恶意篡改。对比已有的银行系统，可以看出，现有的银行机制作为金融交易的第三方中介机构，有代价地提供了交易记录服务。如果参与交易的多方都完全相信银行的记录（数据库），就不存在信任问题。可是如果是更大范围（甚至跨多家银行）进行流通的货币呢？哪家银行的系统能提供完全可靠不中断的服务呢？唯一可能的方案是一套分布式账本。这个账本可以被所有用户自由访问，而且任何个体都无法对所记录的数据进行恶意篡改和控制。为了实现这样一个前所未有的账本系统，比特币网络巧妙地设计了区块链结构，提供了可靠、无法被篡改的数字货币账本功能。 65 | 66 | 比特币网络中，货币的发行是通过比特币协议来规定的。货币总量受到控制，发行速度随时间自动进行调整。既然总量确定，那么单个比特币的价值会随着越来越多的经济实体认可而水涨船高。发行速度的自动调整则可以避免出现通胀或者通缩的情况。 67 | 68 | 此外，也要看到，作为社会学实验，比特币已经获得了某种成功，特别是基于区块链技术，已经出现了许多颇有价值的商业场景和创新技术。但这绝不意味着比特币自身必然能够进入未来的商业体系中。比特币自身价值的波动十分剧烈；同时由于账目公开可查，通过分析仍有较大概率追踪到实际使用者；比特币系统在管理环节上仍然依赖中心化的机制。 69 | 70 | ### 更有价值的区块链技术 71 | 72 | 如果说比特币是影响力巨大的社会学实验，那么从比特币核心设计中提炼出来的区块链技术，则让大家看到了塑造更高效、更安全的未来商业网络的可能性。 73 | 74 | 2014 年开始，比特币背后的区块链技术开始逐渐受到大家关注，并进一步引发了分布式记账（Distributed Ledger）技术的革新浪潮。区块链思想和结构恰好应对了分布式场景下记账的技术挑战。 75 | 76 | 区块链技术早已从比特币项目脱颖而出，在金融、贸易、征信、物联网、共享经济等诸多领域崭露头角。现在，除非特别指出是“比特币区块链”，否则当人们提到“区块链”时，往往已与比特币没有什么必然联系了。 77 | -------------------------------------------------------------------------------- /01_history/business.md: -------------------------------------------------------------------------------- 1 | ## 区块链的商业价值 2 | 3 | 商业行为的典型过程为：交易多方通过协商确定商业合约，通过执行合约完成交易。区块链擅长的正是如何在多方之间达成合约，并确保合约的顺利执行。 4 | 5 | 根据类别和应用场景不同，区块链所体现的特点和价值也不同。 6 | 7 | 从技术角度，一般认为，区块链具有如下特点： 8 | 9 | * 分布式容错性：分布式账本网络极其鲁棒，能够容忍部分节点的异常状态； 10 | * 不可篡改性：共识提交后的数据会一直存在，不可被销毁或修改； 11 | * 隐私保护性：密码学保证了数据隐私，即便数据泄露，也无法解析。 12 | 13 | 随之带来的业务特性将可能包括： 14 | 15 | * 可信任性：区块链技术可以提供天然可信的分布式账本平台，不需要额外第三方中介机构参与； 16 | * 降低成本：与传统技术相比，区块链技术可能通过自动化合约执行带来更快的交易，同时降低维护成本； 17 | * 增强安全：区块链技术将有利于安全、可靠的审计管理和账目清算，减少犯罪风险。 18 | 19 | 区块链并不是凭空诞生的新技术，而是多种技术演化到一定程度后的产物，因此，其商业应用场景也跟促生其出现的环境息息相关。对于基于数字方式的交易行为，区块链技术能潜在地降低交易成本、加快交易速度，同时能提高安全性。笔者认为，**能否最终提高生产力，将是一项技术能否被实践接受的关键**。 20 | 21 | Gartner 在 2017 年的报告《Forecast: Blockchain Business Value, Worldwide, 2017-2030》中预测：“区块链带来的商业价值在 2025 年将超过 1760 亿美金，2030 年将超过 3.1 万亿美金（the business value-add of blockchain will grow to slightly more than $176 billion by 2025, and then it will exceed $3.1 trillion by 2030）”。IDC 在 2018 年的报告《Worldwide Semiannual Blockchain Spending Guide》中预测，到 2021 年全球分布式记账科技相关投资将接近百亿美元，五年内的复合增长率高达 81.2%。 22 | 23 | 目前，区块链技术已经得到了众多金融机构和商业公司的关注，包括大量金融界和信息技术界的领军性企业和团体。典型企业和组织如下所列（排名不分先后）。 24 | 25 | * 维萨国际公司（VISA International） 26 | * 美国纳斯达克证券交易所（Nasdaq Stock Exchange） 27 | * 高盛投资银行（Goldman Sachs） 28 | * 花旗银行（Citi Bank） 29 | * 美国富国银行（Wells Fargo） 30 | * 中国人民银行（The People's Bank Of China，PBOC） 31 | * 瑞士联合银行（Union Bank of Switzerland） 32 | * 德意志银行（Deutsche Bank AG） 33 | * 美国证券集中保管结算公司（Depository Trust Clearing Corporation，DTCC） 34 | * 全球同业银行金融电讯协会（Society for Worldwide Interbank Financial Telecommunication，SWIFT） 35 | * 三菱日联金融集团（Mitsubishi UFJ Financial Group, Inc.，MUFG） 36 | * 国际商业机器公司（International Business Machines Corporation，IBM） 37 | * 甲骨文公司（Oracle Corporation） 38 | * 微软公司（Microsoft Corporation） 39 | * 英特尔公司（Intel Corporation） 40 | * 亚马逊公司（Amazon Corporation） 41 | * 思科公司（Cisco Corporation） 42 | * 埃森哲公司（Accenture Corporation） 43 | * 脸书公司（Facebook Incorporated） 44 | 45 | 实际上，区块链可以有效地实现大规模信息和个体的自主化连接。因此，所有与信息、价值（包括货币、证券、专利、版权、数字商品、实际物品等）、信用等相关的交换过程，都将可能从区块链技术中得到启发或直接受益。但这个过程绝不是一蹴而就的，需要长时间的探索和论证。 46 | 47 | ![区块链影响的交换过程](_images/application_circle.png) 48 | 49 | 本书将在后续章节中通过具体的案例来讲解区块链的多个典型商业应用场景。 50 | -------------------------------------------------------------------------------- /01_history/dlt_problem.md: -------------------------------------------------------------------------------- 1 | ## 分布式记账与区块链 2 | 3 | 金融行业是对前沿信息科技成果最敏感的行业之一。特别是对记账科技，其每次突破都会引发金融领域的重要革新，进而对社会生活的各个方面产生阶段性的影响。那么，从技术层面看，区块链到底解决了什么记账难题呢？ 4 | 5 | ### 分布式记账的难题 6 | 7 | 分布式记账由来已久。为了正常进行商业活动，参与者需要找到一个多方均能信任的第三方来负责记账，确保交易记录的准确。然而，随着商业活动的规模越来越大，商业过程愈加动态和复杂，很多场景下难以找到符合要求的第三方记账方（例如，供应链领域动辄涉及来自数十个行业的数百家参与企业）。这就需要交易各方探讨在分布式场景下进行协同记账的可能性。 8 | 9 | 实际上，可以很容易设计出一个简单粗暴的分布式记账结构，如下图所示方案（一）。多方均允许对账本进行任意读写，一旦发生新的交易即追加到账本上。这种情况下，如果参与多方均诚实可靠，则该方案可以正常工作；但是一旦有参与方恶意篡改已发生过的记录，则无法确保账本记录的正确性。 10 | 11 | ![方案（一）：简单分布式记账结构](_images/dlt-01.png) 12 | 13 | 为了防止有参与者对交易记录进行篡改，需要引入一定的验证机制。很自然，可以借鉴信息安全领域的数字摘要（Digital Digest）技术，从而改进为方案（二）。每次当有新的交易记录被追加到账本上时，参与各方可以使用 Hash 算法对完整的交易历史计算数字摘要，获取当前交易历史的“指纹”。此后任意时刻，每个参与方都可以对交易历史重新计算数字摘要，一旦发现指纹不匹配，则说明交易记录被篡改过。同时，通过追踪指纹改变位置，可以定位到被篡改的交易记录。 14 | 15 | ![方案（二）：带有数字摘要验证的分布式记账](_images/dlt-02.png) 16 | 17 | 方案（二）可以解决账本记录防篡改的问题，然而在实际生产应用时，仍存在较大缺陷。由于每次追加新的交易记录时需要从头对所有的历史数据计算数字摘要，当已存在大量交易历史时，数字摘要计算成本将变得很高。而且，随着新交易的发生，计算耗费将越来越大，系统扩展性很差。 18 | 19 | 为了解决可扩展性的问题，需要进一步改进为方案（三）。注意到每次摘要已经确保了从头开始到摘要位置的完整历史，当新的交易发生后，实际上需要进行额外验证的只是新的交易，即增量部分。因此，计算摘要的过程可以改进为对旧的摘要值再加上新的交易内容进行验证。这样就既解决了防篡改问题，又解决了可扩展性问题。 20 | 21 | ![方案（三）：带有数字摘要验证的可扩展的分布式记账](_images/dlt-03.png) 22 | 23 | 实际上，读者可能已经注意到，方案（三）中的账本结构正是一个区块链结构（如下图所示）。可见，从分布式记账的基本问题出发，可以自然推导出区块链结构，这也说明了**对于分布式记账问题，区块链结构是一个简洁有效的天然答案**。 24 | 25 | ![区块链结构](_images/blockchain.png) 26 | 27 | *注：当然，区块链结构也并非解决分布式记账问题的唯一答案，实际上，除了简单的线性队列结构，也有人提出采用树或图结构。* 28 | 29 | ### 区块链的三次热潮 30 | 31 | 区块链结构的首次大规模应用是在比特币项目。从比特币项目诞生之日算起，区块链已在全球掀起了三次热潮。 32 | 33 | ![区块链的三次热潮](_images/3-hops.png) 34 | 35 | 第一波热潮出现在 2013 年左右。比特币项目上线后，很长一段时间里并未获得太多关注。直到比特币价格发生增长，各种加密货币项目纷纷出现，隐藏在其后的区块链结构才首次引发大家的兴趣。2014 年起，区块链这个术语开始频繁出现，但更多集中在加密货币和相关技术领域。 36 | 37 | 第二波热潮出现在 2016 年前后。以区块链为基础的分布式账本技术被证实在众多商业领域存在应用价值。2015 年 10 月《经济学人》封面文章《信任机器》中，正式指出区块链在构建分布式账本平台中的重要作用，促使更多实验性应用出现。下半年更是出现了“初始代币发行（Initial Coin Offering，ICO）”等新型融资募集形式。这一时期，区块链技术自身也有了发展和突破。2015 年 7 月底，以太坊（Ethereum）开源项目正式上线。该项目面向公有场景针对比特币项目的缺陷进行了改善，重点在于对通用智能合约的支持，同时优化了性能和安全性。 38 | 39 | 2015 年底，Linux 基金会牵头发起了超级账本（Hyperledger）开源项目，希望联合各行业的力量构造开放、企业级的分布式账本技术生态。与此前的开源项目相比，超级账本项目主要面向联盟链场景，关注企业在权限管理、隐私保护和安全性能等方面的核心诉求，并积极推动技术成果在各行业的落地实践。首批会员企业包括来自科技界和金融界的领军企业，如 IBM、Intel、Cisco、Digital Asset 等。超级账本项目自诞生后发展十分迅速，目前已经包括 16 大顶级项目，超过 280 家企业会员，并在金融、供应链等领域得到实践应用。尤为值得称道的是，超级账本项目采取了商业友好的 Apache 2.0 开源许可，吸引了众多企业的选用。 40 | 41 | 随着更多商业项目开始落地，从 2017 年开始至今，众多互联网领域的资本开始关注区块链领域，人才缺口持续加大，商业和政策环境开始加强。区块链已经俨然成为继人工智能后的又一资本热点。 42 | 43 | 分析这三次热潮可以看出，每一次热潮的出现都与金融行业对区块链技术的深化应用密切相关。这也表明金融行业对信息科技始终保持了较高的敏感度。 44 | 45 | ### 分布式记账的重要性 46 | 47 | 分布式记账问题为何重要？可以类比互联网出现后给社会带来的重大影响。 48 | 49 | 互联网是人类历史上最大的分布式互联系统，它已成为信息社会的基础设施，很好地解决了传递**信息**的问题。然而，由于早期设计上的缺陷，互联网无法确保所传递信息的可靠性，这大大制约了人们利用互联网进行大规模协作的能力。而以区块链为基础的分布式记账科技则可能解决传递**可信信息**的问题，这意味着基于分布式记账科技的未来商业网络将成为新一代的文明基础设施——大规模协同网络。 50 | 51 | 分布式记账科技的核心价值在于为未来多方协同网络提供可信基础。区块链引发的记账科技的演进，将促使商业协作和组织形态发生变革。甚至世界经济论坛执行主席 Klaus Schwab 认为 “区块链是（继蒸汽机、电气化、计算机之后的）第四次工业革命的核心成果（Blockchains are at the heart of the Fourth Industrial Revolution）”。 52 | 53 | ### 分布式记账的现状与未来 54 | 55 | 类比互联网，从科技发展的一般规律来看，笔者认为，分布式记账科技现在仍处于发展早期，而商业应用已经在加速落地中，如下表所示。 56 | 57 | 阶段 | 互联网 | 区块链 | 阶段 58 | -- | -- | -- | -- 59 | 1974~1983 | ARPANet 内部试验网络 | 比特币试验网络 | 2009~2013 60 | 1984~1993 | TCP/IP 基础协议确立，基础架构完成 | 基础协议和框架探索，出现超级账本、以太坊等开源项目 | 2014~2018 61 | 1990s~2000s | HTTP 应用协议出现；互联网正式进入商用领域 | 商业应用的加速落地，仍未出现杀手级应用 | 2019~2023 62 | 2000s~？ | 桌面互联网、移动互联网、物联网 | 分布式协同商业网络 | 2024~ 63 | 64 | 互联网在发展过程中，先后经历了试验网络、基础架构和协议、商业应用、大规模普及等四个阶段，每个阶段都长达 10 年左右。其中第二个阶段尤为关键，TCP/IP 取代了已有的网络控制协议成为核心协议，这奠定了后来全球规模互联网的技术基础。 65 | 66 | 作为一套前所未有的大规模协同网络，分布式记账网络的发展很大可能也要经历这四个阶段的演化。当然，站在前人肩膀上，无论是演化速度还是决策效率，都会有不小的优势。 67 | 68 | 客观来看，虽然超级账本、以太坊等开源项目在基础协议和框架方面进行了诸多探索，并取得了重要成果，但在多账本互联、与已有系统的互操作性等方面还存在不足，商业应用的广度和深度仍需实践的考验。 69 | 70 | 但毫无疑问，分布式记账科技已经成为金融科技领域的重要创新，必将为金融行业创造新的发展机遇。而未来的商业协同网络，也将成为人类文明进步的重要基础。 71 | -------------------------------------------------------------------------------- /01_history/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 区块链思想诞生于对更先进的分布式记账技术的追求，它支持了首个自带信任、防篡改的分布式账本系统——比特币网络。这让人们意识到，除了互联网这样的尽力而为（不保证可信）的基础设施外，区块链技术还将可能塑造彼此信任的未来网络基础设施。 4 | 5 | 从应用角度讲，以比特币为代表的加密货币只是基于区块链技术的一种金融应用。区块链技术还能带来更通用的计算能力和更广泛的商业价值。本书后续章节将具体介绍区块链的核心技术，以及代表性的开源项目，包括 [以太坊](https://www.ethereum.org/)和[超级账本](https://hyperledger.org) 等。这些开源项目加速释放了区块链技术的威力，为更多更复杂的应用场景提供了技术支持。 6 | -------------------------------------------------------------------------------- /02_overview/README.md: -------------------------------------------------------------------------------- 1 | # 核心技术概览 2 | 3 | **设计之妙夺造化，存乎一心胜天工。** 4 | 5 | 跨境商贸中签订的合同，怎么确保对方能严格遵守和及时执行？ 6 | 7 | 酒店宣称刚打捞上来的三文鱼，怎么追踪捕捞和运输过程中的时间和卫生情况？ 8 | 9 | 数字世界里，怎么证明你是谁？怎么证明某个资产属于你？ 10 | 11 | 囚徒困境中的两个人，怎样才能达成利益的最大化？ 12 | 13 | 宇宙不同文明之间的“黑暗森林”猜疑链，有没有可能被彻底打破？ 14 | 15 | 这些看似很难解决的问题，在区块链的世界里已经有了初步的答案。 16 | 17 | 本章将带领大家探索区块链的核心技术，包括其定义与原理、关键的问题等，还将探讨区块链技术的演化，并对未来发展的趋势进行展望。最后，对一些常见的认识误区进行了澄清。 18 | 19 | -------------------------------------------------------------------------------- /02_overview/_images/application_circle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/application_circle.png -------------------------------------------------------------------------------- /02_overview/_images/blockchain_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/blockchain_example.png -------------------------------------------------------------------------------- /02_overview/_images/computing_history.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/computing_history.png -------------------------------------------------------------------------------- /02_overview/_images/ledger.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/ledger.jpg -------------------------------------------------------------------------------- /02_overview/_images/near_dream.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/near_dream.png -------------------------------------------------------------------------------- /02_overview/_images/simpleBlockchain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/simpleBlockchain.png -------------------------------------------------------------------------------- /02_overview/_images/trust_curve.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/02_overview/_images/trust_curve.png -------------------------------------------------------------------------------- /02_overview/classify.md: -------------------------------------------------------------------------------- 1 | ## 技术的演化与分类 2 | 3 | 区块链技术自比特币网络中首次被大规模应用，到今天应用在越来越多的分布式记账场景中。 4 | 5 | ### 区块链的演化 6 | 7 | 比特币区块链面向转账场景，支持简单的脚本计算。很自然想到如果引入更多复杂的计算逻辑，将能支持更多应用场景，这就是智能合约（Smart Contract）。智能合约可以提供除了货币交易功能外更灵活的功能，执行更为复杂的操作。 8 | 9 | 引入智能合约后的区块链，已经超越了单纯的数据记录功能，实际上带有点“智能计算”的意味了；更进一步地，还可以为区块链加入权限管理、高级编程语言支持等，实现更强大的、支持更多商用场景的分布式账本系统。 10 | 11 | 从计算特点上，可以看到现有区块链技术的三种典型演化场景： 12 | 13 | | 场景 | 功能 | 智能合约 | 一致性 | 权限 | 类型 | 性能 | 编程语言 | 代表 | 14 | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | 15 | | 数字货币 | 记账功能 | 不带有或较弱 | PoW | 无 | 公有链 | 较低 | 简单脚本 | 比特币网络 | 16 | | 分布式应用引擎 | 智能合约 | 图灵完备 | PoW、PoS | 无 | 公有链 | 受限 | 特定语言 | 以太坊网络 | 17 | | 带权限的分布式账本 | 商业处理 | 多种语言，图灵完备 | 包括 CFT、BFT 在内的多种机制，可插拔 | 支持 | 联盟链 | 可扩展 | 高级编程语言 | 超级账本 | 18 | 19 | ### 区块链与分布式记账 20 | 21 | ![复式记账的账本](_images/ledger.jpg) 22 | 23 | [现代复式记账系统](https://zh.wikipedia.org/wiki/%E5%A4%8D%E5%BC%8F%E7%B0%BF%E8%AE%B0)最早出现在文艺复兴时期的意大利，直到今天仍是会计学科的核心方法。复式记账法对每一笔账目同时记录来源和去向，首次将对账验证功能嵌入记账过程，提升了记账过程的可靠性和可追查性。区块链则实现了完整交易历史的记录和保护。 24 | 25 | 从这个角度来看，**区块链是首个自带对账功能的数字账本结构**。 26 | 27 | 更广泛地，区块链实现了非中心化的记录。参与到系统中的节点，并不属于同一组织，彼此可以信任或不信任；链上数据由所有节点共同维护，每个节点都存储一份完整或部分的记录拷贝。 28 | 29 | 跟传统的记账技术相比，基于区块链的分布式账本包括如下特点： 30 | 31 | * 维护一条不断增长的链，只可能添加记录，而且记录一旦确认则不可篡改； 32 | * 非中心化，或者说多中心化的共识，无需集中的控制，实现上尽量分布式； 33 | * 通过密码学的机制来确保交易无法被抵赖和破坏，并尽量保护用户信息和记录的隐私性。 34 | 35 | ### 技术分类 36 | 37 | 根据参与者的不同，可以分为公有（Public 或 Permissionless）链、联盟（Consortium 或 Permissioned）链和私有（Private）链。 38 | 39 | 公有链，顾名思义，任何人都可以参与使用和维护，参与者多为匿名。典型的如比特币和以太坊区块链，信息是完全公开的。 40 | 41 | 如果进一步引入许可机制，可以实现私有链和联盟链两种类型。 42 | 43 | 私有链，由集中管理者进行管理限制，只有内部少数人可以使用，信息不公开。一般认为跟传统中心化记账系统的差异不明显。 44 | 45 | 联盟链则介于两者之间，由若干组织一起合作（如供应链机构或银行联盟等）维护一条区块链，该区块链的使用必须是带有权限的限制访问，相关信息会得到保护，典型如超级账本项目。在架构上，现有大部分区块链在实现都至少包括了网络层、共识层、智能合约和应用层等分层结构，联盟链实现往还会引入额外的权限管理机制。 46 | 47 | 目前来看，公有链信任度最高，也容易引发探讨，但短期内更多的应用会首先在联盟链上落地。公有链因为要面向匿名公开的场景，面临着更多的安全挑战和风险；同时为了支持互联网尺度的交易规模，需要更高的可扩展性。这些技术问题在短期内很难得到解决。 48 | 49 | 对于信任度和中心化程度的关系，对于大部分场景都可以绘制如下所示的曲线。一般地，非中心化程度越高，信任度会越好。但两者的关系并非线性那么简单。随着节点数增加，前期的信任度往往会增长较快，到了一定程度后，信任度随节点数增多并不会得到明显改善。这是因为随着成员数的增加，要实现共谋作恶的成本会指数上升。 50 | 51 | ![信任度和非中心化程度](_images/trust_curve.png) 52 | 53 | 另外，根据使用目的和场景的不同，又可以分为以数字货币为目的的货币链，以记录产权为目的的产权链，以众筹为目的的众筹链等，也有不局限特定应用场景的所谓通用链。通用链因为要兼顾不同场景下的应用特点，在设计上需要考虑更加全面。 54 | -------------------------------------------------------------------------------- /02_overview/definition.md: -------------------------------------------------------------------------------- 1 | ## 定义与原理 2 | 3 | ### 定义 4 | 5 | 区块链技术自身仍然在飞速发展中，相关规范和标准还待进一步成熟。 6 | 7 | 公认的最早关于区块链的描述性文献是中本聪所撰写的 [《比特币：一种点对点的电子现金系统》](https://bitcoin.org/bitcoin.pdf)，但该文献重点在于讨论比特币系统，并没有明确提出区块链的术语。在其中，区块和链被描述为用于记录比特币交易账目历史的数据结构。 8 | 9 | 另外，[Wikipedia](https://en.wikipedia.org/wiki/Blockchain) 上给出的定义中，将区块链类比为一种分布式数据库技术，通过维护数据块的链式结构，可以维持持续增长的、不可篡改的数据记录。 10 | 11 | 笔者认为，讨论区块链可以从狭义和广义两个层面来看待。 12 | 13 | 狭义上，区块链是一种以区块为基本单位的链式数据结构，区块中利用数字摘要对之前的交易历史进行校验，适合分布式记账场景下防篡改和可扩展性的需求。 14 | 15 | 广义上，区块链还指代基于区块链结构实现的分布式记账技术，包括分布式共识、隐私与安全保护、点对点通信技术、网络协议、智能合约等。 16 | 17 | ### 早期应用 18 | 19 | 1990 年 8 月，Bellcore（1984 年由 AT&T 拆分而来的研究机构）的 Stuart Haber 和 W. Scott Stornetta 在论文《How to Time-Stamp a Digital Document》中就提出利用链式结构来解决防篡改问题，其中新生成的时间证明需要包括之前证明的 Hash 值。这可以被认为是区块链结构的最早雏形。 20 | 21 | 后来，2005 年 7 月，在 Git 等开源软件中，也使用了类似区块链结构的机制来记录提交历史。 22 | 23 | 区块链结构最早的大规模应用出现在 2009 年初上线的比特币项目中。在无集中式管理的情况下，比特币网络持续稳定，支持了海量的交易记录，并且从未出现严重的漏洞，引发了广泛关注。这些都与区块链结构自身强校验的特性密切相关。 24 | 25 | ### 基本原理 26 | 27 | 区块链的基本原理理解起来并不复杂。首先来看三个基本概念： 28 | 29 | * 交易（Transaction）：一次对账本的操作，导致账本状态的一次改变，如添加一条转账记录； 30 | * 区块（Block）：记录一段时间内发生的所有交易和状态结果等，是对当前账本状态的一次共识； 31 | * 链（Chain）：由区块按照发生顺序串联而成，是整个账本状态变化的日志记录。 32 | 33 | 如果把区块链系统作为一个状态机，则每次交易意味着一次状态改变；生成的区块，就是参与者对其中交易导致状态改变结果的共识。 34 | 35 | 区块链的目标是实现一个分布的数据记录账本，这个账本只允许添加、不允许删除。账本底层的基本结构是一个线性的链表。链表由一个个“区块”串联组成（如下图所示），后继区块中记录前导区块的哈希（Hash）值。某个区块（以及块里的交易）是否合法，可通过计算哈希值的方式进行快速检验。网络中节点可以提议添加一个新的区块，但必须经过共识机制来对区块达成确认。 36 | 37 | ![区块链结构示例](_images/blockchain_example.png) 38 | 39 | ### 以比特币为例理解区块链工作过程 40 | 41 | 具体以比特币网络为例，来看其中如何使用了区块链技术。 42 | 43 | 首先，用户通过比特币客户端发起一项交易，消息广播到比特币网络中等待确认。网络中的节点会将收到的等待确认的交易请求打包在一起，添加上前一个区块头部的哈希值等信息，组成一个区块结构。然后，试图找到一个 nonce 串（随机串）放到区块里，使得区块结构的哈希结果满足一定条件（比如小于某个值）。这个计算 nonce 串的过程，即俗称的“挖矿”。nonce 串的查找需要花费一定的计算力。 44 | 45 | 一旦节点找到了满足条件的 nonce 串，这个区块在格式上就“合法”了，成为候选区块。节点将其在网络中广播出去。其它节点收到候选区块后进行验证，发现确实合法，就承认这个区块是一个新的合法区块，并添加到自己维护的本地区块链结构上。当大部分节点都接受了该区块后，意味着区块被网络接受，区块中所包括的交易也就得到确认。 46 | 47 | 这里比较关键的步骤有两个，一个是完成对一批交易的共识（创建合法区块结构）；一个是新的区块添加到链结构上，被网络认可，确保未来无法被篡改。当然，在实现上还会有很多额外的细节。 48 | 49 | 比特币的这种基于算力（寻找 nonce 串）的共识机制被称为工作量证明（Proof of Work，PoW）。这是因为要让哈希结果满足一定条件，并无已知的快速启发式算法，只能对 nonce 值进行逐个尝试的蛮力计算。尝试的次数越多（工作量越大），算出来的概率越大。 50 | 51 | 通过调节对哈希结果的限制条件，比特币网络控制平均约 10 分钟产生一个合法区块。算出区块的节点将得到区块中所有交易的管理费和协议固定发放的奖励费（目前是 12.5 比特币，每四年减半）。 52 | 53 | 读者可能会关心，比特币网络是任何人都可以加入的，如果网络中存在恶意节点，能否进行恶意操作来对区块链中记录进行篡改，从而破坏整个比特币网络系统。比如最简单的，故意不承认别人产生的合法候选区块，或者干脆拒绝来自其它节点的交易请求等。 54 | 55 | 实际上，因为比特币网络中存在大量（据估计数千个）的维护节点，而且大部分节点都是正常工作的，默认都只承认所看到的最长的链结构。只要网络中不存在超过一半的节点提前勾结一起采取恶意行动，则最长的链将很大概率上成为最终合法的链。而且随着时间增加，这个概率会越来越大。例如，经过 6 个区块生成后，即便有一半的节点联合起来想颠覆被确认的结果，其概率也仅为 (1/2)^6 ≈ 1.6%，即低于 1/60 的可能性。10 个区块后概率将降到千分之一以下。 56 | 57 | 当然，如果整个网络中大多数的节点都联合起来作恶，可以导致整个系统无法正常工作。要做到这一点，往往意味着付出很大的代价，跟通过作恶得到的收益相比，往往得不偿失。 58 | 59 | -------------------------------------------------------------------------------- /02_overview/misunderstand.md: -------------------------------------------------------------------------------- 1 | ## 认识上的误区 2 | 3 | 目前，区块链作为一种相对年轻的技术，自身仍在飞速发展中，在相关概念上仍有一些值得探讨之处。 4 | 5 | 下面总结一些常见的认知误区。 6 | 7 | **区块链是完全创新的新技术** 作为融合多项已有技术而出现的事物，区块链跟现有记账科技和信息体系是一脉相承的。区块链在解决多方合作和可信计算问题上向前多走了一步，但并不意味着它就是万能的（从来不会存在一项万能的科技），更不会快速颠覆已有的众多商业模式。很长一段时间里，区块链的应用场景仍需不断摸索，区块链在自身发展的同时也会与已有系统共存互通。 8 | 9 | **区块链必然是非中心化的，非中心化一定优于中心化设计** 比较两种技术的优劣，必须要先确定场景，区块链也是如此。不可能存在某种技术在任意场景下都是最优的。目前区块链的两大形态——公有链和联盟链之所以在技术选型上存在较大差异，正是因为它们面向的场景不同。中心化设计往往具有设计简单、管理完善、性能高、安全可控的特点，但容错性能比较差；非中心化（多中心化）的设计可以提高容错性能，可以利用多方共识来降低篡改风险，但意味着设计较复杂，性能较差。 10 | 11 | 从实际需求出发，现有大部分区块链技术都介于绝对的中心化和绝对的非中心化之间，以取得不同指标上的平衡。例如某些公有链为了提高性能，选择部分代表节点来参与共识。 12 | 13 | **区块链离不开加密数字货币** 虽说区块链的早期应用之一是比特币等加密数字货币，但发展到今日，区块链技术早已脱颖而出，两者也各自朝着不同的目标向前发展。比特币侧重从金融角度发掘加密数字货币的实验和实践意义；区块链则从技术层面探讨和研究分布式账本科技的商业价值，并试图拓展到更多分布式互信的场景。 14 | 15 | **区块链是一种数据库技术** 虽然区块链中往往使用了已有的数据库技术，也可以用来存储或管理数据（Data Management），但它要面向的主要问题是多方数据互信协作（Data Collaboration）问题，这是传统数据技术无法解决的。单纯从数据存储或管理角度，区块链效率可能不如传统数据库效率高，因此一般不推荐把大量原始数据直接放到区块链系统中。当然，区块链系统可以与现有数据库和大数据系统等进行集成。甲骨文、亚马逊等团队尝试将区块链的一些特性引入到数据库中，提出了 Blockchain Table、Quantum Ledger Database 等新型数据系统，可以满足防篡改历史、方便审计等需求。 16 | 17 | 另一方面，区块链复杂大规模的场景需求也对数据库技术提出了新的需求。例如开源社区普遍使用的 levelDB 在扩展性方面表现并不特别优秀，需要进行增强；部分业务场景下需要支持 SQL 语义。可以借鉴其它数据库（如 RocksDB 和 BerkeleyDB）的一些优势进行改造。 18 | 19 | **Token 等于加密数字货币** 早在区块链概念出现之前，Token（令牌或凭证）就大量应用在计算机系统中。作为权限证明，它可以协助计算机系统进行认证等操作。作为分布式系统，区块链中很自然也可以在某些场景（如游戏积分）下借用 Token 机制，带来应用生态的管理便利。而加密数字货币试图借用数字化技术来实现货币功能，更强调经济价值，跟计算机系统中的原生功能无必然联系。总之，两者是不同层面的概念，即使不依赖 Token，仍然可以实现加密数字货币；数字凭证只有具备可靠、大范围接受的购买力，才可能成为货币，否则只能作为收藏品在小圈子内流通。 20 | -------------------------------------------------------------------------------- /02_overview/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 本章剖析了区块链的相关核心技术，包括其定义、工作原理、技术分类、关键问题和认识上的误区等。通过本章的学习，读者可以对区块链的相关技术体系形成整体上的认识，并对区块链的发展趋势形成更清晰的把握。 4 | 5 | 除了数字货币应用外，业界越来越看重区块链技术在商业应用场景中的潜力。开源社区发起的开放的 [以太坊](https://www.ethereum.org) 和 [超级账本](https://hyperledger.org) 等项目，为更复杂的分布式账本应用提供了坚实的平台支撑。 6 | 7 | 有理由相信，随着更多商业应用场景的落地，区块链技术将在金融和科技领域都起到越来越重要的作用。 8 | -------------------------------------------------------------------------------- /02_overview/vision.md: -------------------------------------------------------------------------------- 1 | ## 趋势与展望 2 | 3 | 关于区块链技术发展趋势的探讨和争论，自其诞生之日起就从未停息。或许，读者可以从现代计算技术的演变史中得到一些启发。 4 | 5 | ![现代计算技术的演变史，笔者于某次技术交流会中提出](_images/computing_history.png) 6 | 7 | 以云计算为代表的现代计算技术，其发展历史上有若干重要的时间点和事件： 8 | 9 | * 1969 - ARPANet（Advanced Research Projects Agency Network）：现代互联网的前身，由美国高级研究计划署（Advanced Research Project Agency）提出，使用的协议是 NCP ，核心缺陷之一是无法做到和个别计算机网络交流； 10 | * 1973 - TCP/IP：Vinton.Cerf（温顿•瑟夫）与 Bob Karn（鲍勃•卡恩）共同开发出 TCP 模型，解决了 NCP 的缺陷； 11 | * 1982 - Internet：TCP/IP 正式成为规范，并被大规模应用，现代互联网诞生； 12 | * 1989 - WWW：早期互联网的应用主要包括 telnet、ftp、email 等，蒂姆·伯纳斯-李（Tim Berners-Lee）设计的 WWW 协议成为互联网的杀手级应用，引爆了现代互联网，从那开始，互联网业务快速扩张； 13 | * 1999 - salesforce：互联网出现后，一度只能进行通信应用，但 salesforce 开始以云的理念提供基于互联网的企业级服务； 14 | * 2006 - aws ec2：AWS EC2 奠定了云计算的业界标杆，直到今天，竞争者们仍然在试图追赶 AWS 的脚步； 15 | * 2013 - cognitive：以 IBM Watson 为代表的认知计算开始进入商业领域，计算开始变得智能，进入“后云计算时代”。 16 | 17 | 从这个历史中能看出哪些端倪呢？ 18 | 19 | 一个是 **技术领域也存在着周期律。** 这个周期目前看是 7 年左右。或许正如人有“七年之痒”，技术也存在着七年这道坎，到了这道坎，要么自身发生突破迈过去，要么就被新的技术所取代。事实上，从比特币网络上线（2009 年 1 月）算起，区块链技术在七年后出现了不少突破。 20 | 21 | *注：为何恰好是七年？7 年按照产品周期来看基本是 2~3 个产品周期，市场或许只能提供不超过三次机会。* 22 | 23 | 另外，**最早出现的未必是先驱，也可能是先烈。** 创新科技固然先进，但过早播撒种子，缺乏合适环境也难发芽长大。技术创新与科研创新很不同的一点便是，技术创新必须立足于需求，过早过晚都会错失良机；科研创新则要越早越好，比如二十世纪的现代物理学发展，超前的研究成果奠定了后续一百多年内科技革命的基础。 24 | 25 | 最后，**事物的发展往往是延续的、长期的。** 新生事物大多数不是凭空而生，往往是解决了先贤未能解决的问题，或是出现了之前未曾出现过的场景。很多时候，新生事物的出现需要长期的孵化，坚持还是放弃的故事会不断重复。但只要是朝着提高生产力的正确方向努力，迟早会有出现在舞台上的一天。 26 | 27 | ![坚持还是放弃？](_images/near_dream.png) 28 | 29 | 目前，区块链在金融相关领域的应用相对成熟，其它方向尚处于初步实践阶段。但毫无疑问的是，区块链技术在已经落地的行业中，确实带来了生产力提升。2018 年 3 月，国际银行间金融电信协会（The Society for Worldwide Interbank Financial Telecommunication，SWIFT）基于超级账本项目经过一年多的成功验证，宣布认可分布式账本技术可满足银行间实时交易，同时遵守监管的报告要求。 30 | 31 | 此外，相关标准化组织也在积极从标准和规范角度探讨如何使用分布式账本。包括： 32 | 33 | * 国际电信联盟电信标准化组织（International Telecommunication Union Telecommunication Standardization Sector，ITU-T）自 2016 年起发起 3 个工作小组（SG16，17，20）来分别进行分布式账本整体需求、分布式账本安全需求和分布式账本在物联网领域应用等方面的研究； 34 | * 国际标准化组织（International Organization for Standardization，ISO）成立 5 个课题组，探讨制定关于分布式账本架构、应用、安全保护、身份管理和智能合约方面的相关规范； 35 | * 电气电子工程师协会（IEEE）成立 P2418.2 项目，探讨区块链系统数据格式标准； 36 | * 国际互联网工程任务组（Internet Engineering Task Force，IETF）成立了 Decentralized Internet Infrastructure Proposed RG (dinrg)。该研究组将集中在非中心化架构服务中的信任管理、身份管理、命名和资源发现等问题； 37 | * 万维网联盟（World Wide Web Consortium，W3C）成立了三个相关的研究小组，分别探讨区块链技术和应用；数字资产管理规范以及跨账本互联协议等。 38 | 39 | 当然，企业界的进展也不甘落后。不少科技企业已推出了分布式账本相关的产品或方案，并得到了初步的验证。由于分布式账本技术自身的复杂性且尚不成熟，正确使用还需要较高的门槛。目前，这些企业方案多数依托流行的云计算技术，将节约开发成本、方便用户使用账本服务作为主要目标。 40 | 41 | 笔者大胆预测，随着区块链和分布式账本相关技术的成熟，更多应用实践将会落地，特别是面向企业应用的场景。而在未来解决了跨链等一系列问题后，将会出现随时接入、成本低廉的联合账本网络，为人们生活带来更多便利。 42 | -------------------------------------------------------------------------------- /03_scenario/README.md: -------------------------------------------------------------------------------- 1 | # 典型应用场景 2 | 3 | **创新落地，应用为王。** 4 | 5 | 新的技术能否最终落地得以普及，受很多因素影响，其中最关键一点便是合适的应用场景。 6 | 7 | 比特币网络支撑了全球范围内的支付交易，成功论证了去中心化系统长时间自治运转的可行性。这引发了对区块链应用潜力的遐想：如果基于区块链技术构造自动运行的商业价值网络，其中的交易自动完成且无法伪造；所有签署的合同都能按照约定严格执行，这将大大提高商业系统协作的效率。从这个意义上讲，人们相信，基于区块链技术构建的未来商业网络，将是继互联网之后又一次巨大的产业变革。 8 | 9 | 目前，除了金融领域外，在权属追溯、资源共享、物流供应链、征信管理和物联网等诸多领域，也涌现出大量的应用案例。本章将通过剖析这些典型的应用场景，展现区块链技术为不同行业带来的创新潜力。 10 | -------------------------------------------------------------------------------- /03_scenario/glance.md: -------------------------------------------------------------------------------- 1 | ## 应用场景概览 2 | 3 | 区块链技术已经从单纯的技术探讨走向了应用落地的阶段。国内外已经出现大量与之相关的企业和团队。有些企业已经结合自身业务摸索出了颇具特色的应用场景，更多的企业还处于不断探索和验证的阶段。 4 | 5 | 实际上，要找到合适的应用场景，还是要从区块链技术自身的特性出发进行分析。 6 | 7 | 区块链在不引入第三方中介机构的前提下，可以提供去中心化、不可篡改、安全可靠等特性保证。因此，所有直接或间接依赖于第三方担保机构的活动，均可能从区块链技术中获益。 8 | 9 | 区块链自身维护着一个按时间顺序持续增长、不可篡改的数据记录，当现实或数字世界中的资产可以生成数字摘要时，区块链便成为确权类应用的完美载体，提供包含所属权和时间戳的数字证据。 10 | 11 | 可编程的智能合约使得在区块链上登记的资产可以获得在现实世界中难以提供的流动性，并能够保证合约规则的透明和不可篡改。这就为区块链上诞生更多创新的经济活动提供了土壤，为社会资源价值提供更加高效且安全的流动渠道。 12 | 13 | 此外，还需要思考区块链解决方案的合理边界。面向大众消费者的区块链应用需要做到公开、透明、可审计，既可以部署在无边界的公有链，也可以部署在应用生态内多中心节点共同维护的区块链；面向企业内部或多个企业间的商业区块链场景，则可将区块链的维护节点和可见性限制在联盟内部，并用智能合约重点解决联盟成员间信任或信息不对等问题，以提高经济活动效率。 14 | 15 | 笔者认为，未来几年内，可能深入应用区块链技术的场景将包括： 16 | 17 | * 金融服务：区块链带来的潜在优势包括降低交易成本、减少跨组织交易风险等。该领域的区块链应用目前最受关注，全球不少银行和金融交易机构都是主力推动者。部分投资机构也在应用区块链技术降低管理成本和管控风险。从另一方面，要注意可能引发的问题和风险。例如，DAO（Decentralized Autonomous Organization 是史上最大的一次众筹活动，基于区块链技术确保资金的管理和投放）这样的众筹实验，提醒应用者在业务和运营层面都要谨慎处理。 18 | * 征信和权属管理：征信和权属的数字化管理是大型社交平台和保险公司都梦寐以求的。目前该领域的主要技术问题包括缺乏足够的数据和分析能力；缺乏可靠的平台支持以及有效的数据整合管理等。区块链被认为可以促进数据交易和流动，提供安全可靠的支持。征信行业的门槛比较高，需要多方资源共同推动。 19 | * 资源共享：以 Airbnb 为代表的分享经济公司将欢迎去中心化应用，可以降低管理成本。该领域主题相对集中，设计空间大，受到大量的投资关注。 20 | * 贸易管理：区块链技术可以帮助自动化国际贸易和物流供应链领域中繁琐的手续和流程。基于区块链设计的贸易管理方案会为参与的多方企业带来极大的便利。另外，贸易中销售和法律合同的数字化、货物监控与检测、实时支付等方向都可能成为创业公司的突破口。 21 | * 物联网：物联网也是很适合应用区块链技术的一个领域，预计未来几年内会有大量应用出现，特别是租赁、物流等特定场景，都是很合适结合区块链技术的场景。但目前阶段，物联网自身的技术局限将造成短期内不会出现大规模应用。 22 | 23 | 这些行业各有不同的特点，但或多或少都需要第三方担保机构的参与，因此都可能从区块链技术中获得益处。 24 | 25 | 当然，对于商业系统来说，技术支持只是一种手段，根本上需要满足业务需求。区块链作为一个底层的平台技术，要利用好它，需要根据行业特性进行综合考量设计，对其上的业务系统和商业体系提供合理的支持。 26 | 27 | 有理由相信，区块链技术落地的案例会越来越多。这也会进一步促进新技术在传统行业中的应用，带来更多的创新业务和场景。 -------------------------------------------------------------------------------- /03_scenario/iot.md: -------------------------------------------------------------------------------- 1 | ## 物联网 2 | 曾有人认为，物联网是大数据时代的基础。 3 | 4 | 笔者认为，区块链技术是物联网时代的基础。 5 | 6 | ### 典型应用场景分析 7 | 一种可能的应用场景为：物联网络中每一个设备分配地址，给该地址所关联一个账户，用户通过向账户中支付费用可以租借设备，以执行相关动作，从而达到租借物联网的应用。 8 | 9 | 典型的应用包括对大量分散监测点的数据获取、温度检测服务、服务器租赁、网络摄像头数据调用等等。 10 | 11 | 另外，随着物联网设备的增多、边沿计算需求的增强，大量设备之间形成分布式自组织的管理模式，并且对容错性要求很高。区块链自身分布式和抗攻击的特点可以很好地融合到这一场景中。 12 | 13 | ### IBM 14 | IBM 在物联网领域已经持续投入了几十年的研发，目前正在探索使用区块链技术来降低物联网应用的成本。 15 | 16 | 2015 年初，IBM 与三星宣布合作研发“去中心化的 P2P 自动遥测系统（Autonomous Decentralized Peer-to-Peer Telemetry）”系统，使用区块链作为物联网设备的共享账本，打造去中心化的物联网。 17 | 18 | 2017 年，IBM 和哥伦比亚物流解决方案供应商 AOS 合作，共同为物流行业开发新的区块链和物联网解决方案。方案通过物联网传感器采集货车可用空间、负载信息、天气温度等信息，并将货物、货主、司机、物流行为等信息上链，实现对货物状态和相关方行为的完整追溯。 19 | 20 | ### Filament 21 | 美国的 Filament 公司以区块链为基础提出了一套去中心化的物联网软件堆栈。通过创建一个智能设备目录，Filament 的物联网设备可以进行安全沟通、执行智能合约以及发送小额交易。 22 | 23 | 基于上述技术，Filament 能够通过远程无线网络将辽阔范围内的工业基础设备沟通起来，其应用包括追踪自动售货机的存货和机器状态、检测铁轨的损耗、基于安全帽或救生衣的应急情况监测等。 24 | 25 | ### NeuroMesh 26 | 2017 年 2 月，源自 MIT 的 NeuroMesh 物联网安全平台获得了 MIT 100K Accelerate 竞赛的亚军。该平台致力于成为“物联网疫苗”，能够检测和消除物联网中的有害程序，并将攻击源打入黑名单。 27 | 28 | 所有运行 NeuroMesh 软件的物联网设备都通过访问区块链账本来识别其他节点和辨认潜在威胁。如果一个设备借助深度学习功能检测出可能的威胁，可通过发起投票的形式告知全网，由网络进一步对该威胁进行检测并做出处理。 29 | 30 | ### 公共网络服务 31 | 现有的互联网能正常运行，离不开很多近乎免费的网络服务，例如域名服务（DNS）。任何人都可以免费查询到域名，没有 DNS，现在的各种网站将无法访问。因此，对于网络系统来说，类似的基础服务必须要能做到安全可靠，并且低成本。 32 | 33 | 区块链技术恰好具备这些特点，基于区块链打造的分布式 DNS 系统，将减少错误的记录和查询，并且可以更加稳定可靠地提供服务。 34 | -------------------------------------------------------------------------------- /03_scenario/logistics.md: -------------------------------------------------------------------------------- 1 | ## 物流与供应链 2 | 3 | 物流与供应链行业被认为是区块链一个很有前景的应用方向。Gartner 一项调查显示，接近 60% 的物流相关企业计划考虑使用分布式账本技术。 4 | 5 | 该行业往往涉及到诸多实体，包括物流、资金流、信息流等，这些实体之间存在大量复杂的协作和沟通。传统模式下，不同实体各自保存各自的供应链信息，严重缺乏透明度，造成了较高的时间成本和金钱成本，而且一旦出现问题（冒领、货物假冒等），难以追查和处理。 6 | 7 | 通过区块链，各方可以获得一个透明可靠的统一信息平台，可以实时查看状态，降低物流成本，追溯物品的生产和运送全过程，从而提高供应链管理的效率。当发生纠纷时，举证和追查也变得更加清晰和容易。 8 | 9 | 例如，运送方通过扫描二维码来证明货物到达指定区域，并自动收取提前约定的费用；冷链运输过程中通过温度传感器实时检测货物的温度信息并记录在链等。 10 | 11 | 来自美国加州的 Skuchain 公司创建基于区块链的新型供应链解决方案，实现商品流与资金流的同步，同时缓解假货问题。 12 | 13 | ### 马士基推出基于区块链的跨境供应链解决方案 14 | 15 | 2017 年 3 月，马士基和 IBM 宣布，计划与由货运公司、货运代理商、海运承运商、港口和海关当局构成的物流网络合作，构建一个新型全球贸易数字化解决方案 TradeLens。该方案利用区块链技术在各方之间实现信息透明性，降低贸易成本和复杂性，旨在帮助企业减少欺诈和错误，缩短产品在运输和海运过程中所花的时间，改善库存管理，最终减少浪费并降低成本。 16 | 17 | 马士基在 2014 年发现，仅仅是将冷冻货物从东非运到欧洲，就需要经过近 30 个人员和组织进行超过 200 次的沟通和交流，大量文书工作可以替换为无法篡改的数字记录，类似问题都有望借助区块链进行解决。 18 | 19 | 基于区块链的供应链方案，预计每年可为全球航运业节省数十亿美元。 20 | 21 | ### 国际物流区块链联盟 22 | 23 | 2017 年 8 月，国际物流区块链联盟（Blockchain In Transport Alliance，BiTA）正式成立。 24 | 25 | 该联盟目标为利用分布式账本技术来提高物流和货运效率，并探索新的行业标准。 26 | 27 | 目前，联盟已经发展为超过 25 个国家，500 多家会员企业，包括联合包裹（UPS）、联邦快递（FedEx）、施耐德卡车运输公司（Schneider Trucking）、SAP 等。 28 | 29 | -------------------------------------------------------------------------------- /03_scenario/nft.md: -------------------------------------------------------------------------------- 1 | ## 数字艺术品和 NFT 2 | 3 | 过去几年里，数字艺术品探索了采用 NFT（非同质化代币，Non Fungible Token）这一新的数字媒介形式进行资产交易的可能性。 4 | 5 | 未来大量的物品交易，都可以通过 NFT 形式进行。另外，NFT 可以将资产所有权进行数字化，方便更充分地实现价值。 6 | 7 | NFT 的出现，代表了交易者从基于纸质合约转变为基于数字合约交易的迫切需求。 8 | 9 | ### 数字艺术品 10 | 11 | 数字艺术品是指利用计算机技术生成的具备某种艺术价值的一组数据。类似于传统的物理创作的艺术品，数字艺术品被认为具备唯一性和收藏价值。由于数字艺术品的交易多通过加密货币进行，因此也被称为密码艺术品（CryptoArt）。 12 | 13 | 早在 1993 年，Hal Finney（也是比特币早期专家）就在密码论坛 Cypherpunks 上讨论了关于“加密交易卡”的想法，这可能是最早的关于密码艺术品和 NFT 的讨论。 14 | 15 | 数字艺术品主要包括如下特点： 16 | 17 | * 基于区块链平台，生成规则一旦确定，艺术品无法增发或修改，也无法造假； 18 | * 多使用加密货币交易，所有记录公开可见，可以有效追溯； 19 | * 用户购买后所有权被记录在分布式账本上，无法被篡改或造假； 20 | * 艺术品交易都是直接立刻完成，不存在传统的第三方； 21 | * 数字艺术品自身并不稀缺，甚至很容易被复制，但是其所有权唯一，并且得到市场的认可。 22 | 23 | 24 | 2014 年，Robby Dermody、Adam Krellenstein、Ouziel Slama 等基于比特币网络上线了 Counterparty 交易平台。该平台通过元数据代币协议提供点对点金融交易，支持创建代币、去中心化资产交易等。2016 年 9 月，上线了“稀有的 Pepe 蛙（Rare Pepe）”项目，成为早期的数字艺术品。 25 | 26 | 2017 年 6 月 23 日，Larva Labs 上线了 CryptoPunks 项目。该项目创建了 10000 个朋克头像，每个头像都是独一无二的 24x24 的 8 位像素图。最初，该项目在以太网络上免费发行，希望纪念朋克精神。后来随着爱好者们的宣传和参与，项目吸引了大量用户甚至投资机构的关注，至今仍然十分活跃，单个售价往往在数万美金。2021 年 6 月，编号 7523 的头像售价达到了 1180 万美金。CryptoPunks 作为收藏品具有独特的文化趣味，被认为是后来加密数字艺术品潮流的开端。此后，Larva Labs 还开发了 Autoglyphs 和 Meebits 项目，也都引起了市场的追捧。 27 | 28 | 2017 年 11 月 28 日，Axiom Zen 团队（后孵化了 Dapper Labs 公司）推出基于以太币交易的 CryptoKitties 游戏。每个玩家可以通过以太币来购买一只数字猫咪，繁殖后代，并且可以出售。所有的记录都在以太网络上公开可见。通过该游戏，玩家可以学习掌握以太币的基本使用方法。该游戏一度十分火爆，单只数字猫咪售价曾超过 10 万美元，相关交易占据以太网络近 2 成的交易流量，造成了交易延迟和堵塞。游戏的成功，也启发了众多的模仿者。项目遵循的 ERC-721 标准得到广泛采用。 29 | 30 | 2021 年 4 月，Yuga Labs 在以太坊网络上推出了 Bored Ape Yacht Club 项目，该项目包括 10000 个不相同的猿猴画像，由计算机生成。其中编号 8817 的画像，曾被拍卖出 340 万美金的高价。 31 | 32 | 33 | ### NFT 34 | 35 | 虽然目前很多 NFT 都是数字艺术品，但是 NFT 的 内涵实际上要更为广泛。任何可以在数字世界流通的东西，都可以认为是 NFT。包括画作、摄影、音乐、书籍、游戏等。 36 | 37 | NFT 的字面意思是非同质化代币。传统的加密数字货币是同质（Fungible Token）的，任意两枚之间并无差别，可以相互替换，并且往往可以拆分为更小的单位，例如比特币。而 NFT 则是唯一的，不能被其它 NFT 替换，并且往往不能分割为更小的单位。例如一个画作 NFT，代表该画作自身，并不能被其它的 NFT 所替代。 38 | 39 | 目前 NFT 产品往往具有如下特点： 40 | 41 | * 不可相互替换； 42 | * 不可拆分为更小单位； 43 | * 往往唯一存在。 44 | 45 | NFT 的非同质化的特点，使得其可以容易锚定到物理世界中的物品上，例如房产、汽车、收藏品等。任何现实物品的产权都可以绑定到一个 NFT 上。因此，NFT 被认为具备巨大的潜力。 46 | 47 | 2020 年，随着全球范围内主权货币的大量增发，NFT 开始受到越来越多的追捧。2021 年，NFT 项目更是迎来了大爆发，因此 2021 年也被不少人称为“NFT 元年”。目前，大部分的 NFT 都通过 Opensea、Rarible、Nifty Gateway 等平台交易，并依托以太网络和 IPFS 进行存储。 48 | 49 | NFT 想法的出现十分自然，其最早的原型，可以追溯到 2012 年出现的基于比特币的彩色币（ColoredCoin）。彩色币带有颜色属性，可以用颜色来代表不同的资产。这为现实资产上链提供了可行性。 50 | 51 | 但比特币网络不支持智能合约，限制了其表达能力。2015 年 7 月上线的以太坊网络，加强了对智能合约的支持，使得 NFT 的大量出现成为现实。特别是 2017 年 9 月，ERC-721 规范正式被提出，成为大量基于以太坊项目实现的 NFT 的参考标准。这一年里加密猫项目上线，非同质化代币这一概念也被正式确立。2018 年，以太坊社区还提出了支持批量交易的 ERC-1155 标准，目前已经被交易市场 Rarible 支持。 52 | 53 | Sky Mavis于 2018 年开发了游戏 Axie Infinity，后来成为以太坊网络上的热门游戏之一。它支持通过 NFT 方式让玩家交易其中的虚拟宠物和土地资源，同时，玩家可以通过玩游戏来获取积分并兑换。部分虚拟宠物价格高达 300 个以太币（约一百万美金）。 54 | 55 | 2020 年 10 月，Dapper Labs 公司与 NBA 合作，推出了 NBA Top Shot 游戏项目。它将某位球员在比赛中的精彩视频片段上传到 Dapper Labs 研发的公链 Flow 上，制作为 NFT 产品。NBA Top Shot 项目上线后，吸引了大量用户的参与。总成交额已经超过 2 亿美金，部分产品如球员 LeBron James 的灌篮视频的 NFT 价格一度飙升到 40 万美金。 56 | 57 | 此外，大英博物馆、俄罗斯冬宫博物馆等也对世界名画的 NFT 产品进行了拍卖。 58 | 59 | 2021 年 2 月，林肯公园（Linkin Park）乐队成员 Mike Shinoda 在平台 Zora 上发行了一款 NFT 音乐作品，售价高达 40 万美元。 60 | 61 | 2021 年 2 月，数字艺术家 Mike Winkelmann（又名 Beeple）自 2007 年 5 月起耗时十三年半创作的 5000 副数字画作 “Everydays – The First 5000 Days”，拼接为一个 316 MB 大小的图片 NFT，以历史性价格 6934 万美元（42329 个以太币）在佳士得（Christie's）售出，购买者为加密货币投资人 Vignesh Sundaresan。 62 | 63 | 2021 年 4 月，Centrifuge 公司使用房屋作为抵押，成功获取了一笔 MakerDAO 贷款。 64 | 65 | 2021 年 12 月，代号 Pak 的数字艺术家将包括 312686 个数字画作集 “The Merge”，在数字艺术品拍卖平台 NiftyGateway 售出，28983 位买家参与购买，成交总价为 9180 万美元。这也是目前售价最高的 NFT 作品。 66 | 67 | 68 | ### NFT 的优势 69 | 70 | 使用 NFT 来达成交易包括如下优势： 71 | 72 | * 即时交易：买卖双方从平台达成交易并写入区块链后，NFT 所有权即得到转移，交易记录保存在分布式账本上，无法被篡改； 73 | * 不易作假：一旦 NFT 产品被确认后，其交易历史会被完整记录，其他人很难伪造； 74 | * 提高效率：基于 NFT 的交易，都是通过智能合约进行自动化处理，处理效率远高于人工操作； 75 | * 降低成本：NFT 平台的手续费通常远低于现实交易的中介费，降低交易成本也可促进市场的繁荣。 76 | 77 | ### NFT 的问题 78 | 79 | NFT 的快速发展，也导致一些问题的出现： 80 | 81 | * NFT 的审计问题：在成为 NFT 并被交易之前，平台或审计方需要确认所绑定物品的实际权属。一旦出现虚假产权情况，需要能有办法进行回退，这对目前的分布式账本技术提出了新的需求； 82 | * 市场的理性回归问题：目前，优秀的 NFT 产品十分稀缺，导致很多产品上线后被炒作出虚高的价格。新生事物发展初期的过度繁荣往往导致泡沫的快速产生和破灭。交易平台应设计更为理性的拍卖机制，并提高参与门槛。 83 | * 不同平台之间的互联问题：基于不同平台实现的 NFT 往往采用了不同的标准，彼此之间很难互联互通，这限制了 NFT 在更大市场上的流通。 -------------------------------------------------------------------------------- /03_scenario/others.md: -------------------------------------------------------------------------------- 1 | ## 其它场景 2 | 3 | 区块链还有一些很有趣的应用场景，包括但不限于云存储、医疗、社交、游戏等多个方面。 4 | 5 | ### 云存储 6 | 7 | Storj 项目提供了基于区块链的安全的分布式云存储服务。服务保证只有用户自己能看到自己的数据，并号称提供高速的下载速度和 99.99999% 的高可用性。用户还可以“出租”自己的额外硬盘空间来获得报酬。 8 | 9 | 协议设计上，Storj 网络中的节点可以传递数据、验证远端数据的完整性和可用性、复原数据，以及商议合约和向其他节点付费。数据的安全性由数据分片（Data Sharding）和端到端加密提供，数据的完整性由可复原性证明（Proof of Retrievability）提供。 10 | 11 | ### 医疗 12 | 13 | 医院与医保医药公司，不同医院之间，甚至医院里不同部门之间的数据流动性往往很差。考虑到医疗健康数据的敏感性，笔者认为，如果能够满足数据访问权、使用权等规定的基础上促进医疗数据的提取和流动，健康大数据行业将迎来春天。 14 | 15 | 目前，全球范围内的个人数据市场估值每年在 2000 亿美金左右。 16 | 17 | GemHealth 项目由区块链公司 Gem 于 2016 年 4 月提出，其目标除了用区块链存储医疗记录或数据，还包括借助区块链增强医疗健康数据在不同机构不同部门间的安全可转移性、促进全球病人身份识别、医疗设备数据安全收集与验证等。项目已与医疗行业多家公司签订了合作协议。 18 | 19 | Hu.Manity 是一家创业公司，提供健康数据的匿名出售服务。用户可以选择售卖个人健康数据，但这些数据会消除掉个人的隐私信息。 20 | 21 | 麻省理工学院媒体实验室也在建立一个医疗数据的共享系统，允许病人自行选择分享哪些数据给医疗机构。 22 | 23 | ### 通信和社交 24 | 25 | BitMessage 是一套去中心化通信系统，在点对点通信的基础上保护用户的匿名性和信息的隐私。BitMessage 协议在设计上充分参考了比特币，二者拥有相似的地址编码机制和消息传递机制。BitMessage 也用工作量证明（Proof-of-Work）机制防止通信网络受到大量垃圾信息的冲击。 26 | 27 | 类似的，Twister 是一套去中心化的“微博”系统，Dot-Bit 是一套去中心化的 DNS 系统。 28 | 29 | ### 投票 30 | 31 | Follow My Vote 项目致力于提供一个安全、透明的在线投票系统。通过使用该系统进行选举投票，投票者可以随时检查自己选票的存在和正确性，看到实时记票结果，并在改变主意时修改选票。 32 | 33 | 该项目使用区块链进行记票，并开源其软件代码供社区用户审核。项目也为投票人身份认证、防止重复投票、投票隐私等难点问题提供了解决方案。 34 | 35 | ### 在线音乐 36 | 37 | Ujo 音乐平台通过使用智能合约来创建一个透明的、去中心化的版权和版权所有者数据库来进行音乐版权税费的自动支付。 38 | 39 | ### 预测 40 | 41 | Augur 是一个运行在以太坊上的预测市场平台。使用 Augur，来自全球不同地方的任何人都可发起自己的预测话题市场，或随意加入其它市场，来预测一些事件的发展结果。预测结果和奖金结算由智能合约严格控制，使得在平台上博弈的用户不用为安全性产生担忧。 42 | 43 | ### 电子游戏 44 | 45 | 2017 年 3 月，来自马来西亚的电子游戏工作室 Xhai Studios 宣布将区块链技术引入其电子游戏平台。工作室旗下的一些游戏将支持与 NEM 区块链的代币 XEM 整合。通过这一平台，游戏开发者可以在游戏架构中直接调用支付功能，消除对第三方支付的依赖；玩家则可以自由地将 XEM 和游戏内货币、点数等进行双向兑换。 46 | 47 | ### 存证 48 | TODO：展开解释存证或版权案例 49 | “纸贵版权” 引入公证处、版权局、知名高校作为版权存证联盟链的存证和监管节点，所有上链的版权存证信息都会经过多个节点的验证和监管，保证任何时刻均可出具具备国家承认的公证证明，具有最高司法效力。同时，通过在公证处部署联盟链存证节点服务器，存证主体即可视为公证处。在遭遇侵权行为时，区块链版权登记证书可作为证据证明版权归属，得到法院的采信。 50 | 51 | 2018 年 12 月 22 日，北京互联网法院“天平链”正式发布。该区块链平台融合了司法鉴定中心、公证处、行业机构等，三个月时间内发展到 17 个节点，采集数据超过一百万条。这些存证数据有望提高电子诉讼的采证效率。 52 | -------------------------------------------------------------------------------- /03_scenario/ownership.md: -------------------------------------------------------------------------------- 1 | ### 权属管理与溯源 2 | 3 | 区块链技术可以用于产权、版权等所有权的管理和追踪。其中包括汽车、房屋、艺术品等各种贵重物品的交易等，也包括数字出版物，以及可以标记的数字资源。 4 | 5 | 目前权属管理领域存在的几个难题是： 6 | 7 | * 物品所有权的确认和管理； 8 | * 交易的安全性和可靠性保障； 9 | * 必要的隐私保护机制。 10 | 11 | 以房屋交易为例。买卖双方往往需要依托中介机构来确保交易的进行，并通过纸质的材料证明房屋所有权。但实际上，很多时候中介机构也无法确保交易的正常进行。 12 | 13 | 而利用区块链技术，物品的所有权是写在数字链上的，谁都无法修改。并且一旦出现合同中约定情况，区块链技术将确保合同能得到准确执行。这能有效减少传统情况下纠纷仲裁环节的人工干预和执行成本。 14 | 15 | 例如，公正通（Factom）尝试使用区块链技术来革新商业社会和政府部门的数据管理和数据记录方式。包括审计系统、医疗信息记录、供应链管理、投票系统、财产契据、法律应用、金融系统等。它将待确权数据的指纹存放到基于区块链的分布式账本中，可以提供资产所有权的追踪服务。 16 | 17 | 区块链账本共享、信息可追踪溯源且不可篡改的特性同样可用于打击造假和防范欺诈。Everledger 自 2016 年起就研究基于区块链技术实现贵重资产检测系统，将钻石或者艺术品等的数字指纹信息（包括钻石超过40个数据点的颜色、清晰度、切割和重量等信息）记录在区块链上。并于 2017 年宣布与 IBM 合作，实现生产商、加工商、运送方、零售商等多方之间的可信高效协作。 18 | 19 | 类似地，针对食品造假这一难题，IBM、沃尔玛、清华大学于 2016 年底共同宣布将在食品安全领域展开合作，将用区块链技术搭建透明可追溯的跨境食品供应链。这一全新的供应链将改善食品的溯源和物流环节，打造更为安全的全球食品市场。 20 | 21 | ### 存证 22 | 23 | ### 溯源 24 | 25 | ### 数据协作 26 | 27 | ### 其他项目 28 | 29 | 在人力资源和教育领域，MIT 研究员朱莉安娜·纳扎雷（Juliana Nazaré）和学术创新部主管菲利普·施密特（Philipp Schmidt）发表了文章[《MIT Media Lab Uses the Bitcoin Blockchain for Digital Certificates》](http://quarktalk.cc/threads/mit-media-lab-uses-the-bitcoin-blockchain-for-digital-certificates.1553/)，介绍基于区块链的学历认证系统。基于该系统，用人单位可以确认求职者的学历信息是真实可靠的。2018 年 2 月，麻省理工学院向应届毕业生颁发了首批基于区块链的数字学位证书。 30 | 31 | 此外，还包括一些其他相关的应用项目： 32 | 33 | * Chronicled：基于区块链的球鞋鉴定方案，为正品球鞋添加电子标签，记录在区块链上。 34 | * Mediachain：通过 metadata 协议，将内容创造者与作品唯一对应。 35 | * Mycelia：区块链产权保护项目，为音乐人实现音乐的自由交易。 36 | * Tierion: 将用户数据锚定在比特币或以太坊区块链上，并生成“区块链收据”。 37 | * Ziggurat：基于区块链提供文字、图片、音视频版权资产的登记和管理服务。 38 | -------------------------------------------------------------------------------- /03_scenario/sharing.md: -------------------------------------------------------------------------------- 1 | ## 资源共享 2 | 3 | 当前，以 Uber、Airbnb 为代表的共享经济模式正在多个垂直领域冲击传统行业。这一模式鼓励人们通过互联网的方式共享闲置资源。资源共享目前面临的问题主要包括： 4 | 5 | * 共享过程成本过高； 6 | * 用户行为评价难； 7 | * 共享服务管理难。 8 | 9 | 区块链技术为解决上述问题提供了更多可能。相比于依赖于中间方的资源共享模式，基于区块链的模式有潜力更直接的连接资源的供给方和需求方，其透明、不可篡改的特性有助于减小摩擦。 10 | 11 | 有人认为区块链技术会成为新一代共享经济的基石。笔者认为，区块链在资源共享领域是否存在价值，还要看能否比传统的专业供应者或中间方形式实现更高的效率和更低的成本，同时不能损害用户体验。 12 | 13 | ### 短租共享 14 | 大量提供短租服务的公司已经开始尝试用区块链来解决共享中的难题。 15 | 16 | 高盛在报告《Blockchain: Putting Theory into Practice》中宣称： 17 | 18 | > Airbnb 等 P2P 住宿平台已经开始通过利用私人住所打造公开市场来变革住宿行业，但是这种服务的接受程度可能会因人们对人身安全以及财产损失的担忧而受到限制。而如果通过引入安全且无法篡改的数字化资质和信用管理系统，我们认为区块链就能有助于提升 P2P 住宿的接受度。 19 | 20 | 该报告还指出，可能采用区块链技术的企业包括 Airbnb、HomeAway 以及 OneFineStay 等，市场规模为 30~90 亿美元。 21 | 22 | ### 社区能源共享 23 | 24 | 在纽约布鲁克林的一个街区，已有项目尝试将家庭太阳能发的电通过社区的电力网络直接进行买卖。具体的交易不再经过电网公司，而是通过区块链执行。 25 | 26 | 与之类似，ConsenSys 和微电网开发商 LO3 提出共建光伏发电交易网络，实现点对点的能源交易。 27 | 28 | 这些方案的主要难题包括： 29 | 30 | * 太阳能电池管理； 31 | * 社区电网构建； 32 | * 电力储备系统搭建； 33 | * 低成本交易系统支持。 34 | 35 | 现在已经有大量创业团队在解决这些问题，特别是硬件部分已经有了不少解决方案。而通过区块链技术打造的平台可以解决最后一个问题，即低成本地实现社区内的可靠交易系统。 36 | 37 | ### 电商平台 38 | 39 | 传统情况下，电商平台起到了中介的作用。一旦买卖双方发生纠纷，电商平台会作为第三方机构进行仲裁。这种模式存在着周期长、缺乏公证、成本高等缺点。OpenBazaar 试图在无中介的情形下，实现安全电商交易。 40 | 41 | 具体地，OpenBazaar 提供的分布式电商平台，通过多方签名机制和信誉评分机制，让众多参与者合作进行评估，实现零成本解决纠纷问题。 42 | 43 | ### 大数据共享 44 | 大数据时代里，价值来自于对数据的挖掘，数据维度越多，体积越大，潜在价值也就越高。 45 | 46 | 一直以来，比较让人头疼的问题是如何评估数据的价值，如何利用数据进行交换和交易，以及如何避免宝贵的数据在未经许可的情况下泄露出去。 47 | 48 | 区块链技术为解决这些问题提供了潜在的可能。 49 | 50 | 利用共同记录的共享账本，数据在多方之间的流动将得到实时的追踪和管理。通过对敏感信息的脱敏处理和访问权限的设定，区块链可以对大数据的共享授权进行精细化管控，规范和促进大数据的交易与流通。 51 | 52 | ### 减小共享风险 53 | 54 | 传统的资源共享平台在遇到经济纠纷时会充当调解和仲裁者的角色。对于区块链共享平台，目前还存在线下复杂交易难以数字化等问题。除了引入信誉评分、多方评估等机制，也有方案提出引入保险机制来对冲风险。 55 | 56 | 2016 年 7 月，德勤、Stratumn 和 LemonWay 共同推出一个为共享经济场景设计的“微保险”概念平台，称为 LenderBot。针对共享经济活动中临时交换资产可能产生的风险，LenderBot 允许用户在区块链上注册定制的微保险，并为共享的资产（如相机、手机、电脑）投保。区块链在其中扮演了可信第三方和条款执行者的角色。 57 | 58 | 59 | -------------------------------------------------------------------------------- /03_scenario/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 本章介绍了大量基于区块链技术的应用案例和场景，展现了区块链以及基于区块链的分布式账本技术所具有的巨大市场潜力。 3 | 4 | 当然，任何事物的发展都不是一帆风顺的。 5 | 6 | 目前来看，制约区块链技术进一步落地的因素有很多。比如如何来为区块链上的合同担保？特别在金融、法律等领域，实际执行的时候往往还需要线下机制来配合；另外就是基于区块链系统的价值交易，必须要实现物品价值的数字化，非数字化的物品很难直接放到数字世界中进行管理。 7 | 8 | 这些问题看起来都不容易很快得到解决。但笔者相信，一门新的技术能否站住脚，根本上还是看它能否最终提高生产力，而区块链技术已经证明了这一点。随着生态的进一步成熟，区块链技术必将在更多领域获得用武之地。 -------------------------------------------------------------------------------- /03_scenario/trust.md: -------------------------------------------------------------------------------- 1 | ## 征信管理 2 | 3 | 征信管理是一个巨大的潜在市场，据称超过千亿规模（可参考美国富国银行报告和平安证券报告），也是目前大数据应用领域最有前途的方向之一。 4 | 5 | 目前征信相关的大量有效数据集中在少数机构手中。由于这些数据太过敏感，并且具备极高的商业价值，往往会被严密保护起来，形成很高的行业门槛。 6 | 7 | 虽然现在大量的互联网企业（包括各类社交网站）尝试从各种维度获取了海量的用户信息，但从征信角度看，这些数据仍然存在若干问题。这些问题主要包括： 8 | 9 | * 数据量不足：数据量越大，能获得的价值自然越高，过少的数据量无法产生有效价值； 10 | * 相关度较差：最核心的数据也往往是最敏感的。在隐私高度敏感的今天，用户都不希望暴露过多数据给第三方，因此企业获取到数据中有效成分往往很少； 11 | * 时效性不足：企业可以从明面上获取到的用户数据往往是过时的，甚至存在虚假信息，对相关分析的可信度造成严重干扰。 12 | 13 | 区块链天然存在着无法篡改、不可抵赖的特性。同时，区块链平台将可能提供前所未有规模的相关性极高的数据，这些数据可以在时空中准确定位，并严格关联到用户。因此，基于区块链提供数据进行征信管理，将大大提高信用评估的准确率，同时降低评估成本。 14 | 15 | 另外，跟传统依靠人工的审核过程不同，区块链中交易处理完全遵循约定自动化执行。基于区块链的信用机制将天然具备稳定性和中立性。 16 | 17 | 目前，包括 IDG、腾讯、安永、普华永道等都已投资或进入基于区块链的征信管理领域，特别是跟保险和互助经济相关的应用场景。 18 | 19 | ### 保险行业 20 | 21 | 保险行业区块链倡议组织（Blockchain 22 | Insurance Industry Initiative，B3i）诞生于 2016 年下半年，面向保险行业，探索基于分布式账本的新型技术。 23 | 24 | 分布式账本带来的可信能力，将有望给保险行业带来新的变革。 25 | 26 | 目前，B3i 已经包括超过 40 家会员企业，包括美国国际集团、友邦保险、安联保险、瑞士再保险等保险行业巨头。 27 | -------------------------------------------------------------------------------- /04_distributed_system/README.md: -------------------------------------------------------------------------------- 1 | # 分布式系统核心技术 2 | 3 | **万法皆空，因果不空。** 4 | 5 | 随着摩尔定律碰到瓶颈，分布式架构逐渐流行起来。 6 | 7 | 从单点演变到分布式结构，重要问题之一就是数据一致性。很显然，如果分布式集群中多个节点处理结果无法保证一致，那么在其上的业务系统将无法正常工作。 8 | 9 | 区块链系统是一个典型的分布式系统，必然也会碰到这些经典问题。 10 | 11 | 本章将介绍分布式系统领域的核心技术，包括一致性、共识，介绍这些概念的定义、基本原理和常见算法，最后还介绍了评估分布式系统可靠性的指标。 12 | -------------------------------------------------------------------------------- /04_distributed_system/acid.md: -------------------------------------------------------------------------------- 1 | ## ACID 原则与多阶段提交 2 | 3 | ### ACID 原则 4 | ACID，即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）四种特性的缩写。 5 | 6 | ACID 也是一种比较出名的描述一致性的原则，通常出现在分布式数据库等基于事务过程的系统中。 7 | 8 | 具体来说，ACID 原则描述了分布式数据库需要满足的一致性需求，同时允许付出可用性的代价。 9 | 10 | * Atomicity：每次事务是原子的，事务包含的所有操作要么全部成功，要么全部不执行。一旦有操作失败，则需要回退状态到执行事务之前； 11 | * Consistency：数据库的状态在事务执行前后的状态是一致的和完整的，无中间状态。即只能处于成功事务提交后的状态； 12 | * Isolation：各种事务可以并发执行，但彼此之间互相不影响。按照标准 SQL 规范，从弱到强可以分为未授权读取、授权读取、可重复读取和串行化四种隔离等级； 13 | * Durability：状态的改变是持久的，不会失效。一旦某个事务提交，则它造成的状态变更就是永久性的。 14 | 15 | 与 ACID 相对的一个原则是 eBay 技术专家 Dan Pritchett 提出的 BASE（Basic Availability，Soft-state，Eventual Consistency）原则。BASE 原则面向大型高可用分布式系统，主张牺牲掉对强一致性的追求，而实现最终一致性，来换取一定的可用性。 16 | 17 | *注：ACID 和 BASE 在英文中分别是“酸”和“碱”，看似对立，实则是对 CAP 三特性的不同取舍。* 18 | 19 | ### 两阶段提交 20 | 21 | 对于分布式事务一致性的研究成果包括著名的两阶段提交算法（Two-phase Commit，2PC）和三阶段提交算法（Three-phase Commit，3PC）。 22 | 23 | 两阶段提交算法最早由 Jim Gray 于 1979 年在论文《Notes on Database Operating Systems》中提出。其基本思想十分简单，既然在分布式场景下，直接提交事务可能出现各种故障和冲突，那么可将其分解为预提交和正式提交两个阶段，规避风险。 24 | 25 | * 预提交（PreCommit）：协调者（Coordinator）发起执行某个事务的执行并等待结果。各参与者（Participant）执行事务但不提交，反馈是否能完成，并阻塞等待协调者指令； 26 | * 正式提交（DoCommit）：协调者如果得到所有参与者的成功答复，则发出正式提交指令，否则发出状态回滚指令。 27 | 28 | 两阶段提交算法因为其简单容易实现的优点，在关系型数据库等系统中被广泛应用。当然，其缺点也很明显。 29 | 30 | * 第一阶段时，各参与者同步阻塞等待时无法处理请求，会导致系统性较差； 31 | * 存在协调者单点故障问题，最坏情况下协调者总是在第二阶段故障，无法完成提交； 32 | * 可能产生数据不一致的情况。例如第二个阶段时，协调者将正式提交请求发给部分参与者后发生故障。 33 | 34 | ### 三阶段提交 35 | 36 | 三阶段提交算法针对两阶段提交算法第一阶段中参与者阻塞问题进行了优化。具体来说，将预提交阶段进一步拆成两个步骤：询问提交和预提交。 37 | 38 | 完整过程如下： 39 | 40 | * 询问提交（CanCommit）：协调者询问参与者是否能进行某个事务的提交。参与者需要返回答复是否准备好，但无需执行提交，也无需阻塞。这就避免出现参与者被阻塞的情况； 41 | * 预提交（PreCommit）：协调者检查收集到的答复，如果全部为真，则发起执行事务请求。各参与参与者（Participant）需要执行事务但不提交，并反馈能否完成。注意此时说明所有参与者都已经处于准备好状态。； 42 | * 正式提交（DoCommit）：协调者如果得到所有参与者的成功答复，则发出正式提交请求，否则发出状态回滚指令。本阶段时，如果参与者一直收不到请求，则超时后继续提交。 43 | 44 | 三阶段提交主要解决了阻塞问题和协调者单点故障问题。第三阶段时，如果参与者无法及时收到协调者的消息，可以在超时后自动进行提交。但是当协调者发出的回滚消息未被部分参与者收到时，会出现不一致的情况。 45 | 46 | 其实，无论两阶段还是三阶段提交，都只是一定程度上缓解了提交冲突的问题，并无法确保系统的一致性。首个有效的共识算法是后来提出的 Paxos 算法。 47 | -------------------------------------------------------------------------------- /04_distributed_system/algorithms.md: -------------------------------------------------------------------------------- 1 | ## 共识算法 2 | 3 | 共识（Consensus）这个术语很多时候会与一致性（Consistency）术语放在一起讨论。严谨地讲，两者的含义并不完全相同。 4 | 5 | 一致性的含义比共识宽泛，在不同场景（基于事务的数据库、分布式系统等）下意义不同。具体到分布式系统场景下，一致性指的是多个副本对外呈现的状态。如前面提到的顺序一致性、线性一致性，描述了多节点对数据状态的共同维护能力。而共识，则特指在分布式系统中多个节点之间对某个事情（例如多个事务请求，先执行谁？）达成一致看法的过程。因此，达成某种共识并不意味着就保障了一致性。 6 | 7 | 实践中，要保障系统满足不同程度的一致性，往往需要通过共识算法来达成。 8 | 9 | 共识算法解决的是分布式系统对某个提案（Proposal），大部分节点达成一致意见的过程。提案的含义在分布式系统中十分宽泛，如多个事件发生的顺序、某个键对应的值、谁是主节点……等等。可以认为任何可以达成一致的信息都是一个提案。 10 | 11 | 对于分布式系统来讲，各个节点通常都是相同的确定性状态机模型（又称为状态机复制问题，State-Machine Replication），从相同初始状态开始接收相同顺序的指令，则可以保证相同的结果状态。因此，系统中多个节点最关键的是对多个事件的顺序进行共识，即排序。 12 | 13 | *注：计算机世界里采用的是典型的“多数人暴政”，足够简单、高效。* 14 | 15 | ### 问题与挑战 16 | 17 | 无论是在现实生活中，还是计算机世界里，达成共识都要解决两个基本的问题： 18 | 19 | * 首先，如何提出一个待共识的提案？如通过令牌传递、随机选取、权重比较、求解难题等； 20 | * 其次，如何让多个节点对该提案达成共识（同意或拒绝），如投票、规则验证等。 21 | 22 | 理论上，如果分布式系统中各节点都能以十分“理想”的性能（瞬间响应、超高吞吐）稳定运行，节点之间通信瞬时送达（如量子纠缠），则实现共识过程并不十分困难，简单地通过广播进行瞬时投票和应答即可。 23 | 24 | 可惜的是，现实中这样的“理想”系统并不存在。不同节点之间通信存在延迟（光速物理限制、通信处理延迟），并且任意环节都可能存在故障（系统规模越大，发生故障可能性越高）。如通信网络会发生中断、节点会发生故障、甚至存在被入侵的节点故意伪造消息，破坏正常的共识过程。 25 | 26 | 一般地，把出现故障（Crash 或 Fail-stop，即不响应）但不会伪造信息的情况称为“非拜占庭错误（Non-Byzantine Fault）”或“故障错误（Crash Fault）”；伪造信息恶意响应的情况称为“拜占庭错误”（Byzantine Fault），对应节点为拜占庭节点。显然，后者场景中因为存在“捣乱者”更难达成共识。 27 | 28 | 此外，任何处理都需要成本，共识也是如此。当存在一定信任前提（如接入节点都经过验证、节点性能稳定、安全保障很高）时，达成共识相对容易，共识性能也较高；反之在不可信的场景下，达成共识很难，需要付出较大成本（如时间、经济、安全等），而且性能往往较差（如工作量证明算法）。 29 | 30 | *注：非拜占庭场景的典型例子是通过报数来统计人数，即便偶有冲突（如两人同时报一个数）也能很快解决；拜占庭场景的一个常见例子是“杀人游戏”，当参与者众多时很难快速达成共识。* 31 | 32 | ### 常见算法 33 | 根据解决的场景是否允许拜占庭错误情况，共识算法可以分为 Crash Fault Tolerance (CFT) 和 Byzantine Fault Tolerance（BFT）两类。 34 | 35 | 对于非拜占庭错误的情况，已经存在不少经典的算法，包括 Paxos（1990 年）、Raft（2014 年）及其变种等。这类容错算法往往性能比较好，处理较快，容忍不超过一半的故障节点。 36 | 37 | 对于要能容忍拜占庭错误的情况，包括 PBFT（Practical Byzantine Fault Tolerance，1999 年）为代表的确定性系列算法、PoW（1997 年）为代表的概率算法等。确定性算法一旦达成共识就不可逆转，即共识是最终结果；而概率类算法的共识结果则是临时的，随着时间推移或某种强化，共识结果被推翻的概率越来越小，最终成为事实上结果。拜占庭类容错算法往往性能较差，容忍不超过 1/3 的故障节点。 38 | 39 | 此外，XFT（Cross Fault Tolerance，2015 年）等最近提出的改进算法可以提供类似 CFT 的处理响应速度，并能在大多数节点正常工作时提供 BFT 保障。 40 | 41 | Algorand 算法（2017 年）基于 PBFT 进行改进，通过引入可验证随机函数解决了提案选择的问题，理论上可以在容忍拜占庭错误的前提下实现更好的性能（1000+ TPS）。 42 | 43 | *注：实践中，对客户端来说要拿到共识结果需要自行验证，典型地，可访问足够多个服务节点来比对结果，确保获取结果的准确性。* 44 | 45 | ### 理论界限 46 | 47 | 科学家都喜欢探寻问题最坏情况的理论界限。那么，共识问题的最坏界限在哪里呢？很不幸，在推广到任意情况时，分布式系统的共识问题无通用解。 48 | 49 | 这似乎很容易理解，当多个节点之间的通信网络自身不可靠情况下，很显然，无法确保实现共识（例如，所有涉及共识的消息都丢失）。那么，对于一个设计得当，可以大概率保证消息正确送达的网络，是不是一定能获得共识呢？ 50 | 51 | 理论证明告诉我们，**即便在网络通信可靠情况下，一个可扩展的分布式系统的共识问题通用解法的下限是——没有下限（无解）。** 52 | 53 | 这个结论，被称为“FLP 不可能原理”。该原理极其重要，可以看做是分布式领域里的“测不准原理”。 54 | 55 | *注：不光分布式系统领域，实际上很多领域都存在类似测不准原理的约束，或许说明世界本源就存在限制。* 56 | -------------------------------------------------------------------------------- /04_distributed_system/availability.md: -------------------------------------------------------------------------------- 1 | ## 可靠性指标 2 | 3 | 可靠性（Availability），或者说可用性，是描述系统可以提供服务能力的重要指标。高可靠的分布式系统往往需要各种复杂的机制来进行保障。 4 | 5 | 通常情况下，服务的可用性可以用服务承诺（Service Level Agreement，SLA）、服务指标（Service Level Indicator，SLI）、服务目标（Service Level Objective，SLO）等方面进行衡量。 6 | 7 | ### 几个 9 的指标 8 | 9 | 完美的可靠性是不存在的。很多领域里谈到服务的高可靠性，通常都会用“几个 9”的指标来进行衡量。 10 | 11 | “几个 9”的指标，其实是概率意义上粗略反映了系统能提供服务的可靠性指标，最初是电信领域提出的概念。 12 | 13 | 下表给出不同指标下，每年允许服务出现不可用时间的参考值。 14 | 15 | | 指标 | 概率可靠性 | 每年允许不可用时间 | 典型场景 | 16 | |--------|-----------:|-------------------:|----------| 17 | | 一个 9 | 90% | 1.2 个月 | 简单测试 | 18 | | 二个 9 | 99% | 3.6 天 | 普通单点 | 19 | | 三个 9 | 99.9% | 8.6 小时 | 普通集群 | 20 | | 四个 9 | 99.99% | 51.6 分钟 | 高可用 | 21 | | 五个 9 | 99.999% | 5 分钟 | 电信级 | 22 | | 六个 9 | 99.9999% | 31 秒 | 极高要求 | 23 | | 七个 9 | 99.99999% | 3 秒 | N/A | 24 | 25 | 一般来说，单点的服务器系统至少应能满足两个 9；普通企业信息系统应能满足三个 9；少数领先企业（如亚马逊、甲骨文）产品能实现四个 9 甚至更多。大型金融和电信系统指标是五个 9，意味着每年最多允许出现五分钟左右的服务故障。五个 9 以上的系统十分罕见，要实现往往意味着极高的成本。 26 | 27 | ### 两个核心时间 28 | 29 | 一般地，描述系统出现故障的可能性和故障出现后的恢复能力，有两个基础的指标：MTBF 和 MTTR。 30 | 31 | * MTBF：Mean Time Between Failures，平均故障间隔时间，即系统可以无故障运行的预期时间。 32 | * MTTR：Mean Time To Repair，平均修复时间，即发生故障后，系统可以恢复到正常运行的预期时间。 33 | 34 | MTBF 衡量了系统发生故障的频率，如果一个系统的 MTBF 很短，则往往意味着该系统可用性低；而 MTTR 则反映了系统碰到故障后服务的恢复能力，如果系统的 MTTR 过长，则说明系统一旦发生故障，需要较长时间才能恢复服务。 35 | 36 | 一个高可用的系统应该是具有尽量长的 MTBF 和尽量短的 MTTR。 37 | 38 | ### 提高可靠性 39 | 40 | 那么，该如何提升可靠性呢？有两个基本思路：一是让系统中的单个组件都变得更可靠；二是干脆消灭单点。 41 | 42 | IT 从业人员大都有类似的经验，普通笔记本电脑，基本上是过一阵可能就要重启下；而运行 Linux/Unix 系统的专用服务器，则可能连续运行几个月甚至几年时间都不出问题。另外，普通的家用路由器，跟生产级别路由器相比，更容易出现运行故障。这些都是单个组件可靠性不同导致的例子，可以通过简单升级单点的软硬件来改善可靠性。 43 | 44 | 然而，依靠单点实现的可靠性毕竟是有限的。要想进一步的提升，那就只好消灭单点，通过主从、多活等模式让多个节点集体完成原先单点的工作。这可以从概率意义上改善服务对外整体的可靠性，这也是分布式系统的一个重要用途。 45 | -------------------------------------------------------------------------------- /04_distributed_system/cap.md: -------------------------------------------------------------------------------- 1 | ## CAP 原理 2 | 3 | CAP 原理最早出现在 2000 年，由加州大学伯克利分校的 Eric Brewer 教授在 ACM 组织的 Principles of Distributed Computing（PODC）研讨会上提出的猜想。两年后，麻省理工学院的 Nancy Lynch 等学者进行了理论证明。 4 | 5 | 该原理被认为是分布式系统领域的重要原理之一，深刻影响了分布式计算与系统设计的发展。 6 | 7 | ### 定义 8 | **CAP 原理**：分布式系统无法同时确保一致性（Consistency）、可用性（Availability）和分区容忍性（Partition），设计中往往需要弱化对某个特性的需求。 9 | 10 | 一致性、可用性和分区容忍性的具体含义如下： 11 | 12 | * 一致性（Consistency）：任何事务应该都是原子的，所有副本上的状态都是事务成功提交后的结果，并保持强一致； 13 | * 可用性（Availability）：系统（非失败节点）能在有限时间内完成对操作请求的应答； 14 | * 分区容忍性（Partition）：系统中的网络可能发生分区故障（成为多个子网，甚至出现节点上线和下线），即节点之间的通信无法保障。而网络故障不应该影响到系统正常服务。 15 | 16 | CAP 原理认为，分布式系统最多只能保证三项特性中的两项特性。 17 | 18 | 比较直观地理解，当网络可能出现分区时候，系统是无法同时保证一致性和可用性的。要么，节点收到请求后因为没有得到其它节点的确认而不应答（牺牲可用性），要么节点只能应答非一致的结果（牺牲一致性）。 19 | 20 | 由于大部分时候网络被认为是可靠的，因此系统可以提供一致可靠的服务；当网络不可靠时，系统要么牺牲掉一致性（多数场景下），要么牺牲掉可用性。 21 | 22 | *注意：网络分区是可能存在的，出现分区情况后很可能会导致发生“脑裂”现象。* 23 | 24 | ### 应用场景 25 | 26 | 既然 CAP 三种特性不可同时得到保障，则设计系统时候必然要弱化对某个特性的支持。 27 | 28 | #### 弱化一致性 29 | 对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才最终更新成功，期间不保证一致性。 30 | 31 | 例如网站静态页面内容、实时性较弱的查询类数据库等，简单分布式同步协议如 Gossip，以及 CouchDB、Cassandra 数据库等，都为此设计。 32 | 33 | #### 弱化可用性 34 | 对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis、MapReduce 等为此设计。 35 | 36 | Paxos、Raft 等共识算法，主要处理这种情况。在 Paxos 类算法中，可能存在着无法提供可用结果的情形，同时允许少数节点离线。 37 | 38 | #### 弱化分区容忍性 39 | 现实中，网络分区出现概率较小，但很难完全避免。 40 | 41 | 两阶段的提交算法，某些关系型数据库以及 ZooKeeper 主要考虑了这种设计。 42 | 43 | 实践中，网络可以通过双通道等机制增强可靠性，实现高稳定的网络通信。 44 | 45 | -------------------------------------------------------------------------------- /04_distributed_system/flp.md: -------------------------------------------------------------------------------- 1 | ## FLP 不可能原理 2 | 3 | ### 定义 4 | 5 | **FLP 不可能原理**：在网络可靠、但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法（No completely asynchronous consensus protocol can tolerate even a single unannounced process death）。 6 | 7 | 提出并证明该定理的论文《Impossibility of Distributed Consensus with One Faulty Process》是由 Fischer、Lynch 和 Patterson 三位科学家于 1985 年发表，该论文后来获得了 Dijkstra（就是发明最短路径算法的那位计算机科学家）奖。 8 | 9 | FLP 不可能原理告诉我们，**不要浪费时间去试图为异步分布式系统设计面向任意场景的共识算法**。 10 | 11 | ### 如何理解 12 | 13 | 要正确理解 FLP 不可能原理，首先要弄清楚“异步”的含义。 14 | 15 | 在分布式系统中，同步和异步这两个术语存在特殊的含义： 16 | 17 | * 同步，是指系统中的各个节点的时钟误差存在上限；并且消息传递必须在一定时间内完成，否则认为失败；同时各个节点完成处理消息的时间是一定的。因此同步系统可以轻易判断是节点宕机还是传输消息丢失； 18 | * 异步，则意味着系统中各个节点可能存在较大的时钟差异；同时消息传输时间是任意长的；各节点对消息进行处理的时间也可能是任意长的。这就造成无法判断某个消息迟迟没有被响应是哪里出了问题（节点故障还是传输故障？）。不幸地是，现实生活中的系统往往都是异步系统。 19 | 20 | FLP 不可能原理在论文中以图论的形式进行了严格证明。要理解其基本原理并不复杂，一个不严谨的例子如下。 21 | 22 | 三个人在不同房间进行投票（投票结果是 0 或者 1），彼此可以通过电话进行沟通，但经常有人会时不时睡着。比如某个时候，A 投票 0，B 投票 1，C 收到了两人的投票，然后 C 睡着了。此时，A 和 B 将永远无法在有限时间内获知最终的结果，因为他们无法判断究竟是 C 没有应答还是应答的时间过长。如果可以重新投票，则类似情形可以在每次取得结果前发生，这将导致共识过程永远无法完成。 23 | 24 | FLP 不可能原理实际上说明对于允许节点失效情况下，纯粹异步系统无法确保共识在有限时间内完成。即便对于非拜占庭错误的前提下，包括 Paxos、Raft 等算法也都存在无法达成共识的极端情况，只是在工程实践中这种情况出现的概率很小。 25 | 26 | 那么，这是否意味着研究共识算法压根没有意义？ 27 | 28 | 不必如此悲观。学术研究，往往考虑地是数学和物理意义上理想化的情形，很多时候现实世界要稳定得多（感谢这个世界如此鲁棒！）。例如，上面例子中描述的最坏情形，每次都发生的概率其实并没有那么大。工程实现上，若某次共识失败，再尝试几次，很大可能就成功了。 29 | 30 | **科学告诉你，什么是不可能的；工程则告诉你，付出一些代价，可以把它变成可行。** 31 | 32 | 这就是科学和工程不同的魅力。FLP 不可能原理告诉大家不必浪费时间去追求完美的共识方案，而要根据实际情况设计可行的工程方案。 33 | 34 | 那么，退一步讲，在付出一些代价的情况下，共识能做到多好？ 35 | 36 | 回答这一问题的是另一个很出名的原理：CAP 原理。 37 | 38 | *注：科学告诉你去赌场是愚蠢的，因为最终总会输钱；工程则告诉你，如果你愿意接受最终输钱的风险，中间说不定能偶尔小赢几笔呢！* 39 | -------------------------------------------------------------------------------- /04_distributed_system/problem.md: -------------------------------------------------------------------------------- 1 | ## 一致性问题 2 | 3 | 一致性问题是分布式领域最基础、最重要的问题，也是半个世纪以来的研究热点。 4 | 5 | 随着业务场景越来越复杂，计算规模越来越庞大，单点系统往往难以满足高可扩展（Scalability）和高容错（Fault-tolerance）两方面的需求。此时就需要多台服务器通过组成集群，构建更加强大和稳定的“虚拟超级服务器”。 6 | 7 | 任务量越大，处理集群的规模越大，设计和管理的挑战也就越高。谷歌公司的全球搜索集群系统，包括数十万台服务器，每天响应百亿次的互联网搜索请求。 8 | 9 | 集群系统要实现一致性不是一件容易的事。不同节点可能处于不同的状态，不同时刻收到不同的请求，而且随时可能有节点出现故障。要保持对外响应的“一致性”，好比训练一群鸭子齐步走，难度可想而知。 10 | 11 | ### 定义与重要性 12 | 13 | **定义** 一致性（Consistency），早期也叫（Agreement），在分布式系统领域中是指对于多个服务节点，给定一系列操作，在约定协议的保障下，使得它们对处理结果达成“某种程度”的协同。 14 | 15 | 理想情况（不考虑节点故障）下，如果各个服务节点严格遵循相同的处理协议（即构成相同的状态机逻辑），则在给定相同的初始状态和输入序列时，可以确保处理过程中的每个步骤的执行结果都相同。因此，传统分布式系统中讨论一致性，往往是指在外部任意发起请求（如向多个节点发送不同请求）的情况下，确保系统内大部分节点实际处理请求序列的一致，即对请求进行全局排序。 16 | 17 | 那么，为什么说一致性问题十分重要呢？ 18 | 19 | 举个现实生活中的例子，多个售票处同时出售某线路上的火车票，该线路上存在多个经停站，怎么才能保证在任意区间都不会出现超售（同一个座位卖给两个人）的情况？ 20 | 21 | 这个问题看起来似乎没那么难，现实生活中经常通过分段分站售票的机制。然而，要支持海量的用户进行并行购票，并非易事（如 12306 网站高峰期日均访问量超过 500 亿次）。特别是计算机系统往往需要达到远超物理世界的高性能和高可扩展性需求，挑战会变得更大。这也是为何每年到了促销季，各大电商平台都要提前完善系统。 22 | 23 | *注：一致性关注的是系统呈现的状态，并不关注结果是否正确；例如，所有节点都对某请求达成否定状态也是一种一致性。* 24 | 25 | ### 问题挑战 26 | 27 | 计算机固然很快，但在很多地方都比人类世界脆弱的多。典型的，在分布式系统中，存在不少挑战： 28 | 29 | * 节点完成请求的时间无法保障，处理的结果可能是错误的，甚至节点自身随时可能发生故障； 30 | * 为了实现可扩展性，集群往往要采用异步设计，依靠网络消息交互，意味着不可预测的通信延迟、丢失或错误。 31 | 32 | 仍以火车票售卖问题为例，愿意动脑筋的读者可能已经想到了一些不错的解决思路，例如： 33 | 34 | * 要出售任意一张票前，先打电话给其他售票处，确认下当前这张票不冲突。即退化为同步调用来避免冲突； 35 | * 多个售票处提前约好隔离的售票时间。比如第一家可以在上午 8 点到 9 点期间卖票，接下来一个小时是另外一家……即通过令牌机制来避免冲突； 36 | * 成立一个第三方的存票机构，票集中存放，每次卖票前找存票机构查询。此时问题退化为中心化中介机制。 37 | 38 | 这些思路假设售票处都能保证正常工作，并且消息传递不会出现错误。 39 | 40 | 当然，还可以设计出更多更完善的方案，但它们背后的核心思想，都是**将可能引发不一致的并行操作进行串行化**。这实际上也是现代分布式系统处理一致性问题的基础思路。另外，由于普通计算机硬件和软件的可靠性不足，在工程实现上还要对核心部件稳定性进行加强。 41 | 42 | 反过来，如果节点都很鲁棒，性能足够强，同时网络带宽足够大、延迟足够低，这样的集群系统往往更容易实现一致性。 43 | 44 | 然而，真实情况可能比人们预期的糟糕。2015年，论文《Taming Uncertainty in Distributed Systems with Help from the Network》中指出，即便部署了专业设备和冗余网络的中等规模的数据中心，每个月发生的网络故障高达 12 次。 45 | 46 | ### 一致性的要求 47 | 48 | 规范来看，分布式系统达成一致的过程，应该满足： 49 | 50 | * 可终止性（Termination）：一致的结果在有限时间内能完成； 51 | * 约同性（Agreement）：不同节点最终完成决策的结果是相同的； 52 | * 合法性（Validity）：决策的结果必须是某个节点提出的提案。 53 | 54 | 可终止性很容易理解。有限时间内完成，意味着可以保障提供服务（Liveness）。这是计算机系统可以被正常使用的前提。需要注意，在现实生活中这点并不是总能得到保障的。例如取款机有时候会出现“服务中断”；拨打电话有时候是“无法连接”的。 55 | 56 | 约同性看似容易，实际上暗含了一些潜在信息。决策的结果相同，意味着算法要么不给出结果，任何给出的结果必定是达成了共识的，即安全性（Safety）。挑战在于算法必须要考虑的是可能会处理任意的情形。凡事一旦推广到任意情形，往往就不像看起来那么简单。例如现在就剩一张某区间（如北京 --> 南京）的车票了，两个售票处也分别刚通过某种方式确认过这张票的存在。这时，两家售票处几乎同时分别来了一个乘客要买这张票，从各自“观察”看来，自己一方的乘客都是先到的……这种情况下，怎么能达成对结果的共识呢？看起来很容易，卖给物理时间上率先提交请求的乘客即可。然而，对于两个来自不同位置的请求来说，要判断在时间上的“先后”关系并不是那么容易。两个车站的时钟时刻可能是不一致的；时钟计时可能不精确的……根据相对论的观点，不同空间位置的时间是不一致的。因此追求绝对时间戳的方案是不可行的，能做的是要对事件的发生进行排序。 57 | 58 | 事件发生的相对先后顺序（逻辑时钟）十分重要，确定了顺序，就没有了分歧。这也是解决分布式系统领域很多问题的核心秘诀：**把不同时空发生的多个事件进行全局唯一排序，而且这个顺序还得是大家都认可的**。 59 | 60 | 如果存在可靠的物理时钟，实现排序往往更为简单。高精度的石英钟的漂移率为 $$10^{-7}$$，最准确的原子震荡时钟的漂移率为 $$10^{-13}$$。Google 曾在其分布式数据库 Spanner 中采用基于原子时钟和 GPS 的“TrueTime”方案，能够将不同数据中心的时间偏差控制在 10ms 置信区间。在不考虑成本的前提下，这种方案简单、有效。然而，计算机系统的时钟误差要大得多，这就造成分布式系统达成一致顺序十分具有挑战。 61 | 62 | *注：Leslie Lamport 在 1978 年发表的论文《Time, Clocks and the Ordering of Events in a Distributed System》中将分布式系统中顺序与相对论进行对比，提出了偏序关系的观点。而根据相对论，并不存在绝对的时间。因此，先后顺序可能更有意义。* 63 | 64 | 最后的合法性看似绕口，但其实比较容易理解，即达成的结果必须是节点执行操作的结果。仍以卖票为例，如果两个售票处分别决策某张票出售给张三和李四，那么最终达成一致的结果要么是张三，要么是李四，而不能是其他人。 65 | 66 | ### 带约束的一致性 67 | 从前面的分析可以看出，要实现理想的严格一致性（Strict Consistency）代价很大。除非系统所有节点都不发生任何故障，而且节点间通信没有延迟，此时整个系统等价于一台机器。实际上，实现较强的一致性要求同步操作，容错性差，同时会牺牲部分性能和可扩展性。实际系统往往会选择不同强度的一致性，主要包括强一致性（Strong Consistency）和弱一致性（Weak Consistency）两大类。 68 | 69 | 强一致性主要包括顺序一致性（[Sequential Consistency](https://en.wikipedia.org/wiki/Sequential_consistency)）和线性一致性（[Linearizability Consistency](https://en.wikipedia.org/wiki/Linearizability)： 70 | 71 | * 顺序一致性：又叫因果一致性，最早由 Leslie Lamport 1979 年经典论文《How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs》中提出，是一种较强的约束。所有进程看到的全局执行顺序（total order）一致（否则数据副本就不一致了）；并且每个进程看自身操作的顺序（local order）跟实际发生顺序一致。例如，某进程先执行 A，后执行 B，则实际得到的全局结果（其它进程也看到这个结果）中就应该为 A 在 B 前面，而不能反过来。如果另一个进程先后执行了C、D操作，则全局顺序可以共识为 A、B、C、D 或 A、C、B、D 或 C、A、B、D 或 C、D、A、B 的一种（即 A、B 和 C、D 的组合），决不能出现 B、A 或 D、C。顺序一致性实际上限制了各进程自身指令的偏序关系，但不需要在进程间按照物理时间进行全局排序，属于实践中应用较多的强一致性。以算盘为例，每个进程的事件是某根横轴上的算珠，它们可以前后拨动（改变不同进程之间先后顺序），但同一个横轴上的算珠的相对先后顺序无法改变。 72 | * 线性一致性：由 Maurice P. Herlihy 与 Jeannette M. Wing 在 1990 年经典论文《Linearizability: A Correctness Condition for Concurrent Objects》中共同提出，是最强的一致性。它在顺序一致性前提下增加了进程间的操作顺序要求，形成理想化完全一致的全局顺序。线性一致性要求系统看起来似乎只有一个数据副本，客户端操作都是原子的，并且顺序执行；所有进程的操作似乎是实时同步的，并且跟实际发生顺序一致。例如某个客户端写入成功，则其它客户端将立刻看到最新的值。线性一致性下所有进程的所有事件似乎都处于同一个横轴，存在唯一的先后顺序。线性一致性较难实现，目前基本上要么依赖于全局的时钟或锁，要么通过一些共识算法，性能往往不高。 73 | 74 | 强一致性比较难实现，很多场景下可以放宽对一致性的要求，采用部分异步操作，从而提升性能、可扩展性，降低响应延迟，这些在某些方面弱化的一致性都笼统称为弱一致性。例如互联网领域常用的最终一致性（Eventual Consistency），允许出现临时不一致或看到过时数据，但在经历一段时间后可以达到一致的状态。例如电商购物时将某物品放入购物车，但是可能在最终付款时才提示物品已经售罄了。 75 | -------------------------------------------------------------------------------- /04_distributed_system/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 分布式系统是计算机学科中十分重要的一个领域。随着集群规模的不断增长，所处理的数据量越来越大，对于性能、可靠性的要求越来越高，分布式系统相关技术已经变得越来越重要，起到的作用也越来越关键。 4 | 5 | 分布式系统中如何保证共识是个经典问题，无论在学术上还是在工程上都存在很高的研究价值。令人遗憾的是，理想的（各项指标均最优）解决方案并不存在，在现实各种约束条件下，往往需要通过牺牲掉某些需求，来设计出满足特定场景的协议。通过本章的学习，读者可以体会到在工程应用中的类似设计技巧。 6 | 7 | 实际上，工程领域中不少问题都不存在一劳永逸的通用解法；而实用的解决思路都是合理地在实际需求和条件限制之间进行灵活的取舍（trade-off）。 8 | -------------------------------------------------------------------------------- /05_crypto/README.md: -------------------------------------------------------------------------------- 1 | # 密码学与安全技术 2 | 3 | **工程领域从来没有黑科技；密码学不仅是工程。** 4 | 5 | 密码学作为核心的安全技术在信息科技领域的重要性无需多言。离开现代密码学和信息安全技术，人类社会将无法全面步入信息时代。区块链和分布式账本中大量使用了密码学和安全技术的最新成果，特别是身份认证和隐私保护相关技术。 6 | 7 | 从数学定理到工程实践，密码学和信息安全所涉及的知识体系十分繁杂。本章将介绍与区块链密切相关的安全知识，包括 Hash 算法与摘要、加密算法、数字签名和证书、PKI 体系、Merkle 树、布隆过滤器、同态加密等。通过本章，读者可以了解常见安全技术体系，以及如何实现信息安全的核心要素：机密性、完整性、可认证性和不可抵赖性，为后续理解区块链的设计奠定基础。 8 | -------------------------------------------------------------------------------- /05_crypto/_images/Merkle_tree.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/05_crypto/_images/Merkle_tree.png -------------------------------------------------------------------------------- /05_crypto/_images/basic_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/05_crypto/_images/basic_flow.png -------------------------------------------------------------------------------- /05_crypto/_images/bloom_filter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/05_crypto/_images/bloom_filter.png -------------------------------------------------------------------------------- /05_crypto/_images/tls_handshake.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/05_crypto/_images/tls_handshake.png -------------------------------------------------------------------------------- /05_crypto/bloom_filter.md: -------------------------------------------------------------------------------- 1 | ## 布隆过滤器 2 | 3 | 布隆过滤器（Bloom Filter）是在 1970 年由 Burton Howard Bloom 在论文《Space/Time Trade-offs in Hash Coding with Allowable Errors》提出的。布隆过滤器是一种基于 Hash 的高效查找结构，能够快速（常数时间内）回答“某个元素是否在一个集合内”的问题。 4 | 5 | 该结构因为具有高效性而广泛应用到网络和安全领域，例如信息检索（BigTable 和 HBase）、垃圾邮件规则、注册管理等。 6 | 7 | ### 基于 Hash 的快速查找 8 | 9 | 在介绍布隆过滤器之前，先来看看基于 Hash 的快速查找算法。在前面的讲解中，我们提到，Hash 可以将任意内容映射到一个固定长度的字符串，而且不同内容映射到相同串的概率很低。因此，这就构成了一个很好的“内容 -> 索引”的生成关系。 10 | 11 | 试想，如果给定一个内容和存储数组，通过构造 Hash 函数，让映射后的 Hash 值总不超过数组的大小，则可以实现快速的基于内容的查找。例如，内容 “hello world” 的 Hash 值如果是 “100”，则存放到数组的第 100 个单元上去。如果需要快速查找任意内容，如 “hello world” 字符串是否在存储系统中，只需要将其在常数时间内计算 Hash 值，并用 Hash 值查看系统中对应元素即可。该系统“完美地”实现了常数时间内的查找。 12 | 13 | 然而，令人遗憾的是，当映射后的值限制在一定范围（如总数组的大小）内时，会发现 Hash 冲突的概率会变高，而且范围越小，冲突概率越大。很多时候，存储系统的大小又不能无限扩展，这就造成算法效率的下降。为了提高空间利用率，后来人们基于 Hash 算法的思想设计出了布隆过滤器结构。 14 | 15 | ### 更高效的布隆过滤器 16 | 17 | ![布隆过滤器](_images/bloom_filter.png) 18 | 19 | 布隆过滤器采用了多个 Hash 函数来提高空间利用率。 20 | 21 | 对同一个给定输入来说，多个 Hash 函数计算出多个地址，分别在位串的这些地址上标记为 1。在查找时，进行同样的计算过程，并查看对应元素，如果都为 1，则说明较大概率是存在该输入。 22 | 23 | 布隆过滤器与单个 Hash 算法查找相比，大大提高了空间利用率，可以使用较少的空间来表示较大集合的存在关系。 24 | 25 | 实际上，无论是 Hash 还是布隆过滤器，基本思想是一致的，都是基于内容的编址。Hash 函数存在冲突，布隆过滤器也存在冲突，即这两种方法都存在着误报（False Positive）的情况，但绝对不会漏报（False Negative）。 26 | 27 | 布隆过滤器在应用中误报率往往很低，例如，在使用 7 个不同 Hash 函数的情况下，记录 100 万个数据，采用 2 MB 大小的位串，整体的误判率将低于 1%。而传统的 Hash 查找算法的误报率将接近 10%。 28 | -------------------------------------------------------------------------------- /05_crypto/hash.md: -------------------------------------------------------------------------------- 1 | ## Hash 算法与数字摘要 2 | 3 | ### 定义 4 | Hash（哈希或散列）算法，又常被称为指纹（fingerprint）或摘要（digest）算法，是非常基础也非常重要的一类算法。可以将任意长度的二进制明文串映射为较短的（通常是固定长度的）二进制串（Hash 值），并且不同的明文很难映射为相同的 Hash 值。 5 | 6 | 例如计算 “hello blockchain world, this is yeasy@github” 的 SHA-256 Hash 值。 7 | 8 | ```bash 9 | $ echo "hello blockchain world, this is yeasy@github"|shasum -a 256 10 | db8305d71a9f2f90a3e118a9b49a4c381d2b80cf7bcef81930f30ab1832a3c90 11 | ``` 12 | 13 | 对于某个文件，无需查看其内容，只要其 SHA-256 Hash 计算后结果同样为 `db8305d71a9f2f90a3e118a9b49a4c381d2b80cf7bcef81930f30ab1832a3c90`，则说明文件内容（极大的概率）就是 “hello blockchain world, this is yeasy@github”。 14 | 15 | 除了快速对比内容外，Hash 思想也经常被应用到基于内容的编址或命名算法中。 16 | 17 | 一个优秀的 Hash 算法，将能满足： 18 | 19 | * 正向快速：给定原文和 Hash 算法，在有限时间和有限资源内能计算得到 Hash 值； 20 | * 逆向困难：给定（若干）Hash 值，在有限时间内无法（基本不可能）逆推出原文； 21 | * 输入敏感：原始输入信息发生任何改变，新产生的 Hash 值都应该发生很大变化； 22 | * 碰撞避免：很难找到两段内容不同的明文，使得它们的 Hash 值一致（即发生碰撞）。 23 | 24 | 碰撞避免有时候又被称为“抗碰撞性”，可分为“弱抗碰撞性”和“强抗碰撞性”。给定原文前提下，无法找到与之碰撞的其它原文，则算法具有“弱抗碰撞性”；更一般地，如果无法找到任意两个可碰撞的原文，则称算法具有“强抗碰撞性”。 25 | 26 | 很多场景下，也往往要求算法对于任意长的输入内容，输出为定长的 Hash 结果。 27 | 28 | ### 常见算法 29 | 30 | 目前常见的 Hash 算法包括国际上的 Message Digest（MD）系列和 Secure Hash Algorithm（SHA）系列算法，以及国内的 SM3 算法。 31 | 32 | MD 算法主要包括 MD4 和 MD5 两个算法。MD4（RFC 1320）是 MIT 的 Ronald L. Rivest 在 1990 年设计的，其输出为 128 位。MD4 已证明不够安全。MD5（RFC 1321）是 Rivest 于 1991 年对 MD4 的改进版本。它对输入仍以 512 位进行分组，其输出是 128 位。MD5 比 MD4 更加安全，但过程更加复杂，计算速度要慢一点。MD5 已于 2004 年被成功碰撞，其安全性已不足应用于商业场景。 33 | 34 | SHA 算法由美国国家标准与技术院（National Institute of Standards and Technology，NIST）征集制定。首个实现 SHA-0 算法于 1993 年问世，1998 年即遭破解。随后的修订版本 SHA-1 算法在 1995 年面世，它的输出为长度 160 位的 Hash 值，安全性更好。SHA-1 设计采用了 MD4 算法类似原理。SHA-1 已于 2005 年被成功碰撞，意味着无法满足商用需求。 35 | 36 | 为了提高安全性，NIST 后来制定出更安全的 SHA-224、SHA-256、SHA-384 和 SHA-512 算法（统称为 SHA-2 算法）。新一代的 SHA-3 相关算法也正在研究中。 37 | 38 | 此外，中国密码管理局于 2010 年 12 月 17 日发布了 GM/T 0004-2012 《SM3 密码杂凑算法》，建立了国内商用密码体系中的公开 Hash 算法标准，已经被广泛应用在数字签名和认证等场景中。 39 | 40 | *注：MD5 和 SHA-1 算法的破解工作都是由清华大学教授、中国科学院院士王小云主导完成。* 41 | 42 | ### 性能 43 | 44 | 大多数 Hash 算法都是计算敏感型算法，在强大的计算芯片上完成得更快。因此要提升 Hash 计算的性能可以考虑硬件加速。例如采用普通 FPGA 来计算 SHA-256 值，可以轻易达到数 Gbps 的吞吐量，使用专用芯片吞吐量甚至会更高。 45 | 46 | 也有一些 Hash 算法不是计算敏感型的。例如 scrypt 算法，计算过程需要大量的内存资源，因此很难通过选用高性能芯片来加速 Hash 计算。这样的算法可以有效防范采用专用芯片进行算力攻击。 47 | 48 | ### 数字摘要 49 | 数字摘要是 Hash 算法重要用途之一。顾名思义，数字摘要是对原始的数字内容进行 Hash 运算，获取唯一的摘要值。 50 | 51 | 利用 Hash 函数抗碰撞性特点，数字摘要可以检测内容是否被篡改过。 52 | 53 | 细心的读者可能会注意到，有些网站在提供文件下载时，会同时提供相应的数字摘要值。用户下载原始文件后可以在本地自行计算摘要值，并与所提供摘要值进行比对，以确保文件内容没有被篡改过。 54 | 55 | ### Hash 攻击与防护 56 | Hash 算法并不是一种加密算法，不能用于对信息的保护。 57 | 58 | 但 Hash 算法可被应用到对登录口令的保存上。例如网站登录时需要验证用户名和密码，如果网站后台直接保存用户的口令原文，一旦发生数据库泄露后果不堪设想（事实上，网站数据库泄露事件在国内外都不少见）。 59 | 60 | 利用 Hash 的防碰撞特性，后台数据库可以仅保存用户口令的 Hash 值，这样每次通过 Hash 值比对，即可判断输入口令是否正确。即便数据库泄露了，攻击者也无法轻易从 Hash 值还原出口令。 61 | 62 | 然而，有时用户设置口令的安全强度不够，采用了一些常见的字符串，如 password、123456 等。有人专门搜集了这些常见口令，计算对应的 Hash 值，制作成字典。这样通过 Hash 值可以快速反查到原始口令。这一类型以空间换时间的攻击方法包括字典攻击和彩虹表攻击（只保存一条 Hash 链的首尾值，相对字典攻击可以节省存储空间）等。 63 | 64 | 为了防范这一类攻击，可以采用加盐（Salt）的方法。保存的不是原文的直接 Hash 值，而是原文再加上一段随机字符串（即“盐”）之后的 Hash 值。Hash 结果和“盐”分别存放在不同的地方，这样只要不是两者同时泄露，攻击者就很难进行破解。 65 | -------------------------------------------------------------------------------- /05_crypto/history.md: -------------------------------------------------------------------------------- 1 | ## 密码学简史 2 | 3 | 从历史角度看，密码学可以大致分为古典密码学和近现代密码学两个阶段。两者以现代信息技术的诞生为分界点，现在所讨论的密码学多是指后者，建立在信息论和数学成果基础之上。 4 | 5 | 古典密码学源自数千年前。最早在公元前 1900 年左右的古埃及，就出现过使用特殊字符和简单替换式密码来保护信息。美索不达米亚平原上曾出土一个公元前 1500 年左右的泥板，其上记录了加密描述的陶器上釉工艺配方。古希腊时期（公元前 800 ~ 前 146 年）还发明了通过物理手段来隐藏信息的“隐写术”，例如使用牛奶书写、用蜡覆盖文字等。后来在古罗马时期还出现了基于替换加密的凯撒密码，据称凯撒曾用此方法与其部下通信而得以命名。 6 | 7 | 这些手段多数是采用简单的机械工具来保护秘密，在今天看来毫无疑问是十分简陋，很容易破解的。严格来看，可能都很难称为密码科学。 8 | 9 | 近现代密码的研究源自第一、二次世界大战中对军事通信进行保护和破解的需求。 10 | 11 | 1901 年 12 月，意大利工程师 Guglielmo Marconi（奎里亚摩·马可尼）成功完成了跨越大西洋的无线电通信实验，在全球范围内引发轰动，推动了无线电通信时代的带来。无线电极大提高了远程通信的能力，但存在着天然缺陷——它很难限制接收方，这意味着要想保护所传递信息的安全，必须采用可靠的加密技术。 12 | 13 | 对无线电信息进行加密以及破解的过程直接促进了近现代密码学和计算机技术的出现。反过来，这些科技进步也影响了时代的发展。一战时期德国外交部长 Arthur Zimmermann（阿瑟·齐默尔曼）拉拢墨西哥构成抗美军事同盟的电报（1917 年 1 月 16 日）被英国情报机构 —— 40 号办公室破译，直接导致了美国的参战；二战时期德国使用的恩尼格玛（Enigma）密码机（当时最先进的加密设备）被盟军成功破译（1939 年到 1941 年），导致大西洋战役德国失败。据称，二战时期光英国从事密码学研究的人员就达到 7000 人，而他们的成果使二战结束的时间至少提前了一到两年时间。 14 | 15 | 1945 年 9 月 1 日，Claude Elwood Shannon（克劳德·艾尔伍德·香农）完成了划时代的内部报告《A Mathematical Theory of Cryptography（密码术的一个数学理论）》，1949 年 10 月，该报告以《Communication Theory of Secrecy Systems（保密系统的通信理论）》为题在 Bell System Technical Journal（贝尔系统技术期刊）上正式发表。这篇论文首次将密码学和信息论联系到一起，为对称密码技术提供了数学基础。这也标志着近现代密码学的正式建立。 16 | 17 | 1976 年 11 月，Whitfield Diffie 和 Martin E.Hellman 在 IEEE Transactions on Information Theory 上发表了论文《New Directions in Cryptography（密码学的新方向）》，探讨了无需传输密钥的保密通信和签名认证体系问题，正式开创了现代公钥密码学体系的研究。 18 | 19 | 现代密码学的发展与电气技术特别是计算机信息理论和技术关系密切，已经发展为包括随机数、Hash 函数、加解密、身份认证等多个课题的庞大领域，相关成果为现代信息系统特别是互联网奠定了坚实的安全基础。 20 | 21 | *注：Enigma 密码机的加密消息在当年需要数年时间才能破解，而今天使用最新的人工智能技术进行破译只需要 10 分钟左右。* -------------------------------------------------------------------------------- /05_crypto/homoencryption.md: -------------------------------------------------------------------------------- 1 | ## 同态加密 2 | 3 | ### 定义 4 | 5 | 同态加密（Homomorphic Encryption）是一种特殊的加密方法，允许对密文进行处理得到仍然是加密的结果。即对密文直接进行处理，跟对明文进行处理后再对处理结果加密，得到的结果相同。从抽象代数的角度讲，保持了同态性。 6 | 7 | 同态加密可以保证实现处理者无法访问到数据自身的信息。 8 | 9 | 如果定义一个运算符 $$\triangle{}$$，对加密算法 `E` 和 解密算法 `D`，满足： 10 | 11 | $$E(X\triangle{}Y) = E(X)\triangle{} E(Y)$$ 12 | 13 | 则意味着对于该运算满足同态性。 14 | 15 | 同态性来自代数领域，一般包括四种类型：加法同态、乘法同态、减法同态和除法同态。同时满足加法同态和乘法同态，则意味着是代数同态，即全同态（Full Homomorphic）。同时满足四种同态性，则被称为算数同态。 16 | 17 | 对于计算机操作来讲，实现了全同态意味着对于所有处理都可以实现同态性。只能实现部分特定操作的同态性，被称为特定同态（Somewhat Homomorphic）。 18 | 19 | ### 问题与挑战 20 | 21 | 同态加密的问题最早在 1978 年由 Ron Rivest、Leonard Adleman 和 Michael L. Dertouzos 提出（同年 Ron Rivest、Adi Shamir 和 Leonard Adleman 还共同发明了 RSA 算法）。但第一个“全同态”的算法直到 2009 年才被克雷格·金特里（Craig Gentry）在论文《Fully Homomorphic Encryption Using Ideal Lattices》中提出并进行数学证明。 22 | 23 | 仅满足加法同态的算法包括 Paillier 和 Benaloh 算法；仅满足乘法同态的算法包括 RSA 和 ElGamal 算法。 24 | 25 | 同态加密在云计算和大数据的时代意义十分重大。目前，虽然云计算带来了包括低成本、高性能和便捷性等优势，但从安全角度讲，用户还不敢将敏感信息直接放到第三方云上进行处理。如果有了比较实用的同态加密技术，则大家就可以放心地使用各种云服务了，同时各种数据分析过程也不会泄露用户隐私。加密后的数据在第三方服务处理后得到加密后的结果，这个结果只有用户自身可以进行解密，整个过程第三方平台无法获知任何有效的数据信息。 26 | 27 | 另一方面，对于区块链技术，同态加密也是很好的互补。使用同态加密技术，运行在区块链上的智能合约可以处理密文，而无法获知真实数据，极大的提高了隐私安全性。 28 | 29 | 目前全同态的加密方案主要包括如下三种类型： 30 | 31 | * 基于理想格（ideal lattice）的方案：Gentry 和 Halevi 在 2011 年提出的基于理想格的方案可以实现 72 bit 的安全强度，对应的公钥大小约为 2.3 GB，同时刷新密文的处理时间需要几十分钟。 32 | * 基于整数上近似 GCD 问题的方案：Dijk 等人在 2010 年提出的方案（及后续方案）采用了更简化的概念模型，可以降低公钥大小至几十 MB 量级。 33 | * 基于带扰动学习（Learning With Errors，LWE）问题的方案：Brakerski 和 Vaikuntanathan 等在 2011 年左右提出了相关方案；Lopez-Alt A 等在 2012 年设计出多密钥全同态加密方案，接近实时多方安全计算的需求。 34 | 35 | 目前，已知的同态加密技术往往需要较高的计算时间或存储成本，相比传统加密算法的性能和强度还有差距，但该领域关注度一直很高，笔者相信，在不远的将来会出现接近实用的方案。 36 | 37 | ### 函数加密 38 | 与同态加密相关的一个问题是函数加密。 39 | 40 | 同态加密保护的是数据本身，而函数加密顾名思义保护的是处理函数本身，即让第三方看不到处理过程的前提下，对数据进行处理。 41 | 42 | 该问题已被证明不存在对多个通用函数的任意多密钥的方案，目前仅能做到对某个特定函数的一个密钥的方案。 43 | 44 | -------------------------------------------------------------------------------- /05_crypto/merkle_trie.md: -------------------------------------------------------------------------------- 1 | ## Merkle 树结构 2 | 3 | [默克尔树](https://en.wikipedia.org/wiki/Merkle_tree)（又叫哈希树）是一种典型的二叉树结构，由一个根节点、一组中间节点和一组叶节点组成。默克尔树最早由 Merkle Ralf 在 1980 年提出，曾广泛用于文件系统和 P2P 系统中。 4 | 5 | 其主要特点为： 6 | 7 | * 最下面的叶节点包含存储数据或其哈希值； 8 | * 非叶子节点（包括中间节点和根节点）都是它的两个孩子节点内容的哈希值。 9 | 10 | 进一步地，默克尔树可以推广到多叉树的情形，此时非叶子节点的内容为它所有的孩子节点的内容的哈希值。 11 | 12 | 默克尔树逐层记录哈希值的特点，让它具有了一些独特的性质。例如，底层数据的任何变动，都会传递到其父节点，一层层沿着路径一直到树根。这意味树根的值实际上代表了对底层所有数据的“数字摘要”。 13 | 14 | 目前，默克尔树的典型应用场景包括如下几种。 15 | 16 | ### 证明某个集合中存在或不存在某个元素 17 | 18 | 通过构建集合的默克尔树，并提供该元素各级兄弟节点中的 Hash 值，可以不暴露集合完整内容而证明某元素存在。 19 | 20 | 另外，对于可以进行排序的集合，可以将不存在元素的位置用空值代替，以此构建稀疏默克尔树（Sparse Merkle Tree）。该结构可以证明某个集合中不包括指定元素。 21 | 22 | ### 快速比较大量数据 23 | 24 | 对每组数据排序后构建默克尔树结构。当两个默克尔树根相同时，则意味着所代表的两组数据必然相同。否则，必然不同。 25 | 26 | 由于 Hash 计算的过程可以十分快速，预处理可以在短时间内完成。利用默克尔树结构能带来巨大的比较性能优势。 27 | 28 | ### 快速定位修改 29 | 30 | 以下图为例，基于数据 D0……D3 构造默克尔树，如果 D1 中数据被修改，会影响到 N1，N4 和 Root。 31 | 32 | ![Merkle 树示例](_images/Merkle_tree.png) 33 | 34 | 因此，一旦发现某个节点如 Root 的数值发生变化，沿着 Root --> N4 --> N1，最多通过 O(lgN) 时间即可快速定位到实际发生改变的数据块 D1。 35 | 36 | ### 零知识证明 37 | 38 | 仍以上图为例，如何向他人证明拥有某个数据 D0 而不暴露其它信息。挑战者提供随机数据 D1，D2 和 D3，或由证明人生成（需要加入特定信息避免被人复用证明过程）。 39 | 40 | 证明人构造如图所示的默克尔树，公布 N1，N5，Root。验证者自行计算 Root 值，验证是否跟提供值一致，即可很容易检测 D0 存在。整个过程中验证者无法获知与 D0 相关的额外信息。 41 | -------------------------------------------------------------------------------- /05_crypto/signature.md: -------------------------------------------------------------------------------- 1 | ## 消息认证码与数字签名 2 | 3 | 消息认证码和数字签名技术通过对消息的摘要进行加密，可以防止消息被篡改和认证身份。 4 | 5 | ### 消息认证码 6 | 消息认证码（Hash-based Message Authentication Code，HMAC），利用对称加密，对消息完整性（Integrity）进行保护。 7 | 8 | 基本过程为对某个消息，利用提前共享的对称密钥和 Hash 算法进行处理，得到 HMAC 值。该 HMAC 值持有方可以向对方证明自己拥有某个对称密钥，并且确保所传输消息内容未被篡改。 9 | 10 | 典型的 HMAC 生成算法包括 K，H，M 三个参数。K 为提前共享的对称密钥，H 为提前商定的 Hash 算法（如 SHA-256），M 为要传输的消息内容。三个参数缺失了任何一个，都无法得到正确的 HMAC 值。 11 | 12 | 消息认证码可以用于简单证明身份的场景。如 Alice、Bob 提前共享了 K 和 H。Alice 需要知晓对方是否为 Bob，可发送一段消息 M 给 Bob。Bob 收到 M 后计算其 HMAC 值并返回给 Alice，Alice 检验收到 HMAC 值的正确性可以验证对方是否真是 Bob。 13 | 14 | *注：例子中并没有考虑中间人攻击的情况，并假定信道是安全的。* 15 | 16 | 消息认证码的主要问题是需要提前共享密钥，并且当密钥可能被多方同时拥有（甚至泄露）的场景下，无法追踪消息的真实来源。如果采用非对称加密算法，则能有效地解决这个问题，即数字签名。 17 | 18 | ### 数字签名 19 | 类似在纸质合同上进行签名以确认合同内容和证明身份，数字签名既可以证实某数字内容的完整性，又可以确认其来源（即不可抵赖，Non-Repudiation）。 20 | 21 | 一个典型的场景是，Alice 通过信道发给 Bob 一个文件（一份信息），Bob 如何获知所收到的文件即为 Alice 发出的原始版本？Alice 可以先对文件内容进行摘要，然后用自己的私钥对摘要进行加密（签名），之后同时将文件和签名都发给 Bob。Bob 收到文件和签名后，用 Alice 的公钥来解密签名，得到数字摘要，与对文件进行摘要后的结果进行比对。如果一致，说明该文件确实是 Alice 发过来的（因为别人无法拥有 Alice 的私钥），并且文件内容没有被修改过（摘要结果一致）。 22 | 23 | 理论上所有的非对称加密算法都可以用来实现数字签名，实践中常用算法包括 1991 年 8 月 NIST 提出的 DSA（Digital Signature Algorithm，基于 ElGamal 算法）和安全强度更高的 ECDSA（Elliptic Curve Digital Signature Algorithm，基于椭圆曲线算法）等。 24 | 25 | 除普通的数字签名应用场景外，针对一些特定的安全需求，产生了一些特殊数字签名技术，包括盲签名、多重签名、群签名、环签名等。 26 | 27 | #### 盲签名 28 | 29 | 盲签名（Blind Signature），1982 年由 David Chaum 在论文《Blind Signatures for Untraceable Payment》中[提出](http://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/Chaum.BlindSigForPayment.1982.PDF)。签名者需要在无法看到原始内容的前提下对信息进行签名。 30 | 31 | 盲签名可以实现对所签名内容的保护，防止签名者看到原始内容；另一方面，盲签名还可以实现防止追踪（Unlinkability），签名者无法将签名内容和签名结果进行对应。典型的实现包括 RSA 盲签名算法等。 32 | 33 | #### 多重签名 34 | 多重签名（Multiple Signature），即 n 个签名者中，收集到至少 m 个（n >= m >= 1）的签名，即认为合法。 35 | 36 | 其中，n 是提供的公钥个数，m 是需要匹配公钥的最少的签名个数。 37 | 38 | 多重签名可以有效地应用在多人投票共同决策的场景中。例如双方进行协商，第三方作为审核方。三方中任何两方达成一致即可完成协商。 39 | 40 | 比特币交易中就支持多重签名，可以实现多个人共同管理某个账户的比特币交易。 41 | 42 | #### 群签名 43 | 44 | 群签名（Group Signature），即某个群组内一个成员可以代表群组进行匿名签名。签名可以验证来自于该群组，却无法准确追踪到签名的是哪个成员。 45 | 46 | 群签名需要一个群管理员来添加新的群成员，因此存在群管理员可能追踪到签名成员身份的风险。 47 | 48 | 群签名最早在 1991 年由 David Chaum 和 Eugene van Heyst 提出。 49 | 50 | #### 环签名 51 | 52 | 环签名（Ring Signature），由 Rivest，Shamir 和 Tauman 三位密码学家在 2001 年首次提出。环签名属于一种简化的群签名。 53 | 54 | 签名者首先选定一个临时的签名者集合，集合中包括签名者自身。然后签名者利用自己的私钥和签名集合中其他人的公钥就可以独立地产生签名，而无需他人的帮助。签名者集合中的其他成员可能并不知道自己被包含在最终的签名中。 55 | 56 | 环签名在保护匿名性方面也具有很多用途。 57 | 58 | ### 安全性 59 | 60 | 数字签名算法自身的安全性由数学问题进行保护。但在实践中，各个环节的安全性都十分重要，一定要严格遵循标准流程。 61 | 62 | 例如，目前常见的数字签名算法需要选取合适的随机数作为配置参数，配置参数使用不当或泄露都会造成安全漏洞和风险。 63 | 64 | 2010 年 8 月，SONY 公司因为其 PS3 产品在采用十分安全的 ECDSA 进行签名时不慎使用了重复的随机参数，导致私钥被最终破解，造成重大经济损失。 65 | -------------------------------------------------------------------------------- /05_crypto/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 本章总结了密码学与安全领域中的一些核心问题和经典算法。通过阅读本章内容，相信读者已经对现代密码学的发展状况和关键技术有了初步了解。掌握这些知识，对于理解区块链系统如何实现隐私保护和安全防护都很有好处。 4 | 5 | 现代密码学安全技术在设计上大量应用了十分专业的现代数学知识，如果读者希望能够深入学习其原理，则需要进一步学习并掌握近现代的数学科学，特别是数论、抽象代数等相关内容。 6 | 7 | 从应用的角度来看，完善的安全系统除了核心算法外，还需要包括协议、机制、系统、人员等多个方面。任何一个环节出现漏洞都将带来巨大的安全风险。因此，实践中要实现真正高安全可靠的系统是十分困难的。 8 | 9 | 区块链中大量利用了现代密码学的已有成果；反过来，区块链在诸多场景中的应用也提出了很多新的需求，促进了安全学科的进一步发展。 10 | -------------------------------------------------------------------------------- /06_bitcoin/README.md: -------------------------------------------------------------------------------- 1 | # 比特币 —— 区块链思想诞生的摇篮 2 | 3 | **之所以看得更远，是因为站在了巨人的肩膀上。** 4 | 5 | 作为区块链思想的源头，比特币项目值得区块链技术爱好者们仔细学习和研究。 6 | 7 | 比特币网络是首个得到大规模部署的区块链平台，也是首个得到长时间实践检验的加密货币实现，无论在科技史还是金融史上都将具有十分重要的意义。比特币项目在诞生和发展过程中，借鉴了加密货币、密码学、博弈论、分布式系统、控制论等多个领域的技术成果，可谓博采众家之长于一身，是集大成者。 8 | 9 | 后来的区块链技术应用已经超越了加密货币的范畴，但探索比特币项目的发展历程和设计思路，对于深刻理解区块链技术的来龙去脉有着重要的价值。 10 | 11 | 本章将介绍比特币项目的来源、核心原理设计、相关的工具，以及关键的技术话题。 12 | 13 | -------------------------------------------------------------------------------- /06_bitcoin/_images/bitcoin_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/bitcoin_logo.png -------------------------------------------------------------------------------- /06_bitcoin/_images/bitcoin_price.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/bitcoin_price.png -------------------------------------------------------------------------------- /06_bitcoin/_images/bitcoin_wp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/bitcoin_wp.png -------------------------------------------------------------------------------- /06_bitcoin/_images/block_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/block_example.png -------------------------------------------------------------------------------- /06_bitcoin/_images/block_size.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/block_size.png -------------------------------------------------------------------------------- /06_bitcoin/_images/coins.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/coins.png -------------------------------------------------------------------------------- /06_bitcoin/_images/pow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/pow.png -------------------------------------------------------------------------------- /06_bitcoin/_images/sidechain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/sidechain.png -------------------------------------------------------------------------------- /06_bitcoin/_images/sidechain_workflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/sidechain_workflow.png -------------------------------------------------------------------------------- /06_bitcoin/_images/transaction_example.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/06_bitcoin/_images/transaction_example.png -------------------------------------------------------------------------------- /06_bitcoin/consensus.md: -------------------------------------------------------------------------------- 1 | ## 共识机制 2 | 3 | 比特币网络是完全公开的，任何人都可以匿名接入，因此共识协议的稳定性和防攻击性十分关键。 4 | 5 | 比特币区块链采用了 Proof of Work（PoW）机制来实现共识，该机制最早于 1998 年在 [B-money](http://www.weidai.com/bmoney.txt) 设计中提出。 6 | 7 | 目前，Proof of X 系列中比较出名的一致性协议包括 PoW、PoS 和 DPoS 等，都是通过经济惩罚来限制恶意参与。 8 | 9 | ### 工作量证明 10 | 11 | 工作量证明是通过计算来猜测一个数值（nonce），使得拼凑上交易数据后内容的 Hash 值满足规定的上限（来源于 hashcash）。由于 Hash 难题在目前计算模型下需要大量的计算，这就保证在一段时间内，系统中只能出现少数合法提案。反过来，如果谁能够提出合法提案，也证明提案者确实已经付出了一定的工作量。 12 | 13 | 同时，这些少量的合法提案会在网络中进行广播，收到的用户进行验证后，会基于用户认为的最长链基础上继续难题的计算。因此，系统中可能出现链的分叉（Fork），但最终会有一条链成为最长的链。 14 | 15 | Hash 问题具有不可逆的特点，因此，目前除了暴力计算外，还没有有效的算法进行解决。反之，如果获得符合要求的 nonce，则说明在概率上是付出了对应的算力。谁的算力多，谁最先解决问题的概率就越大。当掌握超过全网一半算力时，从概率上就能控制网络中链的走向。这也是所谓 `51%` 攻击的由来。 16 | 17 | 参与 PoW 计算比赛的人，将付出不小的经济成本（硬件、电力、维护等）。当没有最终成为首个算出合法 nonce 值的“幸运儿”时，这些成本都将被沉没掉。这也保障了，如果有人尝试恶意破坏，需要付出大量的经济成本。也有人考虑将后算出结果者的算力按照一定比例折合进下一轮比赛。 18 | 19 | 有一个很直观的超市付款的例子，可以说明为何这种经济博弈模式会确保系统中最长链的唯一性。 20 | 21 | ![Pow 保证一致性](_images/pow.png) 22 | 23 | 假定超市只有一个出口，付款时需要排成一队，可能有人不守规矩要插队。超市管理员会检查队伍，认为最长的一条队伍是合法的，并让不合法的分叉队伍重新排队。新到来的人只要足够理智，就会自觉选择最长的队伍进行排队。这是因为，多条链的参与者看到越长的链越有可能胜出，从而更倾向于选择长的链。 24 | 25 | 可以看到，最长链机制可以提高很好地抗攻击性，同时其代价是浪费掉了非最长链上的计算资源。部分改进工作是考虑以最长链为基础，引入树形结构以提高整体的交易性能，如 GHOST 协议（《Secure high-rate transaction processing in bitcoin》）和 Conflux 算法（《Scaling Nakamoto Consensus to Thousands of Transactions per Second》）。 26 | 27 | ### 权益证明 28 | 29 | 权益证明（Proof of Stake，PoS）最早在 2013 年被提出，最早在 [Peercoin]() 系统中被实现，类似于现实生活中的股东机制，拥有股份越多的人越容易获取记账权（同时越倾向于维护网络的正常工作）。 30 | 31 | 典型的过程是通过保证金（代币、资产、名声等具备价值属性的物品即可）来对赌一个合法的块成为新的区块，收益为抵押资本的利息和交易服务费。提供证明的保证金（例如通过转账货币记录）越多，则获得记账权的概率就越大。合法记账者可以获得收益。 32 | 33 | PoS 试图解决在 PoW 中大量资源被浪费的问题，因而受到了广泛关注。恶意参与者将存在保证金被罚没的风险，即损失经济利益。 34 | 35 | 一般情况下，对于 PoS 来说，需要掌握超过全网 1/3 的资源，才有可能左右最终的结果。这也很容易理解，三个人投票，前两人分别支持一方，这时候，第三方的投票将决定最终结果。 36 | 37 | PoS 也有一些改进的算法，包括授权股权证明机制（DPoS），即股东们投票选出一个董事会，董事会中成员才有权进行代理记账。这些算法在实践中得到了不错的验证，但是并没有理论上的证明。 38 | 39 | 2017 年 8 月，来自爱丁堡大学和康涅狄格大学的 Aggelos Kiayias 等学者在论文《Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol》中提出了 Ouroboros 区块链共识协议，该协议可以达到诚实行为的近似纳什均衡，被认为是首个可证实安全的 PoS 协议。 40 | 41 | -------------------------------------------------------------------------------- /06_bitcoin/currency.md: -------------------------------------------------------------------------------- 1 | ## 实体货币到加密数字货币 2 | 3 | 区块链最初的思想，诞生于无数先哲对于用加密数字货币替代实体货币的探讨和设计中。 4 | 5 | ### 货币的历史演化 6 | 众所周知，货币是人类文明发展过程中的一大发明。其最重要的职能包括价值尺度、流通手段、贮藏手段等。很难想象离开了货币，现代社会庞大而复杂的经济和金融体系如何保持运转。也正是因为它如此重要，货币的设计和发行机制是关系到国计民生的大事。 7 | 8 | 历史上，在自然和人为因素的干预下，货币的形态经历了多个阶段的演化，包括实物货币、金属货币、代用货币、信用货币、电子货币、数字货币等。近代之前相当长的一段时间里，货币的形态一直是以实体的形式存在，可统称为“实体货币”。计算机诞生后，为货币的虚拟化提供了可能性。 9 | 10 | 同时，货币自身的价值依托也不断发生演化，从最早的实物价值依托、功能价值依托、发行方信用价值依托，直到今天的对信息科技（包括软件、系统、算法等）的信任价值依托。 11 | 12 | *注：中国最早关于货币的确切记载“夏后以玄币”，出现在恒宽《盐铁论·错币》。TBD* 13 | 14 | ### 从纸币到数字货币 15 | 16 | 理论上任何事物都可以作为货币，只要使用者愿意接受。例如在随便一张纸上注明代表若干金额，只要交易各方都认可，这张纸就可以起到货币职能。实际上如今世界最常见的货币流通形式就是纸币，既方便携带、不易仿制，又相对容易辩伪。 17 | 18 | 或许有人会认为信用卡等电子方式，相对于纸币等货币形式使用起来更为方便。确实，信用卡在某些场景下会更为便捷，但它依赖背后的集中式支付体系，一旦碰到支付系统故障、断网、缺乏支付终端等情况，信用卡就无法使用；另外，信用卡形式往往还需要额外的终端设备支持。 19 | 20 | 目前，无论是货币形式，还是信用卡形式，都需要额外的支持机构（例如银行）来完成生产、分发、管理等操作。“中心化”的结构带来了管理和监管上的便利，但系统安全性方面存在很大挑战。诸如伪造、信用卡诈骗、盗刷、转账等安全事件屡见不鲜。 21 | 22 | 很显然，如果能实现一种数字货币，保持既有货币方便易用的特性，同时消除纸质货币的缺陷，无疑将极大提高社会整体经济活动的运作效率。 23 | 24 | 让我们来对比现有的数字货币（以比特币为例）和现实生活中的纸币，两者的优劣如下表所示。 25 | 26 | | 属性 | 分析 | 优势方 | 27 | | --- | --- | --- | 28 | | 便携 | 大部分场景（特别大额支付）下数字货币将具备更好的便携性。 | 数字货币 | 29 | | 防伪 | 两者各有千秋，但数字货币整体上会略胜一筹。纸币依靠的是各种设计（纸张、油墨、暗纹、夹层等）上的精巧，数字货币依靠的则是密码学上的保障。事实上，纸币的伪造时有发生，但数字货币的伪造目前还无法实现。 | 数字货币 | 30 | | 辩伪 | 纸币即使依托验钞机等专用设备仍会有误判情况，数字货币依靠密码学易于校验。数字货币胜出。 | 数字货币 | 31 | | 匿名 | 比特币利用化名（Pseudonymity）来隐藏身份，但账目公开可见。两者都无法阻止有意的追踪。 | 持平 | 32 | | 交易 | 对纸币来说，谁物理持有纸币谁就是合法拥有者，交易通过纸币自身的转移即可完成，无法复制。对数字货币来说则复杂得多，因为任何数字物品都是可以被复制的，但数字形式也意味着转移成本会更低。总体看，两者适用不同的情景。 | 持平 | 33 | | 资源 | 通常情况下，纸币的生产成本要远低于面额。数字货币消耗资源的计算则复杂的多。以比特币为例，最坏情况下可能需要消耗接近其面值的电能。 | 纸币 | 34 | | 发行 | 纸币的发行需要第三方机构的参与；数字货币则通过分布式算法来完成发行。历史上，通胀和通缩往往是不合理地发行货币造成的；数字货币尚缺乏大规模验证，还有待观察。 | 持平 | 35 | | 管理 | 纸币发行和回收往往通过统一机构，易于监管和审计；而目前数字货币在这方面还缺乏足够支持和验证。 | 纸币 | 36 | 37 | 可见，数字货币并非在所有领域都优于已有的货币形式。要比较两者的优劣应该针对具体情况具体分析。不带前提地鼓吹数字货币并不是一种科学和严谨的态度。实际上，仔细观察数字货币的应用情况就会发现，虽然以比特币为代表的数字货币已在众多领域得到应用，但还没有任何一种数字货币能完全替代已有货币。目前，世界各国央行都在密切关注和探索数字货币应用。 38 | 39 | 虽然当前的数字货币“实验”已经取得了不小影响，但可见的局限也很明显：其依赖的区块链和分布式账本技术还缺乏大规模场景的考验；系统的性能和安全性还有待提升；资源的消耗过高；对监管和审计支持不足等。这些问题的解决，都有待金融科技的进一步发展。 40 | 41 | *注：严格来讲，货币（money）不仅局限于现金或通货（cash/currency），货币的含义范围更广。* 42 | 43 | ### “非中心化”的技术难关 44 | 45 | 虽然数字货币带来的预期优势可能很美好，但要设计和实现一套能经得住实用考验的数字货币并非易事。任何货币系统，首先要解决如何发行、如何流通和如何确定价值三个基本问题。 46 | 47 | 现实生活中常用的纸币具备良好的可转移性，可以相对容易地完成价值的交割。但是对于数字货币来说，因为数字化内容容易被复制，数字货币持有人可以试图将同一份货币发给多个接收者，这种攻击被称为“双重支付攻击（Double-spend Attack）”。 48 | 49 | 也许有人会想到，银行中的货币实际上也是数字化的，因为通过电子账号里面的数字记录了客户的资产。说的没错，这种电子货币模式有人称为“数字货币 1.0”，它实际上依赖了一个前提：假定存在一个安全可靠的第三方记账机构负责记账，这个机构负责所有的担保所有的环节，最终完成交易。 50 | 51 | 中心化控制下，数字货币的实现相对容易。但是，有些时候很难找到一个安全可靠的第三方机构，来充当这个记账者角色。 52 | 53 | 例如，发生贸易的两国可能缺乏足够的外汇储备用以支付；汇率的变化等导致双方对合同有不同意见；网络上的匿名双方进行直接买卖而不通过电子商务平台；交易的两个机构彼此互不信任，找不到双方都认可的第三方担保；使用第三方担保系统，但某些时候可能无法连接；第三方的系统可能会出现故障或被篡改攻击…… 54 | 55 | 这个时候，就只有实现非中心化（De-centralized）或多中心化（Multi-centralized）的数字货币系统。在“非中心化”的场景下，实现数字货币存在如下几个难题： 56 | 57 | * 货币的发行：如何合理发行货币，避免导致通货膨胀或其他经济问题； 58 | * 货币的防伪：如何确保和检验货币的真实性，防止被伪造或篡改； 59 | * 货币的交易：如何确保随时随地可以从支付方安全转移到接收方； 60 | * 避免双重支付：电子数据很容易被复制，如何避免同一个数字货币被多次支付。 61 | 62 | 可见，在不存在第三方记账机构的情况下，实现一个数字货币系统的挑战着实不小。 63 | 64 | 能否通过技术创新来解决这个难题呢？比特币融合了数十年在金融、密码学和分布式系统领域的科技成果，终于实现了在全球范围内运行的大规模加密货币系统。 65 | -------------------------------------------------------------------------------- /06_bitcoin/hot_topics.md: -------------------------------------------------------------------------------- 1 | ## 热点问题 2 | 3 | ### 设计中的权衡 4 | 5 | 比特币的设计目标在于支持一套安全、开放、分布式的数字货币系统。围绕这一目标，比特币协议的设计中很多地方都体现了权衡（trade-off）的思想。 6 | 7 | * 区块容量：更大的区块容量可以带来更高的交易吞吐率，但会增加挖矿成本，带来中心化的风险，同时增大存储的代价。兼顾多方面的考虑，当前的区块容量上限设定为 1MB。 8 | * 出块间隔时间：更短的出块间隔可以缩短交易确认的时间，但也可能导致分叉增多，降低网络可用性。 9 | * 脚本支持程度：更强大的脚本指令集可以带来更多灵活性，但也会引入更多安全风险。 10 | 11 | ### 分叉 12 | 13 | 比特币协议不会一成不变。当需要修复漏洞、扩展功能或调整结构时，比特币需要在全网的配合下进行升级。升级通常涉及更改交易的数据结构或区块的数据结构。 14 | 15 | 由于分布在全球的节点不可能同时完成升级来遵循新的协议，因此比特币区块链在升级时可能发生分叉（Fork）。对于一次升级，如果把网络中升级了的节点称为新节点，未升级的节点称为旧节点，根据新旧节点相互兼容性上的区别，可分为软分叉（Soft Fork）和硬分叉（Hard Fork）。 16 | 17 | * 如果旧节点仍然能够验证接受新节点产生的交易和区块，则称为软分叉。旧节点可能不理解新节点产生的一部分数据，但不会拒绝。网络既向后和向前兼容，因此这类升级可以平稳进行。 18 | * 如果旧节点不接受新节点产生的交易和区块，则称为硬分叉。网络只向后兼容，不向前兼容。这类升级往往引起一段时间内新旧节点所认可的区块不同，分出两条链，直到旧节点升级完成。 19 | 20 | 尽管通过硬分叉升级区块链协议的难度大于软分叉，但软分叉能做的事情毕竟有限，一些大胆的改动只能通过硬分叉完成。 21 | 22 | ### 交易延展性 23 | 24 | 交易延展性（Transaction Malleablility）是比特币的一个设计缺陷。简单来讲，是指当交易发起者对交易签名（sign）之后，交易 ID 仍然可能被改变。 25 | 26 | 下面是一个比特币交易的例子。 27 | 28 | ```json 29 | { 30 | "txid": "f200c37aa171e9687452a2c78f2537f134c307087001745edacb58304053db20", 31 | "version": 1, 32 | "locktime": 0, 33 | "vin": [ 34 | { 35 | "txid": "21f10dbfb0ff49e2853629517fa176dc00d943f203aae3511288a7dd89280ac2", 36 | "vout": 0, 37 | "scriptSig": { 38 | "asm": "304402204f7fb0b1e0d154db27dbdeeeb8db7b7d3b887a33e712870503438d8be2d66a0102204782a2714215dc0d581e1d435b41bc6eced2c213c9ba0f993e7fcf468bb5d311[ALL] 025840d511c4bc6690916270a54a6e9290fab687f512c18eb2df0428fa69a26299", 39 | "hex": "47304402204f7fb0b1e0d154db27dbdeeeb8db7b7d3b887a33e712870503438d8be2d66a0102204782a2714215dc0d581e1d435b41bc6eced2c213c9ba0f993e7fcf468bb5d3110121025840d511c4bc6690916270a54a6e9290fab687f512c18eb2df0428fa69a26299" 40 | }, 41 | "sequence": 4294967295 42 | } 43 | ], 44 | "vout": [ 45 | { 46 | "value": 0.00167995, 47 | "n": 0, 48 | "scriptPubKey": { 49 | "asm": "OP_DUP OP_HASH160 7c4338dea7964947b3f0954f61ef40502fe8f791 OP_EQUALVERIFY OP_CHECKSIG", 50 | "hex": "76a9147c4338dea7964947b3f0954f61ef40502fe8f79188ac", 51 | "reqSigs": 1, 52 | "type": "pubkeyhash", 53 | "addresses": [ 54 | "1CL3KTtkN8KgHAeWMMWfG9CPL3o5FSMU4P" 55 | ] 56 | } 57 | } 58 | ] 59 | } 60 | ``` 61 | 62 | 发起者对交易的签名（scriptSig）位于交易的输入（vin）当中，属于交易内容的一部分。交易 ID（txid）是整个交易内容的 Hash 值。这就造成了一个问题：攻击者（尤其是签名方）可以通过改变 scriptSig 来改变 txid，而交易仍旧保持合法。例如，反转 ECDSA 签名过程中的 S 值，签名仍然合法，交易仍然能够被传播。 63 | 64 | 这种延展性攻击能改变交易 ID，但交易的输入和输出不会被改变，所以攻击者不会直接盗取比特币。这也是为什么这一问题能在比特币网络中存在如此之久，而仍未被根治。 65 | 66 | 然而，延展性攻击仍然会带来一些问题。比如，在原始交易未被确认之前广播 ID 改变了的交易可能误导相关方对交易状态的判断，甚至发动拒绝服务攻击；多重签名场景下，一个签名者有能力改变交易 ID，给其他签名者的资产带来潜在风险。同时，延展性问题也会阻碍闪电网络等比特币扩展方案的实施。 67 | 68 | ### 扩容之争 69 | 70 | 比特币当前将区块容量限制在 1MB 以下。如图所示，随着用户和交易量的增加，这一限制已逐渐不能满足比特币的交易需求，使得交易日益拥堵、交易手续费不断上涨。 71 | 72 | ![日益增加的区块容量](_images/block_size.png) 73 | 74 | 关于比特币扩容的持续争论从 2015 年便已开始，期间有一系列方案被摆上台面，包括各种链上扩容提议、用侧链或闪电网络扩展比特币等。考虑到比特币复杂的社区环境，其扩容方案早已不是一方能说了算；而任何一个方案想让要达成广泛共识都比较困难，不同的方案之间也很难调和。 75 | 76 | 当前，扩容之争主要集中在两派：代表核心开发者的 Bitcoin Core 团队主推的隔离见证方案，和 Bitcoin Unlimited 团队推出的方案。 77 | 78 | #### 隔离见证方案 79 | 80 | 隔离见证（Segregated Witness，简称 SegWit）是指将交易中的签名部分从交易的输入中隔离出来，放到交易末尾的被称为见证（Witness）的字段当中。 81 | 82 | 对交易 ID 的计算将不再包含这一签名部分，所以这也是延展性问题的一种解法，给引入闪电网络等第二层协议增强了安全性。 83 | 84 | 同时，隔离见证会将区块容量上限理论上提高到 4MB。对隔离见证的描述可详见五个比特币改进协议（Bitcoin Improvement Proposal）：BIP 141 ~ BIP 145。 85 | 86 | #### Bitcoin Unlimited 方案 87 | 88 | Bitcoin Unlimited 方案（简称 BU）是指扩展比特币客户端，使矿工可以自由配置他们想要生成和验证的区块的容量。 89 | 90 | 根据方案的设想，区块容量的上限会根据众多节点和矿工的配置进行自然收敛。Bitcoin Unlimited Improvement Proposal（BUIP） 001 中表述了这一对比特币客户端的拓展提议，该方案已获得一些大型矿池的支持和部署。 91 | 92 | ### 比特币的监管和追踪 93 | 94 | 比特币的匿名特性，使得对其交易进行监管并不容易。 95 | 96 | 不少非法分子利用这一点，通过比特币转移资金。例如 WannaCry 网络病毒向受害者勒索比特币，短短三天时间里传播并影响到全球 150 多个国家。尽管这些不恰当的行为与比特币项目自身并无直接关系，但都或多或少给比特币社区带来了负面影响。 97 | 98 | 实际上，认为通过比特币就可以实现完全匿名化并不现实。虽然交易账户自身是匿名的 Hash 地址，但一些研究成果（如《An analysis of anonymity in the bitcoin system》）表明，通过分析大量公开可得的交易记录，有很大概率可以追踪到比特币的实际转移路线，甚至可以追踪到真实用户。 99 | 100 | -------------------------------------------------------------------------------- /06_bitcoin/intro.md: -------------------------------------------------------------------------------- 1 | ## 比特币项目简介 2 | 3 | ![比特币项目](_images/bitcoin_logo.png) 4 | 5 | 比特币（BitCoin，BTC）是基于区块链技术的一种加密货币；比特币网络是首个经过大规模、长时间检验的公有区块链系统。 6 | 7 | 自 2009 年 1 月 3 日正式上线以来，比特币价格经历了数次的震荡，目前每枚比特币市场价格超过 7000 美金。 8 | 9 | 比特币网络在功能上具有如下特点： 10 | 11 | * 非中心化：意味着没有任何独立个体可以对网络造成有效破坏，交易请求需要大多数参与者进行共识才能被接受； 12 | * 隐私性：网络中账户地址是化名的，很难从交易信息直接关联到具体的个体，但交易记录是公开可查的； 13 | * 通胀预防：比特币的发行通过挖矿实现，发行量每四年减半，总量上限为 2100 万枚，不会出现通胀。 14 | 15 | 下图来自 [blockchain.info](https://blockchain.info/charts/market-price?timespan=all) 网站，可以看到比特币字诞生以来的汇率（以美元为单位）变化历史。 16 | 17 | ![比特币汇率历史](_images/bitcoin_price.png) 18 | 19 | ### 比特币大事记 20 | 21 | #### 2008 ~ 2013 22 | 23 | ![比特币白皮书邮件](_images/bitcoin_wp.png) 24 | 25 | 2008 年 11 月 1 日 19:16:33，中本聪在 metzdowd 的加密技术邮件列表发布比特币白皮书：“比特币：一种点对点的电子现金系统（Bitcoin: A Peer-to-Peer Electronic Cash System）”。 26 | 27 | 2009 年 1 月 3 日 18:15:05，中本聪在位于芬兰赫尔辛基（Helsinki）的一个小型服务器上挖出了首批 50 个比特币，并在首个区块中记录了当天泰晤士报的头版标题：“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks（财政大臣考虑再次紧急援助银行危机）”。首个区块也被称为创世区块或初始区块（Genesis Block），可以通过 [https://blockchain.info/block-index/14849](https://blockchain.info/block-index/14849) 查看其详细内容。 28 | 29 | 2009 年 1 月 12 日，中本聪将 10 枚比特币转账给开发者 Hal Finney，这也是首笔比特币转账（位于区块 170）。 30 | 31 | 2010 年 5 月 21 日，第一次比特币交易：佛罗里达程序员 Laszlo Hanyecz 用 1 万 BTC 购买了价值 25 美元的披萨优惠券。这是比特币的首个兑换汇率：1: 0.0025 美金。这些比特币在今日价值超过 8000 万美金。 32 | 33 | 2010 年 7 月 17 日，第一个比特币交易平台 Mt.Gox 成立。 34 | 35 | 2011 年 4 月，首个有官方正式记载的版本 0.3.21 发布，支持普通用户参与到 P2P 网络中，并开始支持最小单位 “聪”。 36 | 37 | 2011 年 4 月 26 日，比特币宏大网络缺失的最后一块砖被砌好。中本聪发出一封简短的邮件之后，从此不再现身。 38 | 39 | 2011 年初，开始出现基于显卡的挖矿设备。2011 年年底，比特币价格约为 2 美元。 40 | 41 | 2012 年 6 月，Coinbase 成立，支持比特币相关交易。公司目前已经发展为全球数字资产交易平台，同时支持包括比特币、以太币等数字货币。 42 | 43 | 2011 年 6 月 19 日，由于安全事故，Mt.Gox 数据库发生泄漏，其宣称所保管的部分比特币被盗走。 44 | 45 | 2012 年 9 月 27 日，比特币基金创立，此时比特币价格为 12.46 美元。 46 | 47 | 2012 年 11 月 28 日，比特币产量第一次减半，单个区块产生的比特币从 50 个减半到 25 个。 48 | 49 | 2013 年 3 月，三分之一的专业矿工已经开始采用专用 ASIC 矿机进行挖矿。 50 | 51 | 2013 年 3 月 11 日，比特币发布 0.8.0 版本，大量完善了节点内部管理和网络通信，使得比特币有能力支持后来大规模的 P2P 网络。该版本包含一个严重的 bug，虽然后来被紧急修复，仍造成比特币价格大幅下跌。 52 | 53 | 2013年 4 月 10 日，BTC 创下历史新高，266 美元。 54 | 55 | 2013 年 6 月 27 日，德国会议作出决定：持有比特币一年以上将予以免税，被业内认为此举变相认可了比特币的法律地位，此时比特币价格为 102.24 美元。 56 | 57 | 2013 年 10 月 29 日，世界第一台可以兑换比特币的 ATM 在加拿大上线。 58 | 59 | 2013 年 11 月 29 日，比特币的交易价格创下 1242 美元的历史新高，而同时黄金价格为一盎司 1241.98 美元，比特币价格首度超过黄金。 60 | 61 | 62 | #### 2014 ~ 2019 63 | 64 | 2014 年 2 月 24 日，全球最大比特币交易平台 Mt.Gox 因 85 万个比特币被盗而宣告破产并关闭，造成大量投资者的损失，比特币价格一度暴跌。 65 | 66 | 2014 年 3 月，中国第一台可以兑换比特币的 ATM 在香港上线。 67 | 68 | 2014 年 6 月，美国加州通过 AB-129 法案，允许比特币等数字货币在加州进行流通。 69 | 70 | 2015 年 6 月 3 日，纽约成为美国第一个正式进行数字货币监管的州。 71 | 72 | 2015 年 10 月 22 日，欧盟司法部宣布比特币和其它加密货币为货币而非商品，欧盟法院裁定比特币交易免征增值税。 73 | 74 | 2015 年 10 月 31 日，《经济学人》杂志发表封面文章《信任机器》，开始关注比特币网络背后的区块链技术。 75 | 76 | 2016 年 1 月，中国人民银行在京召开了数字货币研讨会，会后发布公告宣称或推出数字货币。 77 | 78 | 2016 年 7 月 9 日，比特币产量第二次减半，每个区块产出从 25 枚比特币减少为 12.5 枚。 79 | 80 | 2016 年 8 月 2 日，知名比特币交易所 Bitfinex 遭遇安全攻击，按照当时市值计算，损失超过 6000 万美金。 81 | 82 | 2017 年 1 月 24 日，中国部分交易所（Okcoin、火币、BTCC）开始收取比特币交易手续费（为成交金额的 0.2%）。 83 | 84 | 2017 年 3 月，美国证券交易监督委员会（U.S. Securities and Exchange Commission，SEC）连续否决了比特币 ETF 申请。 85 | 86 | 2017 年 4 月 1 日，日本通过法案，正式将数字货币交易所纳入监管体系，承认比特币是合法的预付款工具。 87 | 88 | 2017 年 7 月，比特币网络全网算力首次突破 6 exahash/s（即每秒10的18次方哈希），创下历史新高。 89 | 90 | 2017 年 9 月 4 日，北京市互联网金融风险专项整治工作领导小组办公室下发通知，停止各类 ICO 和代币发行活动。之后，国内各大交易所和矿池陆续终止境内业务。 91 | 92 | 2017 年 10 月 13 日，比特币的价格首次突破 5000 美元。 93 | 94 | 2017 年 12 月 11 日，全球首个比特币期货合约在芝加哥期权交易所（Chicago Board Options Exchange，CBOE）上市。 95 | 96 | 2017 年 12 月 17 日，比特币期货在芝加哥商品交易所（Chicago Mercantile Exchange，CME）上市，当天单个比特币价格一度冲破 20000 美元（总市值超过 2000 亿美金），创下历史新高。 97 | 98 | 2018 年 3 月 6 日，韩国政府发布禁令，禁止公职人员持有和交易加密货币。彼时比特币价格已经长期在 5000 美金左右波动。 99 | 100 | 2018 年 3 月 7 日，美国证券交易监督委员会发布了《关于可能违法的数字资产交易平台的声明》，规定数字货币交易所必须通过注册。 101 | 102 | 2018 年 6 月 21 日，受美联储降息和 Facebook 发币消息的影响，比特币价格重新攀升超过 10000 美金，并一度接近 13000 美金。 103 | 104 | 2019 年 6 月，由于交易量不足以及来自芝加哥商品交易所的竞争，芝加哥期权交易所决定暂停比特币期货合约交易。 105 | 106 | 2018 年 12 月，受到行业周期和社区内部冲突的影响，比特币价格一路下跌，迫近 3000 美金关口。 107 | 108 | 2019 年 6 月 18 日，Facebook 发布了加密货币项目 Libra 的白皮书，宣布要打造简单的、无国界的为数十亿普通人服务的金融基础设施。 109 | 110 | 2019 年 9 月 23 日，比特币期货交易平台 Bakkt 上线，支持以比特币实物进行结算。 111 | 112 | 2019 年 10 月 26 日，受到一系列利好消息影响，比特币价格暴涨，单日从 7600 美元涨到 10800 美元。但随后逐步跌破 7000 美金。 113 | 114 | 目前，比特币区块链已经生成了超过 60 万个区块，完整存储需要约 250 GB 的空间，每天平均完成 20 万笔交易。 115 | 116 | ### 其它数字货币 117 | 118 | 比特币的“成功”，刺激了相关的生态和社区发展，大量类似数字货币（超过 1000 种）纷纷出现，比较出名的包括以太币和瑞波（Ripple）币等。 119 | 120 | 123 | 124 | 这些数字货币大部分复用已有的区块链（例如比特币网络）系统，少数建立在自己独立的区块链网络上。全球活跃的数字货币用户据称在 290 万 ~ 580 万之间（参考剑桥大学 Judge 商学院 2017 年 4 月发表的《全球加密货币基准研究（Global Cryptocurrency Benchmarking Study）》报告）。 125 | 126 | *注：通过 [www.blockchain.com](www.blockchain.com) 网站可以实时查询到比特币网络的信息，包括区块、交易、价格等在内的详细数据。* 127 | -------------------------------------------------------------------------------- /06_bitcoin/lightning_network.md: -------------------------------------------------------------------------------- 1 | ## 闪电网络 2 | 3 | 比特币的交易网络最为人诟病的一点便是交易性能：全网每秒 7 笔左右的交易速度，远低于传统的金融交易系统；同时，等待 6 个块的可信确认将导致约 1 个小时的最终确认时间。 4 | 5 | 为了提升性能，社区提出了闪电网络等创新的设计。 6 | 7 | 闪电网络的主要思路十分简单——将大量交易放到比特币区块链之外进行，只把关键环节放到链上进行确认。该设计最早于 2015 年 2 月在论文《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》中提出。 8 | 9 | 比特币的区块链机制自身已经提供了很好的可信保障，但是相对较慢；另一方面考虑，对于大量的小额交易来说，是否真需要这么高的可信性？ 10 | 11 | 闪电网络主要通过引入智能合约的思想来完善链下的交易渠道。核心的概念主要有两个：RSMC（Recoverable Sequence Maturity Contract）和 HTLC（Hashed Timelock Contract）。前者解决了链下交易的确认问题，后者解决了支付通道的问题。 12 | 13 | ### RSMC 14 | 15 | Recoverable Sequence Maturity Contract，即“可撤销的顺序成熟度合同”。这个词很绕，其实主要原理很简单，类似资金池机制。 16 | 17 | 首先假定交易双方之间存在一个“微支付通道”（资金池）。交易双方先预存一部分资金到“微支付通道”里，初始情况下双方的分配方案等于预存的金额。每次发生交易，需要对交易后产生资金分配结果共同进行确认，同时签字把旧版本的分配方案作废掉。任何一方需要提现时，可以将他手里双方签署过的交易结果写到区块链网络中，从而被确认。从这个过程中可以可以看到，只有在提现时候才需要通过区块链。 18 | 19 | 任何一个版本的方案都需要经过双方的签名认证才合法。任何一方在任何时候都可以提出提现，提现时需要提供一个双方都签名过的资金分配方案（意味着肯定是某次交易后的结果，被双方确认过，但未必是最新的结果）。在一定时间内，如果另外一方拿出证明表明这个方案其实之前被作废了（非最新的交易结果），则资金罚没给质疑方；否则按照提出方的结果进行分配。罚没机制可以确保了没人会故意拿一个旧的交易结果来提现。 20 | 21 | 另外，即使双方都确认了某次提现，首先提出提现一方的资金到账时间要晚于对方，这就鼓励大家尽量都在链外完成交易。通过 RSMC，可以实现大量中间交易发生在链外。 22 | 23 | ### HTLC 24 | 25 | 微支付通道是通过 Hashed Timelock Contract 来实现的，中文意思是“哈希的带时钟的合约”。这个其实就是限时转账。理解起来也很简单，通过智能合约，双方约定转账方先冻结一笔钱，并提供一个哈希值，如果在一定时间内有人能提出一个字符串，使得它哈希后的值跟已知值匹配（实际上意味着转账方授权了接收方来提现），则这笔钱转给接收方。 26 | 27 | 不太恰当的例子，约定一定时间内，有人知道了某个暗语（可以生成匹配的哈希值），就可以拿到这个指定的资金。 28 | 29 | 假设 Alice 和 Bob 想进行跨链或链上资产交换： 30 | 31 | * Alice 是交易的发起者，生成 secret。Bob 是交易的参与者，需要使用 Alice 的 secret 解锁资产。 32 | * Alice 生成一个随机密钥（secret），并计算其哈希值 H。 33 | * Alice 部署 HTLC 合约，将资金锁定到合约中，解锁条件是：任何人提供满足 Hash(secret) = H 的 secret，即可解锁资产。同时设置时间锁，超时后资金退还给 Alice。 34 | * Bob 观察到 Alice 提供的哈希值 H，并在链上（或跨链）部署一个自己的 HTLC 合约，将他的资金锁定，并使用同一个哈希值 H 作为解锁条件。 35 | * Alice 提供 secret 原像（例如 "abc123"）到 Bob 的 HTLC 合约上，满足了哈希值要求，获得资产。 36 | * Bob 通过链上记录看到 Alice 提供的 secret，在 Alice 部署的 HTLC 合约上，使用 secret 解锁资金，获得资产。 37 | 38 | 如果任意一人不提供正确的信息，则智能合约在超时后，会将资产退回。从上面过程可以看出，Bob 的合约超时时间，要短于 Alice 的合约超时时间。 39 | 40 | HTLC 机制还可以扩展到多个人的场景。例如三个人的场景，甲想转账给丙，丙先发给甲一个哈希值。甲可以先跟乙签订一个合同，如果你在一定时间内能告诉我一个暗语，我就给你多少钱。乙于是跑去跟丙签订一个合同，如果你告诉我那个暗语，我就给你多少钱。丙于是告诉乙暗语，拿到乙的钱，乙又从甲拿到钱。最终达到结果是甲转账给丙。这样甲和丙之间似乎构成了一条完整的虚拟的“支付通道”。 41 | 42 | ### 闪电网络 43 | 44 | RSMC 保障了两个人之间的直接交易可以在链下完成，HTLC 保障了任意两个人之间的转账都可以通过一条“支付”通道来完成。闪电网络整合这两种机制，就可以实现任意两个人之间的交易都在链下完成了。 45 | 46 | 在整个交易中，智能合约起到了中介的重要角色，而区块链网络则确保最终的交易结果被确认。 47 | 48 | -------------------------------------------------------------------------------- /06_bitcoin/mining.md: -------------------------------------------------------------------------------- 1 | ## 挖矿过程 2 | 3 | ### 基本原理 4 | 5 | 比特币中最独特的一个概念就是“挖矿”。挖矿是指网络中的维护节点，通过协助生成和确认新区块来获取一定量新增比特币的过程。 6 | 7 | 当用户向比特币网络中发布交易后，需要有人将交易进行记录和确认，形成新的区块，并串联到区块链中。在一个互相不信任的分布式系统中，该由谁来完成这件事情呢？比特币网络采用了“挖矿”的方式来解决这个问题。 8 | 9 | 目前，每 10 分钟左右生成一个不超过 1 MB 大小的区块（记录了这 10 分钟内发生的验证过的交易内容），串联到最长的链尾部，每个区块的成功提交者可以得到系统 12.5 个比特币的奖励（该奖励作为区块内的第一个交易，一定区块数后才能使用），以及用户附加到交易上的支付服务费用。即便没有任何用户交易，矿工也可以自行产生合法的区块并获得奖励。 10 | 11 | 每个区块的奖励最初是 50 个比特币，每隔 21 万个区块自动减半，即 4 年时间，最终比特币总量稳定在 2100 万个。因此，比特币是一种通缩的货币。 12 | 13 | ### 挖矿过程 14 | 15 | 挖矿的具体过程为：参与者综合上一个区块的 Hash 值，上一个区块生成之后的新的验证过的交易内容，再加上自己猜测的一个随机数 X，一起打包到一个候选新区块，让新区块的 Hash 值小于比特币网络中给定的一个数。这是一道面向全体矿工的“计算题”，这个数越小，计算出来就越难。 16 | 17 | 系统每隔两周（即经过 2016 个区块）会根据上一周期的挖矿时间来调整挖矿难度（通过调整限制数的大小），来调节生成区块的时间稳定在 10 分钟左右。为了避免震荡，每次调整的最大幅度为 4 倍。历史上最快的出块时间小于 10s，最慢的出块时间超过 1 个小时。 18 | 19 | 为了挖到矿，参与处理区块的用户端往往需要付出大量的时间和计算力。算力一般以每秒进行多少次 Hash 计算为单位，记为 h/s。目前，比特币网络算力峰值已经达到了每秒数百亿亿次。 20 | 21 | 汇丰银行分析师 Anton Tonev 和 Davy Jose 在 2016 年一份客户报告中曾表示，比特币区块链（通过挖矿）提供了一个局部的、迄今为止最优的解决方案：如何在分散的系统中验证信任。这就意味着，区块链本质上解决了传统依赖于第三方的问题，因为这个协议不只满足了中心化机构追踪交易的需求，还使得陌生人之间产生信任。区块链的技术和安全的过程使得陌生人之间在没有被信任的第三方时产生信任。 22 | 23 | ### 如何看待挖矿 24 | 25 | 2010 年以前，挖矿还是一个非常热门的盈利行业。 26 | 27 | 但是随着相关技术和设备的发展，现在个人进行挖矿的收益已经降得很低。从概率上说，由于当前参与挖矿的计算力实在过于庞大（已经超出了大部分的超算中心），一般的算力已经不可能挖到比特币。特别是利用虚拟机来挖矿的想法，已经基本不可能了。 28 | 29 | 从普通的 CPU（2009 年）、到后来的 GPU（2010 年） 和 FPGA（2011 年末）、到后来的 ASIC 矿机（2013 年年初，目前单片算力已达每秒数百亿次 Hash 计算）、再到现在众多矿机联合组成矿池（知名矿池包括 F2Pool、BitFury 等）。短短数年间，比特币矿机的技术走完了过去几十年的集成电路的进化历程，甚至还颇有创新之处。高回报刺激了科技的飞速发展。目前，矿机主要集中在少数矿池手中，全网的算力已超过每秒 10^20 次 Hash 计算。如果简单认为一次 Hash 计算等同于一次浮点运算，那么比特币全网算力将等同于 500 台 Summit 超级计算机（目前最快的超级计算机，由 IBM 和 Nvidia 于 2018 年研制）。 30 | 31 | 很自然地，读者可能会想到，如果有人掌握了强大的计算力，计算出所有的新区块，并且拒不承认他人的交易内容，那是不是就能破坏掉比特币网络。确实如此，基本上个体达到 1/3 的计算力，比特币网络就存在被破坏的风险了；达到 1/2 的算力，从概率上就掌控整个网络了。但是要实现这么大的算力，将需要付出巨大的经济成本。 32 | 33 | 那么有没有办法防护呢？除了尽量避免计算力放到同一个组织手里，没太好的办法，这是目前 PoW 机制自身造成的。 34 | 35 | 也有人认为为了共识区块的生成，大部分计算力（特别是最终未能算出区块的算力）其实都浪费了。有人提出用 PoS（Proof of Stake）和 DPoS 等协议，利用权益证明（例如持有货币的币龄）作为衡量指标进行投票，相对 PoW 可以节约大量的能耗。PoS 可能会带来囤积货币的问题。除此之外，还有活跃度证明（Proof of Activity，PoA）、消耗证明（Proof of Burn，PoB）、能力证明（Proof of Capacity, PoC）、消逝时间证明（Proof of Elapsed Time）、股权速率证明（Proof of Stake Velocity，PoSV）等，采用了不同的衡量指标。 36 | 37 | 当然，无论哪种机制，都无法解决所有问题。一种可能的优化思路是引入随机代理人制度，通过算法在某段时间内确保只让部分节点参加共识的提案，并且要发放一部分“奖励”给所有在线贡献的节点。 38 | 39 | -------------------------------------------------------------------------------- /06_bitcoin/sidechain.md: -------------------------------------------------------------------------------- 1 | ## 侧链 2 | 3 | 侧链（Sidechain）协议允许资产在比特币区块链和其他区块链之间互转。这一项目也来自比特币社区，最早是在 2013 年 12 月提出，2014 年 4 月立项，由 Blockstream 公司（由比特币核心开发者 Adam Back、Matt Corallo 等共同发起成立）主导研发。侧链协议于 2014 年 10 月在白皮书《Enabling Blockchain Innovations with Pegged Sidechains》中公开。 4 | 5 | 侧链诞生前，众多“山寨币”的出现正在碎片化整个数字货币市场，再加上以太坊等项目的竞争，一些比特币开发者希望能借助侧链的形式扩展比特币的底层协议。 6 | 7 | 简单来讲，以比特币区块链作为主链（Parent chain），其他区块链作为侧链，二者通过双向挂钩（Two-way peg），可实现比特币从主链转移到侧链进行流通。 8 | 9 | ![比特币侧链](_images/sidechain.png) 10 | 11 | 侧链可以是一个独立的区块链，有自己按需定制的账本、共识机制、交易类型、脚本和合约的支持等。侧链不能发行比特币，但可以通过支持与比特币区块链挂钩来引入和流通一定数量的比特币。当比特币在侧链流通时，主链上对应的比特币会被锁定，直到比特币从侧链回到主链。可以看到，侧链机制可将一些定制化或高频的交易放到比特币主链之外进行，实现了比特币区块链的扩展。侧链的核心原理在于能够冻结一条链上的资产，然后在另一条链上产生，可以通过多种方式来实现。这里讲解 Blockstream 提出的基于简单支付验证（Simplified Payment Verification，SPV）证明的方法。 12 | 13 | ### SPV 证明 14 | 15 | 如前面章节所述，在比特币系统中验证交易时，涉及到交易合法性检查、双重花费检查、脚本检查等。由于验证过程需要完整的 UTXO 记录，通常要由运行着完整功能节点的矿工来完成。 16 | 17 | 而很多时候，用户只关心与自己相关的那些交易，比如当用户收到其他人号称发来的比特币时，只希望能够知道交易是否合法、是否已在区块链中存在了足够的时间（即获得足够的确认），而不需要自己成为完整节点做出完整验证。 18 | 19 | 中本聪设计的简单支付验证（Simplified Payment Verification，SPV）可以实现这一点。SPV 能够以较小的代价判断某个支付交易是否已经被验证过（存在于区块链中），以及得到了多少算力保护（定位包含该交易的区块在区块链中的位置）。SPV 客户端只需要下载所有区块的区块头（Block Header），并进行简单的定位和计算工作就可以给出验证结论。 20 | 21 | 侧链协议中，用 SPV 来证明一个交易确实已经在区块链中发生过，称为 SPV 证明（SPV Proof）。一个 SPV 证明包括两部分内容：一组区块头的列表，表示工作量证明；一个特定输出（output）确实存在于某个区块中的密码学证明。 22 | 23 | ### 双向挂钩 24 | 25 | 侧链协议的设计难点在于如何让资产在主链和侧链之间安全流转。简而言之，接受资产的链必须确保发送资产的链上的币被可靠锁定。 26 | 27 | ![侧链双向挂钩的过程](_images/sidechain_workflow.png) 28 | 29 | 具体，协议采用双向挂钩机制实现比特币向侧链转移和返回。主链和侧链需要对对方的特定交易做 SPV 验证。完整过程如下： 30 | 31 | * 当用户要向侧链转移比特币时，首先在主链创建交易，待转移的比特币被发往一个特殊的输出。这些比特币在主链上被锁定。 32 | * 等待一段确认期，使得上述交易获得足够的工作量确认。 33 | * 用户在侧链创建交易提取比特币，需要在这笔交易的输入指明上述主链被锁定的输出，并提供足够的 SPV 证明。 34 | * 等待一段竞争期，防止双重花费攻击。 35 | * 比特币在侧链上自由流通。 36 | * 当用户想让比特币返回主链时，采取类似的反向操作。首先在侧链创建交易，待返回的比特币被发往一个特殊的输出。先等待一段确认期后，在主链用足够的对侧链输出的 SPV 证明来解锁最早被锁定的输出。竞争期过后，主链比特币恢复流通。 37 | 38 | ### 最新进展 39 | 40 | 侧链技术最早由 Blockstream 公司进行探索，于 2015 年 10 月联合合作伙伴发布了基于侧链的商业化应用 Liquid。 41 | 42 | 基于一年多的探索，Blockstream 于 2017 年 1 月发表文章《Strong Federations: An Interoperable Blockchain Solution to Centralized Third Party Risks》，被称为对侧链早期白皮书的补充和改良。白皮书中着重描述了联合挂钩（Federated Pegs）的相关概念和应用。 43 | 44 | 此外，还有一些其他公司或组织也在探索如何合理地应用侧链技术，包括 ConsenSys、Rootstock、Lisk 等。 45 | 46 | -------------------------------------------------------------------------------- /06_bitcoin/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 本章介绍了比特币项目的相关知识，包括起源、核心原理和设计、重要机制，以及最新的闪电网络、侧链和扩容讨论等进展。 4 | 5 | 比特币自身作为数字货币领域的重大突破，对分布式记账领域有着很深远的影响。尤其是其底层的区块链技术，已经受到金融和信息行业的重视，在许多场景下都得到应用。 6 | 7 | 通过本章的剖析，可以看出，比特币网络系统中并非是全新出现的技术，而是有机地组合了密码学、博弈论、记账技术、分布式系统和网络、控制论等领域的已有成果。比特币发明者能从如此广博的多个领域进行了恰当的选取，有效吸收前人的研究成果，这是真正的大师境界。正是如此巧妙的组合，让比特币项目产生了广泛且深远的影响。 8 | -------------------------------------------------------------------------------- /06_bitcoin/tools.md: -------------------------------------------------------------------------------- 1 | ## 相关工具 2 | 3 | 比特币相关工具包括客户端、钱包和矿机等。 4 | 5 | ### 客户端 6 | 7 | 比特币客户端用于和比特币网络进行交互，同时可以参与到网络的维护。 8 | 9 | 客户端分为三种：完整客户端、轻量级客户端和在线客户端。 10 | 11 | * 完整客户端：存储所有的交易历史记录，功能完备； 12 | * 轻量级客户端：不保存交易副本，交易需要向别人查询； 13 | * 在线客户端：通过网页模式来浏览第三方服务器提供的服务。 14 | 15 | 比特币客户端可以从 https://bitcoin.org/en/download 下载到。 16 | 17 | 基于比特币客户端，可以很容易实现用户钱包功能。 18 | 19 | ### 钱包 20 | 21 | 比特币钱包存储和保护用户的私钥，并提供查询比特币余额、收发比特币等功能。根据私钥存储方式不同，钱包主要分为以下几种： 22 | 23 | * 离线钱包：离线存储私钥，也称为“冷钱包”。安全性相对最强，但无法直接发送交易，便利性差。 24 | * 本地钱包：用本地设备存储私钥。可直接向比特币网络发送交易，易用性强，但本地设备存在被攻击风险。 25 | * 在线钱包：用钱包服务器存储经用户口令加密过的私钥。易用性强，但钱包服务器同样可能被攻击。 26 | * 多重签名钱包：由多方共同管理一个钱包地址，比如 2 of 3 模式下，集合三位管理者中的两位的私钥便可以发送交易。 27 | 28 | 比特币钱包可以从 https://bitcoin.org/en/choose-your-wallet 获取到。 29 | 30 | ### 矿机 31 | 32 | 比特币矿机是专门为“挖矿”设计的硬件设备，目前主要包括基于 GPU 和 ASIC 芯片的专用矿机。这些矿机往往采用特殊的设计来加速挖矿过程中的计算处理。 33 | 34 | 矿机最重要的属性是可提供的算力（通常以每秒可进行 Hash 计算的次数来表示）和所需要的功耗。当算力足够大，可以在概率意义上挖到足够多的新的区块，来弥补电力费用时，该矿机是可以盈利的；当单位电力产生的算力不足以支付电力费用时，该矿机无法盈利，意味着只能被淘汰。 35 | 36 | 目前，比特币网络中的全网算力仍然在快速增长中，矿工需要综合考虑算力变化、比特币价格、功耗带来的电费等许多问题，需要算好“经济账”。 37 | 38 | -------------------------------------------------------------------------------- /07_ethereum/README.md: -------------------------------------------------------------------------------- 1 | # 以太坊 —— 挣脱数字货币的枷锁 2 | 3 | **君子和而不同。** 4 | 5 | 在区块链领域，以太坊项目同样是十分出名的开源项目。作为公有区块链平台，以太坊将比特币针对数字货币交易的功能进一步进行拓展，面向更为复杂和灵活的应用场景，支持了智能合约（Smart Contract）这一重要特性。 6 | 7 | 从此，区块链技术的应用场景，从单一基于 UTXO 的数字货币交易，延伸到图灵完备的通用计算领域。用户不再受限于仅能使用比特币脚本所支持的简单逻辑，而是可以自行设计任意复杂的合约逻辑。这就为构建各种多样化的上层应用开启了大门，可谓意义重大。 8 | 9 | 本章将参照比特币项目来介绍以太坊项目的核心概念和改进设计，以及如何安装客户端和使用智能合约等内容。 10 | -------------------------------------------------------------------------------- /07_ethereum/_images/dapps.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/07_ethereum/_images/dapps.png -------------------------------------------------------------------------------- /07_ethereum/_images/ethereum_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/07_ethereum/_images/ethereum_logo.png -------------------------------------------------------------------------------- /07_ethereum/_images/mist.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/07_ethereum/_images/mist.png -------------------------------------------------------------------------------- /07_ethereum/concept.md: -------------------------------------------------------------------------------- 1 | ## 核心概念 2 | 3 | 基于比特币网络的核心思想，以太坊项目提出了许多创新的技术概念，包括智能合约、基于账户的交易、以太币和燃料等。 4 | 5 | ### 智能合约 6 | 7 | 智能合约（Smart Contract）是以太坊中最为重要的一个概念，即以计算机程序的方式来缔结和运行各种合约。最早在上世纪 90 年代，Nick Szabo 等人就提出过类似的概念，但一直依赖因为缺乏可靠执行智能合约的环境，而被作为一种理论设计。区块链技术的出现，恰好补充了这一缺陷。 8 | 9 | 以太坊支持通过图灵完备的高级语言（包括 Solidity、Serpent、Viper）等来开发智能合约。智能合约作为运行在以太坊虚拟机（Ethereum Virtual Machine，EVM）中的应用，可以接受来自外部的交易请求和事件，通过触发运行提前编写好的代码逻辑，进一步生成新的交易和事件，可以进一步调用其它智能合约。 10 | 11 | 智能合约的执行结果可能对以太坊网络上的账本状态进行更新。这些修改由于经过了以太坊网络中的共识，一旦确认后无法被伪造和篡改。 12 | 13 | ### 账户 14 | 15 | 在之前章节中，笔者介绍过比特币在设计中并没有账户（Account）的概念，而是采用了 UTXO 模型记录整个系统的状态。任何人都可以通过交易历史来推算出用户的余额信息。而以太坊则采用了不同的做法，直接用账户来记录系统状态。每个账户存储余额信息、智能合约代码和内部数据存储等。以太坊支持在不同的账户之间转移数据，以实现更为复杂的逻辑。 16 | 17 | 具体来看，以太坊账户分为两种类型：合约账户（Contracts Accounts）和外部账户（Externally Owned Accounts，或 EOA）。 18 | 19 | * 合约账户：存储执行的智能合约代码，只能被外部账户来调用激活； 20 | * 外部账户：以太币拥有者账户，对应到某公钥。账户包括 nonce、balance、storageRoot、codeHash 等字段，由个人来控制。 21 | 22 | 当合约账户被调用时，存储其中的智能合约会在矿工处的虚拟机中自动执行，并消耗一定的燃料。燃料通过外部账户中的以太币进行购买。 23 | 24 | ### 交易 25 | 26 | 交易（Transaction），在以太坊中是指从一个账户到另一个账户的消息数据。消息数据可以是以太币或者合约执行参数。 27 | 28 | 以太坊采用交易作为执行操作的最小单位。每个交易包括如下字段： 29 | 30 | * to：目标账户地址。 31 | * value：可以指定转移的以太币数量。 32 | * nonce：交易相关的字串，用于防止交易被重放。 33 | * gasPrice：执行交易需要消耗的 Gas 价格。 34 | * gasLimit：交易消耗的最大 Gas 值。 35 | * data: 交易附带字节码信息，可用于创建/调用智能合约。 36 | * signature：基于椭圆曲线加密的签名信息，包括R，S，V 三个字段。。 37 | 38 | 类似比特币网络，在发送交易时，用户需要缴纳一定的交易费用，通过以太币方式进行支付和消耗。目前，以太坊网络可以支持超过比特币网络的交易速率（可以达到每秒几十笔）。 39 | 40 | ### 以太币 41 | 42 | 以太币（Ether）是以太坊网络中的货币。 43 | 44 | 以太币主要用于购买燃料，支付给矿工，以维护以太坊网络运行智能合约的费用。以太币最小单位是 wei，一个以太币等于 10^18 个 wei。 45 | 46 | 以太币同样可以通过挖矿来生成。成功生成新区块的以太坊矿工可以获得 2 个以太币的奖励，以及包含在区块内的燃料费用和发现叔块(Uncle block)获得的奖励。用户也可以通过交易市场来直接购买以太币。 47 | 48 | 目前每年大约可以通过挖矿生成超过一千万个以太币，单个以太币的市场价格目前超过 300 美金。 49 | 50 | ### 燃料 51 | 52 | 燃料（Gas），控制某次交易执行指令的上限。每执行一条合约指令会消耗固定的燃料。当某个交易还未执行结束，而燃料消耗完时，合约执行终止并回滚状态。 53 | 54 | Gas 可以跟以太币进行兑换。需要注意的是，以太币的价格是波动的，但运行某段智能合约的燃料费用可以是固定的，通过设定 Gas 价格等进行调节。 55 | -------------------------------------------------------------------------------- /07_ethereum/design.md: -------------------------------------------------------------------------------- 1 | ## 主要设计 2 | 3 | 以太坊项目的基本设计与比特币网络类似。为了支持更复杂的智能合约，以太坊在不少地方进行了改进，包括交易模型、共识、对攻击的防护和可扩展性等。 4 | 5 | ### 智能合约相关设计 6 | 7 | #### 运行环境 8 | 9 | 以太坊采用以太坊虚拟机作为智能合约的运行环境。以太坊虚拟机是一个隔离的轻量级虚拟机环境，运行在其中的智能合约代码无法访问本地网络、文件系统或其它进程。 10 | 11 | 对同一个智能合约来说，往往需要在多个以太坊虚拟机中同时运行多份，以确保整个区块链数据的一致性和高度的容错性。另一方面，这也限制了整个网络的容量。 12 | 13 | #### 开发语言 14 | 15 | 以太坊为编写智能合约设计了图灵完备的高级编程语言，降低了智能合约开发的难度。 16 | 17 | 目前 Solidity 是最常用的以太坊合约编写语言之一。 18 | 19 | 智能合约编写完毕后，用编译器编译为以太坊虚拟机专用的二进制格式（EVM bytecode），由客户端上传到区块链当中，之后在矿工的以太坊虚拟机中执行。 20 | 21 | ### 交易模型 22 | 23 | 出于智能合约的便利考虑，以太坊采用了账户的模型，状态可以实时的保存到账户里，而无需像比特币的 UXTO 模型那样去回溯整个历史。 24 | 25 | UXTO 模型和账户模型的对比如下。 26 | 27 | | 特性 |UXTO 模型|账户模型| 28 | |--|--|--| 29 | |状态查询和变更|需要回溯历史|直接访问| 30 | |存储空间|较大|较小| 31 | |易用性|较难处理|易于理解和编程| 32 | |安全性|较好|需要处理好重放攻击等情况| 33 | |可追溯性|支持历史|不支持追溯历史| 34 | 35 | ### 共识 36 | 37 | 以太坊目前采用了基于成熟的 PoW 共识的变种算法 Ethash 协议作为共识机制。 38 | 39 | 为了防止 ASIC 矿机矿池的算力攻击，跟原始 PoW 的计算密集型 Hash 运算不同，Ethash 在执行时候需要消耗大量内存，反而跟计算效率关系不大。这意味着很难制造出专门针对 Ethash 的芯片，反而是通用机器可能更加有效。 40 | 41 | 虽然，Ethash 相对原始的 PoW 进行了改进，但仍然需要进行大量无效的运算，这也为人们所诟病。 42 | 43 | 社区已经有计划在未来采用更高效的 Proof-of-Stake（PoS）作为共识机制。相对 PoW 机制来讲，PoS 机制无需消耗大量无用的 Hash 计算，但其共识过程的复杂度要更高一些，还有待进一步的检验。 44 | 45 | ### 降低攻击 46 | 47 | 以太坊网络中的交易更加多样化，也就更容易受到攻击。 48 | 49 | 以太坊网络在降低攻击方面的核心设计思想，仍然是通过经济激励机制防止少数人作恶： 50 | 51 | * 所有交易都要提供交易费用，避免 DDoS 攻击； 52 | * 程序运行指令数通过 Gas 来限制，所消耗的费用超过设定上限时就会被取消，避免出现恶意合约。 53 | 54 | 这就确保了攻击者试图消耗网络中虚拟机的计算资源时，需要付出经济代价（支付大量的以太币）；同时难以通过构造恶意的循环或不稳定合约代码来对网络造成破坏。 55 | 56 | ### 提高扩展性 57 | 58 | 可扩展性是以太坊网络承接更多业务量的最大制约。 59 | 60 | 以太坊项目未来希望通过分片（sharding）机制来提高整个网络的扩展性。 61 | 62 | 分片是一组维护和执行同一批智能合约的节点组成的子网络，是整个网络的子集。 63 | 64 | 支持分片功能之前，以太坊整个网络中的每个节点都需要处理所有的智能合约，这就造成了网络的最大处理能力会受限于单个节点的处理能力。 65 | 66 | 分片后，同一片内的合约处理是同步的，彼此达成共识，不同分片之间则可以是异步的，可以提高网络整体的可扩展性。 67 | -------------------------------------------------------------------------------- /07_ethereum/install.md: -------------------------------------------------------------------------------- 1 | ## 安装客户端 2 | 3 | 本节将介绍如何安装 Geth，即 Go 语言实现的以太坊客户端。这里以 Ubuntu 16.04 操作系统为例，介绍从 PPA 仓库和从源码编译这两种方式来进行安装。 4 | 5 | ### 从 PPA 直接安装 6 | 7 | 首先安装必要的工具包。 8 | 9 | ```sh 10 | $ apt-get install software-properties-common 11 | ``` 12 | 13 | 之后用以下命令添加以太坊的源。 14 | 15 | ```sh 16 | $ add-apt-repository -y ppa:ethereum/ethereum 17 | $ apt-get update 18 | ``` 19 | 20 | 最后安装 go-ethereum。 21 | 22 | ```sh 23 | $ apt-get install ethereum 24 | ``` 25 | 26 | 安装成功后，则可以开始使用命令行客户端 Geth。可用 `geth --help` 查看各命令和选项，例如，用以下命令可查看 Geth 版本为 1.6.1-stable。 27 | 28 | ```sh 29 | $ geth version 30 | 31 | Geth 32 | Version: 1.6.1-stable 33 | Git Commit: 021c3c281629baf2eae967dc2f0a7532ddfdc1fb 34 | Architecture: amd64 35 | Protocol Versions: [63 62] 36 | Network Id: 1 37 | Go Version: go1.8.1 38 | Operating System: linux 39 | GOPATH= 40 | GOROOT=/usr/lib/go-1.8 41 | ``` 42 | 43 | ### 从源码编译 44 | 45 | 也可以选择从源码进行编译安装。 46 | 47 | #### 安装 Go 语言环境 48 | 49 | Go 语言环境可以自行访问 [golang.org](https://golang.org) 网站下载二进制压缩包安装。注意不推荐通过包管理器安装版本，往往比较旧。 50 | 51 | 如下载 Go 1.8 版本，可以采用如下命令。 52 | 53 | ```bash 54 | $ curl -O https://storage.googleapis.com/golang/go1.8.linux-amd64.tar.gz 55 | ``` 56 | 57 | 下载完成后，解压目录，并移动到合适的位置（推荐为 /usr/local 下）。 58 | 59 | ```bash 60 | $ tar -xvf go1.8.linux-amd64.tar.gz 61 | $ sudo mv go /usr/local 62 | ``` 63 | 64 | 安装完成后记得配置 GOPATH 环境变量。 65 | 66 | ```bash 67 | $ export GOPATH=YOUR_LOCAL_GO_PATH/Go 68 | $ export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin 69 | ``` 70 | 71 | 此时，可以通过 `go version` 命令验证安装 是否成功。 72 | 73 | ```bash 74 | $ go version 75 | 76 | go version go1.8 linux/amd64 77 | ``` 78 | 79 | #### 下载和编译 Geth 80 | 81 | 用以下命令安装 C 的编译器。 82 | 83 | ```sh 84 | $ apt-get install -y build-essential 85 | ``` 86 | 87 | 下载选定的 go-ethereum 源码版本，如最新的社区版本： 88 | 89 | ```bash 90 | $ git clone https://github.com/ethereum/go-ethereum 91 | ``` 92 | 93 | 编译安装 Geth。 94 | 95 | ```bash 96 | $ cd go-ethereum 97 | $ make geth 98 | ``` 99 | 100 | 安装成功后，可用 `build/bin/geth --help` 查看各命令和选项。例如，用以下命令可查看 Geth 版本为 1.6.3-unstable。 101 | 102 | ```bash 103 | $ build/bin/geth version 104 | Geth 105 | Version: 1.6.3-unstable 106 | Git Commit: 067dc2cbf5121541aea8c6089ac42ce07582ead1 107 | Architecture: amd64 108 | Protocol Versions: [63 62] 109 | Network Id: 1 110 | Go Version: go1.8 111 | Operating System: linux 112 | GOPATH=/usr/local/gopath/ 113 | GOROOT=/usr/local/go 114 | ``` 115 | 116 | -------------------------------------------------------------------------------- /07_ethereum/intro.md: -------------------------------------------------------------------------------- 1 | ## 以太坊项目简介 2 | 3 | ![以太坊项目](_images/ethereum_logo.png) 4 | 5 | 以太坊（Ethereum）项目的最初目标，是打造一个运行智能合约的平台（Platform for Smart Contract）。该平台支持图灵完备的应用，按照智能合约的约定逻辑自动执行，理想情况下将不存在故障停机、审查、欺诈，以及第三方干预等问题。 6 | 7 | 以太坊平台目前支持 Golang、C++、Python 等多种语言实现的客户端。由于核心实现上基于比特币网络的核心思想进行了拓展，因此在很多设计特性上都与比特币网络十分类似。 8 | 9 | 基于以太坊项目，以太坊团队目前运营了一条公开的区块链平台——以太坊网络。智能合约开发者使用官方提供的工具和以太坊专用应用开发语言 Solidity，可以很容易开发出运行在以太坊网络上的“去中心化”应用（Decentralized Application，DApp）。这些应用将运行在以太坊的虚拟机（Ethereum Virtual Machine，EVM）里。用户通过以太币（Ether）来购买燃料（Gas），维持所部署应用的运行。 10 | 11 | 以太坊项目的官网网站为 [ethereum.org](https://ethereum.org)，代码托管在 [github.com/ethereum](github.com/ethereum)。 12 | 13 | 14 | ### 以太坊项目简史 15 | 16 | 相对比特币网络自 2009 年上线的历史，以太坊项目要年轻的多。 17 | 18 | 2013 年底，比特币开发团队中有一些开发者开始探讨将比特币网络中的核心技术，主要是区块链技术，拓展到更多应用场景的可能性。以太坊的早期发明者 Vitalik Buterin 提出应该能运行任意形式（图灵完备）的应用程序，而不仅仅是比特币中受限制的简单脚本。该设计思想并未得到比特币社区的支持，后来作为以太坊白皮书发布。 19 | 20 | 2014 年 2 月，更多开发者（包括 Gavin Wood、Jeffrey Wilcke 等）加入以太坊项目，并计划在社区开始以众筹形式募集资金，以开发一个运行智能合约的信任平台。 21 | 22 | 2014 年 7 月，以太币预售，经过 42 天，总共筹集到价值超过 1800 万美金的比特币。随后在瑞士成立以太坊基金会，负责对募集到的资金进行管理和运营；并组建研发团队以开源社区形式进行平台开发。 23 | 24 | 2015 年 7 月底，以太坊第一阶段 Frontier 正式发布，标志着以太坊区块链网络的正式上线。这一阶段采用类似比特币网络的 PoW 共识机制，参与节点以矿工挖矿形式维护网络；支持上传智能合约。Frontier 版本实现了计划的基本功能，在运行中测试出了一些安全上的漏洞。这一阶段使用者以开发者居多。 25 | 26 | 2016 年 3 月，第二阶段 Homestead 开始运行（区块数 1150000），主要改善了安全性，同时开始提供图形界面的客户端，提升了易用性，更多用户加入进来。 27 | 28 | 2016 年 6 月，DAO 基于以太坊平台进行众筹，受到漏洞攻击，造成价值超过 5000 万美金的以太币被冻结。社区最后通过硬分叉（Hard Fork）进行解决。 29 | 30 | 2017 年 3 月，以太坊成立以太坊企业级联盟（Enterprise Ethereum Alliance，EEA），联盟成员主要来自摩根大通，微软，芝加哥大学和部分创业企业等。 31 | 32 | 2017 年 11 月，再次暴露多签名钱包漏洞，造成价值 2.8 亿美元的以太币被冻结。 33 | 34 | 目前，以太坊网络支持了接近比特币网络的交易量，成为广受关注的公有链项目。 35 | 36 | 后续按照计划将发布第三阶段 Metropolis 和第四阶段 Serenity，主要特性包括支持 PoS 股权证明的共识机制，以降低原先 PoW 机制造成的能耗浪费；以及图形界面的钱包，以提升易用性。 37 | 38 | 包括 DAO 在内，以太坊网络已经经历了数次大的硬分叉，注意每次硬分叉后的版本对之前版本并不兼容。 39 | 40 | ### 主要特点 41 | 42 | 以太坊区块链底层也是一个类似比特币网络的 P2P 网络平台，智能合约运行在网络中的以太坊虚拟机里。网络自身是公开可接入的，任何人都可以接入并参与网络中数据的维护，提供运行以太坊虚拟机的资源。 43 | 44 | 跟比特币项目相比，以太坊区块链的技术特点主要包括： 45 | 46 | * 支持图灵完备的智能合约，设计了编程语言 Solidity 和虚拟机 EVM； 47 | * 选用了内存需求较高的哈希函数，避免出现强算力矿机、矿池攻击； 48 | * 叔块（Uncle Block）激励机制，降低矿池的优势，并减少区块产生间隔（10 分钟降低到 15 秒左右）； 49 | * 采用账户系统和世界状态，而不是 UTXO，容易支持更复杂的逻辑； 50 | * 通过 Gas 限制代码执行指令数，避免循环执行攻击； 51 | * 支持 PoW 共识算法，并计划支持效率更高的 PoS 算法。 52 | 53 | 此外，开发团队还计划通过分片（Sharding）方式来解决网络可扩展性问题。 54 | 55 | 这些技术特点，解决了比特币网络在运行中被人诟病的一些问题，让以太坊网络具备了更大的应用潜力。 56 | 57 | -------------------------------------------------------------------------------- /07_ethereum/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 以太坊项目将区块链技术在数字货币的基础上进行了延伸，提出打造更为通用的智能合约平台的宏大构想，并基于开源技术构建了以太坊为核心的开源生态系统。 4 | 5 | 本章内容介绍了以太坊的相关知识，包括核心概念、设计、工具，以及客户端的安装、智能合约的使用和编写等。 6 | 7 | 比照比特币项目，读者通过学习可以掌握以太坊的相关改进设计，并学习智能合约的编写。实际上，智能合约并不是一个新兴概念，但区块链技术的出现为智能合约的“代码即律法”提供提供了信任基础和实施架构。通过引入智能合约，区块链技术释放了支持更多应用领域的巨大潜力。 8 | -------------------------------------------------------------------------------- /07_ethereum/tools.md: -------------------------------------------------------------------------------- 1 | ## 相关工具 2 | 3 | ### 客户端和开发库 4 | 5 | 以太坊客户端可用于接入以太坊网络，进行账户管理、交易、挖矿、智能合约等各方面操作。 6 | 7 | 以太坊社区现在提供了多种语言实现的客户端和开发库，支持标准的 JSON-RPC 协议。用户可根据自己熟悉的开发语言进行选择。 8 | 9 | * [go-ethereum](https://github.com/ethereum/go-ethereum)：Go 语言实现； 10 | * [Parity](https://github.com/ethcore/parity)：Rust 语言实现； 11 | * [cpp-ethereum](https://github.com/bobsummerwill/cpp-ethereum)：C++ 语言实现； 12 | * [ethereumjs-lib](https://github.com/ethereumjs/ethereumjs-lib)：javascript 语言实现； 13 | * [Ethereum(J)](https://github.com/ethereum/ethereumj)：Java 语言实现； 14 | * [ethereumH](https://github.com/blockapps/ethereumH)：Haskell 语言实现； 15 | * [pyethapp](https://github.com/ethereum/pyethapp)：Python 语言实现； 16 | * [ruby-ethereum](https://github.com/janx/ruby-ethereum)：Ruby 语言实现。 17 | 18 | #### Geth 19 | 20 | 上述实现中，go-ethereum 的独立客户端 Geth 是最常用的以太坊客户端之一。 21 | 22 | 用户可通过安装 Geth 来接入以太坊网络并成为一个完整节点。Geth 也可作为一个 HTTP-RPC 服务器，对外暴露 JSON-RPC 接口，供用户与以太坊网络交互。 23 | 24 | Geth 的使用需要基本的命令行基础，其功能相对完整，源码托管于 github.com/ethereum/go-ethereum。 25 | 26 | ### 以太坊钱包 27 | 28 | 对于只需进行账户管理、以太坊转账、DApp 使用等基本操作的用户，则可选择直观易用的钱包客户端。 29 | 30 | Mist 是官方提供的一套包含图形界面的钱包客户端，除了可用于进行交易，也支持直接编写和部署智能合约。 31 | 32 | 注意： Mist 钱包于 2019 年被废弃。用户建议切换到像 MetaMask 或 Trust Wallet 这样的持续维护的钱包。 33 | 34 | ![Mist 浏览器](_images/mist.png) 35 | 36 | 所编写的代码编译发布后，可以部署到区块链上。使用者可通过发送调用相应合约方法的交易，来执行智能合约。 37 | 38 | ### IDE 39 | 40 | 对于开发者，以太坊社区涌现出许多服务于编写智能合约和 DApp 的 IDE，例如： 41 | 42 | * [Truffle](http://truffleframework.com/)：一个功能丰富的以太坊应用开发环境。 43 | * [Embark](https://github.com/iurimatias/embark-framework)：一个 DApp 开发框架，支持集成以太坊、IPFS 等。 44 | * [Remix](http://remix.ethereum.org)：一个用于编写 Solidity 的 IDE，内置调试器和测试环境。 45 | 46 | ### 网站资源 47 | 48 | 已有一些网站提供对以太坊网络的数据、运行在以太坊上的 DApp 等信息进行查看，例如： 49 | 50 | * ethstats.net：实时查看网络的信息，如区块、价格、交易数等。 51 | * ethernodes.org：显示整个网络的历史统计信息，如客户端的分布情况等。 52 | * dapps.ethercasts.com：查看运行在以太坊上的 DApp 的信息，包括简介、所处阶段和状态等。 53 | 54 | ![以太坊网络上的 Dapp 信息](_images/dapps.png) 55 | -------------------------------------------------------------------------------- /08_hyperledger/README.md: -------------------------------------------------------------------------------- 1 | # 超级账本 —— 面向企业的分布式账本 2 | 3 | **欲戴王冠，必承其重（Uneasy lies the head that wears a crown）。** 4 | 5 | 超级账本（Hyperledger）项目是全球最大的开源企业级分布式账本平台。 6 | 7 | 在 Linux 基金会的支持下，超级账本项目吸引了包括 IBM、Intel、Cisco、DAH、摩根大通、R3、甲骨文、百度、腾讯等在内的众多科技和金融巨头的参与贡献，以及在银行、供应链等领域的应用实践。成立两年多时间以来，超级账本得到了广泛的关注和飞速发展，目前囊括十大顶级项目，拥有近三百家企业会员。超级账本的开源代码和技术，也成为分布式账本领域的首选。 8 | 9 | 本章将介绍超级账本项目的发展历史和社区组织，以及旗下的多个顶级开源项目的情况，还将展示开源社区提供的多个高效开发工具。最后介绍如何参与到超级账本项目中，进行代码贡献。 10 | 11 | -------------------------------------------------------------------------------- /08_hyperledger/_images/aries.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/aries.png -------------------------------------------------------------------------------- /08_hyperledger/_images/avalon.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/avalon.png -------------------------------------------------------------------------------- /08_hyperledger/_images/besu.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/besu.png -------------------------------------------------------------------------------- /08_hyperledger/_images/burrow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/burrow.png -------------------------------------------------------------------------------- /08_hyperledger/_images/caliper.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/caliper.png -------------------------------------------------------------------------------- /08_hyperledger/_images/cello.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/cello.png -------------------------------------------------------------------------------- /08_hyperledger/_images/community_growth.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/community_growth.png -------------------------------------------------------------------------------- /08_hyperledger/_images/composer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/composer.png -------------------------------------------------------------------------------- /08_hyperledger/_images/explorer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/explorer.png -------------------------------------------------------------------------------- /08_hyperledger/_images/fabric.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/fabric.png -------------------------------------------------------------------------------- /08_hyperledger/_images/github.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/github.png -------------------------------------------------------------------------------- /08_hyperledger/_images/grid.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/grid.png -------------------------------------------------------------------------------- /08_hyperledger/_images/hyperledger.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/hyperledger.png -------------------------------------------------------------------------------- /08_hyperledger/_images/hyperledger_logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/hyperledger_logo.png -------------------------------------------------------------------------------- /08_hyperledger/_images/indy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/indy.png -------------------------------------------------------------------------------- /08_hyperledger/_images/iroha.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/iroha.png -------------------------------------------------------------------------------- /08_hyperledger/_images/jira.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/jira.png -------------------------------------------------------------------------------- /08_hyperledger/_images/network_topo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/network_topo.png -------------------------------------------------------------------------------- /08_hyperledger/_images/orgnization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/orgnization.png -------------------------------------------------------------------------------- /08_hyperledger/_images/patchset-lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/patchset-lifecycle.png -------------------------------------------------------------------------------- /08_hyperledger/_images/quilt.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/quilt.png -------------------------------------------------------------------------------- /08_hyperledger/_images/rocket_chat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/rocket_chat.png -------------------------------------------------------------------------------- /08_hyperledger/_images/sawtooth.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/sawtooth.png -------------------------------------------------------------------------------- /08_hyperledger/_images/top_projects.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/top_projects.png -------------------------------------------------------------------------------- /08_hyperledger/_images/transact.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/transact.png -------------------------------------------------------------------------------- /08_hyperledger/_images/ursa.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/08_hyperledger/_images/ursa.png -------------------------------------------------------------------------------- /08_hyperledger/community.md: -------------------------------------------------------------------------------- 1 | ## 社区组织结构 2 | 3 | 每个成功的开源项目都离不开一个健康开发、不断繁荣的社区生态。 4 | 5 | 超级账本社区自成立之日起就借鉴了众多开源社区组织的经验，形成了技术开发为主体、积极结合应用的体系结构。 6 | 7 | 超级账本社区的项目开发工作由技术委员会（Technical Steering Committee，TSC）指导，首任主席Chris Ferris 来自 IBM ，是 IBM 开源技术部门的 CTO ；管理委员会主席则由来自 Digital Asset Holdings 的 CEO Blythe Masters 担任。另外，自 2016 年 5 月起，Apache 基金会创始人 Brian Behlendorf 担任超级账本项目的执行总监（Executive Director）。 8 | 9 | 社区十分重视大中华地区的应用落地和开发情况，2016 年 12 月，[中国技术工作组](ttps://wiki.hyperledger.org/display/TWGC) 正式成立，负责推动社区组织建设和开源技术的发展和应用。 10 | 11 | ### 基本结构 12 | 13 | ![Hyperledger 社区组织结构](_images/orgnization.png) 14 | 15 | 社区目前主要是三驾马车领导的结构： 16 | 17 | * Technical Steering Committee（技术委员会）：负责领导社区技术，指导各个开源项目的发展方向，下设多个技术工作组（如 Architecture、Identity、Learning Materials Development、Performance and Scale、Smart Contracts）和兴趣小组（如 Healthcare、Public Sector、Social Impact、Telecom、Trade Finance）。每年由社区开发者进行换届选举； 18 | * Governing Board（管理董事会）：负责整体社区的组织决策，从超级账本会员中推选出代表座位成员； 19 | * Linux Foundation（Linux 基金会）：负责基金管理和大型活动组织，协助社区在 Linux 基金会的支持下健康发展。 20 | 21 | ### 大中华区技术工作组 22 | 23 | 随着开源精神和开源文化在中国的普及，越来越多的企业和组织开始意识到共建一个健康生态系统的重要性，也愿意为开源事业做出一定贡献。 24 | 25 | Linux 基金会和超级账本社区十分重视项目在大中华区的应用和落地情况，并希望能为开发者们贡献开源社区提供便利。在此背景下，超级账本首任执行董事 Brian Behlendorf 于 2016 年 12 月 1 日 [提议](https://lists.hyperledger.org/pipermail/hyperledger-tsc/2016-December/000504.html) 成立 [大中华区技术工作组（TWG-China）](https://wiki.hyperledger.org/groups/tsc/technical-working-group-china)，并得到了 TSC 成员们的一致支持和通过。笔者也有幸参与了工作组的创建，并担任首届联席主席。 26 | 27 | 技术工作组的 [主要职责](https://docs.google.com/document/d/1sXVltDZxnlB5Srd1A-EW0jtTz7P2cDLG8JmgaAYvMzU) 包括： 28 | 29 | * 带领和引导大中华区的技术开发相关活动，包括贡献代码、文档、项目提案等。 30 | * 推动技术相关的交流，促进会员企业之间的合作和实践案例的落地； 31 | * 通过邮件列表、RocketChat、论坛等方式促进社区开发者们的技术交流； 32 | * 协助举办社区活动，包括 Meetup、黑客松、Hackfest、技术分享、培训等。 33 | 34 | 目前，工作组由来自各个成员企业的数十名技术专家组成，并得到了来自社区的众多志愿者的支持。工作组每两周举行在线例会，每个月定期在各大城市举办技术交流沙龙，各项会议和活动内容都是开放的，可以在 Wiki 首页（https://wiki.hyperledger.org/display/TWGC）上找到相关参与方式。 35 | -------------------------------------------------------------------------------- /08_hyperledger/intro.md: -------------------------------------------------------------------------------- 1 | ## 超级账本项目简介 2 | 3 | ![超级账本项目](_images/hyperledger_logo.png) 4 | 5 | 2015 年 12 月，开源世界的旗舰组织 —— [Linux 基金会](http://www.linuxfoundation.org) 牵头，联合 30 家初始企业成员（包括 IBM、Accenture、Intel、J.P.Morgan、R3、DAH、DTCC、FUJITSU、HITACHI、SWIFT、Cisco 等），共同 [宣布](https://www.hyperledger.org/news/announcement/2016/02/hyperledger-project-announces-30-founding-members) 超级账本（Hyperledger）联合项目成立。超级账本项目致力为透明、公开、去中心化的企业级分布式账本技术提供开源参考实现，并推动区块链和分布式账本相关协议、规范和标准的发展。项目官方网站为 [hyperledger.org](https://www.hyperledger.org)。 6 | 7 | 成立之初，项目就收到了众多开源技术贡献。IBM 贡献了 4 万多行已有的 [Open Blockchain](https://github.com/openblockchain) 代码，Digital Asset 贡献了企业和开发者相关资源，R3 贡献了新的金融交易架构，Intel 贡献了分布式账本相关的代码。 8 | 9 | 作为一个联合项目（Collaborative Project），超级账本由面向不同目的和场景的子项目构成。目前包括 Fabric、SawToothLake、Iroha、Blockchain Explorer、Cello、Indy、Composer、Burrow、Quilt、Caliper、Ursa、Grid、Transact、Aries、Besu、Avalon 等顶级项目，所有项目都遵守 Apache v2 许可，并约定共同遵守如下的 [基本原则](https://github.com/hyperledger/hyperledger)： 10 | 11 | * 重视模块化设计：包括交易、合同、一致性、身份、存储等技术场景； 12 | * 重视代码可读性：保障新功能和模块都可以很容易添加和扩展； 13 | * 可持续的演化路线：随着需求的深入和更多的应用场景，不断增加和演化新的项目。 14 | 15 | 超级账本项目的企业会员和技术项目发展都十分迅速，如下图所示。 16 | 17 | ![Hyperledger 项目快速成长](_images/community_growth.png) 18 | 19 | 社区目前拥有近 300 家全球知名企业和机构（大部分均为各自行业的领导者）会员，其中包括 60 多家来自中国本土的企业，早期包括艾亿数融科技公司（[2016.05.19](https://www.hyperledger.org/news/announcement/2016/05/hyperledger-project-announces-addition-eight-new-members)）、Onchain（[2016.06.22](https://www.hyperledger.org/news/announcement/2016/06/hyperledger-projects-maintains-strong-momentum-new-members)）、比邻共赢（Belink）信息技术有限公司（2016.06.22）、BitSE（2016.06.22）等，另外还包括华为（[2016.10.24](https://www.hyperledger.org/announcements/2016/10/24/hyperledger-reaches-95-members-ahead-of-money2020)）、百度（2017.10.17）、腾讯（2018.01.25）等行业领军企业。此外，还有大量机构和高校成为超级账本联合会员，如英格兰银行、MIT 连接科学研究院、UCLA 区块链实验室、伊利诺伊区块链联盟、北京大学、浙江大学等。 20 | 21 | 如果说比特币为代表的加密货币提供了区块链技术应用的原型，以太坊为代表的智能合约平台延伸了区块链技术的适用场景，那么面向企业场景的超级账本项目则开拓了区块链技术的全新阶段。超级账本首次将区块链技术引入到了联盟账本的应用场景，引入权限控制和安全保障，这就为基于区块链技术的未来全球商业网络打下了坚实的基础。 22 | 23 | 超级账本项目的出现，实际上证实区块链技术已经不局限在单一应用场景中，也不限于完全开放匿名的公有链模式下，而是有更多的可能性，也说明区块链技术已经被主流企业市场正式认可和实践。同时，超级账本项目中提出和实现了许多创新的设计和理念，包括权限和审查管理、多通道、细粒度隐私保护、背书-共识-提交模型，以及可拔插、可扩展的实现框架，对于区块链相关技术和产业的发展都将产生十分深远的影响。 24 | 25 | *注：Apache v2 许可协议是商业友好的知名开源协议，鼓励代码共享，尊重原作者的著作权，允许对代码进行修改和再发布（作为开源或商业软件）。因其便于商业公司使用而得到业界的拥护。* 26 | 27 | -------------------------------------------------------------------------------- /08_hyperledger/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 超级账本项目是 Linux 基金会重点支持的面向企业的分布式账本平台。它同时也是开源界和工业界颇有历史意义的合作成果，将为分布式账本技术提供了在代码实现、协议和规范标准上的技术参考。 3 | 4 | 成立两年多时间以来，超级账本社区已经吸引了国内外各行业的大量关注，并获得了飞速发展。社区的开源项目、工作组和会员企业，共同构造了完善的企业级区块链生态。同时，超级账本项目中提出的许多创新技术和设计，也得到了来自业界和开源界的认可。 5 | 6 | 超级账本社区也十分重视应用落地。目前基于超级账本相关技术，已经出现了大量的企业应用案例，这为更多企业使用区块链技术提供了很好的应用参考。 7 | -------------------------------------------------------------------------------- /08_hyperledger/tools.md: -------------------------------------------------------------------------------- 1 | ## 开发必备工具 2 | 3 | 工欲善其事，必先利其器。开源社区提供了大量易用的开发协作工具。掌握好这些工具，对于高效的开发来说十分重要。 4 | 5 | ### Linux Foundation ID 6 | 7 | 超级账本项目受到 Linux 基金会的支持，采用 Linux Foundation ID（LF ID）作为社区唯一的 ID。 8 | 9 | 个人申请 ID 是完全免费的。可以到 https://identity.linuxfoundation.org/ 进行注册。 10 | 11 | 用户使用该 ID 即可访问到包括 Jira、RocketChat 等社区的开发工具。 12 | 13 | ### Jira - 任务和进度管理 14 | 15 | ![Jira 任务管理](_images/jira.png) 16 | 17 | Jira 是 Atlassian 公司开发的一套任务管理和事项跟踪的追踪平台，提供 Web 操作界面，使用十分方面。 18 | 19 | 社区采用 jira.hyperledger.org 作为所有项目开发计划和任务追踪的入口，使用 LF ID 即可登录。 20 | 21 | 登录之后，可以通过最上面的 Project 菜单来查看某个项目相关的事项，还可以通过 Create 按钮来快速创建事项（常见的包括 task、bug、improvement 等）。 22 | 23 | 用户打开事项后可以通过 assign 按钮分配给自己来领取该事项。 24 | 25 | 一般情况下，事项分为 TODO（待处理）、In Process（处理中）、In Review（补丁已提交、待审查）、Done（事项已完成）等多个状态，由事项所有者来进行维护。 26 | 27 | ### Github - 代码仓库和 Review 管理 28 | 29 | ![Github 代码仓库管理](_images/github.png) 30 | 31 | Github 是全球最大的开源代码管理仓库服务，微软公司于 2018 年 7 月以 75 亿美金价格纳入旗下。 32 | 33 | 超级账本社区目前所有项目都通过 Github 进行管理。早期 Fabric、Cello、Explorer 等项目采用了自建的 Gerrit 服务作为官方的代码仓库，2019 年下半年也都陆续迁移到了 Github 服务器上。 34 | 35 | 用户使用自己的账号登录之后，可以查看所有项目信息，也可以查看自己提交的补丁等信息。每个补丁的页面上会自动追踪修改历史，审阅人可以通过页面进行审阅操作，赞同提交则可以批准，发现问题则可以进行批注。 36 | 37 | ### RocketChat - 在线沟通 38 | 39 | ![RocketChat 在线沟通](_images/rocket_chat.png) 40 | 41 | 除了邮件列表外，社区也为开发者们提供了在线沟通的渠道—— RocketChat。 42 | 43 | RocketChat 是一款功能十分强大的在线沟通软件，支持多媒体消息、附件、提醒、搜索等功能，虽然是开源软件，但在体验上可以跟商业软件 Slack 媲美。支持包括网页、桌面端、移动端等多种客户端。 44 | 45 | 社区采用 chat.hyperledger.org 作为服务器。最简单的，用户直接使用自己的 LF ID 登录该网站，即可访问。之后可以自行添加感兴趣项目的频道。 46 | 47 | 用户也可以下载 RocketChat 客户端，添加 chat.hyperledger.org 作为服务器即可访问社区内的频道，跟广大开发者进行在线交流。 48 | 49 | 通常，每个项目都有一个同名的频道作为主频道，例如 `#Fabric`，`#Cello` 等。同时，各个工作组也往往有自己的频道，例如大中华区技术工作组的频道为 `#twg-china`。 50 | 51 | ### 邮件列表 - 常见渠道 52 | 53 | 各个项目和工作组都建立了专门的邮件列表，作为常见的交流渠道。当发现问题不知道往哪里报告时，可以先发到邮件列表进行询问，一般都能获得及时的回答。 54 | 55 | 例如，大中华区技术工作组的频道为 `twg-china@lists.hyperledger.org`。 56 | 57 | 用户在 https://lists.hyperledger.org/g/main/subgroups 看到社区已有的邮件列表并选择加入。 58 | 59 | ### 提问的智慧 60 | 61 | 为什么我在社区提出的问题会过了很长时间也无人回应？ 62 | 63 | 开源社区是松散自组织形式，大部分开发者都是利用业余时间进行开发和参与社区工作。因此，在社区提出问题时就必须要注意问题的质量和提问的方式。碰到上述情况，首先要先从自身找原因。 64 | 65 | 如果能做到下面几点，会使你提出的问题得到更多的关注： 66 | 67 | * 正确的渠道：这点十分重要。不同项目和领域有各自的渠道，一定要在相关的渠道进行提问，而不要问跟列表主题不相关的话题，例如，每个项目相关问题应该发送到对应的邮件列表。 68 | * 问题的新颖性：在提问之前，应该利用包括搜索引擎、技术文档、邮件列表等常见方式进行查询，确保提出的问题是新颖的，有价值的，而不是已经被回答过多遍的常识性问题。 69 | * 适当的上下文：不少提问者的问题中只包括一条很简单的错误信息，这样会让社区的开发者有心帮忙也无力回答。良好的上下文包括完整的环境信息、所使用的软件版本、所进行操作的详细步骤、问题相关的日志、自己对问题的思考等。这些都可以帮助他人快速重现问题并帮忙回答。 70 | * 注意礼仪：虽然技术社区里大家沟通方式会更为直接一些，但懂得礼仪毫无疑问是会受到欢迎的。要牢记，别人的帮助并非是义务的，要对任何来自他人的帮助心存感恩。 71 | -------------------------------------------------------------------------------- /09_fabric_deploy/README.md: -------------------------------------------------------------------------------- 1 | # Fabric 安装与部署 2 | 3 | **纸上得来终觉浅，绝知此事要躬行。** 4 | 5 | 作为被广泛应用的联盟链项目，Fabric 吸取了来自科技界和金融界的最新成果，提供面向企业场景的开放分布式账本平台实现。 6 | 7 | 本章将带领读者动手实践，学习如何从源码进行编译、安装 Fabric ，如何使用官方容器镜像，以及在多服务器环境下部署一个典型的 Fabric 网络，同时，还将介绍通道的相关实践操作。 8 | -------------------------------------------------------------------------------- /09_fabric_deploy/_images/docker_images.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/09_fabric_deploy/_images/docker_images.png -------------------------------------------------------------------------------- /09_fabric_deploy/_images/network_bootup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/09_fabric_deploy/_images/network_bootup.png -------------------------------------------------------------------------------- /09_fabric_deploy/_images/network_topology.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/09_fabric_deploy/_images/network_topology.png -------------------------------------------------------------------------------- /09_fabric_deploy/intro.md: -------------------------------------------------------------------------------- 1 | ## 简介 2 | 3 | Fabric 是超级账本社区首个项目也是最流行的分布式账本实现，由 IBM、DAH 等会员企业于 2015 年底贡献到社区。 4 | 5 | 作为面向企业场景的联盟链，Fabric 中有许多经典的设计和先进的理念。包括多通道、身份证书机制、隐私保护、运维管理接口等。另外，其可扩展的架构可以满足不同场景下的性能需求，如虚拟机部署场景下可以达到 3500 tps 的吞吐量和小于 1 秒的延迟（参考《Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains》），更多物理资源情况下可以达到更大的（10 K+）的吞吐量。 6 | 7 | ### 主要版本历史 8 | 9 | Fabric 首个主版本 1.0.0 于 2017 年 7 月发布，该版本根据之前测试版的应用反馈，在架构上进行了重新设计，在可扩展性和可插拔性方面都有了不少改进。后续版本基本上按照每季度一个小版本的节奏发布。重点对性能和安全性、隐私性进行了完善和提升。目前最新大版本为 2.0.0 版本。Fabric 的主要版本历史总结如下表所示，也可在 https://github.com/hyperledger/fabric/releases 找到。 10 | 11 | 版本 | 发布时间 | 新特性 | 增强和改善 12 | --- | ------- | ---- | ---- 13 | 1.0.0 | 2017-07-11 | 重新设计架构，支持多通道、Kafka 共识机制、系统链码、分角色节点 | 大幅度提升性能和可扩展性 14 | 1.1.0 | 2018-03-15 | Node.Js 链码，链码加密库，链码中基于证书属性的访问控制，节点之间的双向 TLS，Fabric CA 中对 CRL 的支持。部分实验特性，如 sideDB、idemix、细粒度的权限控制。| 大幅优化了性能，某些场景下可提升一个数量级；提供基于通道的事件通知模型 15 | 1.2.0 | 2018-07-04 | 正式支持私有数据库（Private Data），提供可插拔的 ESCC 和 VSCC，细粒度访问控制，服务自动发现 | 提高了稳定性和易用性 16 | 1.3.0 | 2018-10-11 | 正式支持 Java 链码；提供细粒度的基于状态的背书策略；支持 idemix 增强隐私保护| 部分重构链码生命周期管理；通过分页机制优化链码中对大量数据的查询 17 | 1.4.0 | 2019-01-09 | 提供运维相关的 RESTful API（统计、健康检查、日志级别）；使用新的日志控制环境变量 | 增强私有数据：新 Peer 自动获取缺失私有数据，客户端层面对私有数据的权限控制；开始支持新的 RAFT 排序机制 18 | 2.0.0 | 2020-03-TBD | 新的面向通道的链码生命周期管理；独立 shim 库等 | 增强私有数据支持；增强排序服务；改进性能 19 | 20 | ### 网络基本结构 21 | 22 | Fabric 网络中存在四种不同种类的服务节点，彼此协作完成整个区块链系统的记账功能： 23 | 24 | * 背书节点（Endorser Peer）：一类特殊的 Peer，对交易提案（Transaction Proposal）进行检查，通过执行智能合约计算交易执行结果（读写集合）并对其进行背书； 25 | * 记账节点（Committer Peer）：负责维护账本，检查排序后交易结果合法性，接受合法修改，并写入到本地账本结构，目前所有 Peer 默认都是记账节点； 26 | * 排序节点（Orderer）：正式交易会发给排序节点，排序节点负责对网络中所有交易进行排序处理，并整理为区块结构，之后被记账节点拉取提交到本地账本； 27 | * 证书节点（CA）：提供标准的 PKI 服务，负责对网络中所有的证书进行管理，包括签发和撤销。 28 | 29 | 节点角色是 Fabric 设计中的一大创新。根据性能和安全需求，不同的节点可以由组织分别管理，共同构建联盟链。 30 | 31 | 此外，网络账本的基本单位是通道（Channel），每个通道内的成员可以共享账本，不同通道内账本则彼此隔离。客户端可以向网络内发送交易，交易经过共识后被通道内的 Peer 节点接收并更新本地对应的账本。 32 | 33 | 本章后续将详细介绍安装、部署 Fabric 网络并进行启动的操作过程，建议读者跟随步骤进行实践学习。 34 | -------------------------------------------------------------------------------- /09_fabric_deploy/start_docker.md: -------------------------------------------------------------------------------- 1 | ## 容器方式启动 Fabric 网络 2 | 3 | 除了上面讲解的手动部署的方式，读者还可以基于容器方式来快速部署 Fabric 网络并验证功能。 4 | 5 | 首先，按照如下命令下载 Docker-Compose 模板文件，并进入 `hyperledger_fabric` 目录，可以看到有对应多个 Fabric 版本的项目，用户可以根据需求选用特定版本： 6 | 7 | ```sh 8 | $ git clone https://github.com/yeasy/docker-compose-files 9 | $ cd docker-compose-files/hyperledger_fabric 10 | ``` 11 | 12 | 以 Fabric 2.0.0 版本为例，进入到对应目录下，并先下载所需镜像文件： 13 | 14 | ```bash 15 | $ cd v2.0.0 16 | $ make download 17 | ``` 18 | 19 | 查看目录下内容，主要包括若干 Docker-Compose 模板文件，主要包括： 20 | 21 | * docker-compose-2orgs-4peer-raft.yaml：包括 4 个 peer 节点（属于两个组织）、3 个 Orderer 节点（Raft 模式）、2 个 CA 节点、1 个客户端节点； 22 | * docker-compose-1orgs-1peers-dev.yaml：包括 1 个 peer 节点、1 个 Orderer 节点、1 个 CA 节点、1 个客户端节点。本地 Fabric 源码被挂载到了客户端节点中，方便进行调试； 23 | * docker-compose-2orgs-4peer-kafka.yaml：包括 4 个 peer 节点（属于两个组织）、3 个 Orderer 节点（Kafka 模式）、2 个 CA 节点、1 个客户端节点； 24 | * docker-compose-2orgs-4peer-couchdb.yaml：包括 4 个 peer 节点（属于两个组织，启用 couchDB 作为状态数据库）、2 个 Orderer 节点、1 个 CA 节点、1 个客户端节点。 25 | 26 | 使用 Make 命令进行操作。例如使用 HLF_MODE 指定排序服务为 Raft 模式，快速启动网络并执行一系列测试： 27 | 28 | ```bash 29 | $ HLF_MODE=raft make test 30 | ``` 31 | 32 | `make test` 实际上自动执行了一系列指令： 33 | 34 | * make gen_config_crypto：生成网络需要的身份文件； 35 | * make gen_config_channel：生成网络需要的配置文件； 36 | * make start：启动网络； 37 | * make channel_test：执行通道创建和加入通道； 38 | * make update_anchors：更新锚节点信息； 39 | * make cc_test：执行链码相关测试，包括安装、实例化和调用； 40 | * make test_lscc：测试系统链码 LSCC 调用（使用 2.0 中新的链码生命周期则不支持）； 41 | * make test_qscc：测试系统链码 QSCC 调用； 42 | * make test_cscc：测试系统链码 CSCC 调用； 43 | * make test_fetch_blocks：获取通道内的区块； 44 | * make test_config_update：生成新版本配置； 45 | * make test_channel_update：测试更新通道配置； 46 | * make test_configtxlator：测试 configtxlator 转换； 47 | * make test_channel_list：测试列出 Peer 加入的通道； 48 | * make test_channel_getinfo：测试获取通道信息； 49 | * make stop：停止网络。 50 | 51 | 运行过程中会自动创建网络并逐个完成通道和链码的相关测试，注意查看输出日志中无错误信息。 52 | 53 | 网络启动后，可以通过 `docker ps` 命令查看本地系统中运行的容器信息： 54 | 55 | ```bash 56 | $ docker ps 57 | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 58 | 1ee7db027b3f yeasy/hyperledger-fabric-peer:2.0.0 "peer node start" 27 seconds ago Up 22 seconds 9443/tcp, 0.0.0.0:8051->7051/tcp peer1.org1.example.com 59 | 8f7bffcd14b3 yeasy/hyperledger-fabric-peer:2.0.0 "peer node start" 27 seconds ago Up 22 seconds 9443/tcp, 0.0.0.0:10051->7051/tcp peer1.org2.example.com 60 | 8a4e9aaec7ba yeasy/hyperledger-fabric-peer:2.0.0 "peer node start" 27 seconds ago Up 22 seconds 9443/tcp, 0.0.0.0:9051->7051/tcp peer0.org2.example.com 61 | 7b9d394f26c0 yeasy/hyperledger-fabric-peer:2.0.0 "peer node start" 27 seconds ago Up 23 seconds 0.0.0.0:7051->7051/tcp, 9443/tcp peer0.org1.example.com 62 | ce9ca6c7b672 yeasy/hyperledger-fabric-orderer:2.0.0 "orderer start" 30 seconds ago Up 27 seconds 8443/tcp, 0.0.0.0:8050->7050/tcp orderer1.example.com 63 | 2646b7f0e462 yeasy/hyperledger-fabric:2.0.0 "bash -c 'cd /tmp; s…" 30 seconds ago Up 15 seconds 7050-7054/tcp fabric-cli 64 | c35e8694c634 yeasy/hyperledger-fabric-orderer:2.0.0 "orderer start" 30 seconds ago Up 27 seconds 8443/tcp, 0.0.0.0:9050->7050/tcp orderer2.example.com 65 | 1d6dd5009141 yeasy/hyperledger-fabric-orderer:2.0.0 "orderer start" 30 seconds ago Up 27 seconds 0.0.0.0:7050->7050/tcp, 8443/tcp orderer0.example.com 66 | ``` 67 | 68 | 用户如果希望在客户端、Peer 或 Orderer 容器内执行命令，可以通过 `make cli|peer|orderer` 命令进入到容器中。 69 | 70 | 例如，如下命令可以让用户登录到客户端节点，在其中以指定身份发送网络请求： 71 | 72 | ```bash 73 | $ make cli 74 | ``` 75 | 76 | 用户也可以通过如下命令来查看日志输出： 77 | 78 | ```bash 79 | $ make logs 80 | ``` 81 | 82 | 更多操作命令用户可以参考 Makefile 内容，在此不再赘述。 83 | 84 | -------------------------------------------------------------------------------- /09_fabric_deploy/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 本章详细讲解了 Fabric 网络生成和启动的主要步骤，包括如何本地编译、安装并进行各种组件的配置，以及如何启动 Fabric 网络。同时，还介绍了如何对通道进行操作并让 Peer 加入到通道。生产环境中推荐通过容器方式来启动和管理网络。 4 | 5 | 通过本章内容的学习和实践，相信读者可以掌握部署 Fabric 网络的步骤，同时也对 Fabric 网络的主要功能特别是通道有了初步了解。后续章节将介绍更多的网络操作，包括智能合约和网络管理等。 6 | -------------------------------------------------------------------------------- /10_fabric_op/README.md: -------------------------------------------------------------------------------- 1 | # 操作 Fabric 网络 2 | 3 | **万事万物皆系统。可观，然后可以控。** 4 | 5 | 本章将讲解使用和管理 Fabric 网络的常见操作，包括管理通道、链码等资源，利用事件监听和网络发现来提高使用效率等，还介绍了 SDK 项目，运维和升级网络的操作。最后，本章探讨了生产环境部署管理的注意事项。 6 | -------------------------------------------------------------------------------- /10_fabric_op/_images/ChaincodeInvocationSpec.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/ChaincodeInvocationSpec.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_install_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_install_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_install_structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_install_structure.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_instantiate_Envelope.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_instantiate_Envelope.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_instantiate_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_instantiate_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_instantiate_signedproposal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_instantiate_signedproposal.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_invoke_Envelope.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_invoke_Envelope.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_invoke_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_invoke_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_invoke_signedproposal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_invoke_signedproposal.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_lifecycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_lifecycle.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_list_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_list_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_package_Envelope.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_package_Envelope.png -------------------------------------------------------------------------------- /10_fabric_op/_images/chaincode_upgrade_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/chaincode_upgrade_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_create_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_create_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_create_tx.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_create_tx.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_fetch_envelope.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_fetch_envelope.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_fetch_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_fetch_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_getinfo_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_getinfo_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_getinfo_signed_proposal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_getinfo_signed_proposal.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_join_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_join_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_join_signed_proposal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_join_signed_proposal.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_list_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_list_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_list_signed_proposal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_list_signed_proposal.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_update_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_update_flow.png -------------------------------------------------------------------------------- /10_fabric_op/_images/channel_update_tx.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/channel_update_tx.png -------------------------------------------------------------------------------- /10_fabric_op/_images/prometheus.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/10_fabric_op/_images/prometheus.png -------------------------------------------------------------------------------- /10_fabric_op/best_practice.md: -------------------------------------------------------------------------------- 1 | ## 注意事项与最佳实践 2 | 3 | 区块链分布式结构的特点，使得其在管理上相对单点系统要复杂的多，需要从多个角度进行仔细考量和论证。这里总结一些在生产环境中使用 Fabric 网络需要注意的地方和最佳实践技巧。 4 | 5 | ### 节点角色差异 6 | 7 | Fabric 网络中各个节点可以拥有不同的角色。不同角色的众多节点负责整个网络功能中不同环节的工作负载，呈现出了差异化的处理特性。 8 | 9 | Ordering 服务需要排序整个网络中所有的交易消息，是全网的关键组件。Orderer 维护网络中所有通道的区块链结构，往往大量吞吐区块文件。因此，对于 Orderer 节点来讲需要加强网络（至少千兆网络）、存储和内存方面的配置，并且采用集群部署的方式提高其可靠性。 10 | 11 | Peer 节点除了处理区块和背书交易（Endorser）之外，还需要对账本状态进行更新（Committer），对身份进行验证。同时，对于每个通道来说，加入通道的节点都需要维护一个针对该通道的账本结构（存放在数据库中）和区块链结构（存放在文件系统）。因此，Peer 节点需要加强CPU、内存、存储等资源配置，Endorser 还可以在签名处理方面进行加权。对于打开文件句柄较多的节点（如配置使用 CouchDB 作为状态数据库时），可能还需要对系统的 ulimit 等参数进行调整。 12 | 13 | 而对于链码容器来说，自身不需要维护太多状态信息，但是需要执行计算操作，因此需要提高较好的计算能力支持。 14 | 15 | 一般来讲，链码容器常常跟 Peer 节点在同一服务器上，建议为 Peer 服务预留 2 GB 以上的空闲内存，4 CPU 以上资源，并且一般每个链码容器分配 256 MB 运行内存和 1/10 的 CPU 核资源（根据链码逻辑进行调整）。 16 | 17 | ### 日志级别 18 | 19 | 日志级别越低，输出日志内容越详细，出现问题后方便进行调试。但输出过多日志会拖慢系统的吞吐性能，严重时甚至能降低几个数量级。 20 | 21 | 因此，在生产环境中必须要仔细调整日志级别。对于关键路径上的系统，通常要配置不低于 Warning 级别的日志输出；对于非关键路径上的系统，则可以采用不低于 Info 级别的日志输出。 22 | 23 | Fabric 在日志级别上，支持对不同组件提供不同的级别。推荐将全局配置为 warning 级别，gRPC 组件由于需要处理大量交互消息，可以配置为更高的 error 级别。 24 | 25 | 如果要追踪区块链网络中的状态变化，可以通过事件监听等方式，降低对网络处理的压力。 26 | 27 | ### 链码升级 28 | 29 | Fabric 目前已经支持了链码升级特性，升级时会调用链码中的 Init 方法。通过合适地设计链码，对其进行升级操作可以保护旧版本链码所关联的状态数据不被破坏。 30 | 31 | 但是注意目前升级操作并不需要整个网络的共识，因此对部分节点上链码版本升级后，未被升级的节点上仍然会运行旧版本的链码。 32 | 33 | 从数据一致性上考虑，在对某链码代码进行升级前，推荐先将所有该链码的容器停止，并从 Peer 上备份并移除旧链码部署文件。之后先在个别 Peer 节点上部署新链码，对原有数据进行测试，成功后再在其它节点上进行升级操作。 34 | 35 | 另外，在一开始编写链码过程中，就需要考虑链码升级操作，通过传入 Init 参数指定特定的升级方法来保护原有数据。 36 | 37 | ### 组织结构 38 | 39 | 组织代表了维护网络的独立成员身份。一般来说，组成联盟链的各个成员，每个都拥有代表自己身份的组织。一个组织可以进一步包括多个资源实体，这些资源实体彼此具有较强的信任度，并且对外都呈现为同一组织身份。 40 | 41 | 由于 Gossip 协议目前在 MSP 范围内进行传播，因此，一般建议将组织与 MSP 一一对应，即每个组织拥有自己专属的 MSP。当一个组织拥有多个 MSP 时，不同成员之间的交互可能会带来障碍；当多个组织同属于一个 MSP 时，可能会发生不希望的跨组织的数据泄露。 42 | 43 | 另外，一个组织可以包括多个成员身份，多个 Peer 可以通过使用同一成员身份来提高高可用性。 44 | 45 | ### 证书管理 46 | 47 | Fabric 网络中，CA 负责证书的管理。用户虽然可以通过 cryptogen 工具提前分配好各组织的身份证书，但对于加入到网络中的用户，以及未来支持的交易证书，都需要 Fabric CA 来进行统一管理。 48 | 49 | Fabric CA 占据网络中安全和隐私的最核心位置，因此需要加强安全方面的防护。CA 不应该暴露在公共网络域中，并且只能由有限个具备权限的用户可以访问。 50 | 51 | 另外，根证书往往要进行离线保护处理，减少接触和泄露的可能性。通常使用中间层证书来完成实体证书的签发。同时，绝对不能直接用根证书作为组织管理员的身份证书。 52 | 53 | ### 账本备份和裁剪 54 | 55 | 目前，Fabric 自身并未考虑对账本结构的备份和裁剪操作。在生产环境中，需要用户自己进行处理。 56 | 57 | 一方面，推荐用户根据业务需求和吞吐量来估算所需磁盘的大小。一般的，在平均每秒百次 TPS、交易消息不太大情况下，每年大约产生 3 TB 左右数据。 58 | 59 | 账本文件一般位于默认的 /var/hyperledger/production 目录下，包括区块链结构（文件存储）和相关状态（数据库存储）。大部分操作只与数据库存储相关，因此，对于旧的区块链文件，可以考虑从本地移除，备份到容量更大的持久化存储中。当需要时，再从大容量存储中恢复到本地。 60 | 61 | ### 系统优化 62 | 63 | 区块链作为分布式系统，对系统的计算、网络、存储等资源都有所需求，优化的系统配置可以有效提高资源效率。 64 | 65 | 例如，可以调整系统缓存策略、允许打开的文件句柄数、调整 TCP 连接超时时间等网络参数等。如果使用容器，还可以调整容器的资源限额和访问权限等。 66 | 67 | 此外，对于第三方软件也应该根据对应文档进行调整和优化。例如使用 Kafka 共识机制，在 Kafka 2.0 版本默认保留日志时间为 7 天，应当调整为更长，但同时注意要预留足够的系统存储空间。 68 | 69 | -------------------------------------------------------------------------------- /10_fabric_op/events.md: -------------------------------------------------------------------------------- 1 | ## 监听网络事件 2 | 3 | 用户可能注意到，发往网络的请求是异步处理模式，这就意味着客户端无法获知提交的交易是否最终接受。Fabric 在 Peer 节点上提供了事件 gRPC 服务，用户可以通过客户端来监听。 4 | 5 | 下面通过 eventsclient 工具来监听网络中的事件。 6 | 7 | 首先通过如下命令安装 eventsclient 工具。 8 | 9 | ```bash 10 | $ cd $GOPATH/src/hyperledger/fabric/examples/events/eventsclient 11 | $ go install && go clean 12 | ``` 13 | 14 | 该工具自动封装对 Peer 事件的 gRPC 请求，支持的选项主要包括如下几个： 15 | 16 | * -server "localhost:7053"：监听服务地址，一般指定为 Peer 节点的 7053 端口； 17 | * -channelID string：监听指定通道信息，默认为 testchainid； 18 | * -seek int：指定从哪个区块开始监听。-2代表从初始区块（默认），-1代表从当前最新区块； 19 | * -filtered=true：只获取过滤的区块内容，不显示完整内容。 20 | * -quiet：不打印区块内容，只显示区块号； 21 | * -tls：是否启用 TLS，默认关闭； 22 | * -rootCert string：启用 TLS 时指定信任的根 CA 证书路径； 23 | * -mTls：是否开启双向验证（即服务端也同时验证客户端身份），默认关闭。 24 | * -clientCert string：：启用 TLS 时候客户端证书路径； 25 | * -clientKey string：启用 TLS 时候客户端私钥路径； 26 | 27 | 典型地，用户可以通过环境变量指定所需的参数值，使用如下命令启动监听。 28 | 29 | ```bash 30 | $ eventsclient \ 31 | -server=${PEER_URL} \ 32 | -channelID=${APP_CHANNEL} \ 33 | -filtered=true \ 34 | -tls=true \ 35 | -clientKey=${TLS_CLIENT_KEY} \ 36 | -clientCert=${TLS_CLIENT_CERT} \ 37 | -rootCert=${TLS_CA_CERT} 38 | ``` 39 | 40 | 启动后，该工具会持续监听来自指定通道的事件，并打印出来。 41 | 42 | 例如，监听 businesschannel 通道内区块信息，并对结果进行过滤输出，命令和结果如下所示。 43 | 44 | ```bash 45 | $ CORE_PEER_LOCALMSPID=Org1MSP \ 46 | CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp \ 47 | eventsclient \ 48 | -server=peer0.org1.example.com:7051 \ 49 | -channelID=businesschannel \ 50 | -filtered=true \ 51 | -tls=true \ 52 | -clientKey=/etc/hyperledger/fabric/crypto-config/peerOrganizations/org1.example.com/users/Admin@Org1.example.com/tls/client.key \ 53 | -clientCert=/etc/hyperledger/fabric/crypto-config/peerOrganizations/org1.example.com/users/Admin@Org1.example.com/tls/client.crt \ 54 | -rootCert=/etc/hyperledger/fabric/crypto-config/peerOrganizations/org1.example.com/users/Admin@Org1.example.com/tls/ca.crt 55 | 56 | UTC [eventsclient] readEventsStream -> INFO 001 Received filtered block: 57 | { 58 | "channel_id": "businesschannel", 59 | "filtered_transactions": [ 60 | { 61 | "tx_validation_code": "VALID", 62 | "txid": "", 63 | "type": "CONFIG" 64 | } 65 | ], 66 | "number": "0" 67 | } 68 | UTC [eventsclient] readEventsStream -> INFO 002 Received filtered block: 69 | { 70 | "channel_id": "businesschannel", 71 | "filtered_transactions": [ 72 | { 73 | "tx_validation_code": "VALID", 74 | "txid": "", 75 | "type": "CONFIG" 76 | } 77 | ], 78 | "number": "1" 79 | } 80 | UTC [eventsclient] readEventsStream -> INFO 003 Received filtered block: 81 | { 82 | "channel_id": "businesschannel", 83 | "filtered_transactions": [ 84 | { 85 | "tx_validation_code": "VALID", 86 | "txid": "", 87 | "type": "CONFIG" 88 | } 89 | ], 90 | "number": "2" 91 | } 92 | UTC [eventsclient] readEventsStream -> INFO 004 Received filtered block: 93 | { 94 | "channel_id": "businesschannel", 95 | "filtered_transactions": [ 96 | { 97 | "transaction_actions": { 98 | "chaincode_actions": [] 99 | }, 100 | "tx_validation_code": "VALID", 101 | "txid": "2832892094f612237b06950b77a6afc13ca9226176e99c2a8577cf4be2074c0a", 102 | "type": "ENDORSER_TRANSACTION" 103 | } 104 | ], 105 | "number": "3" 106 | } 107 | UTC [eventsclient] readEventsStream -> INFO 005 Received filtered block: 108 | { 109 | "channel_id": "businesschannel", 110 | "filtered_transactions": [ 111 | { 112 | "transaction_actions": { 113 | "chaincode_actions": [] 114 | }, 115 | "tx_validation_code": "VALID", 116 | "txid": "fec547335060bb324e8e4a08067c7fa24092e1295cb62dffb14a93bc77b2fbcf", 117 | "type": "ENDORSER_TRANSACTION" 118 | } 119 | ], 120 | "number": "4" 121 | } 122 | ... 123 | ``` 124 | 125 | -------------------------------------------------------------------------------- /10_fabric_op/intro.md: -------------------------------------------------------------------------------- 1 | ## 简介 2 | 3 | Fabric 网络中存在四种不同种类的服务节点，彼此协作完成整个区块链系统的记账功能。 4 | 5 | * 背书节点（Endorser Peer）：一类特殊的 Peer，负责对交易提案（Transaction Proposal）进行检查，计算交易执行结果（读写集合）并进行背书； 6 | * 记账节点（Committer Peer）：负责维护账本，检查排序后交易结果合法性，接受合法修改，并写入到本地账本结构。目前所有 Peer 默认都是记账节点； 7 | * 排序节点（Orderer）：正式交易会发给排序节点，排序节点负责对网络中所有交易进行排序处理，并整理为区块结构，之后被记账节点拉取提交到本地账本； 8 | * 证书节点（CA）：提供标准的 PKI 服务，负责对网络中所有的证书进行管理。 9 | 10 | 对网络中节点角色进行解耦是 Fabric 设计中的一大创新，这也是联盟链场景下的特殊需求和环境所决定的。 11 | 12 | 通道是 Fabric 网络的另一个重要特性，每个通道实际上都是独立的账本。系统通道（System Channel，只有一个）负责管理网络的各种配置（如排序服务、联盟信息）；应用通道（Application Channel，可以有任意多个，供用户发送交易使用）负责为不同成员之间的业务合作提供隔离支持。 13 | 14 | 网络启动后，对 Fabric 网络的管理主要包括两大类操作： 15 | 16 | * 通道操作：包括创建、加入通道、查询通道信息、更新通道配置等； 17 | * 链码操作：包括安装、实例化（部署）、调用链码等。 18 | 19 | 为了提高使用网络的效率，Fabric 还提供了时间通知机制和网络发现功能。后面讲具体进行介绍。 -------------------------------------------------------------------------------- /10_fabric_op/operation.md: -------------------------------------------------------------------------------- 1 | ## 使用运维服务 2 | 3 | Fabric 自 v1.4.0 版本开始，加强了对运维操作的支持，在 Peer 和 Orderer 上提供了一系列的 RESTful API 来协助监控服务状态。 4 | 5 | 这些 API 主要分为三大类： 6 | 7 | * 获取和配置日志级别，资源为 /logspec； 8 | * 监控系统组件的健康状态，资源为 /healthz； 9 | * 获取系统统计信息，支持外部 Prometheus 拉取，或推送给 StatsD。 10 | 11 | 它们可以通过 Peer 和 Orderer 配置文件中的 operations 字段进行开启和配置。Peer 默认监听端口为 9443，Orderer 默认监听端口为 8443。 12 | 13 | 下面分别进行讲解。 14 | 15 | ### 获取和配置日志级别 16 | 17 | 日志资源为 /logspec。 18 | 19 | 获取日志级别可以发送 GET 请求，返回 JSON 格式对象。例如获取当前日志级别，可以使用如下命令。 20 | 21 | ```bash 22 | $ curl http://orderer:8443/logspec 23 | {"spec":"info"} 24 | $ curl http://peer:9443/logspec 25 | {"spec":"info"} 26 | ``` 27 | 28 | 修改日志级别可以发送 PUT 请求，消息内容为字典结构：{"spec": "[[,...]=][:[[,...]=]...]"}，例如修改 Gossip 模块日志级别为 DEBUG，全局默认级别仍为 INFO。 29 | 30 | ```bash 31 | $ curl -XPUT \ 32 | -d '{"spec":"gossip=debug:info"}' \ 33 | http://peer:9443/logspec 34 | ``` 35 | 36 | ### 监控系统组件的健康状态 37 | 38 | 资源为 /healthz。 39 | 40 | 可以发送 GET 请求，返回带有健康信息的 JSON 格式对象。例如获取健康状况，可以使用如下命令。 41 | 42 | ```bash 43 | $ curl http://orderer:8443/healthz 44 | {"status":"OK","time":"XXXX-YY-ZZT01:02:03.567890Z"} 45 | $ curl http://peer:9443/healthz 46 | {"status":"OK","time":"XXXX-YY-ZZT01:02:03.567890Z"} 47 | ``` 48 | 49 | 目前健康状况支持检测链码容器运行的 Docker 服务的状态，未来会扩展支持更多组件健康状态。 50 | 51 | ### 获取系统统计信息 52 | 53 | 资源为 /metrics。 54 | 55 | 可以发送 GET 请求，返回各个指标的统计信息。例如获取当前统计信息，可以使用如下命令。 56 | 57 | ```bash 58 | $ curl http://orderer:8443/metrics 59 | # HELP blockcutter_block_fill_duration The time from first transaction enqueuing to the block being cut in seconds. 60 | # TYPE blockcutter_block_fill_duration histogram 61 | blockcutter_block_fill_duration_bucket{channel="businesschannel",le="0.005"} 0 62 | blockcutter_block_fill_duration_bucket{channel="businesschannel",le="0.01"} 0 63 | blockcutter_block_fill_duration_bucket{channel="businesschannel",le="0.025"} 0 64 | ... 65 | process_virtual_memory_bytes 3.37268736e+08 66 | # HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes. 67 | # TYPE process_virtual_memory_max_bytes gauge 68 | process_virtual_memory_max_bytes -1 69 | 70 | $ curl http://peer:9443/metrics 71 | # HELP chaincode_launch_duration The time to launch a chaincode. 72 | # TYPE chaincode_launch_duration histogram 73 | chaincode_launch_duration_bucket{chaincode="+lifecycle:1.4.0",success="true",le="0.005"} 1 74 | chaincode_launch_duration_bucket{chaincode="+lifecycle:1.4.0",success="true",le="0.01"} 1 75 | chaincode_launch_duration_bucket{chaincode="+lifecycle:1.4.0",success="true",le="0.025"} 1 76 | ... 77 | process_virtual_memory_bytes 4.21298176e+08 78 | # HELP process_virtual_memory_max_bytes Maximum amount of virtual memory available in bytes. 79 | # TYPE process_virtual_memory_max_bytes gauge 80 | process_virtual_memory_max_bytes -1 81 | ``` 82 | 83 | Orderer 的统计信息包括切块时间、广播队列、校验时间、发送块数量、Go 进程信息、gRPC 请求、系统资源等，可以用来详细了解 Orderer 资源使用和工作情况。 84 | 85 | Peer 的统计信息包括链码执行情况、Go 进程信息、gRPC 请求、区块处理、账本提交、数据库更新、系统资源等多个指标，可以实时了解 Peer 资源使用和工作情况。 86 | 87 | 当然，直接阅读这些统计指标并不高效，更方便的是通过外部监控工具。如果使用 StatsD 来分析数据，需要在 Peer 和 Orderer 配置文件中指定 StatsD 服务器地址（StatsD 是推送方式）；如果使用 Prometheus，直接在其配置中指定 Peer 和 Orderer 的服务地址即可（Prometheus 是推送方式）。 88 | 89 | 以 Prometheus 为例，配置中指定 Peer 和 Orderer 地址后，Prometheus 会主动从 /metrics API 获取统计信息。此时通过 Prometheus 的图形界面（默认监听在 9090 端口）可以查看到这些指标的数据和统计图。 90 | 91 | 下图展示了链码 shim 层请求的执行延迟统计。 92 | 93 | ![使用 prometheus 监控 Fabric 网络](_images/prometheus.png) 94 | 95 | 用户也可以集成使用更多第三方系统来监控和分析 Fabric 系统的监控数据，实现自动化的运维管理。 -------------------------------------------------------------------------------- /10_fabric_op/sdk.md: -------------------------------------------------------------------------------- 1 | ## SDK 支持 2 | 3 | 除了基于命令行的客户端之外，超级账本 Fabric 提供了多种语言的 SDK，包括 Node.Js、Python、Java、Go 等。它们封装了 Fabric 网络中节点提供的 gRPC 服务接口，可以实现更方便的调用。 4 | 5 | 这些客户端 SDK 允许用户和应用跟 Fabric 网络进行交互，还可以实现更为复杂的操作，实现包括节点的启停、通道的创建和加入、链码的生命周期管理等操作。SDK 项目目前已经初步成熟，更多特性仍在开发中，感兴趣的读者可以通过如下途径获取到 SDK 的源码并进行尝试。 6 | 7 | ### 基于 Node.Js 实现的 SDK 8 | 9 | 作为早期创建的 SDK 项目之一，Node.Js 实现的 SDK 目前已经支持了对 Fabric 链码的主要操作，包括安装链码、实例化并进行调用等，以及访问 Fabric CA 服务。内带了不少操作的例子可供参考。 10 | 11 | 源码仓库地址在 github.com/hyperledger/fabric-sdk-node。 12 | 13 | 源码的 test/integration/e2e 目录下包括了大量应用的示例代码，可供参考。 14 | 15 | ### 基于 Python 实现的 SDK 16 | 17 | 早期创建的 SDK 项目之一。Python 实现的 SDK 目前已经完成了对 Fabric 链码的主要操作，包括安装链码、实例化并进行调用等，以及使用 Fabric CA 的基础功能。 18 | 19 | 源码仓库地址在 github.com/hyperledger/fabric-sdk-py。 20 | 21 | 源码的 test/integration 目录下包括了大量应用的示例代码，可供参考。 22 | 23 | ### 基于 Java 实现的 SDK 24 | 25 | 属于较新的 SDK 项目。Java SDK 目前支持对 Fabric 中链码的主要操作，以及访问 Fabric CA 服务。 26 | 27 | 源码仓库地址在 github.com/hyperledger/fabric-sdk-java。 28 | 29 | ### 基于 Go 实现的 SDK 30 | 31 | 属于较新的 SDK 项目。Go SDK 提取了原先 Fabric 中的相关代码，目前支持对 Fabric 中链码的主要操作。将来，Fabric 中的命令行客户端将可能基于该 SDK 重新实现。 32 | 33 | 源码仓库地址在 github.com/hyperledger/fabric-sdk-go。 34 | -------------------------------------------------------------------------------- /10_fabric_op/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 本章详细讲解了管理 Fabric 网络的相关话题，包括如何操作和管理通道、链码的相关客户端命令，以及监听网络事件、探测网络信息、SDK 工具、运维服务和升级网络等。最后，对生产环境中部署 Fabric 网络的注意事项进行了讨论。 4 | 5 | 通过本章内容的学习和实践，相信读者可以掌握管理 Fabric 网络的相关技巧。更多的经验需要在生产实践积累和总结。 6 | -------------------------------------------------------------------------------- /10_fabric_op/upgrade.md: -------------------------------------------------------------------------------- 1 | ## 如何升级版本 2 | 3 | Fabric 保持了较好的向后兼容性，从 v1.0.0 版本开始支持手动升级到更高版本。 4 | 5 | 网络升级主要包括对如下资源进行升级： 6 | 7 | * 核心组件：包括 Peer、Orderer、CA 等核心程序； 8 | * 能力配置：更新通道配置中支持的能力集合版本号，以启动新的特性； 9 | * 第三方资源：包括依赖的 CouchDB、Kafka 等第三方组件。 10 | 11 | ### 能力类型 12 | 13 | 为了避免网络多个节点运行不同版本组件时出现分叉风险，自 1.1.0 版本起在通道配置中引入了能力（Capabilities），标记节点应当支持和启用的特性。如果某节点程序版本低于能力要求则无法加入或自动退出；同时通道内高版本的节点程序在提交校验时只启用指定的特性集合检查（可参考 core/handlers/validation/builtin）。 14 | 15 | 目前能力分为三种类型，分别管理不同范围，如下表所示。 16 | 17 | 类型 | 功能 | 配置路径 18 | --- | --- | --- 19 | 通道（Channel）能力| 通道整体相关能力，排序和 Peer 节点都得满足 | /Channel/Capabilities 20 | 排序（Orderer）能力| 排序服务能力，只与排序节点有关 | /Channel/Orderer/Capabilities 21 | 应用（Application）能力| 应用相关能力，只与 Peer 节点有关 | /Channel/Application/Capabilities 22 | 23 | 如果要启用相应的能力，需要修改通道配置内对应配置。例如，用户可以指定通道能力为 v1.1.0，排序能力为 v1.1.0 模式下，而应用能力为 v1.3.0。此时，只有不低于 v1.1.0 版本（满足通道和排序能力的较大者）的排序节点，以及不低于 v1.3.0 版本（满足通道和应用能力的较大者）的 Peer 节点可以支持该通道。同时，即使排序节点和 Peer 节点程序版本更新（如 v2.x），仍然只会启用指定的能力集合。 24 | 25 | 需要注意能力配置只能调整到更新版本而不应回退，例如可以将能力模式 v1.3.0 更新为更高版本的 v1.4.0，反之无意义。这是因为旧版本的节点即便加入到通道内，仍然无法正常处理其中新版本启用阶段的交易。 26 | 27 | 其中，各能力集合的版本和内容（可参考 common/capabilities）如下表所示，注意并不与程序版本一致。 28 | 29 | 能力版本 | 起始程序版本 | 类型 | 能力内容 30 | --- | --- | --- | --- 31 | ChannelV1_1 | v1.1.0 | 通道 | 仅供标记，程序版本为 1.1.0+ 32 | ChannelV1_3 | v1.3.0 | 通道 | 支持 idemix 33 | OrdererV1_1 | v1.1.0 | 排序 | 重新提交和身份超时检查 34 | OrdererV2_0 | v2.0.0 | 排序 | 排序服务支持从 Kafka 切换到 Raft 35 | ApplicationV1_1 |v1.1.0 | 应用 | 禁止区块内重复交易Id 36 | ApplicationV1_2 |v1.2.0 | 应用 | 正式支持私有数据，支持升级私有数据成员组配置，细粒度的通道资源访问控制（ACL） 37 | ApplicationV1_3 |v1.3.0 | 应用 | 支持基于键值的背书 38 | ApplicationV2_0 |v2.0.0 | 应用 | 新的链码生命周期管理 39 | ApplicationV2_0 |v2.0.0 | 应用 | 支持 FabToken 40 | ApplicationV2_0 |v2.0.0 | 应用 | 支持链码操作 41 | 42 | 43 | ### 推荐升级步骤 44 | 45 | #### 升级排序服务 46 | 47 | 对于不改变排序模式的情况下，升级较为简单。 48 | 49 | 逐个停止排序节点，并备份本地数据，包括身份文件、账本数据、配置文件等。 50 | 51 | 升级排序服务程序。重新启动并检查是否工作正常，如获取区块、发送交易等。 52 | 53 | 如果需要改变排序模式（Kafka 变为 Raft）的情况，TBD。 54 | 55 | #### 升级 Peer 节点 56 | 57 | 逐个停止 Peer 节点，并备份本地数据，包括身份文件、账本数据、链码包、配置文件等。 58 | 59 | 升级 Peer 程序。重新启动并检查是否工作正常，如查询信息、发送交易提案等。 60 | 61 | 链码包如果之前有引入旧的第三方库或者 Shim 包，或者需要启用新的 API，则还要执行链码升级操作。 62 | 63 | #### 升级 CA 服务 64 | 65 | 停止 Fabric-CA 服务，备份数据库。 66 | 67 | 升级 fabric-ca 程序，重新启动并检查是否工作正常，如获取根证书。 68 | 69 | ```bash 70 | $ fabric-ca-client getcacert -u https://:7054 --tls.certfiles tls-cert.pem 71 | ``` 72 | 73 | #### 升级通道配置 74 | 75 | 按照新的格式发送通道更新请求，特别是修改对应能力域值为新的版本。 76 | 77 | 首先升级系统通道，更新通道和排序能力值，之后升级应用通道，更新应用相关能力 78 | 79 | 更新后测试网络功能，如获取新的区块正常。 80 | 81 | #### 升级第三方组件 82 | 83 | 包括 CouchDB、Kafka 等第三方组件，升级之前最好备份数据文件。 84 | 85 | CouchDB 版本自 1.x 版本可以很容易升级到高版本，具体操作可以参考项目文档：http://docs.couchdb.org/en/stable/install/upgrading.html。 86 | 87 | 如果仍然使用 Kafka 模式的排序服务，则还可以升级 Kafka。 88 | 89 | Kafka 自 0.10.0.x 版本开始保持了较好的兼容性，可以较为容易升级到更高版本。之前版本也可执行滚动升级，可参考项目文档：http://docs.couchdb.org/en/stable/install/upgrading.html。 90 | 91 | Kafka 版本更新后需要更新 orderer.yaml 中的 Kafka.Version 域并重启 Orderer。 92 | -------------------------------------------------------------------------------- /11_app_dev/README.md: -------------------------------------------------------------------------------- 1 | # 智能合约开发 2 | 3 | **代码即律法（Code is law）。** 4 | 5 | 智能合约丰富了区块链技术的适用范围，让分布式账本支持大规模的商业应用成为可能。 6 | 7 | 区块链应用开发者不光需要理解业务逻辑，还要能够开发智能合约和用户应用。超级账本 Fabric 的链码支持主流编程语言如 Go、Java、Node，并提供了链码开发框架，简化了分布式应用的开发过程。 8 | 9 | 本章将介绍 Fabric 链码的基本概念、结构和核心 API，并通过案例演示如何实现典型区块链应用，最后还介绍了外部链码机制，讨论了应用开发的最佳实践。通过本章学习，读者将掌握设计和开发链码的实践技巧。 -------------------------------------------------------------------------------- /11_app_dev/chaincode.md: -------------------------------------------------------------------------------- 1 | ## 链码概念与结构 2 | 3 | 超级账本 Fabric 中的链码（Chaincode）延伸自智能合约的概念，负责对应用程序发送的请求做出响应，执行代码逻辑，实现与账本进行交互。 4 | 5 | 区块链网络中成员协商好业务逻辑后，可将其编程到链码中，所有业务流程将遵循合约代码自动执行。 6 | 7 | 链码执行过程中可以创建状态（State）并写入账本中。状态绑定到链码的命名空间，仅限该链码访问。在合适许可下，链码可以调用另一个链码，间接访问其状态。在一些场景下，不仅需要访问状态当前值，还需要查询状态的历史值。 8 | 9 | 原生链码默认在 Docker 容器中执行，2.0 版本中开始支持外部链码。链码通过 gRPC 协议与 Peer 节点进行交互，包括读写账本、返回响应结果等。 10 | 11 | Fabric 支持多种语言实现的链码，包括 Go、JavaScript、Java 等。下面以 Go 语言为例介绍链码接口和相关结构。 12 | 13 | ### Chaincode 接口 14 | 15 | 每个链码都需要实现以下 Chaincode 接口，包括 Init 和 Invoke 两个方法。 16 | 17 | ```go 18 | type Chaincode interface { 19 | Init(stub ChaincodeStubInterface) pb.Response 20 | Invoke(stub ChaincodeStubInterface) pb.Response 21 | } 22 | ``` 23 | 24 | * Init：当链码收到初始化指令时，Init 方法会被调用。 25 | * Invoke：当链码收到调用（invoke）或查询（query）调用时，Invoke 方法会被调用。 26 | 27 | ### 链码结构 28 | 29 | 一个链码的必要结构如下所示： 30 | 31 | ```go 32 | package main 33 | 34 | // 引入必要的包 35 | import ( 36 | "github.com/hyperledger/fabric-chaincode-go/shim" 37 | pb "github.com/hyperledger/fabric-protos-go/peer" 38 | ) 39 | 40 | // 声明一个结构体 41 | type SimpleChaincode struct {} 42 | 43 | // 为结构体添加 Init 方法 44 | func (t *SimpleChaincode) Init(stub shim.ChaincodeStubInterface) pb.Response { 45 | // 在该方法中实现链码初始化或升级时的处理逻辑 46 | // 编写时可灵活使用 stub 中的 API 47 | } 48 | 49 | // 为结构体添加 Invoke 方法 50 | func (t *SimpleChaincode) Invoke(stub shim.ChaincodeStubInterface) pb.Response { 51 | // 在该方法中实现链码运行中被调用或查询时的处理逻辑 52 | // 编写时可灵活使用 stub 中的 API 53 | } 54 | 55 | // 主函数，需要调用 shim.Start() 方法 56 | func main() { 57 | err := shim.Start(new(SimpleChaincode)) 58 | if err != nil { 59 | fmt.Printf("Error starting Simple chaincode: %s", err) 60 | } 61 | } 62 | ``` 63 | 64 | #### 依赖包 65 | 66 | 从 `import` 代码段可以看到，链码需要引入如下的依赖包。 67 | 68 | * `"github.com/hyperledger/fabric-chaincode-go/shim"`：shim 包提供了链码与账本交互的中间层。链码通过 `shim.ChaincodeStub` 提供的方法来读取和修改账本状态。 69 | * `pb "github.com/hyperledger/fabric-protos-go/peer"`: Init 和 Invoke 方法需要返回 `pb.Response` 类型。 70 | 71 | #### Init 和 Invoke 方法 72 | 73 | 编写链码，关键是要实现 Init 和 Invoke 这两个方法。 74 | 75 | 当初始化链码时，Init 方法会被调用。如同名字所描述的，该方法用来完成一些初始化的工作。当调用链码时，Invoke 方法被调用，主要业务逻辑都需要在该方法中实现。 76 | 77 | Init 或 Invoke 方法以 `stub shim.ChaincodeStubInterface` 作为传入参数，`pb.Response` 作为返回类型。其中，`stub` 封装了丰富的 API，功能包括对账本进行操作、读取交易参数、调用其它链码等。 78 | -------------------------------------------------------------------------------- /11_app_dev/chaincode_example01.go: -------------------------------------------------------------------------------- 1 | /* 2 | Copyright IBM Corp 2016 All Rights Reserved. 3 | 4 | Licensed under the Apache License, Version 2.0 (the "License"); 5 | you may not use this file except in compliance with the License. 6 | You may obtain a copy of the License at 7 | 8 | http://www.apache.org/licenses/LICENSE-2.0 9 | 10 | Unless required by applicable law or agreed to in writing, software 11 | distributed under the License is distributed on an "AS IS" BASIS, 12 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13 | See the License for the specific language governing permissions and 14 | limitations under the License. 15 | */ 16 | 17 | package main 18 | 19 | import ( 20 | "errors" 21 | "fmt" 22 | 23 | "github.com/hyperledger/fabric/core/chaincode/shim" 24 | ) 25 | 26 | // SimpleChaincode example simple Chaincode implementation 27 | type SimpleChaincode struct { 28 | } 29 | 30 | func main() { 31 | err := shim.Start(new(SimpleChaincode)) 32 | if err != nil { 33 | fmt.Printf("Error starting Simple chaincode: %s", err) 34 | } 35 | } 36 | 37 | // Init resets all the things 38 | func (t *SimpleChaincode) Init(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error) { 39 | if len(args) != 1 { 40 | return nil, errors.New("Incorrect number of arguments. Expecting 1") 41 | } 42 | 43 | err := stub.PutState("hello_world", []byte(args[0])) 44 | if err != nil { 45 | return nil, err 46 | } 47 | 48 | return nil, nil 49 | } 50 | 51 | // Invoke isur entry point to invoke a chaincode function 52 | func (t *SimpleChaincode) Invoke(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error) { 53 | fmt.Println("invoke is running " + function) 54 | 55 | // Handle different functions 56 | if function == "init" { 57 | return t.Init(stub, "init", args) 58 | } else if function == "write" { 59 | return t.write(stub, args) 60 | } 61 | fmt.Println("invoke did not find func: " + function) 62 | 63 | return nil, errors.New("Received unknown function invocation") 64 | } 65 | 66 | // Query is our entry point for queries 67 | func (t *SimpleChaincode) Query(stub *shim.ChaincodeStub, function string, args []string) ([]byte, error) { 68 | fmt.Println("query is running " + function) 69 | 70 | // Handle different functions 71 | if function == "read" { //read a variable 72 | return t.read(stub, args) 73 | } 74 | fmt.Println("query did not find func: " + function) 75 | 76 | return nil, errors.New("Received unknown function query") 77 | } 78 | 79 | // write - invoke function to write key/value pair 80 | func (t *SimpleChaincode) write(stub *shim.ChaincodeStub, args []string) ([]byte, error) { 81 | var key, value string 82 | var err error 83 | fmt.Println("running write()") 84 | 85 | if len(args) != 2 { 86 | return nil, errors.New("Incorrect number of arguments. Expecting 2. name of the key and value to set") 87 | } 88 | 89 | key = args[0] //rename for funsies 90 | value = args[1] 91 | err = stub.PutState(key, []byte(value)) //write the variable into the chaincode state 92 | if err != nil { 93 | return nil, err 94 | } 95 | return nil, nil 96 | } 97 | 98 | // read - query function to read key/value pair 99 | func (t *SimpleChaincode) read(stub *shim.ChaincodeStub, args []string) ([]byte, error) { 100 | var key, jsonResp string 101 | var err error 102 | 103 | if len(args) != 1 { 104 | return nil, errors.New("Incorrect number of arguments. Expecting name of the key to query") 105 | } 106 | 107 | key = args[0] 108 | valAsbytes, err := stub.GetState(key) 109 | if err != nil { 110 | jsonResp = "{\"Error\":\"Failed to get state for " + key + "\"}" 111 | return nil, errors.New(jsonResp) 112 | } 113 | 114 | return valAsbytes, nil 115 | } 116 | -------------------------------------------------------------------------------- /11_app_dev/chaincode_example01.md: -------------------------------------------------------------------------------- 1 | ## 链码示例一：信息公证 2 | ### 简介 3 | 4 | [chaincode_example01.go](chaincode_example01.go) 主要实现如下的功能： 5 | 6 | * 初始化，以键值形式存放信息； 7 | * 允许读取和修改键值。 8 | 9 | 代码中，首先初始化了 `hello_world` 的值，并根据请求中的参数创建修改查询链上 `key` 中的值，本质上实现了一个简单的可修改的键值数据库。 10 | 11 | ### 主要函数 12 | 13 | * `read`：读取key `args[0]` 的 value； 14 | * `write`：创建或修改 key `args[0]` 的 value； 15 | * `init`：初始化 key `hello_world` 的 value； 16 | * `invoke`：根据传递参数类型调用执行相应的 `init` 和 `write` 函数； 17 | * `query`：调用 `read` 函数查询 `args[0]` 的 value。 18 | 19 | ### 代码运行分析 20 | 21 | `main` 函数作为程序的入口，调用 shim 包的 start 函数，启动 chaincode 引导程序的入口节点。如果报错，则返回。 22 | 23 | ```go 24 | func main() { 25 | err := shim.Start(new(SimpleChaincode)) 26 | if err != nil { 27 | fmt.Printf("Error starting Simple chaincode: %s", err) 28 | } 29 | } 30 | ``` 31 | 32 | 当智能合约部署在区块链上，可以通过 rest api 进行交互。 33 | 34 | 三个主要的函数是 `init`，`invoke`，`query`。在三个函数中，通过 `stub.PutState`与 `stub.GetState` 存储访问 ledger 上的键值对。 35 | 36 | ### 通过 REST API 操作智能合约 37 | 38 | 假设以 jim 身份登录 pbft 集群，请求部署该 chaincode 的 json 请求格式为： 39 | ```json 40 | { 41 | "jsonrpc": "2.0", 42 | "method": "deploy", 43 | "params": { 44 | "type": 1, 45 | "chaincodeID": { 46 | "path": "https://github.com/ibm-blockchain/learn-chaincode/finished" 47 | }, 48 | "ctorMsg": { 49 | "function": "init", 50 | "args": [ 51 | "hi there" 52 | ] 53 | }, 54 | "secureContext": "jim" 55 | }, 56 | "id": 1 57 | } 58 | ``` 59 | 60 | 目前 path 仅支持 github 上的目录，ctorMsg 中为函数 `init` 的传参。 61 | 62 | 调用 invoke 函数的 json 格式为： 63 | 64 | ```json 65 | { 66 | "jsonrpc": "2.0", 67 | "method": "invoke", 68 | "params": { 69 | "type": 1, 70 | "chaincodeID": { 71 | "name": "4251b5512bad70bcd0947809b163bbc8398924b29d4a37554f2dc2b033617c19cc0611365eb4322cf309b9a5a78a5dba8a5a09baa110ed2d8aeee186c6e94431" 72 | }, 73 | "ctorMsg": { 74 | "function": "init", 75 | "args": [ 76 | "swb" 77 | ] 78 | }, 79 | "secureContext": "jim" 80 | }, 81 | "id": 2 82 | } 83 | ``` 84 | 85 | 其中 name 字段为 `deploy` 后返回的 message 字段中的字符串。 86 | 87 | `query` 的接口也是类似的。 88 | -------------------------------------------------------------------------------- /11_app_dev/chaincode_example02.md: -------------------------------------------------------------------------------- 1 | ## 链码示例二：交易资产 2 | 3 | ### 简介 4 | 5 | [chaincode_example02.go](chaincode_example02.go) 主要实现如下的功能： 6 | 7 | * 初始化 A、B 两个账户，并为两个账户赋初始资产值； 8 | * 在 A、B 两个账户之间进行资产交易； 9 | * 分别查询 A、B 两个账户上的余额，确认交易成功； 10 | * 删除账户。 11 | 12 | ### 主要函数 13 | 14 | * `init`：初始化 A、B 两个账户； 15 | * `invoke`：实现 A、B 账户间的转账； 16 | * `query`：查询 A、B 账户上的余额； 17 | * `delete`：删除账户。 18 | 19 | ### 依赖的包 20 | ```go 21 | import ( 22 | "errors" 23 | "fmt" 24 | "strconv" 25 | 26 | "github.com/hyperledger/fabric/core/chaincode/shim" 27 | ) 28 | ``` 29 | `strconv` 实现 int 与 string 类型之间的转换。 30 | 31 | 在invoke 函数中，存在： 32 | ```go 33 | X, err = strconv.Atoi(args[2]) 34 | Aval = Aval - X 35 | Bval = Bval + X 36 | ``` 37 | 38 | 当 `args[2]<0` 时，A 账户余额增加，否则 B 账户余额减少。 39 | 40 | ### 可扩展功能 41 | 实例中未包含新增账户并初始化的功能。开发者可以根据自己的业务模型进行添加。 42 | -------------------------------------------------------------------------------- /11_app_dev/chaincode_example04.md: -------------------------------------------------------------------------------- 1 | ### 学历认证 2 | #### 功能描述 3 | 该 [智能合约](chaincode_example04.go) 实现了一个简单的征信管理的案例。针对于学历认证领域，由于条约公开，在条约外无法随意篡改的特性，天然具备稳定性和中立性。 4 | 5 | 该智能合约中三种角色如下： 6 | - 学校 7 | - 个人 8 | - 需要学历认证的机构或公司 9 | 10 | 学校可以根据相关信息在区块链上为某位个人授予学历，相关机构可以查询某人的学历信息，由于使用私钥签名，确保了信息的真实有效。 11 | 为了简单，尽量简化相关的业务，另未完成学业的学生因违纪或外出创业退学，学校可以修改其相应的学历信息。 12 | 13 | 账户私钥应该由安装在本地的客户端生成，本例中为了简便，使用模拟私钥和公钥。 14 | 15 | #### 数据结构设计 16 | - 学校 17 | - 名称 18 | - 所在位置 19 | - 账号地址 20 | - 账号公钥 21 | - 账户私钥 22 | - 学校学生 23 | - 个人 24 | - 姓名 25 | - 账号地址 26 | - 过往学历 27 | - 学历信息 28 | - 学历信息编号 29 | - 就读学校 30 | - 就读年份 31 | - 完成就读年份 32 | - 就读状态 // 0:毕业 1：退学 33 | - 修改记录（入学也相当于一种修改记录） 34 | - 编号 35 | - 学校账户地址（一般根据账户地址可以算出公钥地址，然后可以进行校验） 36 | - 学校签名 37 | - 个人账户地址 38 | - 个人公钥地址（个人不需要公钥地址） 39 | - 修改时间 40 | - 修改操作// 0:正常毕业 1：退学 2:入学 41 | 42 | 对学历操作信息所有的操作都归为记录。 43 | #### function及各自实现的功能 44 | - `init` 初始化函数 45 | - `invoke` 调用合约内部的函数 46 | 47 | - `updateDiploma` 由学校更新学生学历信息，并签名（返回记录信息） 48 | - `enrollStudent` 学校招生（返回学校信息） 49 | - `createSchool` 添加一名新学校 50 | - `createStudent` 添加一名新学生 51 | - `getStudentByAddress` 通过学生的账号地址访问学生的学历信息 52 | - `getRecordById` 通过Id获取记录 53 | - `getRecords` 获取全部记录（如果记录数大于 10，返回前 10 个） 54 | - `getSchoolByAddress` 通过学校账号地址获取学校的信息 55 | - `getBackgroundById` 通过学历 Id 获取所存储的学历信息 56 | 57 | - `writeRecord` 写入记录 58 | - `writeSchool` 写入新创建的学校 59 | - `writeStudent` 写入新创建的学生 60 | 61 | #### 接口设计 62 | `createSchool` 63 | 64 | request参数: 65 | ``` 66 | args[0] 学校名称 67 | args[1] 学校所在位置 68 | ``` 69 | response参数: 70 | ``` 71 | 学校信息的字节数组，当创建一所新学校时，该学校学生账户地址列表为空 72 | ``` 73 | 74 | `createStudent` 75 | 76 | request参数： 77 | ``` 78 | args[0] 学生的姓名 79 | ``` 80 | 81 | response参数： 82 | ``` 83 | 学生信息的字节数组表示，刚创建过往学历信息列表为空 84 | ``` 85 | 86 | `updateDiploma` 87 | 88 | request参数 89 | ``` 90 | args[0] 学校账户地址 91 | args[1] 学校签名 92 | args[2] 待修改学生的账户地址 93 | args[3] //对该学生的学历进行怎样的修改，0：正常毕业 1：退学 94 | ``` 95 | 96 | response参数 97 | ``` 98 | 返回修改记录的字节数组表示 99 | ``` 100 | 101 | `enrollStudent` 102 | 103 | request参数: 104 | ``` 105 | args[0] 学校账户地址 106 | args[1] 学校签名 107 | args[2] 学生账户地址 108 | ``` 109 | 110 | response参数 111 | ``` 112 | 返回修改记录的字节数组表示 113 | ``` 114 | 115 | `getStudentByAddress` 116 | 117 | request参数 118 | ``` 119 | args[0] address 120 | ``` 121 | response参数 122 | ``` 123 | 学生信息的字节数组表示 124 | ``` 125 | 126 | `getRecordById` 127 | 128 | request参数 129 | ``` 130 | args[0] 修改记录的ID 131 | ``` 132 | response参数 133 | ``` 134 | 修改记录的字节数组表示 135 | ``` 136 | 137 | `getRecords` 138 | 139 | response参数 140 | ``` 141 | 获取修改记录数组（如果个数大于10，返回前10个） 142 | ``` 143 | `getSchoolByAddress` 144 | 145 | request参数 146 | ``` 147 | args[0] address 148 | ``` 149 | response参数 150 | ``` 151 | 学校信息的字节数组表示 152 | ``` 153 | 154 | `getBackgroundById` 155 | 156 | request参数 157 | ``` 158 | args[0] ID 159 | ``` 160 | 161 | response参数 162 | ``` 163 | 学历信息的字节数组表示 164 | ``` 165 | 166 | #### 测试 167 | -------------------------------------------------------------------------------- /11_app_dev/chaincode_example05.md: -------------------------------------------------------------------------------- 1 | ### 社区能源共享 2 | #### 功能描述 3 | 本 [合约](chaincode_example05.go) 以纽约实验性的能源微电网为例，作为一个简单的案例进行实现。 4 | 5 | >“在总统大道的一边，五户家庭通过太阳能板发电；在街道的另一边的五户家庭可以购买对面家庭不需要的电力。而连接这项交易的就是区块链网络，几乎不需要人员参与就可以管理记录交易。”但是这个想法是非常有潜力的，能够代表未来社区管理能源系统。” 6 | 7 | 布鲁克林微电网开发商 LO3 创始人 Lawrence Orsini 说： 8 | 9 | >“我们正在这条街道上建立一个可再生电力市场，来测试人们对于购买彼此手中的电力是否感兴趣。如果你在很远的地方生产能源，运输途中会有很多损耗，你也得不到这电力价值。但是如果你就在街对面，你就能高效的利用能源。” 10 | 11 | 在某一块区域内存在一个能源微电网，每一户家庭可能为生产者也可能为消费者。部分家庭拥有太阳能电池板，太阳能电池板的剩余电量为可以售出的电力的值，为了简化，单位为1.需要电力的家庭可以向有足够余额的电力的家庭购买电力。 12 | 13 | 账户私钥应该由安装在本地的客户端生成，本例中为了简便，使用模拟私钥和公钥。每位用户的私钥为guid+“1”，公钥为guid+“2”。签名方式简化为私钥+"1" 14 | 15 | #### 数据结构设计 16 | 在该智能合约中暂时只有一种角色，为每一户家庭用户。 17 | 18 | - 家庭用户 19 | - 账户地址 20 | - 剩余能量 //部分家庭没有太阳能电池板，值为0 21 | - 账户余额（电子货币） 22 | - 编号 23 | - 状态 //0：不可购买， 1：可以购买 24 | - 账户公钥 25 | - 账户私钥 26 | - 交易(一笔交易必须同时具有卖方和买方的公钥签名，方能承认这笔交易。公钥签名生成规则，公钥+待创建交易的ID号，在本交易类型中，只要买家有足够的货币，卖家自动会对交易进行签名) 27 | - 购买方地址 28 | - 销售方地址 29 | - 电量销售量 30 | - 电量交易金额 31 | - 编号 32 | - 交易时间 33 | 34 | #### function及各自实现的功能 35 | - `init` 初始化操作 36 | - `invoke` 调用合约内部的函数 37 | - `query` 查询相关的信息 38 | - `createUser` 创建新用户，并加入到能源微网中 invoke 39 | - `buyByAddress` 向某一位用户购买一定量的电力 invoke 40 | - `getTransactionById` 通过id获取交易内容 query 41 | - `getTransactions` 获取交易（如果交易数大于10，获取前10个） query 42 | - `getHomes` 获取用户（如果用户数大于10，获取前10个） query 43 | - `getHomeByAddress` 通过地址获取用户 query 44 | - `changeStatus` 某一位用户修改自身的状态 invoke 45 | 46 | - `writeUser` 将新用户写入到键值对中 47 | - `writeTransaction` 记录交易 48 | #### 接口设计 49 | `createUser` 50 | 51 | request参数: 52 | ``` 53 | args[0] 剩余能量值 54 | args[1] 剩余金额 55 | ``` 56 | response参数: 57 | ``` 58 | 新建家庭用户的json表示 59 | ``` 60 | 61 | `buyByAddress` 62 | 63 | request参数: 64 | ``` 65 | args[0] 卖家的账户地址 66 | args[1] 买家签名 67 | args[2] 买家的账户地址 68 | args[3] 想要购买的电量数值 69 | ``` 70 | response参数: 71 | ``` 72 | 购买成功的话返回该transaction的json串。 73 | 购买失败返回error 74 | ``` 75 | 76 | `getTransactionById` 77 | 78 | request参数: 79 | ``` 80 | args[0] 交易编号 81 | ``` 82 | response参数: 83 | ``` 84 | 查询结果的transaction 交易表示 85 | ``` 86 | 87 | `getTransactions` 88 | 89 | request参数: 90 | ``` 91 | none 92 | ``` 93 | response参数: 94 | ``` 95 | 获取所有的交易列表（如果交易大于10，则返回前10个） 96 | ``` 97 | 98 | `getHomeByAddress` 99 | 100 | request参数 101 | ``` 102 | args[0] address 103 | ``` 104 | response参数 105 | ``` 106 | 用户信息的json表示 107 | ``` 108 | 109 | `getHomes` 110 | 111 | response参数 112 | ``` 113 | 获取所有的用户列表（如果用户个数大于10，则返回前10个） 114 | ``` 115 | 116 | `changeStatus` 117 | 118 | request参数: 119 | ``` 120 | args[0] 账户地址 121 | args[1]　账户签名 122 | args[2] 对自己的账户进行的操作，0：设置为不可购买 1：设置状态为可购买 123 | ``` 124 | response参数: 125 | ``` 126 | 修改后的用户信息json表示 127 | ``` 128 | 129 | #### 测试 130 | -------------------------------------------------------------------------------- /11_app_dev/chaincode_example06.md: -------------------------------------------------------------------------------- 1 | ### 物流供应链简单案例 2 | #### 功能描述 3 | 该 [智能合约](chaincode_example06.go) 实现了一个简单的供应链应用案例，针对物流行业的应用场景。由于将合约的协议公开，并且签收快递时需要签名，可以在很大程度上保证不被冒领，实现了一手交钱，一手交货，同时提高了效率，确保了透明。 4 | 5 | 该智能合约中三种角色如下： 6 | - 物流公司（本案例中只有1位） 7 | - 寄货方（本案例中有多位） 8 | - 收货方（本案例中有多位） 9 | 10 | 业务流程如下： 11 | 12 | 1、寄货方填写寄货单，物流公司根据寄货单寄快递。 13 | 14 | 2、寄快递过程中物流公司各个快递点对快递进行扫描，描述目前快递进度，并更新货单状态。寄货方和收货方可以根据单号进行查询。 15 | 16 | 3、快递到达后，收货方检查商品，确认无误后，扫码并使用私钥签名，支付相关费用，更新订单状态。 17 | 18 | 在实际中，物流费的支付分为两类： 19 | - 1、寄货方支付。收货方签收快递后先预付给物流公司。 20 | - 2、收货方支付。收货方签收快递后支付给物流公司。 21 | 22 | 在本案例中暂不考虑货物损坏、收货方失联、货物保值等的相关问题。具体实现逻辑如下： 23 | 24 | - 创建账户。为每个用户生成唯一的私钥与地址。 25 | - 生成寄货单。寄货方填写纸质寄货单，物流公司根据此生成电子单。 26 | - 更新寄货单。物流公司旗下快递点根据配送信息更新电子寄货单。 27 | - 收货方签收确认。收货方收到货物后，使用自己的私钥进行签收，完成相应的付款。 28 | 29 | 账户私钥应该由安装在本地的客户端生成，本例中为了简便，使用模拟私钥和公钥。每位用户的私钥为guid+“1”，公钥为guid+“2”。用户签名为私钥+“1” 30 | 31 | #### 数据结构设计 32 | - 寄货单 33 | - 寄货单编号 34 | - 寄货方地址 35 | - 收货方地址 36 | - 寄货方联系方式 37 | - 收货方联系方式 38 | - 物流费用 39 | - 物流费用支付类型 //0：寄货方支付 1：收货方支付 40 | - 寄货方预支付费用 //模拟实际预支付，寄货方支付物流费下值为物流费，否则为0 41 | - 快递配送信息 // 快递运送状态，所经过快递分拨中心与快递点的数组 42 | - 收货方签名 43 | 44 | - 寄货方 45 | - 姓名 46 | - 所在地址 47 | - 账户地址 48 | - 账户公钥 49 | - 联系方式 50 | - 账户余额 51 | - 收货方 52 | - 姓名 53 | - 所在地址 54 | - 账户地址 55 | - 账户公钥 56 | - 账户私钥 57 | - 联系方式 58 | - 账户余额 59 | - 物流公司 60 | - 账户公钥 61 | - 账户私钥 62 | - 名称 63 | - 地址 64 | - 联系方式 65 | - 账户余额 66 | - 物流公司旗下分拨中心与快递点 67 | - 快递点 68 | - 名称 69 | - 所在地址 70 | - 联系方式 71 | - 快递点公钥 72 | - 快递点私钥 73 | - 快递点账户地址 74 | 75 | #### function及各自实现的功能 76 | - `init` 初始化物流公司及其下相应快递点 77 | - `invoke` 调用合约内部的函数 78 | - `query` 查询相关的信息 79 | - `createUser` 创建用户 init 80 | - `createExpress` 创建物流公司 init 81 | - `createExpressPoint` 创建快递点 init 82 | - `createExpressOrder` 寄货方创建寄货单 init 83 | - `finishExpressOrder` 收货方签收寄货单 invoke 84 | - `addExpressPointer` 物流公司添加新的快递点 invoke 85 | - `updateExpressOrder` 更新物流公司订单,添加快递点的信息 invoke 86 | 87 | 88 | - `getExpressOrderById` 查询订单状态 query 89 | - `getExpress` 获取物流公司信息 query 90 | - `getUserByAddress` 获取用户信息 query 91 | - `getExpressPointByAddress` 获取快递点信息 query 92 | 93 | - `writeExpress` 存储物流公司信息 （以物流公司账户地址进行存储） 94 | - `writeExpressOrder` 存储寄货单 （以“express”+id 进行存储） 95 | - `writeUser` 存储用户信息 （以地址进行存储） 96 | - `writeExpressPoint` 存储物流点信息 （以快递点账户地址进行存储） 97 | 98 | #### 接口设计 99 | `createUser` 100 | 101 | request参数 102 | ``` 103 | args[0] 姓名 104 | args[1] 所在地址 105 | args[2] 联系方式 106 | args[3] 账户余额 107 | ``` 108 | 109 | response参数 110 | ``` 111 | user信息的json表示 112 | ``` 113 | 114 | `createExpressPointer` 115 | 116 | request参数 117 | ``` 118 | args[0] 姓名 119 | args[1] 所在地址 120 | args[2] 联系方式 121 | ``` 122 | 123 | response参数 124 | ``` 125 | 物流点的信息的json表示 126 | ``` 127 | 128 | `createExpress` 129 | 130 | request 参数 131 | ``` 132 | args[0] 名称 133 | args[1] 地址 134 | args[2] 联系方式 135 | args[3] 账户余额 136 | ``` 137 | response 参数 138 | ``` 139 | 物流公司信息的json表示 140 | ``` 141 | 142 | `addExpressPointer` 143 | 144 | request参数 145 | ``` 146 | args[0] 添加快递点 147 | ``` 148 | 149 | response参数 150 | ``` 151 | 物流公司信息的json表示 152 | ``` 153 | 154 | `createExpressOrder` 155 | 156 | request参数 157 | ``` 158 | args[0] 寄货方地址 159 | args[1] 收货方地址 160 | args[2] 寄货方账户地址 161 | args[3] 收货方账户地址 162 | args[4] 寄货方联系方式 163 | args[5] 收货方联系方式 164 | args[6] 物流费用支付类型 165 | args[7] 寄货方预支付费用 （收货方支付的话值为0） 166 | args[8] 物流费用 167 | ``` 168 | 169 | response 参数 170 | ``` 171 | 订单信息的json表示 172 | ``` 173 | 174 | `updateExpressOrder` 175 | 176 | request参数 177 | ``` 178 | args[0] 订单id 179 | args[1] 快递点地址 180 | ``` 181 | 182 | response参数 183 | ``` 184 | 订单信息的json表示 185 | ``` 186 | 187 | `finishExpressOrder` 188 | 189 | request参数 190 | ``` 191 | args[0] 收货方账户地址 192 | args[1] 账户订单编号 193 | args[2] 收货方签名 194 | ``` 195 | 196 | response参数 197 | ``` 198 | 订单信息的json表示 199 | ``` 200 | 201 | `getExpressOrderById` 202 | 203 | request参数： 204 | ``` 205 | args[0] id 206 | ``` 207 | 208 | response参数： 209 | ``` 210 | 快递订单的json表示 211 | ``` 212 | 213 | `getExpress` 214 | 215 | response参数： 216 | ``` 217 | 快递信息的json表示 218 | ``` 219 | 220 | `getUserByAddress` 221 | 222 | request参数 223 | ``` 224 | args[0] address 225 | ``` 226 | 227 | response参数 228 | ``` 229 | 用户信息的json表示 230 | ``` 231 | 232 | `getExpressPointerByAddress` 233 | 234 | request参数 235 | ``` 236 | args[0] address 237 | ``` 238 | 239 | response参数 240 | ``` 241 | 快递点的json信息表示 242 | ``` 243 | 244 | #### 测试 245 | -------------------------------------------------------------------------------- /11_app_dev/intro.md: -------------------------------------------------------------------------------- 1 | ## 简介 2 | 3 | 区块链应用，一般由若干部署在区块链网络中的智能合约，以及调用这些智能合约的用户应用程序组成。典型结构如下图所示。 4 | 5 | ![区块链应用程序](_images/blockchain_application.png) 6 | 7 | 其中，用户访问与业务本身相关的上层应用程序，应用程序调用智能合约，智能合约与账本直接交互。 8 | 9 | 开发者除了需要开发传统的上层业务应用，还需要编写区块链智能合约代码。 10 | 11 | 典型的智能合约是无状态的、事件驱动的代码，被调用时自动执行合约内逻辑。智能合约可以创建和操作账本状态，这些链上状态记录业务相关的重要数据（如资产信息和所有权）。区块链网络中可以部署多个智能合约，应用程序通过名称、版本号等来指定调用特定智能合约。 12 | 13 | 在支持访问控制的场景下，应用程序还需提前从 CA 处申请证书，得到访问许可。 14 | 15 | ### 智能合约开发 16 | 17 | 智能合约直接与账本结构打交道，同时支持上层业务逻辑，作用十分关键。设计得当的智能合约可以简化应用开发；反之则可能导致各种问题。 18 | 19 | 为了合理设计智能合约，开发者需要了解区块链平台的智能合约结构、语言特性、状态存储方式等。例如，比特币网络不支持高级语言，所支持的处理逻辑存在限制；超级账本 Fabric 项目支持多种高级语言，支持图灵完备的处理逻辑，可以开发复杂的逻辑。 20 | 21 | 此外，开发者还需要考虑智能合约的生命周期管理，包括代码的编写、版本管理、提交验证、升级等，都需要遵循标准规范。 22 | 23 | 本章后续内容会以超级账本 Fabric 为例，讲解其智能合约的开发过程。 24 | 25 | ### 应用程序开发 26 | 27 | 应用程序通常以 Web、移动端 App 等形式呈现，通过调用智能合约提供的方法接口来实现业务逻辑。应用程序既可以运行在区块链网络的节点上，也可以运行在外部服务器上，但必须可以访问到区块链网络服务。 28 | 29 | 为方便进行身份管理、网络监听、调用智能合约等，应用程序开发通常需要集成区块链 SDK。以超级账本 Fabric 为例，社区提供的 SDK 封装了一系列与区块链网络打交道的基本方法，包括发送交易、监听网络事件、查询区块和交易信息等，能够提高对智能合约进行使用的效率。 30 | 31 | 例如，利用 SDK 可以自动化对智能合约的调用和确认过程： 32 | 33 | * 客户端从 CA 获取合法的身份证书； 34 | * 构造合法的交易提案发送给 Endorser 节点进行背书； 35 | * 收集到足够多背书支持后，构造合法的交易请求，发给排序节点进行排序； 36 | * 监听网络事件，确保交易已经写入账本。 37 | 38 | Fabric 目前提供了 Node.Js、Python、Java、Go 等语言的 SDK，开发者可以根据需求自行选择。 39 | -------------------------------------------------------------------------------- /11_app_dev/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 -------------------------------------------------------------------------------- /13_fabric_design/README.md: -------------------------------------------------------------------------------- 1 | # Fabric 架构与设计 -------------------------------------------------------------------------------- /13_fabric_design/_images/dataflow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/13_fabric_design/_images/dataflow.png -------------------------------------------------------------------------------- /13_fabric_design/_images/refarch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/13_fabric_design/_images/refarch.png -------------------------------------------------------------------------------- /13_fabric_design/_images/transaction_flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/13_fabric_design/_images/transaction_flow.png -------------------------------------------------------------------------------- /13_fabric_design/intro.md: -------------------------------------------------------------------------------- 1 | ## 简介 -------------------------------------------------------------------------------- /13_fabric_design/protocol.md: -------------------------------------------------------------------------------- 1 | ## 消息协议 2 | 3 | 节点之间通过消息来进行交互，所有消息都由下面的数据结构来实现。 4 | 5 | ```protobuf 6 | message Message { 7 | enum Type { 8 | UNDEFINED = 0; 9 | 10 | DISC_HELLO = 1; 11 | DISC_DISCONNECT = 2; 12 | DISC_GET_PEERS = 3; 13 | DISC_PEERS = 4; 14 | DISC_NEWMSG = 5; 15 | 16 | CHAIN_STATUS = 6; 17 | CHAIN_TRANSACTION = 7; 18 | CHAIN_GET_TRANSACTIONS = 8; 19 | CHAIN_QUERY = 9; 20 | 21 | SYNC_GET_BLOCKS = 11; 22 | SYNC_BLOCKS = 12; 23 | SYNC_BLOCK_ADDED = 13; 24 | 25 | SYNC_STATE_GET_SNAPSHOT = 14; 26 | SYNC_STATE_SNAPSHOT = 15; 27 | SYNC_STATE_GET_DELTAS = 16; 28 | SYNC_STATE_DELTAS = 17; 29 | 30 | RESPONSE = 20; 31 | CONSENSUS = 21; 32 | } 33 | Type type = 1; 34 | bytes payload = 2; 35 | google.protobuf.Timestamp timestamp = 3; 36 | } 37 | ``` 38 | 39 | 消息分为四大类：Discovery（探测）、Transaction（交易）、Synchronization（同步）、Consensus（一致性）。 40 | 41 | 不同消息类型，对应到 payload 中数据不同，分为对应的子类消息结构。 42 | 43 | ### Discovery 44 | 45 | 包括 DISC_HELLO、DISC_GET_PEERS、DISC_PEERS。 46 | 47 | DISC_HELLO 消息结构如下。 48 | 49 | ```protobuf 50 | message HelloMessage { PeerEndpoint peerEndpoint = 1; uint64 blockNumber = 2;}message PeerEndpoint { PeerID ID = 1; string address = 2; enum Type { UNDEFINED = 0; VALIDATOR = 1; NON_VALIDATOR = 2; } Type type = 3; bytes pkiID = 4;} 51 | 52 | message PeerID { string name = 1;} 53 | ``` 54 | 55 | 节点新加入网络时，会向 `CORE_PEER_DISCOVERY_ROOTNODE` 发送 `DISC_HELLO` 消息，汇报本节点的信息（id、地址、block 数、类型等），开始探测过程。 56 | 57 | 探测后发现 block 数落后对方，则会触发同步过程。 58 | 59 | 之后，定期发送 `DISC_GET_PEERS` 消息，获取新加入的节点信息。收到 `DISC_GET_PEERS` 消息的节点会通过 `DISC_PEERS` 消息返回自己知道的节点列表。 60 | 61 | ### Transaction 62 | 63 | 包括 Deploy、Invoke、Query。消息结构如下： 64 | 65 | ```protobuf 66 | message Transaction { enum Type { UNDEFINED = 0; CHAINCODE_DEPLOY = 1; CHAINCODE_INVOKE = 2; CHAINCODE_QUERY = 3; CHAINCODE_TERMINATE = 4; } Type type = 1; string uuid = 5; bytes chaincodeID = 2; bytes payloadHash = 3; 67 | 68 | ConfidentialityLevel confidentialityLevel = 7; bytes nonce = 8; bytes cert = 9; bytes signature = 10; 69 | 70 | bytes metadata = 4; google.protobuf.Timestamp timestamp = 6;} 71 | 72 | message TransactionPayload { bytes payload = 1;} 73 | 74 | enum ConfidentialityLevel { PUBLIC = 0; CONFIDENTIAL = 1;} 75 | ``` 76 | 77 | ### Synchronization 78 | 当节点发现自己 block 落后网络中最新状态，则可以通过发送如下消息（由 consensus 策略决定）来获取对应的返回。 79 | 80 | * SYNC_GET_BLOCKS（对应 SYNC_BLOCKS）：获取给定范围内的 block 数据； 81 | * SYNC_STATE_GET_SNAPSHOT（对应 SYNC_STATE_SNAPSHOT）：获取最新的世界观快照； 82 | * SYNC_STATE_GET_DELTAS（对应 SYNC_STATE_DELTAS）：获取某个给定范围内的 block 对应的状态变更。 83 | 84 | ### Consensus 85 | 86 | consensus 组件收到 `CHAIN_TRANSACTION` 类消息后，将其转换为 `CONENSUS` 消息，然后向所有的 VP 节点广播。 87 | 88 | 收到 `CONSENSUS` 消息的节点会按照预定的 consensus 算法进行处理。 89 | -------------------------------------------------------------------------------- /13_fabric_design/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 -------------------------------------------------------------------------------- /17_baas/README.md: -------------------------------------------------------------------------------- 1 | # 区块链服务平台设计 2 | 3 | **规模是困难之源。** 4 | 5 | 信息产业过去的十年，是云计算的十年。云计算技术为传统信息行业带来了前所未有的便捷。用户无需在意底层实现细节，通过简单的操作，即可获得可用的计算资源，节约大量运维管理的时间成本。 6 | 7 | 区块链平台作为分布式基础设施，其部署和维护过程需要多方面的技能，这对很多应用开发者来说都是不小的挑战。为了解决这些问题，区块链即服务（Blockchain as a Service, BaaS）平台应运而生。BaaS 可以利用云服务基础设施的部署和管理优势，为开发者提供创建、使用，甚至安全监控区块链平台的快捷服务。目前，业界已有一些区块链前沿技术团队率先开发并上线了区块链服务平台。 8 | 9 | 本章将首先介绍 BaaS 的概念，之后分别介绍业界领先的 IBM Bluemix 和微软 Azure 云上所提供的区块链服务。最后，还介绍了超级账本的区块链管理平台 —— Cello 项目，以及如何使用它快速搭建一套可以个性化的区块链服务平台。 10 | -------------------------------------------------------------------------------- /17_baas/_images/azure_admin.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/azure_admin.png -------------------------------------------------------------------------------- /17_baas/_images/azure_config.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/azure_config.png -------------------------------------------------------------------------------- /17_baas/_images/azure_deploy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/azure_deploy.png -------------------------------------------------------------------------------- /17_baas/_images/azure_marketplace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/azure_marketplace.png -------------------------------------------------------------------------------- /17_baas/_images/bluemix_blockchain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/bluemix_blockchain.png -------------------------------------------------------------------------------- /17_baas/_images/bluemix_chaincode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/bluemix_chaincode.png -------------------------------------------------------------------------------- /17_baas/_images/bluemix_dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/bluemix_dashboard.png -------------------------------------------------------------------------------- /17_baas/_images/bluemix_status.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/bluemix_status.png -------------------------------------------------------------------------------- /17_baas/_images/cello.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello.png -------------------------------------------------------------------------------- /17_baas/_images/cello_arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_arch.png -------------------------------------------------------------------------------- /17_baas/_images/cello_dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_dashboard.png -------------------------------------------------------------------------------- /17_baas/_images/cello_dashboard_activechains.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_dashboard_activechains.png -------------------------------------------------------------------------------- /17_baas/_images/cello_dashboard_addcluster.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_dashboard_addcluster.png -------------------------------------------------------------------------------- /17_baas/_images/cello_dashboard_addhost.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_dashboard_addhost.png -------------------------------------------------------------------------------- /17_baas/_images/cello_dashboard_hosts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_dashboard_hosts.png -------------------------------------------------------------------------------- /17_baas/_images/cello_deployment_topo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_deployment_topo.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_chain_code_operate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_chain_code_operate.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_chain_code_running.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_chain_code_running.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_chain_code_template.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_chain_code_template.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_chain_code_template_info.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_chain_code_template_info.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_chain_info.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_chain_info.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_chain_list.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_chain_list.png -------------------------------------------------------------------------------- /17_baas/_images/cello_user_dashboard_login.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/cello_user_dashboard_login.png -------------------------------------------------------------------------------- /17_baas/_images/refarch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/refarch.png -------------------------------------------------------------------------------- /17_baas/_images/sv_home.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/sv_home.png -------------------------------------------------------------------------------- /17_baas/_images/sv_smart_contract.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/17_baas/_images/sv_smart_contract.png -------------------------------------------------------------------------------- /17_baas/azure.md: -------------------------------------------------------------------------------- 1 | ## 微软 Azure 云区块链服务 2 | 3 | Azure 是微软推出的云计算平台，向用户提供开放的 IaaS 和 PaaS 服务。 4 | 5 | Azure 陆续在其应用市场中提供了若干个与区块链相关的服务，分别面向多种不同的区块链底层平台，其中包括以太坊和超级账本 Fabric。 6 | 7 | 可以在应用市场（https://azuremarketplace.microsoft.com/en-us/marketplace/apps）中搜索 “blockchain” 关键字查看这些服务，如下图所示。 8 | 9 | ![Azure 上的区块链服务](_images/azure_marketplace.png) 10 | 11 | 下面具体介绍其中的 Azure Blockchain Service。 12 | 13 | ### 使用服务 14 | 15 | 使用 Azure 服务，用户可以在几分钟之内在云中部署一个区块链网络。云平台会将一些耗时的配置流程自动化，使用户专注在上层应用方案。 16 | 17 | Azure 区块链服务目前支持部署以太坊或超级账本 Fabric 网络。 18 | 19 | 下面以以太坊为例，在 Azure 的仪表盘中，选择创建 Ethereum Consortium Blockchain 后，输入一些配置选项，则可以开始部署该模拟网络，如下图所示。 20 | 21 | ![Azure 区块链配置](_images/azure_config.png) 22 | 23 | 部署过程需要几分钟时间。完成后，可进入资源组查看部署结果，如下图所示，成功部署了一个以太坊网络。 24 | 25 | ![Azure 区块链部署结果](_images/azure_deploy.png) 26 | 27 | 点击 microsoft-azure-blockchain 开头的链接，可以查看网络的一些关键接口，包括管理网址、RPC 接口地址等。 28 | 29 | 复制管理网址 ADMIN-SITE 的链接，用浏览器打开，可以进入区块链管理界面。界面中可查看网络各节点信息，也可以新建一个账户，并从 admin 账户向其发送 1000 个以太币。结果如下图所示。 30 | 31 | ![Azure 区块链管理界面](_images/azure_admin.png) 32 | 33 | Azure 云平台提供了相对简单的操作界面，更多的是希望用户通过 RPC 接口地址来访问所部署的区块链示例。用户可以自行通过 RPC 接口与以太坊模拟网络交互，部署和测试智能合约，此处不再赘述。 -------------------------------------------------------------------------------- /17_baas/bluemix.md: -------------------------------------------------------------------------------- 1 | ## IBM Bluemix 云区块链服务 2 | 3 | Bluemix 是 IBM 推出的开放的 PaaS 云平台，包含大量平台和软件服务，旨在帮助开发者实现一站式地应用开发与部署管理。 4 | 5 | 2016 年，Bluemix 面向开发者推出了基于超级账本 Fabric 的区块链服务，供全球的区块链爱好者使用。用户可以通过访问 https://console.ng.bluemix.net/catalog/services/blockchain 使用该服务。 6 | 7 | ### 服务介绍 8 | 9 | Bluemix 为用户提供了在云上灵活管理超级账本 Fabric 区块链网络的能力，让开发者专注于快速创建、操作和监控区块链网络，而无需过多考虑底层硬件资源。同时，Bluemix 云平台本身也提供了安全、隐私性方面的保障，并对相关资源进行了性能优化。 10 | 11 | Bluemix 目前提供了几种不同类型的区块链网络部署方案，包括免费的基础套餐到收费的高性能方案等。不同方案针对开发者的不同需求，在运行环境、占用资源、配置方式上都有所区别。 12 | 13 | 对于超级账本 Fabric 网络试用者，可选择免费的基础套餐，获得一个包含各类型 Peer 节点和 CA 的完整区块链试用网络，用户可以自行尝试部署链码并实时观察账本状态的变化。 14 | 15 | ### 使用服务 16 | 17 | Bluemix 云平台提供的仪表盘（Dashboard）提供了十分直观的管理方式，用户可以通过 Web 界面来获取和访问区块链资源。 18 | 19 | 如下图所示，用户创建网络后，可以进入 Dashboard 看到属于自己的区块链网络，同时观察各节点的状态，以及与身份认证相关的服务凭证。 20 | 21 | ![Bluemix 区块链服务仪表盘](_images/bluemix_dashboard.png) 22 | 23 | 对于已经申请到的区块链网络，用户可以通过 Dashboard 对其部署并调用链码，并实时查看响应结果。例如，下图中展示了部署自带的 example02 链码。 24 | 25 | ![通过 Dashboard 操作链码](_images/bluemix_chaincode.png) 26 | 27 | 对链码的操作会发送交易，进而生成新的区块。可通过 Dashboard 观察与区块链状态、区块内容相关的信息。例如，下图中区块链生成了 4 个区块，并执行了 1 次部署和 2 次调用。 28 | 29 | ![通过 Dashboard 观察区块链](_images/bluemix_blockchain.png) 30 | 31 | 平台同时会收集各节点的日志信息，监控和记录服务的运行状态。用户同样可以在 Dashboard 中实时查看。如下图所示，显示了服务和网络的正常运行时间等。 32 | 33 | ![通过 Dashboard 获取服务状态](_images/bluemix_status.png) 34 | 35 | 同时，Bluemix 云平台会将与区块链网络交互所需的 gRPC 或 HTTP 接口地址开放给用户，供用户通过 SDK 等进行远程操作，实现更多跟区块链、链码和应用相关的丰富功能。 -------------------------------------------------------------------------------- /17_baas/intro.md: -------------------------------------------------------------------------------- 1 | ## 简介 2 | 3 | 区块链即服务（Blockchain as a Service，BaaS），是部署在云计算基础设施之上，对外提供区块链网络的生命周期管理和运行时服务管理等功能的一套工具。 4 | 5 | 构建一套分布式的区块链方案绝非易事，既需要硬件基础设施的投入，也需要全方位的开发和运营管理（DevOps）。BaaS 作为一套工具，可以帮助开发者快速生成必要的区块链环境，进而验证所开发的上层应用。 6 | 7 | 除了区块链平台本身，一套完整的解决方案实际上还可以包括设备接入、访问控制、服务监控等管理功能。这些功能，让 BaaS 平台可以为开发者提供更强大的服务支持。 8 | 9 | 从 2016 年起，业界已有一些前沿技术团队发布了 BaaS 平台，除了商业的方案如 IBM Bluemix 和微软 Azure 云之外，超级账本开源项目也发起了 Cello 项目，以提供一套实现区块链平台运营管理功能的开源框架。 10 | 11 | ### 参考架构 12 | 13 | 下图给出了区块链即服务功能的参考架构，自上而下分为多层结构。最上层面向应用开发者和平台管理员提供不同的操作能力；核心层负责完成包括资源编排、系统监控、数据分析和权限管理等重要功能；下层可以通过多种类型的驱动和代理组件来访问和管理多种物理资源。 14 | 15 | ![区块链服务参考架构](_images/refarch.png) 16 | 17 | 18 | 典型地，BaaS 平台所提供的业务能力通常包括： 19 | 20 | * 用户按需申请区块链网络，以及所需的计算、存储与网络连接资源； 21 | * 用户对申请到的区块链进行生命周期管理，甚至支持灵活、弹性的区块链配置； 22 | * 通过提供接口，让用户自由访问所申请到的区块链网络并进行调用； 23 | * 提供直观的区块链可视化监控与操作界面，将区块链应用与底层平台无缝对接； 24 | * 提供简单易用的智能合约开发与测试环境，方便用户对应用代码进行管理； 25 | * 为管理员提供用户管理和资源管理操作； 26 | * 为管理员提供对系统各项健康状态的实时监控； 27 | * 提供对平台内各项资源和应用层的数据分析和响应能力。 28 | 29 | ### 考量指标 30 | 31 | 对于 BaaS 服务提供方，搭建这样一套功能完善、性能稳定的 BaaS 平台存在诸多挑战。可以从如下几个角度进行考量设计。 32 | 33 | * 性能保障：包括区块链和应用的响应速度，监控实时性等； 34 | * 可扩展性：支持大规模场景下部署和管理的能力，可以快速进行扩展； 35 | * 资源调度：对于非均匀的资源请求类型可以智能的予以平缓化处理，合理分配系统资源； 36 | * 安全性：注意平衡用户操作区块链的自由度与平台自身的安全可控； 37 | * 可感知性：深度感知数据行为，如可以准确实时评估区块链的运行状况，给用户启发； 38 | * 底层资源普适性：底层应当支持多种混合计算架构，容易导入物理资源。 39 | 40 | 此外，对于面向开发者的 BaaS 服务，创建的区块链环境应当尽量贴近实际应用场景，让用户可以将经过检验的区块链模型很容易地迁移到生产环境。甚至可以直接联动支持第三方发布平台，直接将经过验证的应用推向发布环境。 41 | -------------------------------------------------------------------------------- /17_baas/summary.md: -------------------------------------------------------------------------------- 1 | ## 本章小结 2 | 3 | 本章介绍了区块链即服务的概念，阐述了整合云计算技术能够为区块链部署和管理所带来的便捷。接下来提出了区块链服务平台的参考架构，并从功能和性能等实践角度总结了平台设计的考量指标。 4 | 5 | 本章随后还介绍了业界领先的 IBM Bluemix 和微软 Azure 云上提供的区块链服务。最后讲解了如何使用超级账本 Cello 项目快速搭建一套个性化的区块链服务平台。 6 | 7 | 区块链技术的普及离不开生态系统和相关工具的成熟，区块链应用的落地同样离不开完善的 DevOps 支持。本章的内容能够给予读者不同的视角，从系统方案的角度出发，思考如何在新技术变革中保持应对变化的敏捷与高效。 -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 区块链技术指南 2 | v1.6.4 3 | 4 | 区块链是金融科技（Fintech）领域的一项基础性的创新。 5 | 6 | 作为新一代分布式记账（Distributed Ledger Technology，DLT）系统的核心技术，区块链被认为在金融、物联网、商业贸易、征信、资产管理等众多领域都拥有广泛的应用前景。 7 | 8 | 区块链技术涉及分布式系统、密码学、博弈论、网络协议等诸多学科知识，为学习和实践都带来了不小的挑战。 9 | 10 | 本书希望能客观探索区块链概念的来龙去脉，剖析关键技术和原理，同时以全球最大的开源分布式账本项目——超级账本为例讲解具体应用。在开发超级账本项目，以及为企业设计方案过程中，笔者积累了一些实践经验，也通过本书分享出来，希望能有助于分布式账本科技的发展和应用。 11 | 12 | ## 阅读使用 13 | 本书适用于对区块链技术感兴趣，且具备一定金融科技基础的读者；无技术背景的读者也可以从中了解到区块链技术的现状。 14 | 15 | * [GitBook 在线阅读](https://yeasy.gitbook.io/blockchain_guide/)； 16 | * [GitHub 在线阅读](https://github.com/yeasy/blockchain_guide/blob/master/SUMMARY.md) 17 | 18 | ## 进阶学习 19 | ![区块链原理、设计与应用 第二版](_images/blockchain_book2.png) 20 | 21 | 《[区块链原理、设计与应用 第 2 版](https://item.jd.com/12159265.html)》 围绕超级账本 Fabric 2.x 最新版，详细介绍了区块链和分布式账本领域的核心技术，以及企业分布式账本方案的设计、架构和应用，欢迎大家阅读并反馈建议。本书已被译为多国语言发行，有意欢迎与作者联系。 22 | 23 | * [China-Pub](http://product.china-pub.com/8071482) 24 | * [京东图书](https://item.jd.com/12935394.html) 25 | * [当当图书](http://product.dangdang.com/28996031.html) 26 | 27 | 如果发现疏漏，欢迎提交到 [勘误表](https://github.com/yeasy/blockchain_guide/wiki/%E3%80%8A%E5%8C%BA%E5%9D%97%E9%93%BE%E5%8E%9F%E7%90%86%E3%80%81%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%BA%94%E7%94%A8%E3%80%8B2%E7%89%88%E5%8B%98%E8%AF%AF%E8%A1%A8)。 28 | 29 | ## 参与贡献 30 | 欢迎 [参与维护项目](contribute.md)。 31 | 32 | * [修订记录](revision.md) 33 | * [贡献者名单](https://github.com/yeasy/blockchain_guide/graphs/contributors) 34 | 35 | ## 支持鼓励 36 | 37 | 欢迎鼓励一杯 coffee~ 38 | 39 | ![coffee](_images/coffee.jpeg) 40 | 41 | ## 在线交流 42 | 43 | 欢迎大家加入区块链技术讨论群： 44 | 45 | * QQ 群 IV：364824846（可加） 46 | * QQ 群 III：414919574（已满） 47 | * QQ 群 II：523889325（已满） 48 | * QQ 群 I：335626996（已满） 49 | -------------------------------------------------------------------------------- /_code/unpack_chaincode.go: -------------------------------------------------------------------------------- 1 | // Usage: ./prog inputPkg outputPkg 2 | 3 | package main 4 | 5 | import ( 6 | "fmt" 7 | "github.com/golang/protobuf/proto" 8 | pb "github.com/hyperledger/fabric/protos/peer" 9 | "os" 10 | ) 11 | 12 | func check(msg string, e error) { 13 | if e != nil { 14 | fmt.Println(msg) 15 | panic(e) 16 | } 17 | } 18 | 19 | func main() { 20 | if len(os.Args) != 3 { 21 | fmt.Printf("Usage: %s inputPkg outputPkg\n", os.Args[0]) 22 | return 23 | } 24 | 25 | inputPkg := os.Args[1] 26 | outputPkg := os.Args[2] 27 | fmt.Printf("Input pkg=%s, output=%s\n", inputPkg, outputPkg) 28 | 29 | ccbytes, err := os.ReadFile(inputPkg) 30 | check("Read file failed", err) 31 | 32 | buf := ccbytes 33 | depSpec := &pb.ChaincodeDeploymentSpec{} 34 | err = proto.Unmarshal(buf, depSpec) 35 | check("Unmarshal depSpec failed", err) 36 | 37 | fmt.Printf("chaincodeSpec=%+v\n", depSpec.ChaincodeSpec) 38 | 39 | payload := depSpec.CodePackage 40 | err = os.WriteFile(outputPkg, payload, 0644) 41 | check("Write to file failed", err) 42 | } 43 | -------------------------------------------------------------------------------- /_images/blockchain_book.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/_images/blockchain_book.png -------------------------------------------------------------------------------- /_images/blockchain_book2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/_images/blockchain_book2.png -------------------------------------------------------------------------------- /_images/coffee.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/_images/coffee.jpeg -------------------------------------------------------------------------------- /_images/cover.sketch: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/_images/cover.sketch -------------------------------------------------------------------------------- /appendix/README.md: -------------------------------------------------------------------------------- 1 | # 附录 2 | -------------------------------------------------------------------------------- /appendix/companies.md: -------------------------------------------------------------------------------- 1 | ## 相关企业和组织 2 | 3 | 排名不分先后，大部分信息来自互联网，不保证信息准确性，如有修改意见，欢迎联系。 4 | 5 | ### 国际 6 | 7 | #### 企业 8 | * [IBM](https://www.ibm.com): 贡献区块链平台代码到 HyperLedger 项目，推动区块链产业发展，跟多家银行和企业进行区块链项目合作。 9 | * [DTCC]():贡献区块链代码到 HyperLedger 项目。 10 | * [Circle]()：基于区块链的支付应用公司，已获得 6000 万美元 D 轮投资，投资者包括 IDG、百度、中金甲子、广大投资等，目前年交易额超过 10 亿美金。 11 | * [Consensus]()：区块链创业团队，试图打造区块链平台技术和应用支撑，获得多家投资。 12 | 13 | #### 组织 14 | * [R3 CEV](https://r3cev.com)：创立于 2015 年 9 月，总部位于纽约的金融联盟组织，专注于研究和评估基于区块链的金融技术解决方案，由 40 多家国际金融机构组成，包括 Citi、BOA、高盛、摩根、瑞银、IBM、微软等。R3 开源技术已经 [宣布](www.newsbtc.com/2016/10/22/r3-corda-hyperledger-open-source/) 加入 HyperLedger 项目。 15 | * [HyperLedger 社区]（https://hyperledger.org）：创立于 2015 年 12 月的技术社区，由 Linux 基金会管理，包括 IBM、Accenture、Intel、J.P.Morgan、R3、DAH、DTCC、FUJITSU、HITACHI、SWIFT、Cisco 等多家企业参与成立，试图打造面向企业应用场景的分布式账本平台。 16 | * [Ethereum 社区](https://ethereum.org): 围绕以太坊区块链平台的开放社区。 17 | * [DAO]()： Distributed Autonomous Organization，基于以太坊平台的公募基金(众筹)组织，或去中心化的风投。众筹资金超过 1.6 亿美金。 18 | 19 | 20 | ### 国内 21 | 22 | #### 学术界 23 | 24 | * 清华大学 25 | * 中科院 26 | * 上海交通大学 27 | 28 | #### 企业 29 | 30 | * [中国电信]()：研究区块链相关技术，包括去中心化共享经济平台等。 31 | * [世纪互联]()：投资区块链技术团队，牵头成立“中关村区块链产业联盟”。 32 | * [银联]()：关注区块链相关技术，尝试引入基于区块链的银行业积分系统。 33 | * [能链]()：专注于能源产品相关的区块链应用。 34 | * [恒生电子]()：2016 年牵头成立“金链盟”，希望通过区块链技术为金融行业提供更简单的产品。 35 | * [布比](https://bubi.cn)：主要关注数字资产管理的技术型创业企业，区块链相关平台和产品。 36 | * [小蚁]()：主要关注对资产和权益进行数字化，2014年于上海组建成立。 37 | * [火币]()：国内较大的比特币交易代理平台。 38 | * [BeLink]()：关注保险行业积分系统，主要产品为数贝荷包。 39 | * [BitSe]()：主要产品为唯链（Vechain），面向物品防伪追踪、数字版权管理相关。 40 | * [万向集团]()：投资多家区块链创业团队，致力于推动产业发展。 41 | 42 | #### 组织 43 | 44 | * 中关村区块链产业联盟：2016 年 2 月 3 日成立于北京，由世纪互联联合清华大学、北京邮电大学等高校、中国通信学会、中国联通研究院等运营商，及集佳、布比网络等公司发起； 45 | * ChinaLedger：2016 年 4 月成立于上海，成员包括中证机构间报价系统股份有限公司、中钞信用卡产业发展有限公司北京智能卡技术研究院、万向区块链实验室、浙江股权交易中心、深圳招银前海金融资产交易中心、厦门国际金融资产交易中心、大连飞创信息技术有限公司、通联支付网络服务股份有限公司、上海矩真金融信息服务有限公司、深圳瀚德创客金融投资有限公司、乐视金融等； 46 | * 金融区块链合作联盟（金链盟）：2016 年 5 月 31 日成立于深圳，包括平安银行、恒生电子、京东金融、腾讯微众银行、华为、南方基金、国信证券、安信证券、招商证券、博时基金等 25 家公司与机构。 47 | -------------------------------------------------------------------------------- /appendix/faq.md: -------------------------------------------------------------------------------- 1 | ## 常见问题 2 | 3 | ### 通用问题 4 | ** 问：区块链是谁发明的，有什么特点？** 5 | 6 | 答：区块链相关的思想最早由比特币的发明者-中本聪（化名）在白皮书中提出，将其作为比特币网络的核心支持技术。自那以后，区块链技术逐渐脱离比特币项目，成为一种通用的可以支持分布式记账能力的底层技术，具有非中心化和加密安全等特点。 7 | 8 | ** 问：区块链和比特币是什么关系？** 9 | 10 | 答：比特币是基于区块链技术的一种数字现金（cash）应用；区块链技术最早在比特币网络中得到应用和验证。比特币系统在 2009 年上线后面向全球提供服务，在无中心化管理的情况下运转至今。 11 | 12 | ** 问：区块链和分布式数据库是什么关系？** 13 | 14 | 答：两者定位完全不同。分布式数据库是解决高可用和可扩展场景下的数据管理问题；区块链则是在多方（无须中心化中介角色存在）之间提供一套可信的记账和合约履行机制。可见，两者完全可以配合使用。 15 | 16 | ** 问：区块链有哪些种类？** 17 | 18 | 答：根据部署场景公开程度，可以分为公有链（Public Chain）、联盟链（Consortium Chain）和私有链（Private Chain）；从功能上看，可以分为以支持数字货币为主的数字货币区块链（如比特币网络）、支持智能合约的通用区块链（如以太坊网络）、面向复杂商业应用场景的分布式账本平台（如超级账本）。 19 | 20 | ** 问：区块链是如何保证没有人作恶的？ ** 21 | 22 | 答：恰恰相反，区块链并没有试图保证每一个人都不作恶。以比特币区块链为例，通过经济博弈手段来容忍部分参与者作恶。参与者默认在最长的链（唯一合法链）上进行扩展。当作恶者尝试延续一个非法链的时候，实际上在跟所有的合作者们进行投票竞争。因此，当作恶者占比不高（如不超过一半）时，概率意义上无法造成破坏。而作恶代价是所付出的资源（例如算力）都将浪费掉。 23 | 24 | ** 问：区块链的智能合约应该怎么设计？** 25 | 26 | 答：智能合约也是一种应用程序，在架构上即可以采取单体（monolithic）的方式（一个合约针对一个具体商业应用，功能完善而复杂），也可以采取微服务（microservice）的方式（每个合约功能单一，多个合约可相互调用共同构建应用）。 选择哪种模式根本上取决于其上商业应用的特点。从灵活性角度，推荐适当对应用代码进行切分，划分到若干个智能合约，尽量保持智能合约的可复用性。 27 | 28 | ** 问：如何查看 PEM 格式证书内容？** 29 | 30 | 答：可以通过如下命令转换证书内容进行输出：`openssl x509 -noout -text -in `；例外，还可以通过如下命令来快速从证书文件中提取所证明的公钥内容：`openssl x509 -noout -pubkey -in `。 31 | 32 | ** 问：已知私钥，如何生成公钥？** 33 | 34 | 答：取决于加密算法。对于椭圆曲线加密算法，可以通过如下命令生成公钥：`openssl ec -pubout -outform PEM -in `。 35 | 36 | ** 问：如何校验某证书是否被根证书签名？** 37 | 38 | 答：已知根证书文件 和待验证证书文件 情况下，可以使用如下命令进行验证：`openssl verify -CAfile `。 39 | 40 | ** 问：为何 Hash 函数将任意长的文本映射到定长的摘要，很少会发生冲突？** 41 | 42 | 答：像 SHA-1 这样的 Hash 函数可以将任意长的文本映射到相对很短的定长摘要。从理论上讲，从大的集合映射到小的集合上必然会出现冲突。Hash 函数之所以很少出现冲突的原因在于虽然输入的数据长度可以很大，但其实人类产生的数据并非全空间的，这些数据往往是相对有序（低熵值）的，实际上也是一个相对较小的集合。 43 | 44 | ### 比特币、以太坊相关 45 | 46 | ** 问：比特币区块链为何要设计为每 10 分钟才出来一个块，快一些不可以吗？** 47 | 48 | 答：这个主要是从公平的角度，当某一个新块被计算出来后，需要在全球比特币网络内公布。临近的矿工将最先拿到消息并开始新一轮的计算，较远的矿工则较晚得到通知。最坏情况下，可能造成数十秒的延迟。为尽量确保矿工们都处在同一起跑线上，这个时间不能太短。但出块时间太长又会导致交易的“最终”确认时间过长。目前看，10 分钟左右是一个相对合适的折中。另外，也是从存储代价的角度，让拥有不太大存储的普通节点可以参与到网络的维护。 49 | 50 | ** 问：比特币区块链每个区块大小为何是 1 MB，大一些不可以吗？** 51 | 52 | 答：这个也是折中的结果。区块产生的平均时间间隔是固定的 10 分钟，大一些，意味着发生交易的吞吐量可以增加，但节点进行验证的成本会提高（Hash 处理约为 100 MB/s），同时存储整个区块链的成本会快速上升。区块大小为 1 MB，意味着每秒可以记录 `1 MB/(10*60)=1.7 KB` 的交易数据，而一般的交易数据大小在 `0.2 ~ 1 KB`。 53 | 54 | 实际上，之前比特币社区也曾多次讨论过改变区块大小的提案，但都未被最终接受。部分激进的设计者采取了分叉的手段。 55 | 56 | ** 问：以太坊网络跟比特币网络有何关系？ ** 57 | 58 | 答：以太坊网络所采用的区块链结构，源于比特币网络，基于同样设计原理。此外，以太坊提出了许多改善设计，包括支持更灵活的智能合约、支持除了 PoW 之外的更多共识机制（尚未实现）等。 59 | 60 | ### 超级账本项目 61 | 62 | ** 问：超级账本项目与传统公有区块链有何不同？** 63 | 64 | 答：超级账本是目前全球最大的联盟链开源项目。在联盟场景下，参与多方可以容易达成一定的信任前提。另外，企业十分看重对接入账本各方的权限管理、审计功能、传输数据的安全可靠等特性。超级账本在考虑了商业网络的这些复杂需求后，提出了创新的架构和设计，成为首个在企业应用场景中得到大规模部署和验证的开源项目。 65 | 66 | ** 问：区块链最早是公有链形式，为何现在联盟链在很多场景下得到更多应用？** 67 | 68 | 答：区块链技术出现以前，人们往往通过中心化的信任机制来实现协作，但一旦中心机制出现故障，则无法进行。区块链技术可以提供无中介化情况下的信任保障。公有链情况下，任何人都可以参与监督，可以实现信任的最大化，但随之而来带来包括性能低下、可扩展性差等问题，特别扩大到互联网尺度时存在许多目前很难解决的技术难题。 69 | 70 | 联盟链在两者之间取得了平衡。多方共识模型中，系统整体可信任度随规模以指数增加；同时，联盟的信任前提，可以选用更高性能的共识机制，并支持权限管理。这些对企业场景来说都是迫切的需求。 71 | 72 | ** 问：采用 BFT 类共识算法时，节点掉线后重新加入网络，出现无法同步情况？** 73 | 74 | 答：这是某些算法设计导致的情况。掉线后的节点重新加入到网络中，其视图（View）会领先于其它节点。其它节点正常情况下不会发生视图的变更，发生的交易和区块内容不会同步到掉线节点。出现这种情况，可以有两种解决方案：一个是强迫其它节点出现视图变更，例如也发生掉线或者在一段时间内强制变更；另一种情况是等待再次产生足够多的区块后触发状态追赶。 75 | 76 | ** 问：超级账本 Fabric 里的安全性和隐私性是如何保证的？** 77 | 78 | 答：首先，Fabric 1.0 及往后的版本提供了对多通道的支持，不同通道之间的链码和交易是不可见的，即交易只会发送到该通道内的 Peer 节点。此外，在进行背书阶段，客户端可以根据背书策略来选择性的发送交易到通道内的某些特定 Peer 节点。更进一步的，用户可以对交易的内容进行加密（基于证书的权限管理）或使用私密数据，同时，只有得到授权的节点或用户才能访问到私密数据。另外，排序节点无须访问到交易内容，因此，可以选择不将完整交易（对交易输入数据进行隐藏，或者干脆进行加密或 Hash 处理）发送到排序节点。最后，所有数据在传输过程中可以通过 TLS 来进行安全保护。许多层级的保护需要配合使用来获得不同层级的安全性。 79 | 80 | 实践过程中，也需要对节点自身进行安全保护，通过防火墙、IDS 等防护对节点自身的攻击；另外可以通过审计和分析系统对可疑行为进行探测和响应。 81 | -------------------------------------------------------------------------------- /appendix/golang/README.md: -------------------------------------------------------------------------------- 1 | ## Go 语言开发相关 2 | 3 | Go 是一门年轻的语言。它在设计上借鉴了传统 C 语言的高性能特性，以及多种现代系统语言的优点，被认为是具有很大潜力的系统开发语言。要使用好 Go 语言，首先要掌握好相关的开发工具。 4 | 5 | 这里介绍如何快速安装和配置 Go 语言环境、选用合适的编辑器和 IDE，以及如何配合使用 Go 的配套开发工具来提高开发效率。 -------------------------------------------------------------------------------- /appendix/golang/_images/pprof.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/appendix/golang/_images/pprof.png -------------------------------------------------------------------------------- /appendix/golang/ide.md: -------------------------------------------------------------------------------- 1 | ### 编辑器与 IDE 2 | 3 | 使用传统编辑器如 VIM，可以安装相应的 Golang 支持插件，如 [vim-go](https://github.com/fatih/vim-go)。 4 | 5 | 目前支持 Go 语言的 IDE（Integrated Development Environment） 还不是特别丰富。推荐使用 Jet Brains 出品的 Goland 或微软开发的 Visual Studio Code。 6 | 7 | Goland 是专门针对 Go 语言设计的 IDE，在代码的补全、分析等方面性能更优越。可以从 [https://www.jetbrains.com/go/](https://www.jetbrains.com/go/) 下载获取。 8 | 9 | Visual Studio Code 是一个通用的 IDE，可以通过安装支持 Go 的插件来进行开发。下载地址为 https://code.visualstudio.com/download。 10 | 11 | 此外，简单的代码逻辑验证也可以通过官方的在线 Playground 平台，地址为 https://play.golang.org/。 -------------------------------------------------------------------------------- /appendix/golang/install.md: -------------------------------------------------------------------------------- 1 | ### 安装与配置 Golang 环境 2 | 3 | Go 语言环境安装十分简单，可以通过包管理器或自行下载方式进行，为了使用最新版本的 Go 环境，推荐大家通过下载环境包方式进行安装。 4 | 5 | 首先，从 [https://golang.org/dl/](https://golang.org/dl/) 页面查看最新的软件包，并根据自己的平台进行下载，例如 Linux 环境下，目前最新的环境包为 [https://storage.googleapis.com/golang/go1.13.linux-amd64.tar.gz](https://storage.googleapis.com/golang/go1.13.linux-amd64.tar.gz)。 6 | 7 | 下载后，直接进行环境包的解压，存放到默认的 `/usr/local/go` 目录（否则需要配置 $GOROOT 环境变量指向自定义位置）下。 8 | 9 | ```bash 10 | $ sudo tar -C /usr/local -xzf go1.13.linux-amd64.tar.gz 11 | ``` 12 | 13 | 此时，查看 `/usr/local/go` 路径下，可能看到如下几个子目录。 14 | 15 | * api：Go API 检查器的辅助文件，记录了各个版本的 API 特性。 16 | * bin：Go 语言相关的工具的二进制命令。 17 | * doc：存放文档。 18 | * lib：一些第三方库。 19 | * misc：编辑器和开发环境的支持插件。 20 | * pkg：存放不同平台的标准库的归档文件（.a 文件）。 21 | * src：所有实现的源码。 22 | * test：存放测试文件。 23 | 24 | 安装完毕后，可以添加 Go 工具命令所在路径到系统路径，方便后面使用。创建 `$GOPATH` 环境变量，指向某个本地创建好的目录（如 $HOME/Go），作为后面 Go 项目的存放目录。如果使用 Go 模块模式，则无需进行这些配置。 25 | 26 | 添加如下环境变量到用户启动配置（如 `$HOME/.bashrc`）中。 27 | 28 | ```sh 29 | export PATH=$PATH:/usr/local/go/bin 30 | export GOPATH=$HOME/Go 31 | ``` 32 | 33 | 其它更多平台下安装，可以参考 [https://golang.org/doc/install](https://golang.org/doc/install)。 34 | -------------------------------------------------------------------------------- /appendix/golang/package.md: -------------------------------------------------------------------------------- 1 | ### 依赖管理 2 | 3 | #### govendor 工具 4 | 5 | 长期以来，Go 语言对外部依赖都没有很好的管理方式，只能从 `$GOPATH` 下查找依赖。这就造成不同用户在安装同一个项目时可能从外部获取到不同的依赖库版本，同时当无法联网时，无法编译依赖缺失的项目。 6 | 7 | Golang 自 1.5 版本开始重视第三方依赖的管理，将项目依赖的外部包统一放到 vendor 目录下（类比 Nodejs 的 node_modules 目录），并通过 vendor.json 文件来记录依赖包的版本，方便用户使用相对稳定的依赖。 8 | 9 | Daniel Theophanes 等人开发了 govendor 工具，方便对第三方依赖进行管理。 10 | 11 | govendor 的安装十分简单，可以通过 go get 命令： 12 | 13 | ```bash 14 | $ go get -u -v github.com/kardianos/govendor 15 | ``` 16 | 17 | 对于 govendor 来说，主要存在三种位置的包：项目自身的包组织为本地（local）包；传统的存放在 $GOPATH 下的依赖包为外部（external）依赖包；被 govendor 管理的放在 vendor 目录下的依赖包则为 vendor 包。 18 | 19 | 具体来看，这些包可能的类型如下： 20 | 21 | 状态 | 缩写状态 | 含义 22 | --- | ------- | --- 23 | +local | l | 本地包，即项目自身的包组织 24 | +external | e | 外部包，即被 $GOPATH 管理，但不在 vendor 目录下 25 | +vendor | v | 已被 govendor 管理，即在 vendor 目录下 26 | +std | s | 标准库中的包 27 | +unused | u | 未使用的包，即包在 vendor 目录下，但项目并没有用到 28 | +missing | m | 代码引用了依赖包，但该包并没有找到 29 | +program | p | 主程序包，意味着可以编译为执行文件 30 | +outside | | 外部包和缺失的包 31 | +all | | 所有的包 32 | 33 | 常见的命令如下，格式为 `govendor COMMAND`。 34 | 35 | 通过指定包类型，可以过滤仅对指定包进行操作。 36 | 37 | 命令 | 功能 38 | -- | --- 39 | `init` | 初始化 vendor 目录 40 | `list` | 列出所有的依赖包 41 | `add` | 添加包到 vendor 目录，如 govendor add +external 添加所有外部包 42 | `add PKG_PATH` | 添加指定的依赖包到 vendor 目录 43 | `update` | 从 $GOPATH 更新依赖包到 vendor 目录 44 | `remove` | 从 vendor 管理中删除依赖 45 | `status` | 列出所有缺失、过期和修改过的包 46 | `fetch` | 添加或更新包到本地 vendor 目录 47 | `sync` | 本地存在 vendor.json 时候拉去依赖包，匹配所记录的版本 48 | `get` | 类似 `go get` 目录，拉取依赖包到 vendor 目录 49 | 50 | #### dep 工具 51 | 52 | 为了方便管理依赖，Go 团队 2016 年 4 月开始开发了 dep 工具，试图进一步简化在 Go 项目中对第三方依赖的管理。该工具目前已经被试验性支持，相信很快会成为官方支持的工具。 53 | 54 | dep 目前需要 Go 1.7+ 版本，兼容其他依赖管理工具如 glide、godep、vndr、govend、gb、gvt、govendor、glock 等。 55 | 56 | 类似于 govendor 工具，dep 将依赖都放在本地的 vendor 目录下，通过 Gopkg.toml 和 Gopkg.lock 文件来追踪依赖的状态。 57 | 58 | * Gopkg.toml 文件：手动编写或通过 dep init 命令生成。描述了项目对第三库的依赖规则，例如允许的版本范围等。用户可以通过编辑该文件表达预期的依赖控制目标。 59 | * Gopkg.lock 文件：通过 dep init 或 dep ensure 命令自动生成。根据项目代码和 Gopkg.toml 文件，计算出一个符合要求的具体的依赖关系并锁定，其中包括每个第三方库的具体版本。vendor 目录下的依赖库需要匹配这些版本。 60 | 61 | 安装可以通过 go get 命令： 62 | 63 | ```bash 64 | $ go get -v -u github.com/golang/dep/cmd/dep 65 | ``` 66 | 67 | dep 使用保持简洁的原则，包括四个子命令。 68 | 69 | * init：对一个新的 Go 项目，初始化依赖管理，生成配置文件和 vendor 目录等； 70 | * status：查看当前项目依赖的状态，包括依赖包名称、限制范围、指定版本等。可以通过 -old 参数来只显示过期的依赖； 71 | * ensure：更新依赖，确保满足指定的版本条件。如果本地缺乏某个依赖，会自动安装； 72 | * version：显示 dep 工具的版本信息。 73 | 74 | 其中，ensure 命令最为常用，支持的子命令参数主要包括： 75 | 76 | * -add：添加新的依赖，如 dep ensure -add github.com/pkg/foo@^1.0.0； 77 | * -dry-run：模拟执行，打印参考改动但不实施； 78 | * -no-vendor：根据计算结果更新 Gopkg.lock 文件，但不更新 vendor 中依赖包； 79 | * -update：更新 Gopkg.lock 中的依赖到 Gopkg.toml 中允许的最新版本，默认同时更新 vendor 包中内容； 80 | * -v：输出调试信息方面了解执行过程； 81 | * -vendor-only：按照 Gopkg.lock 中条件更新 vendor 包中内容。 82 | 83 | #### go module 84 | 85 | Go 自 1.11 版本开始引入模块（module），在 1.13 版本中开始正式支持，以取代传统基于 $GOPATH 的方案。模块作为若干个包（package）的集合，带有语义化版本号，统一管理所有依赖。所有依赖模块缓存在 $GOPATH/pkg 目录下的 `mod` 和 `sum` 子目录中，未来计划迁移到 `$GOCACHE` 目录下。另外，不同项目的相同依赖模块全局只会保存一份，极大节约了存储空间。 86 | 87 | 模块需要两个配置文件，go.mod 和 go.sum。 88 | 89 | 前者管理项目中模块的依赖信息，可以通过 go mod init 命令生成；后者记录当前项目直接或间接依赖的所有模块的路径、版本、校验值等。 90 | 91 | 项目模块可以通过 go mod 子命令来显式操作，也会在编译、测试等命令中被隐式更新。 92 | 93 | go mod 支持的子命令包括： 94 | 95 | * download：下载依赖模块到本地的缓存； 96 | * edit：编辑 go.mod 文件； 97 | * graph：查看当前的依赖结构； 98 | * init：初始化，创建 go.mod 文件； 99 | * tidy：整理依赖模块：添加新模块，并删除未使用模块； 100 | * vendor：将依赖模块复制到本地的 vendor 目录，方便兼容原来的 vendor 方式（该命令未来会遗弃）； 101 | * verify：校验当前依赖是否正确，未被篡改； 102 | * why：解释为何需要某个依赖包。 103 | 104 | 基本使用过程为： 105 | 106 | * 使用 `go mod init ` 来初始化本地的 go.mod 文件； 107 | * 使用 `go get -u @` 来获取某个依赖包（不添加版本号会默认获取当前最新），同时自动更新 go.mod 文件。更新全部模块可以使用 `go get -u all`； 108 | * 编译时使用 `go build -mod=readonly` 可以避免在编译过程中修改 go.mod； 109 | * 如果要使用本地的 vendor 目录进行编译，可以使用 `go build -mod=vendor`； 110 | * 如果要检查可更新的依赖，可以使用 `go list -m -u all`。如果要执行更新，可以使用 `go get -u`； 111 | * 此外，执行 `go` 相关命令（build、get、list、test 等）时，也会自动下载依赖并更新 go.mod 文件。 112 | 113 | module 的开启可以通过 GO111MODULE=[auto|on|off] 等环境变量来控制。例如始终使用 go module，可以使用如下命令 114 | 115 | ```bash 116 | $ go env -w GO111MODULE=on # 记录到 os.UserConfigDir 指定路径（默认为 $HOME/.config/go/）下的 env 文件中 117 | ``` 118 | 119 | 此外，1.13 版本起，Go 还支持 GOPROXY 环境变量来指定拉取包的代理服务，GOPRIVATE 指定私有仓库地址。 120 | -------------------------------------------------------------------------------- /appendix/resources.md: -------------------------------------------------------------------------------- 1 | ## 参考资源链接 2 | 3 | ### 论文 4 | 5 | * L. Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System,” Commun. ACM, vol. 21, no. 7, pp. 558–565, 1978. 6 | * M Pease, R Shostak, L Lamport. Reaching Agreement in the Presence of Faults. Journal of the ACM, 1980, 27(2): 228-234. 7 | * M. J. Fischer, N. A. Lynch, and M. S. Paterson, “Impossibility of Distributed Consensus with One Faulty Process,” J. ACM, vol. 32, no. 2, pp. 374–382, 1985. 8 | * L. Lamport, “The Part-Time Parliament,” ACM Trans. Comput. Sys-tems, vol. 16, no. 2, pp. 133–169, 1998. 9 | * M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” Proc. Symp. Oper. Syst. Des. Implement., no. February, pp. 1–14, 1999. 10 | * Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", https://bitcoin.org/bitcoin.pdf，2008. 11 | A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Timón, and P. Wuille, “Enabling Blockchain Innovations with Pegged Sidechains,” pp. 1–25, 2014. 12 | * T. D. Joseph Poon, “The Bitcoin Lightning Network: Scalable Off-Chain Payments, http://lightning.network/lightning-network-paper.pdf,” pp. 1–59, 2016. 13 | * Gentry C., Halevi S.，"Implementing Gentry’s Fully-Homomorphic Encryption Scheme". In: Paterson K.G. (eds) Advances in Cryptology – EUROCRYPT 2011. EUROCRYPT 2011. Lecture Notes in Computer Science, vol 6632. Springer, Berlin, Heidelberg. 14 | * van Dijk M., Gentry C., Halevi S., Vaikuntanathan V., "Fully Homomorphic Encryption over the Integers". In: Gilbert H. (eds) Advances in Cryptology – EUROCRYPT 2010. EUROCRYPT 2010. Lecture Notes in Computer Science, vol 6110. Springer, Berlin, Heidelberg. 15 | * López-Alt, Adriana, Eran Tromer, and Vinod Vaikuntanathan. "On-the-Fly Multiparty Computation on the Cloud via Multikey Fully Homomorphic Encryption.". Proceeding STOC '12 Proceedings of the forty-fourth annual ACM symposium on Theory of computing, Pages 1219-1234. 16 | * I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: Anonymous distributed e-cash from bitcoin,” Proc. - IEEE Symp. Secur. Priv., pp. 397–411, 2013. 17 | * F. Reid and M. Harrigan, “An analysis of anonymity in the bitcoin system,” Secur. Priv. Soc. Networks, pp. 197–223, 2013. 18 | * K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier, N. Kobeissi, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Zanella-Béguelin, “Formal Verification of Smart Contracts,” 2016. 19 | * Y. Sompolinsky and A. Zohar, “Secure high-rate transaction processing in bitcoin,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics), vol. 8975, pp. 507–527, 2015. 20 | * C. Li, P. Li, D. Zhou, W. Xu, F. Long, and A. Yao, “Scaling Nakamoto Consensus to Thousands of Transactions per Second,” 2018. 21 | 22 | ### 开源项目 23 | 24 | * 比特币项目：https://bitcoin.org/。 25 | * [blockchain.info](https://blockchain.info)：比特币信息统计网站。 26 | * [bitcoin.it](https://en.bitcoin.it)：比特币 wiki，相关知识介绍。 27 | * 以太坊项目：https://www.ethereum.org。 28 | * 以太坊网络的状态统计：https://etherchain.org/ 29 | * 超级账本项目：[https://hyperledger.org](https://hyperledger.org); 30 | * 超级账本 Docker 镜像：[https://hub.docker.com/r/hyperledger/](https://hub.docker.com/r/hyperledger/)。 31 | 32 | ### 培训课程 33 | 34 | * [Bitcoin and Cryptocurrency Technologies](https://www.coursera.org/course/bitcointech)：https://www.coursera.org/course/bitcointech, Princeton University； 35 | * Blockchain: Understanding Its Uses and Implications：https://www.edx.org/course/understanding-blockchain-and-its-implications, Linux Foundation。 36 | 37 | ### 区块链服务平台 38 | * [IBM Blockchain](https://www.ibm.com/blockchain)：https://www.ibm.com/blockchain； 39 | * [Oracle Blockchain Platform](https://www.oracle.com/cloud/blockchain/)：https://www.oracle.com/cloud/blockchain； 40 | * [腾讯云区块链](https://cloud.tencent.com/product/tbaas)：https://cloud.tencent.com/product/tbaas； 41 | * [阿里云区块链](https://www.aliyun.com/product/baas)：https://www.aliyun.com/product/baas； 42 | * [百度云区块链](https://cloud.baidu.com/solution/blockchain.html)：https://cloud.baidu.com/solution/blockchain.html； 43 | * [纸贵科技区块链](https://baas.zhigui.com)：https://baas.zhigui.com。 44 | -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "区块链技术指南", 3 | "author": "yeasy", 4 | "plugins": [ 5 | "-autocover", 6 | "-github-buttons", 7 | "image-captions", 8 | "-latex-codecogs", 9 | "-mathjax", 10 | "prism", 11 | "prism-themes", 12 | "-highlight", 13 | "sharing" 14 | ], 15 | "pluginsConfig": { 16 | "image-captions": { 17 | "attributes": { "width": "600" }, 18 | "caption": "图 _PAGE_LEVEL_._PAGE_IMAGE_NUMBER_ - _CAPTION_" 19 | } 20 | } 21 | } 22 | -------------------------------------------------------------------------------- /contribute.md: -------------------------------------------------------------------------------- 1 | ## 参与贡献 2 | 贡献者 [名单](https://github.com/yeasy/blockchain_guide/graphs/contributors)。 3 | 4 | 区块链技术自身仍在快速发展中，生态环境也在蓬勃成长。 5 | 6 | 本书源码开源托管在 Github 上，欢迎参与维护：[github.com/yeasy/blockchain_guide](https://github.com/yeasy/blockchain_guide)。 7 | 8 | 首先，在 GitHub 上 `fork` 到自己的仓库，如 `docker_user/blockchain_guide`，然后 `clone` 到本地，并设置用户信息。 9 | 10 | ```sh 11 | $ git clone git@github.com:docker_user/blockchain_guide.git 12 | $ cd blockchain_guide 13 | $ git config user.name "yourname" 14 | $ git config user.email "your email" 15 | ``` 16 | 17 | 更新内容后提交，并推送到自己的仓库。 18 | 19 | ```sh 20 | $ #do some change on the content 21 | $ git commit -am "Fix issue #1: change helo to hello" 22 | $ git push 23 | ``` 24 | 25 | 最后，在 GitHub 网站上提交 pull request 即可。 26 | 27 | 另外，建议定期使用项目仓库内容更新自己仓库内容。 28 | ```sh 29 | $ git remote add upstream https://github.com/yeasy/blockchain_guide 30 | $ git fetch upstream 31 | $ git checkout master 32 | $ git rebase upstream/master 33 | $ git push -f origin master 34 | ``` 35 | 36 | -------------------------------------------------------------------------------- /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/yeasy/blockchain_guide/3a3c06b7285dd4dc1393d70f978e1087711f11cf/cover.jpg -------------------------------------------------------------------------------- /evaluation/README.md: -------------------------------------------------------------------------------- 1 | # 性能与评测 2 | 3 | **过早优化，往往引来各种麻烦。** 4 | 5 | 一项技术究竟能否实用，有两项基本指标十分关键：一是功能的完备；一是性能的达标。 6 | 7 | 本章将试图对已有区块链技术进行一些评测。所有结果将尽可能保证客观准确，但不保证评测方法是否科学、评测结果是否具备足够参考性。 -------------------------------------------------------------------------------- /evaluation/hyperledger.md: -------------------------------------------------------------------------------- 1 | ## Hyperledger Fabric v0.6 性能评测 2 | 3 | ### 环境配置 4 | | 类型 | 操作系统 | 内核版本 | CPU(GHz) | 内存(GB) | 5 | | :--: | :-------------: | :-----: | :------: | :-----: | 6 | | 物理机 | Ubuntu 14.04.1 | 3.16.0-71-generic | 4x2.0 | 8 | 7 | 8 | 每个集群启动后等待 10s 以上，待状态稳定。 9 | 10 | 仅测试单客户端、单服务端的连接性能情况。 11 | 12 | ### 评测指标 13 | 14 | 一般评测系统性能指标包括吞吐量（throughput）和延迟（latency）。对于区块链平台系统来说，实际交易延迟包括客户端到系统延迟（往往经过互联网），再加上系统处理反馈延迟（跟不同 consensus 算法关系很大，跟集群之间互联系统关系也很大）。 15 | 16 | 本次测试仅给出大家最为关注的交易吞吐量（tps）。 17 | 18 | ### 结果 19 | 20 | #### query 交易 21 | 22 | ##### noops 23 | | clients | VP Nodes | iteration | tps | 24 | | -------- | ------- | --------- | ------ | 25 | | 1 | 1 | 2000 | 195.50 | 26 | | 1 | 4 | 2000 | 187.09 | 27 | 28 | ##### pbft:classic 29 | | clients | VP Nodes | iteration | tps | 30 | | -------- | ------- | --------- | ------ | 31 | | 1 | 4 | 2000 | 193.05 | 32 | 33 | ##### pbft:batch 34 | | clients | VP Nodes | batch size | iteration | tps | 35 | | -------- | ------- | -------- | ---------- | ------ | 36 | | 1 | 4 | 2 | 2000 | 193.99 | 37 | | 1 | 4 | 4 | 2000 | 192.49 | 38 | | 1 | 4 | 8 | 2000 | 192.68 | 39 | 40 | ##### pbft:sieve 41 | | clients | VP Nodes | iteration | tps | 42 | | -------- | ------- | --------- | ------ | 43 | | 1 | 4 | 2000 | 192.86 | 44 | 45 | #### invoke 交易 46 | 47 | ##### noops 48 | 49 | | clients | VP Nodes | iteration | tps | 50 | | -------- | ------- | --------- | ------ | 51 | | 1 | 1 | 2000 | 298.51 | 52 | | 1 | 4 | 2000 | 205.76 | 53 | 54 | ##### pbft:classic 55 | | clients | VP Nodes | iteration | tps | 56 | | -------- | ------- | --------- | ------ | 57 | | 1 | 4 | 2000 | 141.34 | 58 | 59 | 60 | ##### pbft:batch 61 | | clients | VP Nodes | batch size | iteration | tps | 62 | | -------- | ------- | --------- | --------- | ------ | 63 | | 1 | 4 | 2 | 2000 | 214.36 | 64 | | 1 | 4 | 4 | 2000 | 227.53 | 65 | | 1 | 4 | 8 | 2000 | 237.81 | 66 | 67 | 68 | ##### pbft:sieve 69 | | clients | VP Nodes | iteration | tps | 70 | | -------- | ------- | --------- | ------ | 71 | | 1 | 4 | 2000 | 253.49* | 72 | 73 | *注：sieve 算法目前在所有交易完成后较长时间内并没有取得最终的结果，出现大量类似“vp0_1 | 07:49:26.388 [consensus/obcpbft] main -> WARN 23348 Sieve replica 0 custody expired, complaining: 3kwyMkdCSL4rbajn65v+iYWyJ5aqagXvRR9QU8qezpAZXY4y6uy2MB31SGaAiaSyPMM77TYADdBmAaZveM38zA==”警告信息。* 74 | 75 | ### 结论 76 | 单客户端连接情况下，tps 基本在 190 ~ 300 范围内。 -------------------------------------------------------------------------------- /evaluation/intro.md: -------------------------------------------------------------------------------- 1 | ## 简介 2 | 3 | 区块链的平台性能跟很多因素都有关系，特别在实际应用中，根据应用场景的不同和系统设计和使用的不同，可能同一套平台最终在业务体现上会有较大差异。 4 | 5 | 在这里，仅侧重评测一般意义上的平台性能。 6 | 7 | 所有给出指标和结果仅供参考，由于评测环境和方案不同，不保证结果的一致性。 8 | 9 | **生产环境中应用区块链技术请务必进行充分验证评测。** 10 | -------------------------------------------------------------------------------- /evaluation/summary.md: -------------------------------------------------------------------------------- 1 | ## 小结 2 | 3 | -------------------------------------------------------------------------------- /revision.md: -------------------------------------------------------------------------------- 1 | ## 版本历史 2 | 3 | * 1.6.0: 2021-12-01 4 | * Fix expressions; 5 | * Fix typos. 6 | 7 | * 1.5.0: 2021-01-21 8 | * Add operation chapter; 9 | * Fix typos and polish expression. 10 | 11 | * 1.4.0: 2020-06-18 12 | * Refine deployment fabric with v2.0 version; 13 | * Update hyperledger community and projects; 14 | * Add operation guide and best practices. 15 | 16 | * 1.3.0: 2019-12-31 17 | * Add more crypto techniques; 18 | * Update go and related tools; 19 | * Update bitcoin project. 20 | 21 | * 1.2.0: 2018-12-31 22 | * 添加常用 Golang 工具和技巧； 23 | * 更新密码学相关知识，增加布隆过滤器等； 24 | * 更新超级账本项目内容； 25 | * 更新分布式系统章节。 26 | 27 | * 1.1.0: 2018-04-24 28 | * 更新群签名； 29 | * 更新区块链和分布式账本演化; 30 | * 更新比特币、以太坊最新进展。 31 | 32 | * 1.0.0: 2017-12-31 33 | * 更新 baas 设计； 34 | * 更新附录部分； 35 | * 修正部分表达。 36 | 37 | * 0.9.0: 2017-08-24 38 | * 修正字词； 39 | * 添加 fabric 1.0 的内容； 40 | * 《区块链原理、设计与应用》正式出版。 41 | 42 | * 0.8.0: 2017-03-07 43 | * 完善应用场景等； 44 | * 完善分布式系统技术； 45 | * 完善密码学技术； 46 | * 根据最新代码更新 Hyperledger 使用。 47 | 48 | * 0.7.0: 2016-09-10 49 | * 完善一致性技术等； 50 | * 修正文字。 51 | 52 | * 0.6.0: 2016-08-05 53 | * 修改文字； 54 | * 增加更多智能合约； 55 | * 增加更多业务场景。 56 | 57 | * 0.5.0: 2016-07-10 58 | * 增加 Hyperledger 项目的内容； 59 | * 增加以太坊项目内容； 60 | * 增加闪电网络介绍、关键技术剖析； 61 | * 补充区块链即服务； 62 | * 增加比特币项目。 63 | 64 | * 0.4.0: 2016-06-02 65 | * 添加应用场景分析。 66 | 67 | * 0.3.0: 2016-05-12 68 | * 添加数字货币问题分析。 69 | 70 | * 0.2.0: 2016-04-07 71 | * 添加 Hyperledger 项目简介。 72 | 73 | * 0.1.0: 2016-01-17 74 | * 添加区块链简介。 75 | 76 | --------------------------------------------------------------------------------