运行完上边的这个命令之后，你就可以知道你的系统中都少什么库，下边就是安装缺少的库的方法
If you encounter configure: error: libdb_cxx headers missing
提示少libdb_cxx头，这个时候运行下边令命安装db的C++开发库
sudo apt-get install libdb5.1++-dev 

./configure --with-incompatible-bdb

一、恒星网络

恒星网络，stellar，一个由前瑞波(Ripple)创始人Jed McCaleb发起的区块链接项目，用于搭建一个数字货币与法定货币之间传输的去中心化网关。最近，乐视金融与恒星基金会签约，共建NBiLe与Lumens两个平行网络，实现通缩与通胀并行。

恒星网络是基于Ripple基础上进行开发，在比特币和瑞波的技术基础上做了的很多改进，特别是相关的共识机制和验证算法，恒星网络运行节点性能得到提高，并节点资源需求非常低。众多改进其中，最大改动的是恒星支付系统的支撑算法SCP（恒星共识协议），号称是目前最安全的类拜占庭算法。SCP共识机制应用“集合块”，即各节点选择其可信任的其他节点。所有这些个体选择之和便是系统层面的共识集合。这些集合块将整个系统联结起来，正如个体网络的决策统一了互联网一样。SCP对计算能力以及经济成本消耗要求适度，降低了进入门槛并潜在地把金融系统开放给新的参与者，同时也是一种最佳的对抗恶性行为参与者使得系统恢复的构建方法。

开源代码地址为https://github.com/stellar/stellar-core，系统主要开发语言为C++，共识机制为SCP，支持智能合约，适用于公链和联盟链。

二、Tendermint

美国公司推出的Tendermint作为第二代区块链架构，已经超越了受限制的基于代币/类比特币的单片系统，是第一个实施分片技术的公共区块链。

Tendermint是一种开源的区块链套接字协议，消除了区块链之前的复杂性，为区块链开发提供了模块化结构，并且在区块链核心提供了一个开源的区块链引擎，使得各种机构和开发团队都能够轻松且高效地创建属于他们自己的区块链技术。Tendermint主核心将会管理所有的区块链分区，你可以有比特币分区或以太坊分区，具有很大的灵活性。在Tendermint平台上可以搭建基于任何编程语言的应用开发界面，主核心管理所有分片，分片包含很多类型，可以是比特币分片、或者以太坊分片。

Tendermint共识引擎通过Tendermint套接字协议（TMSP）与应用程序进行连接。Tendermint通过在应用程序进程和共识形成过程之间设置一个非常简单的应用程序接口，可以对区块链设计进行分解。并且TMSP不依赖于某一特定的编程语言，所以开发人员可以使用任意一种编程语言来编写智能合约。用户同样还能够利用现有的代码库，工作流和开发生态系统来创建复杂的应用程序。

开源代码地址为https://github.com/tendermint/tendermint，系统主要开发语言为GO，所使用的是拜占庭容错共识机制，支持智能合约，具有去中心化控制、低延时、渐进安全的特效，大大提高扩展性和速度，每秒钟可以完成超过10,000笔交易，适用于公链和联盟链、私链。

三、Openchain

Openchain是由区块链技术公司Coinprism开源分布式总账区块链工具，主要提供给大型企业和金融机构，Openchain 在处理大型企业和金融机构的数据的时候，相较于传统的区块链工具，能大大的降低计算速度，并能降低成本和交易方风险。

不同于比特币，Openchain基于一种独特的分布式账本技术，它可帮助用户部署自己版本的区块链，减少用户的交易成本和结算时间。Openchain去除了区块，交易和交易之间直接连通，这意味着交易可以得到即时确认。任何人都可以连接到一个验证的节点，并收到一份交易验证的实时复制本，Openchain还通过数字签名来保护交易的安全性，使交易不可伪造。另外，通过挂钩模块，基于Openchain的token可以作为侧链挂钩到比特币网络上。

开源代码地址为https://github.com/openchain/，系统主要开发语言为C#开发，他是DNX应用，可以支持跨平台运行，支持智能合约，适用于联盟链。

四、多链MultiChain

多链Multichain，他是一个区块链软件平台，任何人都可以在上面创建和部署私链（permission chain）。隐私与控制的争议是比特币成为行业性金融机构的障碍，而用MultiChain创建的私有链则克服了这个困难。Multichain支持快速部署，两步就可以生成自已的区块链，三步就可以连接上其它区块链。

MultiChain是采用PoW共识机制，通过对用户权限的综合管理解决了挖矿，隐私和公开性问题。MultiChain提供了一种创新性的可信决策网络实体的方法来解决私有区块链的挖矿问题。该平台可将挖矿活动限制在一套可供验证的实体内，并且避免了单一方对挖矿过程的垄断。这种被成为“多样性挖矿”的方案通过限定给定窗口内同一矿工的区块数量来解决挖矿问题。“多样性挖矿”取消了工作量证明的重要性和本地加密货币的必要性，并且可使处理交易的矿工以随机轮转的方式认可交易。

MultiChain向后兼容比特币，因此用户能够把现存的比特币应用导入到 MultiChain。不是支持像比特币内核的单一链， MultiChain可被配置以同时支持同一网络的不同区块链。MultiChain能够支持很多第三方资产，能够使私有区块链和比特币区块链相互转换。

MultiChain开源代码即将发布中。

五、Corda

R3的区块链软件Corda，旨在为参与其中的70多家银行研发解决方案，专为金融服务所设计的新分散式的分类帐平台。他号称自己不是区块链，而用以记录和管理金融合约的分布式账本。但Elwin认为，Cordar的系统核心还是是基于区块链技术的，他包含区块链的五大特性，共识、有效性、唯一性、不可更改性和认证，Corda採用许多区块链技术的优势与特性，同时捨弃掉让区块链技术无法融进大多数金融领域的设计理念，排除了一些不适合银行业应用场景的设计思路。

Corda平台基于产业标准工具所打造，不包含原生虚拟货币，主要特性包括能可支援各种共识机制、自动编排跨组织之间的工作流，不需仰赖单一中心化的控制机构，Corda用非常精确的时间界限来处理交易而非区块挖掘时平均大致的时间界限，且能直接设计出负责监管与监督观察作业的节点，并经由特定交易方来验证，不需由一大群与该交易无关的验证者。

Corda在智能合约，数据处理等方面也做了创新，而且也符合通过协作以保持金融数据协议的准确和共享。自然隐私和监管也在它的专用平台设计之中。Corda关注可互操作性和增量部署，不对第三方泄露机密信息。公司可以查看与对手方达成的协议，并确保双方看到的信息一致并向监管机构报备。Corda系统引入了法律语言体系，并包含管理金融协议的作用，该系统必须使企业逻辑编写简单化并与现有代码兼容，还必须支持协议相关企业间的行为协调。

针对金融使用场景和面向银行为主要使用者，Corda系统主要特点：

l   没有多余的全局数据共享：只有有合法需求的参与方可以按照协议获取数据；

l   Corda编写和配置在企业间流转，无中心控制者；

l   Corda在企业间单个交易水平达成共识，而不是在系统水平上；

l   系统设计直接支持监管观察员节点；

l   交易直接由交易双方验证，而不是由一大群不相干的验证者进行；

l   支持多种共识机制；

l   记录了智能合约代码和人类语言法律文件的清晰联系；

l   用行业标准工具创建；

l   没有原始加密货币。

Corda适用于联盟链，特别为金融业务打造，下个月将发布开源代码。

六、龙链

龙链（Dragonchain）是迪士尼打造的，他是将其混合公有/私有区块链的区块链平台。

龙链是另一种用来保持记录和处理交易的区块链。它与比特币的底层技术十分相似，但又有一点不同。龙链是一种多币制的区块链，节点就可以随之定义一种货币并支持其使用。该网络上可以同时使用多种货币。龙链的共识机制可以支持一种或多种现有的共识机制（Trust，PoW，PoS），甚至是可以支持自己定义和创建一种新的共识机制。

龙链的目标特性：

l   易于集成现有的系统

l   便于传统的工程师和程序员开发，不一定需要熟悉的区块链、分布式系统和密码密码学技术

l   C/S客户服务器方式和RESTful方式集成

l   简单灵活的架构

l   默认情况下提供对业务数据的保护

l   允许业务集中控制过程

l   固定长度和周期，短和高速的区块

l   多货币支持

l   没有基础货币

l   与其他公共和私人blockchains的互操作性

开源代码地址为https://github.com/dragonchain/dragonchain，系统主要开发语言是Python，支持智能合约，适合联盟链和私链。

七、量子链

量子链Qtum是中国社区原创的区块链公链。Qtum通过价值传输协议（Value Transfer Protocol）来实现点对点的价值转移，并根据此协议，构建一个支持多个行业的（金融、物联网、供应链、社交游戏等）去中心化的应用开发平台（DAPP Platform）。

量子链的定位是，做一个符合行业监管的区块链去中心化应用开发平台。为了符合以后的行业监管，量子链团队在设计的时候，为监管者的角色设计了很多可选项，引入数字身份和第三方征信平台，设计一种新的合约类型—主控合约，把监管者的角色引入，同时监管者可以作为 Qtum系统中的喻言和数据源的提供者。

量子链采用可插拔的共识机制：Qtum系统包括 Qtum 公链和Qtum联盟链，因为网络环境和参与者的不同，考虑到公链的去中心化程度、参与门槛、安全性和可靠性，量子链开发团队采用IPOS（Incentive Proof of Stake）机制作为区块链网络的共识机制。因为联盟链大多参与者都是受限的节点、身份已知的对手方，对共识机制的考量不同于公链网络，在联盟链中，量子链将采取Proof of Time 和Raft结合的共识协议，实现高速的区块链共识网络。

Qtum的开源代码地址Elwin未找到，支持EVM的虚拟机（EVM/EVM2.0），支持智能合约，适合公链和联盟链。

八、Chain

Chain是由一家刚成立两年的美国创业公司Chain推出，是一个企业级的区块链平台架构，可以让机构构造从零开始更好的金融服务。

作为区块链供应商，Chain在过去的两年多时间中获得了极好的信用。Chain通过将专属区块链和分布式总账的源代码进行开放，可以让更多的人在其软件上增加应用或是建立专属网络。Chain核心开发者版本的创建花费了数年时间，它是区块链供应商和金融机构合作的直接产物。由于这个开源软件针对的是金融领域，因此它允许用户创建和发行他们自己认为合适的数字资产。

Chain 开放标准在以下方面实现突破：

l   全新的共识模型在不到一秒的时间里实现交易的最终完成，即便是交易量非常大也能支持

l   私密解决方案对区块链数据进行加密，并让相关对手方和监管者进行有选择的读取

l   智能合约框架和虚拟机支持简单的规则执行，以及进行键值存储的图灵完整程序

l   可伸缩的数据模型可以为网络参与者降低运行负荷

l   丰富的元数据层可支持满足KYC（了解你的客户）和 AML（反洗钱）要求

开源代码地址为https://github.com/chain/chain，系统主要开发语言是GO，共识协议采用联邦拜占庭协议，支持多种数字资产，适合联盟链。

在我们的日常生活中，几乎所有的事情都是达成共识的过程。

达成共识越分散的过程，其效率就越低，但满意度越高，因此也越稳定；相反，达成共识越集中的过程，效率越高，也越容易出现独裁和腐败现象。

• 达成共识常用的一种方法就是通过物质上的激励以对某个事件达成共识；但是这种共识存在的问题就是容易被外界其它更大的物质激励所破坏。

• 还有一种就是群体中的个体按照符合自身利益或整个群体利益的方向来对某个事件自发地达成共识；当然形成这种自发式的以维护群体利益为核心的共识过程还是需要时间和环境因素的，但是一旦达成这样的共识趋势，其共识结果也越稳定，越不容易被破坏。

在比特币和其它区块链币中，也存在如何达成共识的问题。或者说，比特币或其它区块链币最核心的问题也是如何在去中心化的环境中达成共识。

区块链是比特币背后的核心技术，也是支撑比特币的基础架构。因此在谈区块链共识，就必然要谈比特币的共识。

比特币最核心的突破是在去中心化的情况下对交易事件达成了共识，即在没有中心组织的情况下对某个交易的有效性达成了一致。

比特币实现这个共识的方法主要包括两个部分：

1. 激励；即通过每个区块产生一定量的新比特币来激励参与者；
2. 引入外部资源确保安全；即通过大量的外部计算来确保共识的安全性，也就是工作量证明（Proof of Power）；

这也是几乎所有PoW币种所采用的的方法。

而这套方法要能持续长期运行下去的前提就是：

1. 这种激励对参与者要有足够的吸引力；也就是说比特币要一直涨价，才能吸引参与者持续参与挖矿计算，以维护整个网络的运行；否则就会导致参与的人减少，破坏网络安全；
2. 没有外部攻击；由于比特币引入了外部计算来确保安全，因此只要有足够的挖矿算力（超过维护系统算力的51%）就能对系统成功进行攻击，这也是比特币长期存在的安全隐患之一；因为只要有钱，就能买到设备和算力。

正是由于比特币存在的问题，例如消耗大量的资源、外部51%攻击等，出现了PoS（Proof of Stake）共识机理。

总体上，PoS共识理论和实践目前仍处在探索阶段。

最原始的PoS机理就是用股权代替PoW中的挖矿算力，来模拟比特币的挖矿过程。请注意，这个过程没有引入外部资源，而是仅仅依靠自身的币种股份来维护网络安全，因此其不需要消耗大量能源来进行计算；而且由于其没有引入外部的资源，因此不会担心外部攻击，例如外界的算力攻击。

看起来PoS是很完美的，但是它存在一个严重漏洞。

PoS存在内部的Nothing-at-Stake攻击。

什么是Nothing-at-Stake（常写作N@S）攻击？

假设系统中出现了两个分支链，那么对于持有币的”挖矿者“来讲，最佳的操作策略就是同时在两个分支上进行“挖矿”，这样，无论哪个分支胜出，对币种持有者来讲，都会获得本属于他的利益，即不会有利益损失。而且由于不需要算力消耗，因此PoS中在两个分支上挖矿是可行的。

这导致的问题是，只要系统存在分叉，“矿工们”都会同时在这几个分支上挖矿；因此在某个情况下，发起攻击的分叉链是极有可能成功的，因为所有人也都在这个分叉链上达成了共识；而且甚至不用持有51%的币量，就可以成功发起分叉攻击；

而这在PoW中是不可行的，因为挖矿需要消耗算力，矿工只能在一个分支上进行挖矿。

第二个问题是重写历史攻击；即攻击者可以通过购买原始持有币种的账户来从头发起攻击，重新分叉一个区块链。因为原始的币种持有者可以将币转移至其它账户，因此他是可以在没有损失的情况下将原始账户出售给攻击者的。攻击者需要的就是有足够数量币的原始账户；当然了，这也只是概率问题，因为有可能原始账户持有者不会出售他们的账户，但是理论上确实存在这种攻击。

第三个问题是，尽管PoS中的挖矿不用消耗算力，运行成本很低，但是也存在如何激励矿工的问题。因为一般的PoS系统是没有新币产生的，矿工只能赚取交易费，而且在交易费不高的情况下，对矿工的激励也是很有限的。

当然了，也有很多PoS币种解决这个问题的办法就是持续的再产生新币来激励挖矿者，这导致的问题就是通胀。

上述3个问题是PoS要解决的，尤其是N@S的问题尤为重要，因为如果没有其它约束机制，这种攻击是完全有可能实现的。

从以上可以看出，无论是PoW还是PoS机理的共识过程，其必要条件有两个：

1. 信息公开共享；
2. 个体参与；

以现实为例，事件的信息越透明、所涉及到的人员参与度越高，最终形成的共识也就越稳定、越持久。这与区块链共识是一致的。

【参考阅读】

• 分布式共识
• PoW vs PoS共识讨论
• PoS共识机理研究
• N@S攻击不可行性
• It will cost you nothing to kill a  Proof of Stake  crypto currency
• Bitcoin PoS
• Ethereum PoS
• Nxt PoS
• DPoS of BitShares

区块链上的共识机制主要解决由谁来构造区块，以及如何维护区块链统一的问题，该问题的理论基础是拜占庭容错（Byzantine Fault-Tolerant，BFT）。BFT从上世纪80年代开始被研究，目前已经是一个被研究得比较透彻的理论，存在解的前提条件及具体实现都已有现成算法。不过本文不打算从BFT说起，因为要分析的是区块链共识机制的演进过程，而中本聪并没有采用BFT。其实在我研究比特币伊始，即便在理解了POW机制之后的很长一段时间内，并不了解拜占庭将军问题。后文分析 HyperLedger Fabric的PBFT以及小蚁项目的DBFT时再全面阐述拜占庭将军问题及传统分布式一致性算法（PAXOS、RAFT）。

共识机制的核心是区块的构建和检验，POW系统构建区块的过程一般称为“挖矿”（mine），POS 系统PPC的区块构建方式一般称为“铸造”（mint），而NXT的区块构建方式一般称为“锻造”(forge)。

POW

共识机制在以前一般被称为证明方式（Proof），因为比特币采用工作量证明（即Proof-Of-Work，简写为POW）。随着大家对分布式账本一致性问题的不断探索，很多方法被提出来，尤其近期有很多区块链项目回归了对传统BFT算法的改进，在思路上已经跳出了“证明”的语义，因此进一步高度概括为共识机制。我记得第一次碰到工作量证明这一概念时感到很费解，对这种表述方式很头疼，掌握了POW机理后才真正明白，通俗讲就是“通过工作以获得指定成果，用成果来证明曾经付出的努力”。其实我们日常工作生活中经常使用工作量证明，比如学生考试成绩，毕业证以及驾照等，这种证明方式的一个显著特征是往往需要很大的工作量才能拿到指定成果，但这个成果很容易验证。因为我们一般很难去实时监督一个人是否真的付出了这些工作量，所以只能使用工作量的结果来证明。

再回到比特币的设计思路，中本聪已经使用非对称密码解决了电子货币的所有权问题，用区块时间戳解决了交易的存在性问题，用分布式账本解决了剔除第三方结构后交易的验证问题，剩下需要解决的问题是双重支付，这要求所有节点账本统一，而真正的平等又必须赋予人人都有记账的权利，记账是一件简单的事情，每个人都可以做，显然最终会存在众多大同小异的账本，但我们只需要其中的一个账本就够了。

中本聪想到给记账加入成本，总账本由各个分页按照时间先后排序，给每个账本分页设立一个评判标准，以区分账本分页是否合格，这给记账增加了难度，同时给每个账本分页加入一个随机元素，用以调节记账难度以保证一定时间段内只有一个人生成合格的账本分页。增加的成本就是工作量，合格的账本分页就是工作量证明。对于比特币而言，所谓的账本分页就是一个区块，区块通过巧妙设计形成区块链，合格的区块可以表述为：

F(Nonce) < Target

其中Nonce是随机元素，Target是合格区块的量化，每个记账节点的Target一致。此外POW的成功运行还需要配合如下两条约定，
Best chain原则：将最长的链条视为正确的链条。

激励原则：找到合格的区块有奖励收益。

第1条约定为硬性规则，无条件遵守，大家要么不玩，要玩就遵守这条原则，毕竟共同的目标是找到一致性账本，而最长的链条代表最大的工作量，如果没有这条约定，每个人都只会构造自己的区块链，无法统一。第2条为工作量激励，既然记账有成本，那唯有收益才能驱动大家都去记账，参与记账构造区块变成投资行为，其成本和收益风险在第1条约束下形成博弈，驱动所有节点按约定规则老老实实够造区块，最终达到纳什均衡。

具体实现方式，比特币采用哈希（Hash）算法，关于哈希算法的原理和特点在前一篇文章（挖矿演进）已经详细讨论。逻辑上比特币是对整个区块进行哈希运算，但真正实现并非将整个区块数据作为哈希函数的参数，区块大体可分为区块链头和交易列表两部分，交易列表通过构造成Merkle树最终浓缩成Merkleroot内置于区块头，区块头只有6个字段，共80字节，如此设计首先带来的好处是方便哈希运算，每次运算只需要80字节的参数输入，而不是整个区块的数据，但交易列表的任何变化又能体现在哈希运行结果上。

比特币采用SHA256哈希运算，且每次都是连续进行两次SHA256运算才能作为最终结果，前一次运算的结果作为后一次运算的输入，即Double SHA256，一般简称SHA256D，扩展上面的公式，比特币合格区块判断依据如下：

SHA256D(nVersion,hashPreBlock,hashMerkleRoot,nTimes,nBits,Nonce)<MAXTARGET/Diff

其中式子左边的6个参数（区块头）在前一篇文章已经解释，MAXTARGET为最大目标值，常量；Diff代表难度，全网难度一致。MAXTARGET/Diff即通常所说的当前目标值。

很显然，POW的核心要义为：算力越大，挖到块的概率越大，维护区块链安全的权重越大。相对其他共识机制而言，POW逻辑简单，容易实现，容错达50%，其安全有严格的数学论证。

POS

POW并非完美，其中被指责最多的主要有两点，一是浪费能源，二是风险和收益博弈必然导致联合挖矿，而大算力矿池可能会对系统的去中心化构成威胁。

于是在2011年，一个名为Quantum Mechanic的数字货币爱好者在Bitcointalk论坛提出Proof-of-Stake（POS）证明机制，该机制被充分讨论之后证明具有可行性。如果说POW主要比拼算力，算力越大，挖到一个块的概率越大，POS则是比拼余额，通俗说就是自己的手里的币越多，挖到一个块的概率越大。POS合格区块可以表述为：

F(Timestamp) < Target * Balance

与POW相比，式子左边的搜索空间由Nonce变为Timestamp，Nonce值域是无限的，而Timestamp极其有限，一个合格区块的区块时间必须在前一个区块时间的规定范围之内，时间太早或者太超前的区块都不会被其他节点接纳。式子右边的目标值引入一个乘积因子余额，可见余额越大，整体目标值（Target * Balance）越大，越容易找到一个区块。因为Timestamp有限，POS铸造区块成功率主要与Balance有关。

POS只是代表一种共识机制理念，具体有多种实现方式，下面重点解析两种比较经典的实现思路。

Peercoin

Peercoin（点点币，PPC）于2012年8月发布，最大创新是其采矿方式混合了POW工作量证明及POS权益证明方式，其中POW主要用于发行货币，未来预计随着挖矿难度上升，产量降低，系统安全主要由POS维护。目前区块链中存在两种类型的区块，POW区块和POS区块。PPC的作者为同样不愿意公开身份的密码货币极客Sunny King，同时也是Primecoin的发明者。

要掌握Peercoin的POS机制，需要重点理解Sunny King专门为PPC设计的几个核心概念：Coinstake，Kernel，Stake Modifier，Modifier Interval，Stake Reward，Coinage等。

Coinstake

为了实现POS，Sunny King专门设计了一种特殊的交易，叫Coinstake，Coinstake的设计借鉴于中本聪的Coinbase设计。本质上Coinbase和Coinsake都是一笔交易，只是对他们的输入输出做了一些硬性限制。

而Coinstake的设计又需要有别于Coinbase，这样才不会扰乱系统原有的POW机制，简单对比一下两者结构上的不同，

Coinbase结构要求：

输入数量必须等于1，且输入的prevout字段（指定前一笔交易的输出）必须置空值。
输出数量必须大于等于1。

Coinstake结构要求：

输入数量大于等于1，且第一个输入的prevout字段不能为空，即要求Kernel必须存在。
输出数量大于等于2，且第一个输出必须置空值。

这两种特殊交易在区块链中存放的位置也有特殊要求，中本聪规定每个区块的第一笔交易必须放置Coinbase，反之，Coinbase不能出现在区块的其他位置。Sunny King显然不想破坏这个规则，他增加了一条规则，对于POS区块，第二笔交易必须放置Coinstake，反之，Coinstake不能出现在其他地方。换言之，只要第二笔交易是Coinstake，那么这个区块就当POS区块来处理。

Coinbase和Coinstake都不会被单独广播，而只存在于区块中，因此客户端节点一般都不允许进入内存池，当花费这两种交易时，都需要检测是否已经成熟。

Kernel Protocal

Coinstake的第一个输入(Input 0)叫Kernel，Kernel在POS机制里确实起到核心作用，合格区块的判定与之息息相关。PPC合格区块判断条件为：

SHA256D(nStakeModifier + txPrev.block.nTime + txPrev.offset + txPrev.nTime + txPrev.vout.n + nTime)< bnTarget * nCoinDayWeight

式子左边的每一个参数都有明确的设计目的，其中，

nStakeModifier：专门为POS设计的调节器，按照以上公式，如果没有参数nStakeModifier，当一个人收到一笔币得到网络确认之后，他立即就能提前计算得知自己在未来何时可以锻造区块，这显然不符合设计目标，Sunny King希望POS矿工和POW矿工一样做盲目探索，以实时在线维护区块链，nStakeModifier的设计就是为了防止POS矿工提前计算。nStakeModifier可以理解为POS区块的一个属性，每一个区块对应一个nStakeModifier值，但nStakeModifier并不是每个区块都变动，不过协议规定每隔一定时间（Modifier Interval）必须重新计算一次，取值与前一个nStakeModifier以及最新区块哈希值有关，因此POS矿工无法提前计算，因为他不知道未来的区块哈希值。

也就是说，在PPC系统中，除了存在区块链，币链（币的交易签名历史），还隐藏着一个很少被提及的链条——权益调节器链条。

值得一提的是，Sunny King是在PPC后来的版本才加入这个调节器的，一开始他使用nBits。

txPrev：Kernel对应的前一笔交易。

txPrev.block.nTime：txPrev所在区块的时间戳，一笔交易被纳入区块的时间是交易发起者不能确定的，节点有可能通过提前计算预估到未来对自己有利的时间戳，这个参数就是为了防止节点利用这种预估优势提前生成大批交易。

txPrev.offset：txPrev在区块中的偏移量，用以降低网路节点同时生成coinstake的概率。

txPrev.nTime：txPrev构造时间，设计目标如txPrev.offset。

txPrev.vout.n：Kernel在txPrev中的输出下标，设计目标如txPrev.offset。

再看等式右边，
bnTarget：全网当前目标难度基准值，类似POW中的当前难度值，由nbits记录。
nCoinDayWeight：Kernel的币龄。

由以上式子可知，Sunny King一方面希望能给POS矿工提供充足的随机性，另一方面搜索空间严格局限于Coinstake的时间戳字段，以保证影响找到合格区块链的最大因素是Kernel的币龄。

节点在锻造区块时，首先从自己所有的UTXO中选定一个作为Kernel，构造coinstake，计算hash,如果不合格，重新构造coinstake，重构时时间戳Time会改变，也可以改变Kernel，以得到不同的Coinstake，如此往复，直到找到合格区块。

Coinage

上面提到了币龄，也叫币天，假如1.5个币存在于区块链中10天，币龄数值为：

Coinage = 1.5*10 = 15

PPC采用币龄，而不是直接采用余额（Balance）来计算。一个UTXO一旦被花费，其币龄被清零，新的UTXO币龄从0开始算起。

stakeReward

权益激励，俗称获得利息，计算公式如下：

stakeReward = nCoinAge * 33 / (365 * 33 + 8) * 0.01 * COIN

公式可简化为：

stakeReward = (0.01 * nCoinAge / 365) * COIN

其中nCoinAge是Coinstake所有输入的币龄总和，由公式可知收益按1%年率计算。理想状态下，假设所有的币全年都参与挖矿，代币总量每年有1%通胀率，这一设计为很多人所诟病，而且，这一设计并不能激励矿工积极参与挖矿以维护区块链的安全，因为如果不考虑手续费，持币用户每隔几个月打开节点铸币，或者实时在线铸币，理论上收益都是一样的。

stakeMinAge

POS系统也存在51%币龄攻击风险，为了增加攻击难度，Sunny King对每一笔UTXO的铸币资格做了最小年龄（stakeMinAge）限制：一个UTXO在区块链存在的时间小于stakeMinAge则没有铸币资格，PPC最小币龄为8小时。

后来有些竞争币种加入了最大年龄（stakeMaxAge）限制：一个UTXO在区块链存在的时间大于stakeMaxAge则币龄始终按stakeMaxAge计算。

在Sunny King设计的POS机制中，一笔UTXO就像是一个矿工，该矿工每成功铸造一个区块后必须休息一段时间，因此，整套系统必须保证足够多的“矿工”同时在线铸造区块，才有可能获得平滑的出块速度。

Nextcoin

2013年9月，一个名为BCNext的用户在Bitcointalk论坛发起一个帖子，宣布将发行一种全新的纯POS币种，后来取名为Nextcoin，简称NXT。与当时其他山寨币直接Fork自Bitcoin源码的开发思路不同，BCNext另起炉灶，采用JAVA语言从头开发NXT，并对区块结构，交易结构，非对称密码等做了很多改进。NXT有很多创新点，这里只讨论其中最重要的创新——透明锻造（Transparent Forging）。

NXT的POS实现方式与PPC完全不同，合格区块判定方法为：

hit < baseTarget * effectiveBalance * elapseTime

其中，
hit：
NXT抛弃中本聪的UTXO设计方案，采用账户（Account）余额方案，每一个账号对应一个私钥。每一个区块都有一个生成签名（generationSignature）字段，hit的生成与这个字段有关。当用户需要锻造区块时，首先计算自己独一无二的hit，计算过程如下：

用户用自己的私钥对上一个区块的generationSignature进行签名，获得自己本区块的generationSignature。
对上一步结果进行SHA256运算，得hashdata。
取hashdata的前8个字节（共64比特位）作为hit变量。

生成签名的设计有点类似于PPC的stakeModifier，也就是说，NXT区块链下隐藏着一个签名链条。

式子右边，
baseTarget：全网难度基准值，这个难度按照每分钟一个区块目标调节。
effectiveBalance：账户有效余额，一笔币转到账户需要足够多的确认才有铸币权利，叫有效余额。
elapseTime：当前时间与上一个区块时间间隔，按照currentTime-lastBlockTime计算。

分析以上式子，如果依然将式子左边视为挖矿，右边视为目标值，可知用户压根就没有搜索空间，因为当全网产生一个最新区块时，对于锻造下一个区块，每个用户自身的hit就固定了。式子右边，每个用户的目标值与自身的账户有效余额成正比关系，而且，随着时间往前推移，目标值不断变大，不等式最终一定会成立，即理论上每个节点都可以挖那个区块，但规定优先选择最早生成的区块。

用上图类比NXT的锻造机制，每个圆柱体自身高度（hit）是固定的，假设限高杆不断升高（目标值target随着时间不断增大），最终所有圆柱体都能通过（合格区块），但高度最矮的圆柱体可以率先通过。

节点段造区块流程为：账户必须实时在线，当全网有最新区块产生时，每个账户立即计算自己对应的hit，然后根据公式elapseTime = hit/(baseTaret * effectiveBalance)计算得知自己锻造区块的期望时间值，并将这个期望时间广播给网络其他节点，如此，全网每个节点都知道其他节点的期望时间，从而也就得知下一个区块优先由谁来锻造。账户在自己的时间窗口锻造好区块并立即广播全网，其他节点检验一个新区块是否有效，首先要检验证区块的生成签名是否有效，还要检验新区块的时间戳是否与产生区块的节点之前发布的期望时间吻合。每次客户端检测到网络中有新的区块产生，都会重新计算自己的期望时间并向全网发布。

因为hit是用户用自己的私钥签名的结果，因此对于不同用户来说具有很大随机性，即便余额很少的用户，如果运气足够好，hit值很小，也有可能快速锻造区块。

NXT区块的生成完全摒弃了竞争的理念，有点“上帝早已安排好一切”的味道，下一个区块由谁来生成冥冥中早就注定了，全网节点能做的就是静静等待那一刻的到来。

如图，如果节点A没有在自己的锻造时间窗口内广播区块怎么办，没问题，网络会等B的区块，但是如果A和B间隔不远，或者由于网络传输原因部分节点先收到A的区块，部分节点先收到B的区块呢，网络就分叉了，此时Bestchain的原则依然是首选最长的链条，长度一致的分支，优先选择最高区块时间戳最小的分支。那如果节点对所有分支都锻造并广播区块呢，那就变成了一种攻击行为，网络最新区块附近的分叉会加剧。缓解问题的办法是让节点只挖最优分支，这一点没法体现在协议中，只能依靠诚实节点的自律。

摒弃了竞争的理念，NXT共识不得不高度依赖于时间轴，节点虽可预知自己在未来何时可生成区块，但必须要等到那个时候才能广播区块，如果节点提前广播，网络其他节点将不会接受，BCNext在客户端实现上做了限制：对于最新区块，客户端只接受本机当前时间前后15秒范围内广播的区块，这种限制也没法体现在协议上，只能依靠客户端实时辅助实现。

也难怪，NXT代币全部预挖，如果采用类似比特币那样由矿工慢慢发行模式，免不了竞争段造区块，而一旦竞争，区块链将立即陷入分叉。NXT整套共识规则的成功运行其实背后有一个潜在的利益博弈，即，持币者就是系统使用者，也是系统的受益者，大家应该联合起来共同维护区块链，做一个诚实的节点。

也许你会想到一种攻击方法：即便手里持币量很少，但可通过生成大批账号并往每个账号转少量币，以每次都能找到很小的hit，也能快速锻造区块，如此一来POS就退化到类似POW的尴尬境地。BCNext首先从非对称签名算法下手，采用ED25519代替比特币的ECDSA，前者的计算难度比后者大。此外成熟期提高到1440个区块（1天），即一个账号有效余额一旦成功锻造一个区块，该部分余额需要等1天才能重新获得锻造资格。

短暂的分叉还是不可避免的，NXT最新区块附近会有很多分支，一笔交易需要多一些确认才足够安全，NXT官方推荐10个确认。

POS2.0

PPC的成功运行很快就吸引了一批追随者，其中较为出名的包括新星币(Novacoin，NVC)、黑币（blackcoin，BLK）等。黑币社区认为币龄可能会被恶意的节点滥用以获得更高的网络权重并成功实施双花攻击，于是发布POS2.0白皮书，对PPC做了几个细节优化，解决了一些潜在的安全问题，其中最重要的改进是用余额代替币龄，合格区块的条件由：

F(Timastamp) < Target * 币数 * 币的年龄

变为：

F(Timastamp) < Target * 币数

如此一来，一笔UTXO无论放置多久其锻造区块的能力不变，此举可激励节点必须更多的保持在线进行铸币，提高系统安全性，将攻击途径减少到最低限度，并且能够显著提高网络保持运行的节点数量。

POS3.0

黑币社区后来进一步升级，推出POS3.0版本，对交易手续费，难度调整做了一些优化，其中最显著的改变是将1%年利率奖励机制变为固定数额奖励（每个区块固定奖励1.5BLK），此举不但降低代币通胀率（考虑到会有代币永久丢失，低额奖励机制回归总量恒定的设计思路），同时意味着持币节点必须实时在线才能获得收益。

DPOS

比特股（Bitshares）项目于2013年8月开始启动，这是一个野心勃勃的项目，对区块链做了很多改造，并引入许多新概念和特征，尤其令人眼花缭乱的 Bitshares X、多态数字资产交易平台、资产锚定等新名词，一时令人无比兴奋而又困惑。此时POW和POS都已成功运行许久，彼此优劣已被反复讨论，两大阵营时至今日依然争论不休。按照项目规划，比特股对交易容量和区块速度有极高要求，显然POW或POS都达不到要求，于是比特股发明了一种新的共识机制——Delegated Proof-Of-Stake（DPOS），即股份授权股权证明。

DPOS很容易理解，类似于现代企业董事会制度，比特股系统将代币持有者称为股东，由股东投票选出101名代表，然后由这些代表负责产生区块。那么需要解决的核心问题主要有：代表如何被选出，代表如何自由退出“董事会”，代表之间如何协作产生区块等。

持币者若想成为一名代表，需先拿自己的公钥去区块链注册，获得一个长度为32位的特有身份标识符，用户可以对这个标识符以交易的形式进行投票，得票数前101位被选为代表。
代表们轮流产生区块，收益（交易手续费）平分。如果有代表不老实生产区块，很容易被其他代表和股东发现，他将立即被踢出“董事会”，空缺位置由票数排名102的代表自动填补。

从某种角度来说，DPOS可以理解为多中心系统，兼具去中心化和中心化的优势。

总结

最后从几方面来简单对比分析以上几种共识机制的优劣和特点：

安全性

POW的安全性存在完整的数学证明，这一点是POS和DPOS无可比拟的优势。区块链共识机制一般要同时考虑抵御DDOS攻击和双重支付攻击，POW存在51%算力攻击威胁，比特币目前超强的算力使得破坏该系统需付出巨大代价。POS也会存在51%币龄攻击，而DPOS安全性完全取决于代表的诚实程度。NXT理论可以实现快速交易，但需要锻造节点曝光自己的IP，如此一来容易成为DDOS攻击对象，DPOS的代表也容易成为DDOS攻击对象。

环保性

在不可能三角理论（去中心化，安全，环保不能同时兼备）中，POW彻底抛弃节约能源的需求，通过巨大算力来维护系统安全和去中心化特征。POS和DPOS几乎不费多余电力，但不可避免在另外两个特性做出牺牲。

共识速度

POW很难缩短区块时间，POS相对而言可以缩短区块时间，尤其NXT会比PPC的实现方式更快，DPOS也可以在很短时间内达成共识，比特股目前30秒产生一个区块。不过POS更容易产生分叉，尤其NXT，所以交易需要等更多确认才被认为安全。

交易容量

这是区块链未来发展需要解决的核心问题，巨大的交易容易意味着巨大的带宽和存储空间，POW的交易容量很难扩展，而NXT由于每个节点都可以预知下一个区块由谁锻造，可以直接将交易发给锻造节点，因此NXT交易容量有很大扩展性。从某种角度来说，DPOS可以理解为多中心系统，兼具去中心化和中心化的优点，如果代表节点都运行强大的服务器且彼此带宽足够大，理论上交易处理能力可比拟传统中心化系统，比如Visa。

出块平滑度

POW由于哈希算法特性，可以得到平滑出块速度，而且可以间隔一段时间再调整全网难度，POS出块主要与余额有关，而用户余额差距梯度比较大，所以POS一般每个块都要调整全网基础难度。DPOS依靠有限代表人的协同作用，如果代表人不会频繁进出，几乎可以做到固定死出块间距。

最终性

POW和PPC通过竞争达成共识，不存在最终性，理论上如果有足够算力，现在可以从头挖比特币区块链，不过可以依靠检测点实现最终性。NXT和DPOS严格依赖时间轴，依靠节点实时在线检测，所以存在最终性。

综合各方优势，个人认为POW适合应用于公链，如果搭建私链，因为不存在验证节点的信任问题，可以采用POS比较合适，而联盟链由于存在不可信局部节点，采用DPOS比较合适。

一、块链是什么

区块链最初是由一位化名中本聪的人为比特币（一种数字货币）而设计出的一种特殊的数据库技术。
从数据的角度来看，区块链是一种把区块以链的方式组合在一起的数据结构，它能够使参与者对全网交易记录的事件顺序和当前状态建立共识。

区块链概括起来是指通过去中心化和去信任的方式集体维护一个可靠数据库的技术。区块链涉及的技术关键点包括：去中心化、去信任、集体维护、可靠数据库、时间戳、非对称加密等。
区块链重新定义了网络中信用的生成方式，在系统中，参与者无需了解其他人的背景资料，也不需要借助第三方机构的担保或保证，区块链保障了系统对价值转移的活动进行记录、传输、存储，其最后的结果一定是可信的。

二、区块链技术现状

比特币之后，多元化区块链共同发展，经过了近8年的发展与实践，人们对区块链技术的了解越来越深入，也在让区块链技术与自身需求更契合的过程中逐渐明白了以下两点：（1）区块链技术本质上是互联网协议的底层技术，是互联网数据层次的技术；（2）区块链倡导的“去中心”并不是反中心，而是分中心（最彻底的分中心就是每个节点自己成为自身的中心）。因此，许多领域试图在比特币区块链的基础之上对其做进一步的改进。目前，区块链已经从比特币完全去中心化的公共区块链，发展出了依附于公有链之上的侧链以及非完全去中心化的私有区块链等。

区块链技术处于理论阶段，尚需实践。区块链技术是伴随比特币的产生而出现的，目前最成熟的区块链就是比特币的区块链。国内外对于区块链技术的投入使用都已经逐渐展开，但目前尚未有完全落地的应用性成果展现出来。从发展的角度来看，区块链技术目前仍然处于理论阶段，今后的技术转换尚需一段很长时间的实践。

三、区块链共识机制

共识机制的作用是为了确认区块链上交易的有效性，目前常见的共识机制有POW工作量证明、POS权益证明、DPOS股份授权证明、Ripple共识机制以及PooL验证池，这几类共识机制各有优劣，应用场景也各不相同，下表展示了从不同维度对这几类共识机制的分析比较：

• POW（Proof of work）

POW即工作量证明，就是众所周知的挖矿，它是一种竞争共识，通过工作量的证明来获得生成区块的权力。

它的优点是完全的去中心化，各个节点完全平等，而且可以自由的进出；缺点则是POW会造成大量的挖矿资源浪费，达成共识的周期也比较长。

• POS（Proof of Stake）

POS即权益证明，是POW的一种升级共识机制，它主要解决了POW工作量计算浪费的问题。当前POS已有很多不同的变种，但基本还是根据每个节点所占有代币的数量和时间（即权益）来决定其挖矿的难度。

它的优点是缩短了各个节点之间达成共识的时间，缺点则是同POW一样仍然需要挖矿，并且POS会使得“富者更富”。

• DPOS（Delegate Proof of Stake）

DPOS即股份授权证明机制，是POS的一个变种。它的原理是让每个持有代币的人进行投票，由此产生一定数量的“超级节点”，由这些节点来轮流产生区块。

它的优点是不再需要通过挖矿来产生区块，从而可以大幅缩小交易确认的时间，能够达到秒级的共识验证，缺点则是DPOS还是得依赖于代币，不适用于一般的商业应用。

• Ripple Consensus（瑞波共识机制）

Ripple Consensus是一种数据正确性优先的网络交易同步机制，它是基于特殊节点列表达成的共识。在这种共识机制下，必须首先确定若干个初始特殊节点，如果要新接入一个节点，必须获得51%的初始节点的确认，并且只能由被确认的节点产生区块。因此，它区别于前面几类共识机制的主要因素是有一定的“中心化”。

Ripple Consensus的优点是能保证任何时候都不会产生硬分叉，并且交易能被实时的验证；而缺点则是新加入节点要取得与其他节点的共识所需时间较长。

• POOL验证池

POOL验证池是基于传统分布式一致性算法加上数据验证的机制，也是目前行业链大范围在使用的共识机制。

它的优点是无需建立代币，在成熟的分布式一致性算法（Pasox、Raft）的基础上，能够实现实时共识验证；缺点是性能会随着节点数的增加而变差，并且去中心化程度不够。

除了常见的以上所述的几类共识机制，在区块链的实际应用过程中，还存在着五花八门的依据业务逻辑自定义的共识机制，如小蚁的“中性记账”、类似Ripple Consensus的Stellar共识机制、Factom等众多以“侧链”形式存在的共识机制等。
因此，本文依据共识机制的特性及典型性将其划分为三大类：POW、非POW以及侧链。

四、区块链技术方案分析

区块链技术发展到今天，已经从最初的数字货币领域扩展到社会领域的方方面面，各种各样的区块链技术方案不断涌现出来。通过对市场上现有的区块链技术方案进行研究，从共识机制、区块链使用方式两个维度对区块链技术方案进行分类，并根据技术影响力决定面积大小、技术成熟度决定颜色深浅对各个区块链技术方案进行绘制，分类结果如图1所示。

图1 区块链技术方案分类 
图1中，对15个区块链技术方案进行分类，其中，将共识机制划分为PoW、非PoW、侧链三个方面，区块链使用方式分为开源项目、商业解决方案、区块链云服务、现有区块链四种方式，技术影响力按面积大小进行区分，面积越大影响力越大，技术成熟度按颜色深浅进行区分，颜色越深技术越成熟。
从图1中可以看出，比特币、以太坊、HyperLedger三种区块链技术方案的技术成熟度最高，影响力最大，下面分别介绍这三种区块链技术方案。

1比特币
比特币的概念最初由中本聪在2009年提出，根据中本聪的思路设计发布的开源软件以及建构其上的P2P网络。比特币是一种P2P形式的数字货币。点对点的传输意味着一个去中心化的支付系统。

与大多数货币不同，比特币不依靠特定货币机构发行，它依据特定算法，通过大量的计算产生，比特币使用整个P2P网络中众多节点构成的分布式数据库来确认并记录所有的交易行为，并使用密码学的设计来确保货币流通各个环节安全性。P2P的去中心化特性与算法本身可以确保无法通过大量制造比特币来人为操控币值。基于密码学的设计可以使比特币只能被真实的拥有者转移或支付。这同样确保了货币所有权与流通交易的匿名性。比特币与其他虚拟货币最大的不同，是其总数量非常有限，具有极强的稀缺性。

2以太坊
以太坊是一个专注于智能合约应用的数字货币和区块链平台，它的去中心化技术使交易摆脱了停机和审查的麻烦，解决了传统合约的纠纷等棘手问题，并且还能避免欺诈和第三方的干扰。以太坊的目标就是提供一个带有内置的成熟的图灵完备语言的区块链，用这种语言可以创建合约来编码任意状态转换功能，用户只要简单地用几行代码来实现逻辑，就能够创建各种满足需求的系统。
从技术架构角度看，以太坊是一个与底层区块链和协议无关的通用分布式运用开发平台和编程语言，包括数字货币以太币（Ether）和以太脚本（EtherScript），用于构建和发布分布式应用。它具备开放通用的特性，且内置有图灵完备虚拟机，可以运用任何货币、协议和区块链。网络上的每一个节点都可以运行以太坊虚拟机来发布分布式智能合约程序。

以太坊有自己的分布式系统：包括文件服务Swarm、信息传输Whisper和信誉担保。Swarm是个去中心化文件服务；Whisper是加密通信传输系统；信用担保提供去信任网络中建立信誉和降低发现的系统，可以由第三方提供。

此外，以太坊本身也是开源软件，具备了开源项目的快速创新特性，通过代码共享让新的项目可以快速的迭代出符合市场需求的产品。目前，以太坊正被一些金融机构、银行财团（比如 R3），以及类似三星、Deloitte、RWE 和 IBM 这类的大公司所密切关注，由此也催生出了一批诸如简化和自动化金融交易、商户忠诚指数追踪、旨在实现电子交易去中心化的礼品卡等等区块链应用。
以太坊两年来得到了技术社区和商业机构的大力支持，发展迅速，未来很有可能会成为区块链领域最具竞争力的解决方案之一。

3HyperLedger
Hyperledger是一个由Linux基金会管理的开源区块链项目, 由IBM、Intel、埃森哲、JP摩根等公司领衔参与。HyperLedger被定义为：负责协调多个客户端的服务数据和低层次的“沟通和共识层”，一个致力于提高全球金融基础设施的“数据骨干”。

Hyperledger利用了和比特币相同的UTXO/script 交易决策，并根据金融服务所需要的功能进行了扩展,HyperLedger提供了一种替代POW的共识机制，是一个带有可插拔各种功能模块架构的区块链实施方案，它的目标打造成一个由全身会来共同维护的一个超级账本。是允许将数据骨干理念扩展到多个组织层,作为全新金融基础设施的重要组成部分。

为了解决不同的业务问题，区块链技术方案的侧重点也不尽相同，因此，从去中心化程度、交易确认时间、是否有挖矿费、是否支持编程、是否全节点记账、私钥丢失是否造成用户财产损失、开源程度等几个方面对现有的区块链技术方案进行汇总，具体分析结果见下表。

存在的目的:
    后端应用程序服务支持应用程序关联到移动设备或者浏览器
关键角色：
    1）通过成员服务管理末端使用者和注册者
    2）启动交易请求，发送请求到末端
Owned by
    Solution provider, Network Proprietor

NVP节点

存在的目的：
    构建交易并且将它们发送到VP节点，peer节点保存了一份所有交易的副本以便于solution providers能够在本地查询它们
关键角色：
    1.管理或者维护通过成员服务发行的用户证书
    2.构建交易并且将交易转发到VP节点
    3.维护一个本地账本，允许application owner查询当地的信息
Owned by:
    Solution Provider, Network Auditor

VP节点
存在的目的:
    创建并且确认交易事物，并且维护chaincode的状态
关键角色：
    1）管理并且维护被成员服务发布的用户证书
    2）创建交易
    3）在区块链网络上和其他VP节点一起执行交易
    4）维护本地账本副本
    5）参与共识并且更新账本
Owned by:
    Network proprietor, Solution provider

membership（在未来的1.0版本中将变成cop）
存在的目的：
    末端用户或者组织的身份发行与管理
关键角色：
    1）发行登记证书给各个末端使用者或者组织
    2）发行交易证书到关联的各个末端使用者
    3）发行TSL证书确保在HyperLedger Fabric之间通信
    4）发行链特别的Key
Owned by: Third Party service provider

注：目前我们使用的HyperLedger fabric是0.6版本，与将要发布的1.0版本相比较，Fabric有以下变动：
1)HyperLedger Fabric v1.0 membersrvc模块将独立出来成为新的COP模块。
    COP将为Hyperledger fabric提供一个类似警方的安全功能
    COP的代码将比membership servicev0.6版本更短更简单
2)HyperLedger Fabric v1.0将更具有安全性和扩展性，COP的独立出来将更使基于HyperLedger Fabric改造更简单。
3)交易加密方面也将比v0.6版本加强很多，例如供应链, FOREX market, 健康医疗方面交易更加安全

1.你可以使用本地的node.js服务来运行rest-api,确保你本机已经安转node.js,如果没有安装，请安转一个
2.命令行下安转node.js
------npm install http-server -g
3.在你本机上启动http-server运行rest-api
------cd /opt/gopath/src/github.com/hyperledger/fabric/core/rest
-------http-server -a 0.0.0.0 -p 5554 --cors
4.浏览器中输入下面语句，确保能成功连接
------http://localhost:5554/rest_api.json
5.使用命令行下载 Swagger-UI包
------git clone https://github.com/swagger-api/swagger-ui.git
6.到 /swagger-ui/dist 下用浏览器打开index.html
7.启动没有连接到leader or validator的peer节点
----cd /opt/gopath/src/github.com/hyperledger/fabric
-----build/bin/peer node start
8.测试
----cd /opt/gopath/src/github.com/hyperledger/fabric/core/rest
----go test -v -run TestServerOpenchain_API_GetBlockCount

二、Node.Js应用程序
构建并且安装 fabric core.
    cd /opt/gopath/src/github.com/hyperledger/fabric
    make peer
在本地仅仅运行一个节点 (不是一个完整的网络) :
    build/bin/peer node start
配置一个测试区块链数据结构通过vagrant来运行测试接下来重启peer进程.
    cd /opt/gopath/src/github.com/hyperledger/fabric/core/rest
    go test -v -run TestServerOpenchain_API_GetBlockCount
在本地电脑上启动http-server来运行rest_api.json服务.
    npm install http-server -g
    cd /opt/gopath/src/github.com/hyperledger/fabric/core/rest
    http-server -a 0.0.0.0 -p 5554 --cors
下载和解压 Sample_1.zip
    unzip Sample_1.zip -d Sample_1
    cd Sample_1
如果没有默认的URL地址就在openchain.js文件中更新api_url变量以搭配合适的URL
    Update the api_url variable within openchain.js to the appropriate URL if it is not already the default
    var api_url = 'http://localhost:5554/rest_api.json';
运行Node.js app
    node ./openchain.js

1、在root的Home目录下创建Docker-compose.yml并写入一下内容

membersrvc:   image: hyperledger/fabric-membersrvc   ports:     - "7054:7054"   command: membersrvc vp0:   image: hyperledger/fabric-peer   ports:     - "7050:7050"     - "7051:7051"     - "7053:7053"   environment:     - CORE_PEER_ADDRESSAUTODETECT=true     - CORE_VM_ENDPOINT=unix:///var/run/docker.sock     - CORE_LOGGING_LEVEL=DEBUG     - CORE_PEER_ID=vp0     - CORE_PEER_PKI_ECA_PADDR=membersrvc:7054     - CORE_PEER_PKI_TCA_PADDR=membersrvc:7054     - CORE_PEER_PKI_TLSCA_PADDR=membersrvc:7054     - CORE_SECURITY_ENABLED=true     - CORE_SECURITY_ENROLLID=test_vp0     - CORE_SECURITY_ENROLLSECRET=MwYpmSRjupbT   links:     - membersrvc   command: sh -c "sleep 5; peer node start --peer-chaincodedev"  

2、通过docker-compose up运行已近配置好的节点

六、进入容器
1、docker -ps 找到要进入的容器的CONTAINER ID
2、用docker-pid指令获取需要进入容器的PID
>>echo PID=(docker-pid  b4378c920828)
3、借助PID进入容器
>>sudo nsenter --target 10981 --mount --uts --ipc --net --pid

七、测试环境是否搭建好
1、选择源码中的一个例子chaincode机型编译
>>cd$GOPATH/src/github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02
>>go build
2、注册和运行chaincode
>>CORE_CHAINCODE_ID_NAME=mycc CORE_PEER_ADDRESS=0.0.0.0:7051 ./chaincode_example02

3、另起一个终端，进入容器的方式和“六”一样，以WebAppAdmin的形式登录到节点上
>>peer network login WebAppAdmin -p DJY27pEnl16d
4、执行下面的代码，在另外一个终端里面会看到执行结果
安全模式
部署交易
>>CORE_SECURITY_ENABLED=true CORE_SECURITY_PRIVACY=true peer chaincode deploy -u WebAppAdmin -n mycc -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'
调用交易
>>CORE_SECURITY_ENABLED=true CORE_SECURITY_PRIVACY=true peer chaincode invoke -u WebAppAdmin -l golang -n mycc -c '{"Function": "invoke", "Args": ["a", "b", "10"]}'
查询交易
>>CORE_SECURITY_ENABLED=true CORE_SECURITY_PRIVACY=true peer chaincode query -u WebAppAdmin -l golang -n mycc -c '{"Function": "query", "Args": ["b"]}'

简介

Hyperledger是Linux 基金会主导的一个开源的区块链(BlockChain)项目. 本文介绍了一个简单的Hyperledger智能合约的开发过程.

开发环境

本文使用Docker作为Hyperledger智能合约的本地开发环境.

第一步

从Docker官网http://www.docker.com/下载其安装包，并安装Docker.

第二步

启动Docker QuickStarter Terminal并运行如下命令在Docker中安装Hyperledger Fabric.

docker pull hyperledger/fabric-peer:latest docker pull hyperledger/fabric-membersrvc:latest

第三步

在工作目录下创建如下的docker-compose.yml

membersrvc:   image: hyperledger/fabric-membersrvc   ports:     - "7054:7054"   command: membersrvc vp0:   image: hyperledger/fabric-peer   ports:     - "7050:7050"     - "7051:7051"     - "7053:7053"   environment:     - CORE_PEER_ADDRESSAUTODETECT=true     - CORE_VM_ENDPOINT=unix:///var/run/docker.sock     - CORE_LOGGING_LEVEL=DEBUG     - CORE_PEER_ID=vp0     - CORE_PEER_PKI_ECA_PADDR=membersrvc:7054     - CORE_PEER_PKI_TCA_PADDR=membersrvc:7054     - CORE_PEER_PKI_TLSCA_PADDR=membersrvc:7054     - CORE_SECURITY_ENABLED=true     - CORE_SECURITY_ENROLLID=test_vp0     - CORE_SECURITY_ENROLLSECRET=MwYpmSRjupbT   links:     - membersrvc   command: sh -c "sleep 5; peer node start --peer-chaincodedev"

然后在Docker QuickStarter Terminal中运行以下命令以启动Hyperledger Fabric

docker-compose up

第四步

安装并运行SSH客户端，例如putty或mRemoteNG, 使用以下信息连接Docker

host : 192.168.99.100 user name : docker password : tcuser

第五步

运行如下命令以确认Hyperledger Fabric的进程

docker ps

运行如下命令以进入Hyperledger Fabric环境

docker exec -it hyperledger_vp0_1 bash

第六步

运行如下命令从git下载Hyperledger Fabric源代码

mkdir -p $GOPATH/src/github.com/hyperledger cd $GOPATH/src/github.com/hyperledger git clone http://gerrit.hyperledger.org/r/fabric

第七步

运行如下命令创建HelloWorld目录

mkdir -p $GOPATH/src/github.com/HelloWorld/ cd $GOPATH/src/github.com/HelloWorld/

创建如下HelloWorld.go文件

package main  import (     "errors"     "fmt"     "strconv"      "github.com/hyperledger/fabric/core/chaincode/shim" )   type HelloWorldChaincode struct { }  func (t *HelloWorldChaincode) Init(stub shim.ChaincodeStubInterface, function string, args []string) ([]byte, error) {     fmt.Printf("HelloWorld - Init called with function %s!\n", function)      return nil, nil }  func (t *HelloWorldChaincode) Invoke(stub shim.ChaincodeStubInterface, function string, args []string) ([]byte, error) {     fmt.Printf("HelloWorld - Invoke called with function %s!\n", function)      return nil, nil     }  func (t *HelloWorldChaincode) Query(stub shim.ChaincodeStubInterface, function string, args []string) ([]byte, error) {     fmt.Printf("HelloWorld - Query called with function %s!\n", function)      message := "Hello World"     return []byte(message), nil; }  func main() {     err := shim.Start(new(HelloWorldChaincode))     if err != nil {         fmt.Printf("Error starting Hello World chaincode: %s", err)     } }

使用如下命令编译代码

go build ./ 

第八步

使用如下命令运行HelloWorld

export CORE_CHAINCODE_ID_NAME=mycc export CORE_PEER_ADDRESS=0.0.0.0:7051 ./HelloWorld &

第九步

向Hyperledger服务接口http://192.168.99.100:7050/registrar 发送如下REST请求，使用内置的jim用户登录系统

{     "enrollId": "jim",     "enrollSecret": "6avZQLwcUe9b" }

第十步

向Hyperledger服务接口http://192.168.99.100:7050/chaincode 发送如下初始化HelloWorld的REST请求

{    "jsonrpc": "2.0",    "method": "deploy",    "params": {     "type": 1,     "chaincodeID":{         "name": "mycc"     },     "ctorMsg": {          "function":"init",          "args":[]      },     "secureContext": "jim"   },    "id": 1  }

调用HelloWorld的REST请求

{    "jsonrpc": "2.0",    "method": "invoke",    "params": {        "type": 1,        "chaincodeID":{            "name":"mycc"        },        "ctorMsg": {           "function":"invoke",           "args":[]        },        "secureContext": "jim"    },    "id": 3  }  

以及查询HelloWorld的REST请求

{    "jsonrpc": "2.0",    "method": "query",    "params": {        "type": 1,        "chaincodeID":{            "name":"mycc"        },        "ctorMsg": {           "function":"query",           "args":[]        },        "secureContext": "jim"    },    "id": 5  }

总结

本文介绍了一个简单的Hyperledger智能合约在本地Docker环境下的开发过程.

http://www.cnblogs.com/huyouhengbc/p/5934683.html#3545114

有些人说以太坊太难对付，于是我们(译注：指Consensys, 下同)写了这篇文章来帮助大家学习如何利用以太坊编写智能合约和应用。这里所用到的工具，钱包，应用程序以及整个生态系统仍处于开发状态，它们将来会更好用！

• 第一部分概述，讨论了关键概念，几大以太坊客户端以及写智能合约用到的编程语言。
• 第二部分讨论了总体的工作流程，以及目前流行的一些DApp框架和工具。
• 第三部分主要关于编程，我们将学习如何使用Truffle来为智能合约编写测试和构建DApp。

第一部分. 概述

如果你对诸如比特币以及其工作原理等密码学货币的概念完全陌生，我们建议你先看看Andreas Antonopoulos所著的Bitcoin Book的头几章，然后读一下以太坊白皮书。(译注：以太坊白皮书中文版请看 http://ethfans.org/posts/ethereum-whitepaper)

如果你觉得白皮书中的章节太晦涩，也可以直接动手来熟悉以太坊。在以太坊上做开发并不要求你理解所有那些“密码经济计算机科学”(crypto economic computer science)，而白皮书的大部分是关于以太坊想对于比特币架构上的改进。

新手教程

ethereum.org提供了官方的新手入门教程，以及一个代币合约和众筹合约的教程。合约语言Solidity也有官方文档。学习智能合约的另一份不错的资料（也是我的入门资料）是dappsForBeginners，不过现在可能有些过时了。

这篇文章的目的是成为上述资料的补充，同时介绍一些基本的开发者工具，使入门以太坊，智能合约以及构建DApps(decentralized apps, 分布式应用)更加容易。我会试图按照我自己(依然是新手)的理解来解释工作流程中的每一步是在做什么，我也得到了ConsenSys酷酷的开发者们的许多帮助。

基本概念

了解这些名词是一个不错的开始：

公钥加密系统。 Alice有一把公钥和一把私钥。她可以用她的私钥创建数字签名，而Bob可以用她的公钥来验证这个签名确实是用Alice的私钥创建的，也就是说，确实是Alice的签名。当你创建一个以太坊或者比特币钱包的时候，那长长的0xdf...5f地址实质上是个公钥，对应的私钥保存某处。类似于Coinbase的在线钱包可以帮你保管私钥，你也可以自己保管。如果你弄丢了存有资金的钱包的私钥，你就等于永远失去了那笔资金，因此你最好对私钥做好备份。过来人表示：通过踩坑学习到这一点是非常痛苦的...

点对点网络。 就像BitTorrent, 以太坊分布式网络中的所有节点都地位平等，没有中心服务器。(未来会有半中心化的混合型服务出现为用户和开发者提供方便，这我们后面会讲到。)

区块链。 区块链就像是一个全球唯一的帐簿，或者说是数据库，记录了网络中所有交易历史。

以太坊虚拟机(EVM)。 它让你能在以太坊上写出更强大的程序（比特币上也可以写脚本程序）。它有时也用来指以太坊区块链，负责执行智能合约以及一切。

节点。 你可以运行节点，通过它读写以太坊区块链，也即使用以太坊虚拟机。完全节点需要下载整个区块链。轻节点仍在开发中。

矿工。 挖矿，也就是处理区块链上的区块的节点。这个网页可以看到当前活跃的一部分以太坊矿工：stats.ethdev.com。

工作量证明。 矿工们总是在竞争解决一些数学问题。第一个解出答案的(算出下一个区块)将获得以太币作为奖励。然后所有节点都更新自己的区块链。所有想要算出下一个区块的矿工都有与其他节点保持同步，并且维护同一个区块链的动力，因此整个网络总是能达成共识。(注意：以太坊正计划转向没有矿工的权益证明系统(POS)，不过那不在本文讨论范围之内。)

以太币。 缩写ETH。一种你可以购买和使用的真正的数字货币。这里是可以交易以太币的其中一家交易所的走势图。在写这篇文章的时候，1个以太币价值65美分。

Gas. (汽油) 在以太坊上执行程序以及保存数据都要消耗一定量的以太币，Gas是以太币转换而成。这个机制用来保证效率。

DApp. 以太坊社区把基于智能合约的应用称为去中心化的应用程序(Decentralized App)。DApp的目标是(或者应该是)让你的智能合约有一个友好的界面，外加一些额外的东西，例如IPFS（可以存储和读取数据的去中心化网络，不是出自以太坊团队但有类似的精神)。DApp可以跑在一台能与以太坊节点交互的中心化服务器上，也可以跑在任意一个以太坊平等节点上。(花一分钟思考一下：与一般的网站不同，DApp不能跑在普通的服务器上。他们需要提交交易到区块链并且从区块链而不是中心化数据库读取重要数据。相对于典型的用户登录系统，用户有可能被表示成一个钱包地址而其它用户数据保存在本地。许多事情都会与目前的web应用有不同架构。)

如果想看看从另一个新手视角怎么理解这些概念，请读Just Enough Bitcoin for Ethereum。

以太坊客户端，智能合约语言

编写和部署智能合约并不要求你运行一个以太坊节点。下面有列出基于浏览器的IDE和API。但如果是为了学习的话，还是应该运行一个以太坊节点，以便理解其中的基本组件，何况运行节点也不难。

运行以太坊节点可用的客户端

以太坊有许多不同语言的客户端实现（即多种与以太坊网络交互的方法），包括C++, Go, Python, Java, Haskell等等。为什么需要这么多实现？不同的实现能满足不同的需求（例如Haskell实现的目标是可以被数学验证），能使以太坊更加安全，能丰富整个生态系统。

在写作本文时，我使用的是Go语言实现的客户端geth (go-ethereum)，其他时候还会使用一个叫testrpc的工具, 它使用了Python客户端pyethereum。后面的例子会用到这些工具。

注: 我曾经使用过C++的客户端，现在仍然在用其中的ethminer组件和geth配合挖矿，因此这些不同的组件是可以一起工作的。
关于挖矿：挖矿很有趣，有点像精心照料你的室内盆栽，同时又是一种了解整个系统的方法。虽然以太币现在的价格可能连电费都补不齐，但以后谁知道呢。人们正在创造许多酷酷的DApp, 可能会让以太坊越来越流行。

交互式控制台。 客户端运行起来后，你就可以同步区块链，建立钱包，收发以太币了。使用geth的一种方式是通过Javascript控制台（JavaScript console, 类似你在chrome浏览器里面按F12出来的那个，只不过是跑在终端里）。此外还可以使用类似cURL的命令通过JSON RPC来与客户端交互。本文的目标是带大家过一边DApp开发的流程，因此这块就不多说了。但是我们应该记住这些命令行工具是调试，配置节点，以及使用钱包的利器。

在测试网络运行节点。 如果你在正式网络运行geth客户端，下载整个区块链与网络同步会需要相当时间。（你可以通过比较节点日志中打印的最后一个块号和stats.ethdev.com上列出的最新块来确定是否已经同步。) 另一个问题是在正式网络上跑智能合约需要实实在在的以太币。在测试网络上运行节点的话就没有这个问题。此时也不需要同步整个区块链，创建一个自己的私有链就勾了，对于开发来说更省时间。

testrpc. 用geth可以创建一个测试网络，另一种更快的创建测试网络的方法是使用testrpc. Testrpc可以在启动时帮你创建一堆存有资金的测试账户。它的运行速度也更快因此更适合开发和测试。你可以从testrpc起步，然后随着合约慢慢成型，转移到geth创建的测试网络上 - 启动方法很简单，只需要指定一个networkid：geth --networkid "12345"。这里是testrpc的代码仓库，下文我们还会再讲到它。

接下来我们来谈谈可用的编程语言，之后就可以开始真正的编程了。

写智能合约用的编程语言

用Solidity就好。 要写智能合约有好几种语言可选：有点类似Javascript的Solidity, 文件扩展名是.sol. 和Python接近的Serpent, 文件名以.se结尾。还有类似Lisp的LLL。Serpent曾经流行过一段时间，但现在最流行而且最稳定的要算是Solidity了，因此用Solidity就好。听说你喜欢Python? 用Solidity。

solc编译器。 用Solidity写好智能合约之后，需要用solc来编译。它是一个来自C++客户端实现的组件（又一次，不同的实现产生互补），这里是安装方法。如果你不想安装solc也可以直接使用基于浏览器的编译器，例如Solidity real-time compiler或者Cosmo。后文有关编程的部分会假设你安装了solc。

注意：以太坊正处于积极的开发中，有时候新的版本之间会有不同步。确认你使用的是最新的dev版本，或者稳定版本。如果遇到问题可以去以太坊项目对应的Gitter聊天室或者forums.ethereum.org上问问其他人在用什么版本。

web3.js API. 当Solidity合约编译好并且发送到网络上之后，你可以使用以太坊的web3.js JavaScript API来调用它，构建能与之交互的web应用。

以上就是在以太坊上编写智能合约和构建与之交互的DApp所需的基本工具。

第二部分. DApp框架，工具以及工作流程

DApp开发框架

虽然有上文提到的工具就可以进行开发了，但是使用社区大神们创造的框架会让开发更容易。

Truffle and Embark. 是Truffle把我领进了门。在Truffle出现之前的那个夏天，我目睹了一帮有天分的学生是如何不眠不休的参加一个hackathon（编程马拉松）活动的，虽然结果相当不错，但我还是吓到了。然后Truffle出现了，帮你处理掉大量无关紧要的小事情，让你可以迅速进入写代码-编译-部署-测试-打包DApp这个流程。另外一个相似的DApp构建与测试框架是Embark。我只用过Truffle, 但是两个阵营都拥有不少DApp大神。

Meteor. 许多DApp开发者使用的另一套开发栈由web3.js和Meteor组成，Meteor是一套通用webapp开发框架（ethereum-meteor-wallet项目提供了一个很棒的入门实例，而SilentCiero正在构建大量Meteor与web3.js和DApp集成的模板）。我下载并运行过一些不错的DApp是以这种方式构造的。在11月9日至13日的以太坊开发者大会ÐΞVCON1上将有一些有趣的讨论，是关于使用这些工具构建DApp以及相关最佳实践的（会议将会在YouTube上直播）。

APIs. BlockApps.net打算提供一套RESTful API给DApp使用以免去开发者运行本地节点的麻烦，这个中心化服务是基于以太坊Haskell实现的。这与DApp的去中心化模型背道而驰，但是在本地无法运行以太坊节点的场合非常有用，比如在你希望只有浏览器或者使用移动设备的用户也能使用你的DApp的时候。BlockApps提供了一个命令行工具bloc，注册一个开发者帐号之后就可以使用。

许多人担心需要运行以太坊节点才能使用DApp的话会把用户吓跑，其实包括BlockApps在内的许多工具都能解决这个问题。Metamask允许你在浏览器里面使用以太坊的功能而无需节点，以太坊官方提供的AlethZero或者AlethOne是正在开发中有易用界面的客户端，ConsenSys正在打造一个轻钱包LightWallet，这些工具都会让DApp的使用变得更容易。轻客户端和水平分片(sharding)也在计划和开发之中。这是一个能进化出混合架构的P2P生态系统。

智能合约集成开发环境 (IDE)

IDE. 以太坊官方出品了用来编写智能合约的Mix IDE，我还没用过但会尽快一试。

基于浏览器的IDE. Solidity real-time compiler和Cosmo都可以让你快速开始在浏览器中编写智能合约。你甚至可以让这些工具使用你的本地节点，只要让本地节点开一个端口（注意安全！这些工具站点必须可信，而且千万不要把你的全部身家放在这样一个本地节点里面！Cosmo UI上有如何使用geth做到这一点的指引）。在你的智能合约调试通过之后，可以用开发框架来给它添加用户界面和打包成DApp，这正是Truffle的工作，后面的编程章节会有详细讲解。

Ether.Camp正在开发另一个强大的企业级浏览器IDE。他们的IDE将支持沙盒测试网络，自动生成用于测试的用户界面（取代后文将展示的手动编写测试），以及一个测试交易浏览器test.ether.camp。当你的合约准备正式上线之前，使用他们的测试网络会是确保你的智能合约在一个接近真实的环境工作正常的好方法。他们也为正式网络提供了一个交易浏览器frontier.ether.camp，上面可以看到每一笔交易的细节。在本文写作时Ether.Camp的IDE还只能通过邀请注册，预计很快会正式发布。

合约和Dapp示例。 在Github上搜索DApp仓库和.sol文件可以看到进行中的有趣东西。这里有一个DApp大列表：dapps.ethercasts.com，不过其中一些项目已经过时。Ether.fund/contracts上有一些Solidity和Serpent写的合约示例，但是不清楚这些例子有没有经过测试或者正确性验证。11月12日的开发者大会ÐΞVCON1将会有一整天的DApp主题演讲。

部署智能合约的流程

流程如下：

1. 启动一个以太坊节点 (例如geth或者testrpc)。
2. 使用solc*编译*智能合约。 => 获得二进制代码。
3. 将编译好的合约部署到网络。（这一步会消耗以太币，还需要使用你的节点的默认地址或者指定地址来给合约签名。） => 获得合约的区块链地址和ABI（合约接口的JSON表示，包括变量，事件和可以调用的方法）。(译注：作者在这里把ABI与合约接口弄混了。ABI是合约接口的二进制表示。)
4. 用web3.js提供的JavaScript API来调用合约。（根据调用的类型有可能会消耗以太币。）

下图详细描绘了这个流程：

你的DApp可以给用户提供一个界面先部署所需合约再使用之（如图1到4步），也可以假设合约已经部署了（常见方法），直接从使用合约（如图第6步）的界面开始。

第三部分. 编程

在Truffle中进行测试

Truffle用来做智能合约的测试驱动开发(TDD)非常棒，我强烈推荐你在学习中使用它。它也是学习使用JavaScript Promise的一个好途径，例如deferred和异步调用。Promise机制有点像是说“做这件事，如果结果是这样，做甲，如果结果是那样，做乙... 与此同时不要在那儿干等着结果返回，行不？”。Truffle使用了包装web3.js的一个JS Promise框架Pudding（因此它为为你安装web3.js）。(译注：Promise是流行于JavaScript社区中的一种异步调用模式。它很好的封装了异步调用，使其能够灵活组合，而不会陷入callback hell.)

Transaction times. Promise对于DApp非常有用，因为交易写入以太坊区块链需要大约12-15秒的时间。即使在测试网络上看起来没有那么慢，在正式网络上却可能会要更长的时间（例如你的交易可能用光了Gas，或者被写入了一个孤儿块）。

下面让我们给一个简单的智能合约写测试用例吧。

使用Truffle

首先确保你 1.安装好了solc以及 2.testrpc。（testrpc需要Python和pip。如果你是Python新手，你可能需要用virtualenv来安装，这可以将Python程序库安装在一个独立的环境中。）

接下来安装 3.Truffle（你可以使用NodeJS's npm来安装：npm install -g truffle, -g开关可能会需要sudo）。安装好之后，在命令行中输入truffle list来验证安装成功。然后创建一个新的项目目录（我把它命名为'conference'），进入这个目录，运行truffle init。该命令会建立如下的目录结构：

现在让我们在另一个终端里通过执行testrpc来启动一个节点（你也可以用geth）：

回到之前的终端中，输入truffle deploy。这条命令会部署之前truffle init产生的模板合约到网络上。任何你可能遇到的错误信息都会在testrpc的终端或者执行truffle的终端中输出。

在开发过程中你随时可以使用truffle compile命令来确认你的合约可以正常编译（或者使用solc YourContract.sol），truffle deploy来编译和部署合约，最后是truffle test来运行智能合约的测试用例。

第一个合约

下面是一个针对会议的智能合约，通过它参会者可以买票，组织者可以设置参会人数上限，以及退款策略。本文涉及的所有代码都可以在这个代码仓库找到。

contract Conference {   address public organizer;   mapping (address => uint) public registrantsPaid;   uint public numRegistrants;   uint public quota;    event Deposit(address _from, uint _amount);  // so you can log these events   event Refund(address _to, uint _amount);     function Conference() { // Constructor     organizer = msg.sender;     quota = 500;     numRegistrants = 0;   }   function buyTicket() public returns (bool success) {     if (numRegistrants >= quota) { return false; }     registrantsPaid[msg.sender] = msg.value;     numRegistrants++;     Deposit(msg.sender, msg.value);     return true;   }   function changeQuota(uint newquota) public {     if (msg.sender != organizer) { return; }     quota = newquota;   }   function refundTicket(address recipient, uint amount) public {     if (msg.sender != organizer) { return; }     if (registrantsPaid[recipient] == amount) {        address myAddress = this;       if (myAddress.balance >= amount) {          recipient.send(amount);         registrantsPaid[recipient] = 0;         numRegistrants--;         Refund(recipient, amount);       }     }   }   function destroy() { // so funds not locked in contract forever     if (msg.sender == organizer) {        suicide(organizer); // send funds to organizer     }   } }

接下来让我们部署这个合约。（注意：本文写作时我使用的是Mac OS X 10.10.5, solc 0.1.3+ (通过brew安装)，Truffle v0.2.3, testrpc v0.1.18 (使用venv)）

部署合约

(译注：图中步骤翻译如下：）

使用truffle部署智能合约的步骤：
1. truffle init (在新目录中) => 创建truffle项目目录结构
2. 编写合约代码，保存到contracts/YourContractName.sol文件。
3. 把合约名字加到config/app.json的'contracts'部分。
4. 启动以太坊节点（例如在另一个终端里面运行testrpc）。
5. truffle deploy（在truffle项目目录中)

添加一个智能合约。 在truffle init执行后或是一个现有的项目目录中，复制粘帖上面的会议合约到contracts/Conference.sol文件中。然后打开config/app.json文件，把'Conference'加入'deploy'数组中。

启动testrpc。 在另一个终端中启动testrpc。

编译或部署。 执行truffle compile看一下合约是否能成功编译，或者直接truffle deploy一步完成编译和部署。这条命令会把部署好的合约的地址和ABI（应用接口）加入到配置文件中，这样之后的truffle test和truffle build步骤可以使用这些信息。

出错了？ 编译是否成功了？记住，错误信息即可能出现在testrpc终端也可能出现在truffle终端。

重启节点后记得重新部署！ 如果你停止了testrpc节点，下一次使用任何合约之前切记使用truffle deploy重新部署。testrpc在每一次重启之后都会回到完全空白的状态。

合约代码解读

让我们从智能合约头部的变量声明开始：

address public organizer; mapping (address => uint) public registrantsPaid; uint public numRegistrants; uint public quota;

address. 地址类型。第一个变量是会议组织者的钱包地址。这个地址会在合约的构造函数function Conference()中被赋值。很多时候也称呼这种地址为'owner'（所有人）。

uint. 无符号整型。区块链上的存储空间很紧张，保持数据尽可能的小。

public. 这个关键字表明变量可以被合约之外的对象使用。private修饰符则表示变量只能被本合约(或者衍生合约)内的对象使用。如果你想要在测试中通过web3.js使用合约中的某个变量，记得把它声明为public。

Mapping或数组。（译注：Mapping类似Hash, Directory等数据类型，不做翻译。）在Solidity加入数组类型之前，大家都使用类似mapping (address => uint)的Mapping类型。这个声明也可以写作address registrantsPaid[]，不过Mapping的存储占用更小(smaller footprint)。这个Mapping变量会用来保存参加者（用他们的钱包地址表示）的付款数量以便在退款时使用。

关于地址。 你的客户端（比如testrpc或者geth）可以生成一个或多个账户/地址。testrpc启动时会显示10个可用地址：

第一个地址, accounts[0]，是发起调用的默认地址，如果没有特别指定的话。

组织者地址 vs. 合约地址。 部署好的合约会在区块链上拥有自己的地址（与组织者拥有的是不同的地址）。在Solidity合约中可以使用this来访问这个合约地址，正如refundTicket函数所展示的：address myAddress = this;

Suicide, Solidity的好东西。（译注：suicide意为'自杀', 为Solidity提供的关键字，不做翻译。）转给合约的资金会保存于合约（地址）中。最终这些资金通过destroy函数被释放给了构造函数中设置的组织者地址。这是通过suicide(orgnizer);这行代码实现的。没有这个，资金可能被永远锁定在合约之中（reddit上有些人就遇到过），因此如果你的合约会接受资金一定要记得在合约中使用这个方法！

如果想要模拟另一个用户或者对手方（例如你是卖家想要模拟一个买家），你可以使用可用地址数组中另外的地址。假设你要以另一个用户，accounts[1], 的身份来买票，可以通过from参数设置：

conference.buyTicket({ from: accounts[1], value: some_ticket_price_integer });

函数调用可以是交易。 改变合约状态（修改变量值，添加记录，等等）的函数调用本身也是转账交易，隐式的包含了发送人和交易价值。因此web3.js的函数调用可以通过指定{ from: __, value: __ }参数来发送以太币。在Solidity合约中，你可以通过msg.sender和msg.value来获取这些信息：

function buyTicket() public {     ...     registrantsPaid[msg.sender] = msg.value;     ... }

事件(Event)。 可选的功能。合约中的Deposit（充值）和Send（发送）事件是会被记录在以太坊虚拟机日志中的数据。它们实际上没有任何作用，但是用事件(Event)把交易记录进日志是好的做法。

好了，现在让我们给这个智能合约写一个测试，来确保它能工作。

写测试

把项目目录test/中的example.js文件重命名为conference.js，文件中所有的'Example'替换为'Conference'。

contract('Conference', function(accounts) {   it("should assert true", function(done) {     var conference = Conference.at(Conference.deployed_address);     assert.isTrue(true);     done();   // stops tests at this point   }); });

在项目根目录下运行truffle test，你应该看到测试通过。在上面的测试中truffle通过Conference.deployed_address获得合约部署在区块链上的地址。

让我们写一个测试来初始化一个新的Conference，然后检查变量都正确赋值了。将conference.js中的测试代码替换为：

contract('Conference', function(accounts) {   it("Initial conference settings should match", function(done) {     var conference = Conference.at(Conference.deployed_address);       // same as previous example up to here     Conference.new({ from: accounts[0]  })     .then(function(conference) {       conference.quota.call().then(           function(quota) {             assert.equal(quota, 500, "Quota doesn't match!");            }).then( function() {             return conference.numRegistrants.call();           }).then( function(num) {             assert.equal(num, 0, "Registrants should be zero!");             return conference.organizer.call();           }).then( function(organizer) {             assert.equal(organizer, accounts[0], "Owner doesn't match!");             done();   // to stop these tests earlier, move this up         }).catch(done);       }).catch(done);     });   });

构造函数。 Conference.new({ from: accounts[0] })通过调用合约构造函数创造了一个新的Conference实例。由于不指定from时会默认使用accounts[0]，它其实可以被省略掉：

Conference.new({ from: accounts[0] }); // 和Conference.new()效果相同

Promise. 代码中的那些then和return就是Promise。它们的作用写成一个深深的嵌套调用链的话会是这样：

conference.numRegistrants.call().then(   function(num) {     assert.equal(num, 0, "Registrants should be zero!");     conference.organizer.call().then(      function(organizer) {         assert.equal(organizer, accounts[0], "Owner doesn't match!");         }).then(           function(...))             }).then(               function(...))             // Because this would get hairy...

Promise减少嵌套，使代码变得扁平，允许调用异步返回，并且简化了表达“成功时做这个”和“失败时做那个”的语法。Web3.js通过回调函数实现异步调用，因此你不需要等到交易完成就可以继续执行前端代码。Truffle借助了用Promise封装web3.js的一个框架，叫做Pudding，这个框架本身又是基于Bluebird的，它支持Promise的高级特性。

call. 我们使用call来检查变量的值，例如conference.quota.call().then(...，还可以通过传参数，例如call(0), 来获取mapping在index 0处的元素。Solidity的文档说这是一种特殊的“消息调用”因为 1.不会为矿工记录和 2.不需要从钱包账户/地址发起（因此它没有被账户持有者私钥做签名）。另一方面，交易/事务(Transaction)会被矿工记录，必须来自于一个账户（也就是有签名），会被记录到区块链上。对合约中数据做的任何修改都是交易。仅仅是检查一个变量的值则不是。因此在读取变量时不要忘记加上call()！否则会发生奇怪的事情。（此外如果在读取变量是遇到问题别忘记检查它是否是public。）call()也能用于调用不是交易的函数。如果一个函数本来是交易，但你却用call()来调用，则不会在区块链上产生交易。

断言。 标准JS测试中的断言（如果你不小心拼成了复数形式'asserts'，truffle会报错，让你一头雾水），assert.equal是最常用的，其他类型的断言可以在Chai的文档中找到。

再一次运行truffle test确保一切工作正常。

测试合约函数调用

现在我们测试一下改变quote变量的函数能工作。在tests/conference.js文件的contract('Conference', function(accounts) {...};)的函数体中添加如下测试用例：

it("Should update quota", function(done) {   var c = Conference.at(Conference.deployed_address);    Conference.new({from: accounts[0] }).then(     function(conference) {       conference.quota.call().then(          function(quota) {            assert.equal(quota, 500, "Quota doesn't match!");          }).then( function() {            return conference.changeQuota(300);         }).then( function(result) {  // result here is a transaction hash           console.log(result);  // if you were to print this out it’d be long hex - the transaction hash           return conference.quota.call()         }).then( function(quota) {            assert.equal(quota, 300, "New quota is not correct!");           done();         }).catch(done);     }).catch(done); });

这里的新东西是调用changeQuota函数的那一行。console.log对于调试很有用，用它能在运行truffle的终端中输出信息。在关键点插入console.log可以查看执行到了哪一步。记得把Solidity合约中changeQuota函数被声明为public，否则你不能调用它：

  function changeQuota(uint newquota) public {  }

测试交易

现在让我们调用一个需要发起人发送资金的函数。

Wei. 以太币有很多种单位（这里有个很有用的转换器）,在合约中通常用的是Wei，最小的单位。Web3.js提供了在各单位与Wei之间互相转换的便利方法，形如web3.toWei(.05, 'ether')。JavaScript在处理很大的数字时有问题，因此web3.js使用了程序库BigNumber，并建议在代码各处都以Wei做单位，直到要给用户看的时候（文档。

账户余额。 Web3.js提供了许多提供方便的方法，其中另一个会在下面测试用到的是web3.eth.getBalance(some_address)。记住发送给合约的资金会由合约自己持有直到调用suicide。

在contract(Conference, function(accounts) {...};)的函数体中插入下面的测试用例。在高亮显示的方法中，测试用例让另一个用户(accounts[1])以ticketPrice的价格买了一张门票。然后它检查合约的账户余额增加了ticketPrice，以及购票用户被加入了参会者列表。

这个测试中的buyTicket是一个交易函数：

it("Should let you buy a ticket", function(done) {   var c = Conference.at(Conference.deployed_address);    Conference.new({ from: accounts[0] }).then(     function(conference) {       var ticketPrice = web3.toWei(.05, 'ether');       var initialBalance = web3.eth.getBalance(conference.address).toNumber();        conference.buyTicket({ from: accounts[1], value: ticketPrice }).then(         function() {           var newBalance = web3.eth.getBalance(conference.address).toNumber();           var difference = newBalance - initialBalance;           assert.equal(difference, ticketPrice, "Difference should be what was sent");           return conference.numRegistrants.call();       }).then(function(num) {           assert.equal(num, 1, "there should be 1 registrant");           return conference.registrantsPaid.call(accounts[1]);       }).then(function(amount) {           assert.equal(amount.toNumber(), ticketPrice, "Sender's paid but is not listed");           done();       }).catch(done);   }).catch(done); });

交易需要签名。 和之前的函数调用不同，这个调用是一个会发送资金的交易，在这种情况下购票用户(accounts[1])会用他的私钥对buyTicket()调用做签名。（在geth中用户需要在发送资金之前通过输入密码来批准这个交易或是解锁钱包的账户。）

toNumber(). 有时我们需要把Solidity返回的十六进制结果转码。如果结果可能是个很大的数字可以用web3.toBigNumber(numberOrHexString)来处理因为JavaScript直接对付大数要糟。

测试包含转账的合约

最后，为了完整性，我们确认一下refundTicket方法能正常工作，而且只有会议组织者能调用。下面是测试用例：

it("Should issue a refund by owner only", function(done) {   var c = Conference.at(Conference.deployed_address);    Conference.new({ from: accounts[0] }).then(     function(conference) {       var ticketPrice = web3.toWei(.05, 'ether');       var initialBalance = web3.eth.getBalance(conference.address).toNumber();         conference.buyTicket({ from: accounts[1], value: ticketPrice }).then(         function() {           var newBalance = web3.eth.getBalance(conference.address).toNumber();           var difference = newBalance - initialBalance;           assert.equal(difference, ticketPrice, "Difference should be what was sent");  // same as before up to here           // Now try to issue refund as second user - should fail           return conference.refundTicket(accounts[1], ticketPrice, {from: accounts[1]});           }).then(           function() {             var balance = web3.eth.getBalance(conference.address).toNumber();             assert.equal(web3.toBigNumber(balance), ticketPrice, "Balance should be unchanged");             // Now try to issue refund as organizer/owner - should work             return conference.refundTicket(accounts[1], ticketPrice, {from: accounts[0]});           }).then(           function() {             var postRefundBalance = web3.eth.getBalance(conference.address).toNumber();             assert.equal(postRefundBalance, initialBalance, "Balance should be initial balance");             done();         }).catch(done);     }).catch(done);  });

这个测试用例覆盖的Solidity函数如下：

function refundTicket(address recipient, uint amount) public returns (bool success) {   if (msg.sender != organizer) { return false; }   if (registrantsPaid[recipient] == amount) {      address myAddress = this;     if (myAddress.balance >= amount) {        recipient.send(amount);       Refund(recipient, amount);       registrantsPaid[recipient] = 0;       numRegistrants--;       return true;     }   }   return false; }

合约中发送以太币。 address myAddress = this展示了如何获取该会议合约实例的地址，以变接下来检查这个地址的余额（或者直接使用this.balance）。合约通过recipient.send(amount)方法把资金发回了购票人。

交易无法返回结果给web3.js. 注意这一点！refundTicket函数会返回一个布尔值，但是这在测试中无法检查。因为这个方法是一个交易函数（会改变合约内数据或是发送以太币的调用），而web3.js得到的交易运行结果是一个交易哈希（如果打印出来是一个长长的十六进制/怪怪的字符串）。既然如此为什么还要让refundTicket返回一个值？因为在Solidity合约内可以读到这个返回值，例如当另一个合约调用refundTicket()的时候。也就是说Solidity合约可以读取交易运行的返回值，而web3.js不行。另一方面，在web3.js中你可以用事件机制（Event, 下文会解释）来监控交易运行，而合约不行。合约也无法通过call()来检查交易是否修改了合约内变量的值。

关于sendTransaction(). 当你通过web3.js调用类似buyTicket()或者refundTicket()的交易函数时（使用web3.eth.sendTransaction），交易并不会立即执行。事实上交易会被提交到矿工网络中，交易代码直到其中一位矿工产生一个新区块把交易记录进区块链之后才执行。因此你必须等交易进入区块链并且同步回本地节点之后才能验证交易执行的结果。用testrpc的时候可能看上去是实时的，因为测试环境很快，但是正式网络会比较慢。

事件/Event. 在web3.js中你应该监听事件而不是返回值。我们的智能合约示例定义了这些事件：

event Deposit(address _from, uint _amount); event Refund(address _to, uint _amount);

它们在buyTicket()和refundTicket()中被触发。触发时你可以在testrpc的输出中看到日志。要监听事件，你可以使用web.js监听器(listener)。在写本文时我还不能在truffle测试中记录事件，但是在应用中没问题：

Conference.new({ from: accounts[0] }).then(   function(conference) {     var event = conference.allEvents().watch({}, ''); // or use conference.Deposit() or .Refund()     event.watch(function (error, result) {       if (error) {         console.log("Error: " + error);       } else {         console.log("Event: " + result.event);       }     });     // ...

过滤器/Filter. 监听所有事件可能会产生大量的轮询，作为替代可以使用过滤器。它们可以更灵活的开始或是停止对事件的监听。更多过滤器的信息可查看Solidity文档。

总的来说，使用事件和过滤器的组合比检查变量消耗的Gas更少，因而在验证正式网络的交易运行结果时非常有用。

Gas. （译注：以太坊上的燃料，因为代码的执行必须消耗Gas。直译为汽油比较突兀，故保留原文做专有名词。）直到现在我们都没有涉及Gas的概念，因为在使用testrpc时通常不需要显式的设置。当你转向geth和正式网络时会需要。在交易函数调用中可以在{from: __, value: __, gas: __}对象内设置Gas参数。Web3.js提供了web3.eth.gasPrice调用来获取当前Gas的价格，Solidity编译器也提供了一个参数让你可以从命令行获取合约的Gas开销概要：solc --gas YouContract.sol。下面是Conference.sol的结果：

为合约创建DApp界面

下面的段落会假设你没有网页开发经验。

上面编写的测试用例用到的都是在前端界面中也可以用的方法。你可以把前端代码放到app/目录中，运行truffle build之后它们会和合约配置信息一起编译输出到build/目录。在开发时可以使用truffle watch命令在app/有任何变动时自动编译输出到build/目录。然后在浏览器中刷新页面即可看到build/目录中的最新内容。（truffle serve可以启动一个基于build/目录的网页服务器。）

app/目录中有一些样板文件帮助你开始：

index.html会加载app.js：

因此我们只需要添加代码到app.js就可以了。

默认的app.js会在浏览器的console(控制台)中输出一条"Hello from Truffle!"的日志。在项目根目录中运行truffle watch，然后在浏览器中打开build/index.html文件，再打开浏览器的console就可以看到。（大部分浏览器例如Chrome中，单击右键 -> 选择Inspect Element然后切换到Console即可。）

在app.js中，添加一个在页面加载时会运行的window.onload调用。下面的代码会确认web3.js已经正常载入并显示所有可用的账户。（注意：你的testrpc节点应该保持运行。）

window.onload = function() {   var accounts = web3.eth.accounts;   console.log(accounts); }

看看你的浏览器console中看看是否打印出了一组账户地址。

现在你可以从tests/conference.js中复制一些代码过来（去掉只和测试有关的断言），将调用返回的结果输出到console中以确认代码能工作。下面是个例子：

window.onload = function() {   var accounts = web3.eth.accounts;   var c = Conference.at(Conference.deployed_address);    Conference.new({ from: accounts[0] }).then(     function(conference) {      var ticketPrice = web3.toWei(.05, 'ether');     var initialBalance = web3.eth.getBalance(conference.address).toNumber();      console.log("The conference's initial balance is: " + initialBalance);      conference.buyTicket({ from: accounts[1], value: ticketPrice }).then(       function() {         var newBalance = web3.eth.getBalance(conference.address).toNumber();         console.log("After someone bought a ticket it's: " + newBalance);         return conference.refundTicket(accounts[1], ticketPrice, {from: accounts[0]});       }).then(         function() {             var balance = web3.eth.getBalance(conference.address).toNumber();           console.log("After a refund it's: " + balance);       });   }); };

上面的代码应该输出如下：

(console输出的warning信息可忽略。)

现在起你就可以使用你喜欢的任何前端工具，jQuery, ReactJS, Meteor, Ember, AngularJS，等等等等，在app/目录中构建可以与以太坊智能合约互动的DApp界面了！接下来我们给出一个极其简单基于jQuery的界面作为示例。

这里是index.html的代码，这里是app.js的代码。

通过界面测试了智能合约之后我意识到最好加入检查以保证相同的用户不能注册两次。另外由于现在是运行在testrpc节点上，速度很快，最好是切换到geth节点并确认交易过程依然能及时响应。否则的话界面上就应该显示提示信息并且在处理交易时禁用相关的按钮。

尝试geth. 如果你使用geth, 可以尝试以下面的命令启动 - 在我这儿(geth v1.2.3)工作的很好：

build/bin/geth --rpc --rpcaddr="0.0.0.0" --rpccorsdomain="*" --mine --unlock='0 1' --verbosity=5 --maxpeers=0 --minerthreads='4'  --networkid '12345' --genesis test-genesis.json

这条命令解锁了两个账户, 0和1。1. 在geth控制台启动后你可能需要输入这两个账户的密码。2. 你需要在test-genesis.json文件里面的'alloc'配置中加入你的这两个账户，并且给它们充足的资金。3. 最后，在创建合约实例时加上gas参数：

Conference.new({from: accounts[0], gas: 3141592})

然后把整个truffle deploy, truffle build流程重来一遍。

教程中的代码。 在这篇基础教程中用到的所有代码都可以在这个代码仓库中找到。

自动为合约生成界面。 SilentCicero制作了一个叫做DApp Builder的工具，可以用Solidity合约自动生成HTML, jQuery和web.js的代码。这种模式也正在被越来越多的正在开发中的开发者工具采用。

教程到此结束！ 最后一章我们仅仅学习了一套工具集，主要是Truffle和testrpc. 要知道即使在ConsenSys内部，不同的开发者使用的工具和框架也不尽相同。你可能会发现更适合你的工具，这里所说的工具可能很快也会有改进。但是本文介绍的工作流程帮助我走上了DApp开发之路。

(⊙ω⊙) wonk wonk

感谢Joseph Chow的校阅和建议，Christian Lundkvist, Daniel Novy, Jim Berry, Peter Borah和Tim Coulter帮我修改文字和debug，以及Tim Coulter, Nchinda Nchinda和Mike Goldin对DApp前端步骤图提供的帮助。

http://ethfans.org/posts/101-noob-intro

以太坊快速上手指南

在正式开始前，首先推荐过下这篇文章 http://ethfans.org/topics/102
如果你暂时不想了解区块链的技术细节，比如什么工作量证明，公钥加密系统什么的，可以先直接跳过。但还是强烈建议在你对整个开发流程有了点感觉后，把这部分知识补充起来。

区块链部分

http://teahour.fm/2015/12/27/talk-with-jan-about-bitcoin-and-blockchain.html

http://teahour.fm/2016/01/19/talk-with-jan-about-ehtereum.html （文字稿：http://ethfans.org/posts/talk-with-jan-about-ehtereum）

编写智能合约

Ethereum提供两种智能合约编程语言Solidity和Serpent，Solidity的语法类似于JavaScript，而Serpent的语法接近于Python。但也仅仅是语法有点类似，事实上有着巨大的差别，学习时不能简单的代入理解。如果你对编程语言没有偏好，请选择Solidity，也是默认的智能合约编程语言。Solidity文档中文版（正在翻译中，欢迎开发者参与翻译）：http://ethfans.org/posts/solidity-content 。

如果不想搭建完整的ethereum开发环境，只是想了解下Solidity，可以看下这个项目：Browser-Solidity

常用辅助工具和开发环境

以太坊的开发生态正在日益完善，相比刚发布时的裸写，现在已经有很多开发工具供选择了。

• Truffle: ConsenSys团队的开发工具
• Embark: 最早的一个开发工具
• Dapple: [Nexus Development]的开发工具，他们也是DAI/Maker项目背后的开发团队

以太坊本地私有链开发环境搭建教程（中文） ： http://ethfans.org/posts/ethereum-private-network-bootstrap

Đapp

通常你都是在写一个面向最终用户的应用，这时你需要一个界面。以太坊的开发者通常使用Web App + Smart Contract的方式来搭建这样的应用，并称之为Đapp(Decentralised Application)。在这里，智能合约部分的代码就相当于BS架构中的服务器代码，而Web部分则相当于前端代码。Web部分可以使用你熟悉的的HTML + JavaScript + CSS 来完成，然后通过JSONRPC的方法使用以太坊客户端提供的API接口，来操作你部署在区块链上的智能合约，这里区块链就相当于你租用的一台云服务器，所以有时候我们可以把以太坊的区块链理解为全球共享的一台World Computer。

Đapp最为关键的就是如何进行JSONRPC调用，以太坊官方提供了一个工具: Web3.js。如果你开发Đapp, 就必然需要使用它。

如何搭建一个测试网络并运行一个简单的 dapp http://ethfans.org/topics/85

Ethereum Bootstrap

通过本文所述方法和项目中的脚本，我们可以快速的搭建好自己的私链进行开发测试。

仓库中包含的工具有：

• 一个测试账户导入脚本，在首次部署时将五个测试账户私钥导入以太坊节点。
• 一个genesis.json配置文件，为对应的五个测试账户提供初始资金（以太币），方便开发测试。
• 一个快速启动私有链节点并进入交互模式的脚本。
• 一个合约样例：contracts/Token.sol。这是一个使用合约语言Solidity编写的智能合约。Token合约的功能是发行一种token（可以理解为货币，积分等等），只有合约的创建者有发行权，token的拥有者有使用权，并且可以自由转账。

测试账户私钥是放在Github上的公开数据，千万不要用于正式环境中或者公有链上。如果在测试环境之外的地方使用这些私钥，你的资金将会被窃取！

准备

1. 在本地安装好go-ethereum和solc, 可以执行geth和solc命令。如果操作系统是ubuntu, 安装官方的ethereum安装包即可。
2. 将本仓库通过git clone命令下载到本地。
3. 安装expect，工具脚本用它来自动化一些过程。例如在ubuntu上: sudo apt-get install expect

启动geth

1. 进入本仓库目录: cd ethereum-bootstrap
2. 导入测试账户私钥: ./bin/import_keys.sh
3. 启动私有链节点: ./bin/private_blockchain.sh. 启动成功后可以看到类似如下输出: 
4. 此时以太坊交互式控制台已经启动，我们可以开始测试和开发了。

注意：工具脚本假设你的geth安装在默认位置, 可以直接通过geth执行。如果geth命令安装在非标准的位置，可以设置GETH环境变量指定geth可执行文件的路径。例如:

GETH=/some/weird/dir/geth ./bin/import_keys.sh

使用以太坊控制台编译和部署智能合约

在contracts目录下有一个智能合约样例文件Token.sol, 通过Solidity语言实现了基本的代币功能, 合约持有者可以发行代币, 使用者可以互相转账.

我们可以使用以太坊控制台来编译部署这个合约．以太坊控制台是最基本的工具，使用会比较繁琐．社区也提供了其他更加方便的部署工具，此处不做讨论．

第一步，我们先把合约代码压缩为一行．新建一个ssh session, 切换到geth用户环境su - geth, 然后输入：cat contracts/Token.sol | tr '\n' ' '.

切换到以太坊控制台，把合约代码保存为一个变量:

var tokenSource = 'contract Token {     address issuer;     mapping (address => uint) balances;      event Issue(address account, uint amount);     event Transfer(address from, address to, uint amount);      function Token() {         issuer = msg.sender;     }      function issue(address account, uint amount) {         if (msg.sender != issuer) throw;         balances[account] += amount;     }      function transfer(address to, uint amount) {         if (balances[msg.sender] < amount) throw;          balances[msg.sender] -= amount;         balances[to] += amount;          Transfer(msg.sender, to, amount);     }      function getBalance(address account) constant returns (uint) {         return balances[account];     } }';

然后编译合约代码：

var tokenCompiled = web3.eth.compile.solidity(tokenSource);

通过tokenCompiled.Token.code可以看到编译好的二进制代码，通过tokenCompiled.Token.info.abiDefinition可以看到合约的ABI．

接下来我们要把编译好的合约部署到网络上去．

首先我们用ABI来创建一个javascript环境中的合约对象：

var contract = web3.eth.contract(tokenCompiled.Token.info.abiDefinition);

我们通过合约对象来部署合约：

var initializer = {from: web3.eth.accounts[0], data: tokenCompiled.Token.code, gas: 300000};  var callback = function(e, contract){     if(!e) {       if(!contract.address) {         console.log("Contract transaction send: TransactionHash: " + contract.transactionHash + " waiting to be mined...");       } else {         console.log("Contract mined!");         console.log(contract);       }     } };  var token = contract.new(initializer, callback);

contract.new方法的第一个参数设置了这个新合约的创建者地址from, 这个新合约的代码data, 和用于创建新合约的费用gas．gas是一个估计值，只要比所需要的gas多就可以，合约创建完成后剩下的gas会退还给合约创建者．

contract.new方法的第二个参数设置了一个回调函数，可以告诉我们部署是否成功．

contract.new执行时会提示输入钱包密码．执行成功后，我们的合约Token就已经广播到网络上了．此时只要等待矿工把我们的合约打包保存到以太坊区块链上，部署就完成了．

在公有链上，矿工打包平均需要15秒，在私有链上，我们需要自己来做这件事情．首先开启挖矿：

miner.start(1)

此时需要等待一段时间，以太坊节点会生成挖矿必须的数据，这些数据都会放到内存里面．在数据生成好之后，挖矿就会开始，稍后就能在控制台输出中看到类似：

:hammer:Mined block

的信息，这说明挖到了一个块，合约已经部署到以太坊网络上了！此时我们可以把挖矿关闭：

miner.stop(1)

接下来我们就可以调用合约了．先通过token.address获得合约部署到的地址, 以后新建合约对象时可以使用．这里我们直接使用原来的contract对象：

// 本地钱包的第一个地址所持有的token数量 > token.getBalance(web3.eth.accounts[0]) 0  // 发行100个token给本地钱包的第一个地址 > token.issue.sendTransaction(web3.eth.accounts[0], 100, {from: web3.eth.accounts[0]}); I1221 11:48:30.512296   11155 xeth.go:1055] Tx(0xc0712460a826bfea67d58a30f584e4bebdbb6138e7e6bc1dbd6880d2fce3a8ef) to: 0x37dc85ae239ec39556ae7cc35a129698152afe3c "0xc0712460a826bfea67d58a30f584e4bebdbb6138e7e6bc1dbd6880d2fce3a8ef"  // 发行token是一个transaction, 因此需要挖矿使之生效 > miner.start(1) :hammer:Mined block > miner.stop(1)  // 再次查询本地钱包第一个地址的token数量 > token.getBalance(web3.eth.accounts[0]) 100  // 从第一个地址转30个token给本地钱包的第二个地址 > token.transfer.sendTransaction(web3.eth.accounts[1], 30, {from: web3.eth.accounts[0]}) I1221 11:53:31.852541   11155 xeth.go:1055] Tx(0x1d209cef921dea5592d8604ac0da680348987b131235943e372f8df35fd43d1b) to: 0x37dc85ae239ec39556ae7cc35a129698152afe3c "0x1d209cef921dea5592d8604ac0da680348987b131235943e372f8df35fd43d1b" > miner.start(1) > miner.stop(2) > token.getBalance(web3.eth.accounts[0]) 70 > token.getBalance(web3.eth.accounts[1]) 30

其他

私有链的所有数据都会放在仓库根目录下的data目录中，删除这个目录可以清除所有数据，重新启动新环境。

做完这些之后你应该对在以太坊私有链上进行开发有了一个大概的了解吧，如果还想学习更多知识，一可以看一看上面执行的脚本代码，到底干了些什么，用了哪些命令行参数，二可以阅读正在ethfans上更新的solidity文档中文版。

http://ethfans.org/posts/ethereum-private-network-bootstrap

以太坊作为一个“去中心化的应用平台”，也确实给搭建测试网络提供了很多便利。以下我们就一步一步的介绍如何搭建一个测试链，并在测试链上运行ethereum.org上的hello world程序。

准备工作

1. 安装geth
2. 如果你准备连接到我在阿里云上的testnet, 下载这个创世块
3. 如果你要搭建自己的testnet，可以参照这里的格式创建创世块

开始

• 首先打开你的终端输入如下命令启动geth

geth --bootnodes "enode://7cc0c2e8abd944d6bee8966fc21b0597de27ef912614ff1b7b4f2c51b7d72078d05038435686f8821aa7ce6918a6065192368bb05cd50a908ed2f8958dfa7197@115.29.32.87:30303" --datadir "YOURTESTNETDATADIR" --genesis "EXAMPLEGENESIS.json"  --networkid 12345 --nodiscover console

• 当屏幕上出现这样的文字后 modules: admin:1.0 db:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 shh:1.0 txpool:1.0 web3:1.0 你就进入了以太坊的命令行控制界面

• 在以太坊的命令行界面输入如下命令创建一个新的账户

personal.newAccount('ethfans')

• 加入阿里云上我搭建的testnet node（如果你搭建一个人的testnet，不需要这一步）

admin.addPeer("enode://7cc0c2e8abd944d6bee8966fc21b0597de27ef912614ff1b7b4f2c51b7d72078d05038435686f8821aa7ce6918a6065192368bb05cd50a908ed2f8958dfa7197@115.29.32.87:30303")

然后输入admin.peers检查是否已添加成功远程节点， 添加失败的话会返回null

• 开始挖矿（第一次挖矿需要生成一个2G的DAG文件，耗时10分钟左右，具体时长取决于电脑性能）

miner.start()

待续