「深度学习福利」大神带你进阶工程师,立即查看>>>
EthTool 开发包适用于希望采用 裸交易 的PHP以太坊应用开发,主要包含以下特性： 支持裸交易部署/调用合约 内置etherscan和infura支持 keystore生成与读取,兼容geth/parity
采用裸交易的一个好处是开发者不必自己部署以太坊节点 —— 同步区块是很痛苦的过程。使用EthTool构造 好裸交易之后,只需要使用第三方（etherscan/infura/...）提供的服务来广播交易即可。 下载地址： http://sc.hubwiz.com/codebag/eth-php-lib/
EthTool运行在**Php 7.1+**环境下,当前版本1.0.0,主要代码文件清单如下：
代码文件 说明
ethtool/src/Callback.php | RPC回调类 | ethtool/src/Credential.php | 身份标识类 |
|---|
| ethtool/src/KeyStore.php | Keystore类,V3算法 | | ethtool/src/EthApi.php | 以太坊交易接口基类 | | ethtool/src/EthApiEtherscan.php | Etherscan交易接口类 | | ethtool/src/EthApiWeb3.php | Infura/Web3交易接口类 | | ethtool/src/RawContract.php | 裸交易合约类 | | ethtool/src/RawTxBuilder.php | 裸交易构造器 | | test/demo-etherscan.php | 裸交易演示代码,使用etherscan提交 | | test/demo-infura.php | 裸交易演示代码,使用infura提交 | | test/demo-keystore.php | keystore演示代码
vendor | composer.json
第三方依赖包目录 | composer配置文件 |
使用说明
代码包的主要类如下： RawTxBuilder: 裸交易构造器 Credential: 账户私钥与交易签名封装 EthApi: 以太坊交易接口封装 KeyStore: V3版本的keystore,兼容geth/parity
裸交易构造
使用 RawTxBuilder 的 create() 静态方法获取一个构造器实例,例如： $rtb = RawTxBuilder::create();
裸交易构造器需要绑定一个账户对象,使用 credential() 方法： $crendetial = Crendetial::fromKey('...'); $rtb->credential($credential);
RawTxBuilder目前支持三种裸交易的构造： 普通裸交易,例如以太币转账交易。使用 getPlaintx() 方法获取。 合约部署裸交易,使用 getDeployTx() 方法获取。 合约方法调用裸交易,使用 getSendTx() 方法获取。
例如,下面的代码生成合约部署裸交易： $rawtx = RawTxBuilder::create() ->credential($credential) ->gasLimit('4000000') ->gasPrice('10000000000') ->chainId($chainId) ->nonce($nonce) ->contract($abi) //创建合约对象,一个RawContract实例 ->bytecode($bin) //设置合约对象的字节码 ->getDeployTx(1000000,'HAPPY COIN',0,'HAPY'); //获取部署裸交易码流
裸交易广播
EthApi 基类目前定义以下方法,可以根据自己的需要扩充 getTransactionCount sendRawTransaction getTransactionReceipt
EthApiEtherscan 是基于Etherscan服务的EthApi实现, EthApiWeb3 是基于以太坊RPC的EthApi 实现。例如,下面的代码使用Etherscan在rinkeby测试链部署前面获得的裸交易： $eth = new EthApiEtherscan($your_api_key/*etherscan api key*/,4/*rinkeby*/); $txid = $eth->sendRawTransaction($rawtx);
KeyStore读写
KeyStore类可以读取geth/parity生成的keystore文件,其生成的 keystore文件也可以被geth/parity读取。
使用 KeyStore 类的静态方法 save() 将私钥转化为keystore格式写入指定目录： $credential = Credential::new(); $prv = $credential->getPrivateKey(); $fileName = KeyStore::save($prv,'123','./keystore')
使用KeyStore类的静态方法 load() 载入指定的keystore文件并解密私钥： $fileName = './keystore/....' $prv = KeyStore::load($fileName,'123'); 「深度学习福利」大神带你进阶工程师,立即查看>>>
俗话说得好“站在风口上,猪都会风”,那么2018年最大风口无疑是“区块链”,区块链处在发展的初期,很多技术和商业模式还在探索之中。很多暴富神话、不可思议的逆袭创富,在区块链行业中经常耳熟能详,那么如何在已有的产业链上来结合区块链呢？怎么打造属于自己的区块链产业链形式？
区块链各种项目相继出现,发行区块链币的、做区块链底层技术开发、区块链交易所、做区块链应用、区块链+游戏,除开线上,还有下线区块链物流、产品追溯溯源等等。从大的方向来看,区块链+金融依然是目前的产业主力军,区块链+各种实体产业,区块链+各种互联网产业链以及所有产业中,都将是未来的发展方向。
目前监管与行情
2017年以来,一方面加大对“爱西欧”项目的监管,另一方面也在积极的扶持国内的区块链相关研究。截止三月底,目前北京、上海、深圳、广州、江苏、浙江等多地发布政策指导与区块链产业链扶持与布局。
比特币与区块链
区块链作为比特币的底层系统架构技术,是区块链技术的首个应用,也是目前“区块链+”最成功的一个应用。比特币已经耳熟能详,人尽皆知。但区块链的发展今年才刚刚爆发,区块链可应用范围还非常广阔,市场发展空间还非常足,可以结合很多现有的产业来运作。
区块链技术
为了摆脱中心化系统对单点的依耐性过强,区块链技术以p2p网络,利用全网的节点来进行推送。bitmessage邮件系统设计思路和传统邮件系统完全不一样,当你在发邮件的时候,会发送给邮件网络系统中的每一个人,每个人都可以尝试解密,但只有真正有私钥的人才能解开。
区块链技术该如何结合已有的产业链？
源中瑞贺顾问表示：首先要分析两个因素,第一点,目前已经做的产业包括哪些？是否已经有了初步或者成熟的规划,或与区块链相结合的思路与开发需求。区块链开发贺顾问微关注QKL17999,第二点,想要结合区块链技术来做自己的产业链,或者只做区块链相关的,可以找我们进行探讨。如果还在考虑自己本身的产品适不适合结合区块链也可以找我们进行探讨梳理这块行业的疑问及需求。
区块链行业中比较知名的一些产业
区块链底层技术开发的各种链项目,场外OTC与C2C等数字资产交易所,交易对btc/eth等撮合机制的交易所模式,类似于Fcoin交易挖矿、法币挖矿、币币挖矿等新兴模式,区块链+p2p抵押理财等,区块链应用社群、聊天、还有直播与数字资产打赏等等。
区块链产品追溯溯源体系,假疫苗、食品安全、药品等生活息息相关的事件增多,区块链结合溯源无疑是未来的重点发展方向,可以让溯源体系施展很大的空间。
区块链与大数据
大数据主要包含三个部分：
1.产品部分包括大数据基础软件、应用软件等产品产业
2.数据部分包括数据源（数据采集、数据提供）、数据流通（数据交易、数据共享）等与数据直接相关的产业
3.服务部分包括基础设施服务（数据的存储、传输、清洗等）大数据分析与大数据应用服务等相关产业
大数据与区块链方面,都是分布式架构。从我们研发商的技术角度来观察,区块链账本可追溯与防伪方面,溯源体系让多方提供数据变得更加信任。两者结合可以维护完整的大数据形态。
加密技术与大数据相结合是一个重要的技术点。
未来区块链必然会变革整个信任时代,有人的地方就可以使用区块链,区块链的前景非常不错,必然的发展方向,建议可以找专门从事区块链研发的进行探讨。打造自己的产业链形成圆环,需要与行业人士多接触。 内容来源：CSDN
作者:wx13823153926
「深度学习福利」大神带你进阶工程师,立即查看>>>
连日来,比特币一直跌跌不休。比特币在11天内暴跌44%,一年内价值缩水80%。那么比特币在未来的价值是否归零呢？
比特币发展：
比特币（BitCoin）是一种P2P形式的数字货币,最初由中本聪在2009年提出概念、设计思路、完成开源软件的发布,并建构了相应的P2P网络,其点对点的传输意味着它是一个去中心化的支付系统。
比特币经济使用整个P2P网络中众多节点构成的分布式数据库来确认并记录所有的交易行为,并使用密码学的设计来确保货币流通各个环节安全性。该货币系统曾在4年内只有不超过1050万个,之后的总数量将被永久限制在2100万个。
比特币可以用来兑现大多数国家的货币,可以用来购买虚拟物品,也可以购买现实物品。2010年,1枚比特币价值0.25美分。2014年2月26日,乔·曼钦（Joe Manchin）要求美国联邦 全面封杀比特币。2017年1月24日中午12：00起,中国三 特币平台正式开始收取交易费,2017年底,比特币价格突破2万美元。
2018年11月21日,比特币报价跌破4100美元,创下了13个月以来的新低。和法定货币相比,比特币没有一个集中的发行方,而是由网络节点的计算生成,谁都有可能参与制造比特币,而且可以全世界流通,可以在任意一台接入互联网的电脑上买卖,不管身处何方,任何人都可以挖掘、购买、出售或收取比特币,并且在交易过程中外人无法辨认用户身份信息。
2009年,不受央行和任何金融机构控制的比特币诞生。比特币是一种“电子货币”,由计算机生成的一串串复杂代码组成,新比特币通过预设的程序制造,随着比特币总量的增加,新币制造的速度减慢,直到2014年达到2100万个的总量上限,被挖出的比特币总量已经超过1200万个。
比特币是否会归零呢？
现在是比特币价值,虽然会跌,但是不会归零,因为它是有限的,而且现在在全球范围内很多国家和地区都已经认可了比特币的价值。香港,日本,美国等国家的政策已经允许比特币的一些实体存在,甚至允许其支付系统,因此比特币的未来只会应用的越来越广。日本和欧洲等地区已经通过了相关的监管政策。美国的监管层面也在慢慢认可比特币。区块链技术在全球范围内被各个国家重视,并且在慢慢的普及之中。这个就是它的价值。
广泛的应用：
虽然比特币和加密货币是一种金融和货币现象,但由于底层的区块链技术,它们也被归类为技术进步。这意味着可以在可以使用区块链和加密货币的不同部门进行整个采用浪潮。已经最近发生的采用已经看到在几个部门,即最高级别的银行,大公司和甚至**。一些主要的全球性银行已经采取了巨大的举措来尝试获得客户可以使用的有效的加密交易服务台,并且他们可以参与提供,启动和运行。由于客户的需求如此之高,银行正在寻求加速加密货币。
兰德商业银行前任区块链主管,现任VALR联合创始人兼首席执行官的Farzam Ehsani说：“所有的银行都意识到他们需要走上这条区块链,我不认为许多银行必须明白船的去向,但他们意识到这是一个正在起飞的发展,如果他们想要这个每个人都在进行的旅程,他们需要在船上。”此外,微软、亚马逊、IBM和甲骨文等公司也开始竞相开始提供面向客户的区块链解决方案（通常与加密货币绑定）以成为第一个推出有效革命性产品的市场。
最后, 对比特币和加密货币采用的手刹开始出现,荷兰 就是这种情况的一个很好的例子。据报道,就在上个月,荷兰经济事务和气候政策部成立了一个部门,负责研究跨技术区块链的进一步发展。这对比特币和它可以归零的想法意味着什么呢？
目前,比特币是在一个下降的通道,但是从比特币对区块链行业的意义和比特币本身的市场和资金盘来说,我认为比特币不会归零,相反还是值得拥有的标的。
相关推荐：
史上最大的泡沫比特币价格一泻千里,币圈会崩盘吗？ 「深度学习福利」大神带你进阶工程师,立即查看>>> EthTool 开发包适用于希望采用__裸交易__旳PHP以太坊应用开发,主要包含以下特性： 支持裸交易部署/调用合约 内置etherscan和infura支持 keystore生成与读取,兼容geth/parity 采用裸交易的一个好处是开发者不必自己部署以太坊节点 —— 同步区块是很痛苦的过程。使用EthTool构造 好裸交易之后,只需要使用第三方（etherscan/infura/...）提供的服务来广播交易即可。 下载地址： http://sc.hubwiz.com/codebag/eth-php-lib/ EthTool运行在**Php 7.1+**环境下,当前版本1.0.0,主要代码文件清单如下： | 代码文件 | 说明 |
|---|
| ethtool/src/Callback.php | RPC回调类 | | ethtool/src/Credential.php | 身份标识类 | | ethtool/src/KeyStore.php | Keystore类,V3算法 | | ethtool/src/EthApi.php | 以太坊交易接口基类 | | ethtool/src/EthApiEtherscan.php | Etherscan交易接口类 | | ethtool/src/EthApiWeb3.php | Infura/Web3交易接口类 | | ethtool/src/RawContract.php | 裸交易合约类 | | ethtool/src/RawTxBuilder.php | 裸交易构造器 | | test/demo-etherscan.php | 裸交易演示代码,使用etherscan提交 | | test/demo-infura.php | 裸交易演示代码,使用infura提交 | | test/demo-keystore.php | keystore演示代码 | | vendor | 第三方依赖包目录 | | composer.json | composer配置文件 | 2. 使用说明 代码包的主要类如下： RawTxBuilder: 裸交易构造器 Credential: 账户私钥与交易签名封装 EthApi: 以太坊交易接口封装 KeyStore: V3版本的keystore,兼容geth/parity 裸交易构造 使用 RawTxBuilder 的 create() 静态方法获取一个构造器实例,例如： $rtb = RawTxBuilder::create(); 裸交易构造器需要绑定一个账户对象,使用 credential() 方法： $crendetial = Crendetial::fromKey('...'); $rtb->credential($credential); RawTxBuilder目前支持三种裸交易的构造： 普通裸交易,例如以太币转账交易。使用 getPlaintx() 方法获取。 合约部署裸交易,使用 getDeployTx() 方法获取。 合约方法调用裸交易,使用 getSendTx() 方法获取。 例如,下面的代码生成合约部署裸交易： $rawtx = RawTxBuilder::create() ->credential($credential) ->gasLimit('4000000') ->gasPrice('10000000000') ->chainId($chainId) ->nonce($nonce) ->contract($abi) //创建合约对象,一个RawContract实例 ->bytecode($bin) //设置合约对象的字节码 ->getDeployTx(1000000,'HAPPY COIN',0,'HAPY'); //获取部署裸交易码流 裸交易广播 EthApi 基类目前定义以下方法,可以根据自己的需要扩充 getTransactionCount sendRawTransaction getTransactionReceipt EthApiEtherscan 是基于Etherscan服务的EthApi实现, EthApiWeb3 是基于以太坊RPC的EthApi 实现。例如,下面的代码使用Etherscan在rinkeby测试链部署前面获得的裸交易： $eth = new EthApiEtherscan($your_api_key/*etherscan api key*/,4/*rinkeby*/); $txid = $eth->sendRawTransaction($rawtx); KeyStore读写 KeyStore类可以读取geth/parity生成的keystore文件,其生成的 keystore文件也可以被geth/parity读取。 使用 KeyStore 类的静态方法 save() 将私钥转化为keystore格式写入指定目录： $credential = Credential::new(); $prv = $credential->getPrivateKey(); $fileName = KeyStore::save($prv,'123','./keystore') 使用KeyStore类的静态方法 load() 载入指定的keystore文件并解密私钥： $fileName = './keystore/....' $prv = KeyStore::load($fileName,'123'); 「深度学习福利」大神带你进阶工程师,立即查看>>>
“在我眼中,隐私就是让我们免于言行受到外界关注的困扰,并创造出一些空间以便我们为了自身的幸福而随心所欲地进行优化,只是为了我们自己的幸福,而不是因为在意别人对我们的看法。”—— Vitalik Buterin
众所周知,隐私性是近来加密货币领域的一项重要话题。无论是公司还是个人,都不希望本国政府、他国政府、家人、同事或商业竞争对手可以毫无限制地随意查看他们发布在公有链上的所有信息。
目前针对保护区块链上隐私的各种方法已经过大量的试验和研究。然而,我们尚未看到过关于这方面的综合性概述。 在这篇文章中,我们将从以下四个方面分析有关隐私领域的最新试验和研究情况：1）隐私币；2）智能合约隐私；3）隐私架构；和4）隐私研究。
1
比特币的隐私（或者说,比特币没有隐私）
原先,比特币是作为匿名加密货币被开发的,只要现实世界的身份无法与比特币地址联系起来,就能保护隐私。然而,由于比特币区块链的公开性,人们很快就发现,基于某些地址和交易的使用模式是有可能识别个人身份的。另外,节点在广播交易时也会泄露自己的 IP 地址。
每个节点代表一个地址,每条边代表一项交易。许多节点（诸如 Mt. Gox、Silk Road 和 Satoshi Dice）的身份都已经根据其交易模式被识别出来了。
2013年,Meiklejohn 等人成功地识别出了很多在线钱包、商户和其它服务提供商的身份。如今,诸如 Chainalysis 和 Elliptic 等服务提供商将区块链去匿名化,从而侦查洗钱、欺诈和违规行为。
-在这个示例中,可以看出 {Alice, Bob} 向 {Carol, Ted} 发送了比特币,但是无法精确判断发送者和接收者的身份。不同的用户重复几次这个过程之后,匿名集就会扩大。-
**为了解决比特币隐私性被削弱的问题,CoinJoin（混币） 等 Tumbler 服务应运而生,以提高比特币的匿名性。**CoinJoin 让用户共同创建交易来变更其代币的所有权,赋予集合中的每个用户匿名性。随着不同的用户不断重复这个过程,这个匿名集会扩大。犯罪分子一直都在利用这种 Tumbler 服务将可识别的比特币与其他资金混在一起,从而掩盖该资金的来源。
但是 Coinjoin 有其自身的缺陷。Coinjoin 的隐私性依赖于匿名集的大小。而实际上,每项 Coinjoin 交易中平均只有 2 到 4 名参与者,因此研究人员能够将 67% 的 Coinjoin 交易去匿名化。后期,随着 Coinjoin 的改进,又出现了更好的加密货币 Tumber 服务,如 TumbleBit 等,但是 TumbleBit 也存在局限性。
2
隐私币
由于比特币缺乏隐私性,而且在协议层面上尚无提高自身隐私性的计划,目前已经涌现出好几种支持私密交易的新型加密货币。
Zcash 由一支强大的密码学家团队通过 zk-SNARKs 技术创建的。1985 年,Goldwasser、Micali 和 Rackoff 最先提出了“零知识证明”的开创性想法。2015 年,Eli Ben-Sasson 等人在零知识证明的基础上进一步开发了 zk-SNARKs 技术,该技术在使人们能够简洁且非交互性地证明自己知道某个信息的同时不透露具体内容。zk-SNARKs 为许多与隐私相关的项目提供了技术支持,并且可以利用一种名为递归组合的技术压缩区块链的规模。
Zcash 团队目前致力于 Sapling 项目,这是一次对网络的性能升级,将改善隐蔽（加密）交易的性能和功能,计划于 2018 年 10 月启动。由于大约 85% 的 Zcash 交易仍公开发送,发送受保护的交易在计算方面的成本十分高昂,因此 Sapling 项目将有望增加受保护交易的数量（编者注：2018 年10 月 28 日,Sapling 在 Zcash 主网成功激活）。
门罗币（Monero）是另一种隐私币,使用的是环签名而非 zk-SNARKs 技术。目前,门罗币团队正在构建 Kovri 以支持保护隐私的封包路由,这样一来,用户可以隐藏自身地理位置和 IP 地址。将用户的网络流量匿名化将大幅度提高门罗币网络的安全性,并确保用户不会因为使用了门罗币而遭到逮捕或人身伤害。
Zcash 和门罗币经常被拿来比较。这两个社区都是由 Twitter 名人领导的—— Zooko Wilcox 领导 Zcash,Riccardo Spagni (@fluffypony) 领导门罗币——但不同之处在于,Zcash 背后有一家公司和一家基金会的支持,而门罗币只拥有一个由核心开发人员组建而成的有机社区。这两个项目曾在匿名性方面都存在缺陷：研究人员能够将 69% 的 Zcash 隐蔽交易与创始人/矿工联系起来,也能将 62% 的门罗币交易去匿名化；但这些缺陷目前已得到修正。
然而,这两个项目本质上采用了迥异的隐私保护方法,并且采取了不同的折衷方案。到目前为止,我还无法确定这两个项目从长远来看哪个更胜一筹。在我看来,Zcash 和门罗币将继续像可口可乐和百事可乐那样共存。
Mimblewimble 是《哈利波特》中的锁舌咒,Tom Elvis Jedusor 是伏地魔的法语名,Ignotus Peverell 是隐形衣的原主人。（校对注：即下文中人采取的化名都是从哈利波特里来的 : ) ）-
Mimblewimble 是一个专注于隐私的新区块链项目,建立在比特币的设计基础上。2016 年 7 月 19 日,“Tom Elvis Jedusor”向一个比特币研究渠道投了白皮书,随后就消失了。后来,“Ignotus Peverell”启动了一个名为 Grin 的 GitHub 项目,并开始真正落实 Mimblewimble 的白皮书。Blockstream 公司的 Andrew Poelstra 在 2017 年斯坦福 BPASE 大会上展示了他们的工作成果,此后 Grin 开始获得大量的主流关注。Grin 的第三个测试网已经发布, 其主网预计将在 2019 年初首次亮相。
Mimblewimble/Grin 是对比特币的隐私交易和 Coinjoin 做出的一次改进。关键特点包括无公开地址、完全隐私化和区块链简洁化。近来, Grin 挖矿迎来了热潮,因为和比特币一样,Grin 币只能够通过工作量证明挖矿获得。Grin 利用的是布谷鸟循环（Cuckoo Cycle）工作量证明算法,该算法最初设计为抵制 ASIC 的,而如今却被认为是支持 ASIC 的。
总体来说,Grin 将一系列令比特币如此强大的社会特性——匿名创始人、无领导的开发团队、POW 共识、无 ICO、无链上治理——与针对 Zcash 和门罗币的技术改进相结合。和比特币不同的是,Grin 的总供应量是不受限制的,它采用了线性供应的货币政策,这意味着通货膨胀在早期非常高,但在一段时间后逐渐趋近（但不达到）零。Grin 网络发布后,早期的通货膨胀会刺激消费而非投机。尽管持续的通货膨胀会阻碍 Grin 成为理想的价值储存手段,但是等到比特币的区块奖励消失而矿工只能赚取交易费的时候,Grin 就能避免像比特币那样的不稳定性。
Grin 的新型货币政策与备受争议的 Zcash 创始人奖励 大不相同,后者指在最初的 4 年里,项目开发人员会得到新铸造的 ZEC 中的 20% 。MimbleWimble 区块链的规模与用户数量而非交易数量成比例,通过使用门罗币的环形签名避免出现 UTXO 集膨胀问题。
其他有趣的隐私币包括 MobileCoin 和 BEAM 等,目前还处在开发早期。
3
智能合约隐私
**智能合约中的程序代码是开放的,所以智能合约隐私与支付隐私是不一样的。**不幸的是,程序混淆经证明是不可能出现的,因此智能合约目前既缺乏保密性（隐藏支付金额）,又缺乏匿名性（隐藏发送者和接收者的身份）。
在我看来, 当企业准备大规模建立去中心化应用并需要隐藏其客户的活动时,就会出现对智能合约隐私性的强烈需求 ；目前,让所有人都看到像加密猫这类去中心化应用的使用,这并没有什么不好。这有点像是互联网一开始出现之时,基础网站都使用的 HTTP 协议,而后由于电子商务等活动需要加密网络流量,才针对相关网站引入了 HTTPS 协议。
-以太坊中没有隐私,所有人都可以在 DappRadar 上看到去中心化应用的使用情况。-
就以太坊而言,Benedikt Bünz 正在斯坦福大学从事一项关于私人支付机制的研究,名为 Zether ；这种机制与以太坊完全兼容,并且可以为以太坊智能合约提供保密性和匿名性。 Zether 将作为一种以太坊智能合约执行,将 gas 消耗降至最低。Zether 还具备多种功能,可以为支付渠道等常见应用带来可证明的隐私性。
**Keep **是另一个通过为私有数据创建链下容器的方式搭建以太坊隐私层的项目。因此,智能合约可以在无需向公有链公开数据的情况下管理和使用私有数据。
虽然对于以太坊来说,隐私性的优先级别目前仅次于 Casper 排在第二,但是以太坊基金会实施 Casper 的进度很慢,而且风险在于隐私性要到多年后才会成为以太坊的核心特征。如果在此期间智能合约中的隐私性成为加密社区急需解决的问题,将会出现新的隐私性智能合约平台来填补这一空白,就像 Zcash 和门罗币的出现填补了比特币在隐私支付方面的缺陷。Enigma、Origo 和 Covalent 也都是新的智能合约平台,它们试图在区块链中实现原生的隐私功能。
**Oasis Labs **是另一个令人兴奋的隐私项目,构建了新的智能合约平台 Ekiden,该平台将智能合约的执行与底层共识机制分隔开。智能合约在一个被称为安全区的独立硬件（如英特尔 SGX）内部运行。这个安全区就像一个暗箱,使计算相对于其他应用保持私密。它还会生成一个加密证明来证明程序是正确执行的,然后将这个证明存储在区块链中。通过将智能合约的执行与共识分离,Ekiden 可以兼容包括以太坊在内的不同底层区块链。
4
隐私架构
除了隐私币和私有智能合约外,Web 3 堆栈（编者注：中译本见文末超链接）还有其他重要的隐私架构项目值得一提。
**Orchid **正在尝试建立一个优化后的 Tor 版本,其中,用户通过出租自己额外的带宽来获得代币,成为 Orchid 网络中的中继者。Tor 的问题在于只有大约 6000 个中继节点和不到 2000 个桥节点,因此政府可以将所有中继节点和桥节点拉入黑名单,从而防止其公民访问 Tor。如果利用代币作为经济激励去鼓励更多人成为中继者的话,除非随着网络的扩大相应加大阻挡面,否则阻挡 Orchid 的难度就会加大。
**BOLT **正在建立一个私人支付渠道；当参与者开户、交易和关闭支付渠道时,该渠道使用盲签名和零知识证明来隐藏参与者的身份。最初的支付渠道建立在 Zcash 上的,但将能够与比特币和以太坊进行互操作。
**NuCypher **正在搭建一个去中心化密钥管理系统；该系统使利用代理再加密技术提供与 HTTPS 相同的功能。代理再加密属于公钥加密,让用户能够在不了解底层消息的情况下将密文从一个公钥转换到另一个公钥。
**Starkware **正在包括以太坊在内的各种区块链上实行 zk-STARKs。zk-STARKs 相比 zk-SNARKs 的优势在于前者不需要可信设置,尽管加密证明的容量也会大得多。
5
隐私研究
密码学的学术研究推动了隐私领域的创新。隐私研究主要涉及的主题有零知识、多方计算和全同态加密。
除了 zk-SNARKs 和 zk-STARKs 之外,Bulletproofs 是一种新型的简短非交互式零知识证明。与 zk-STARKs 类似的一点是,Bulletproofs 不需要可信设置,但验证 Bulletproofs 比验证 zk-SNARKs 证明更耗时。Bulletproofs 在设计上能够实现加密货币的高效私密交易,并将证明的大小从 10 KB 以上缩小到 1-2 KB。如果所有比特币交易都保密且使用 Bulletproofs 的话,那么 UTXO 集的总体大小仅为 17 GB,就目前使用的工作量证明而言,UTXO 集的总体大小是 160 GB。
-不同零知识证明系统的权衡方案。-
多方计算 使一组人在不透露各自输入值的情况下,使用各自的输入值共同计算一则函数。 例如,Alice 和 Bob 想知道谁持有的比特币更多,同时又不透露各自的比特币数量。不幸的是,多方计算目前的局限性在于其在实际运用中效率极低。
全同态加密 使人们能够基于加密数据进行计算。几十年来,这一直是密码学领域一个未解决的问题,直到 2009 年,斯坦福大学博士生 Craig Gentry 利用理想格构想出了首个全同态加密方案。例如,如果 Bob 想对 Alice 的数据进行任意计算,比如训练机器学习模型,同时 Alice 不需要透露其明文数据,那么这时该方案就能发挥用处。全同态加密和多方计算一样仍然处于理论阶段,实际运用时效率太低。
6
何去何从？
总体来说,隐私性是目前密码学研究中最引人注目的领域之一,如果这些理论技术要在现实世界中得以实际运用,还需要对其进行大量的效率优化工作。斯坦福大学区块链研究中心等一系列研究实验室正积极推进这个领域的工作,至于接下来数年将会取得哪些重大突破,我们可以拭目以待。
加密货币的益处在于它为最新的隐私研究提供了直接的应用场景。代币、智能合约和架构中使用的许多隐私技术都是几年前才发明出来的。考虑到这个领域迅猛的发展速度,隐私性将逐渐发展成加密项目设计中最主要的一个部分。 内容来源：公众号-以太坊爱好者
原文链接:
https://thecontrol.co/an-overview-of-privacy-in-cryptocurrencies-893dc078d0d7
作者: Richard Chen
翻译&校对: 张凌 & 闵敏
课程推荐
「深度学习福利」大神带你进阶工程师,立即查看>>> 原文题目： 《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》
原文作者： Ethan Buchman
翻译： 潘振东
校对： 杜满想
本文为节选
构建应用
Tendermint被设计成为可复制的最终确定性状态机的通用的算法。它使用Tendermint套接字协议（TMSP）标准化共识引擎和状态机之间的沟通,使得应用开发者可以用任何语言去构建他们的状态机,并通过这种方式自动复制了基于Tendermit的BFT算法。
背景
互联网上的应用程序通常可以表征为包含两个基本要素： 引擎：处理核心安全性,网络,复制。这通常像一个网络服务器,如Apache或Nginx,可以构建Web应用程序,或者构建分布式应用程序的一致性算法。 状态机：处理交易的实际应用程序逻辑,从引擎接收并更新内部状态。
这种引擎和状态机结构的分离使应用程序开发人员可以用任何编程语言编写想要的应用程序的状态机,在引擎之上可能专门定义其性能,安全性,可用性,支持性和其他考虑因素。与Web服务器及其应用程序不同,后者通常采用的形式是进程通过公共网关接口(CGI)协议使用套接字进行通信。而共识算法一般来说要以更少的可用性或者更少的通用性接口来构建应用程序。像zookeeper,etcd,consul和其他分布式键值对存储应用一样,提供HTTP接口到简单键值对应用程序的特定实例,还有一些更有趣的功能,如原子比较和交换操作并推送通知。但他们没有给应用程序开发人员控制状态机代码本身。
比特币的成功以及源源不断对区块链技术的兴趣产生了要对状态机运行进行高级别的超越共识引擎的控制需求。通过构建更多高级应用直接进入共识,用户,开发商,监管机构等等,可以在任意状态机上实现更大的安全保障,远远超出键值对存储,如货币,交易所,供应链管理 - 治理等等。它之所以引起了这么多人的注意,是因为这个系统巨大的潜力是允许集体执行前执行代码。它实际上是对许多方面的重新发明法律制度,使用分布式共识算法和确定性可执行合同,而不是警察,律师,法官,陪审团和个人喜好。这对人类社会发展的影响是爆炸性的,就像引入民主法治一样。Tendermint旨在提供基本的接口和共识引擎可以构建此类应用程序。
Tendermint 套接字协议
Tendermint套接字协议(TMSP)定义了共识引擎和应用程序状态机之间通讯的核心接口。这个接口定义包括一系列的消息类型,使用Google’s Protocol Buffers (一个长度作为前缀通过套接字传输的协议),一系列的消息类型,他们的参数,返回值和用途都在图5.1中,整体的结构和消息流程也在图5.2中。
图5.1
Golang定义的TMSP Application interface,TMSP消息被定义为使用Google’s Protocal Buffers,序列化格式是通过TMSP套接字传输之前将长度作为前缀,返回值包括一个代码,和HTTP的状态码类似,代表了任意的错误信息,０表示没有错误,消息在客户端缓存直到一个flush消息被发出,在这个点所有的缓存消息都会被发出。服务端设计的是异步化的,消息返回必须是和请求相匹配的正确的顺序。
图5.2
共识逻辑与应用程序逻辑进行通信是通过TMSP（套接字协议）。维护两个sockets(套接字）,一个用于mempool检查新交易的有效性,另一个用于执行共识的新提交的块。
TMSP协议被实现为一个有序的异步的服务,消息类型请求和返回是成对的,当一个特殊的消息类型出现的时候,清空并通过连接推送缓存的所有消息然后等待消息。
在TMSP协议有两种消息是核心,AppendTx 和Commit,一旦块由共识产生,引擎就会在块上调用AppendTx处理每个块中的交易,将其传递给应用程序状态机处理。如果交易有效,则会导致应用程序中的状态转换。
一旦所有AppendTx调用返回,共识引擎调用Commit,使得应用程序提交到最新状态,并将其永久存储到磁盘。
分离协议和执行
使用TMSP可以使我们明确区分共识,或者关于交易顺序的协议,以及它们在状态机中的实际执行情况。特别是,我们首先就顺序达成共识,并且然后按顺序执行交易。这种分离实际上有所提升系统的容错,但是仍然需要总数3f + 1个节点去容忍f个拜占庭式节点的失败,只需要2f + １个节点执行。也就是说,虽然我们仍需要三分之二的多数来排序,我们只需要一半的多数来执行。
另一方面,事实上交易的执行放在排序之后会导致可能是无效的交易,这可能会浪费系统资源。这种情况使用额外的TMSP消息CheckTx解决的,由mempool调用,允许它检查交易是否会对最新的状态有效。但请注意,事实上块中的一次性提交会引起CheckTx处理消息的复杂性。特别是,应用程序希望维护第二个状态机只执行主状态机相关的交易有效性的规则。第二个状态机由CheckTx消息更新状态并在每次提交后重置为最新的已提交状态。在本质上,第二个状态机描述了交易池的过滤规则。
在某种程度上,CheckTx可以用作｀乐观的执行｀返回并将结果发送给交易发送者,但结果可能是错误的,比如一个带有冲突交易的块在利息交易之前提交。这种｀乐观的执行｀是扩展BFT系统的方法的关注焦点,可以很好地适用于交易之间冲突很少的应用程序。与此同时,它增加了客户端的额外复杂性,因为可能需要处理无效的结果。
微服务架构
采用分离关注点作为应用程序设计的策略是从普遍上来看是明智的做法。特别是,许多当今的大规模应用部署采用微服务架构。其中每个功能组件实现为独立的网络服务,通常封装在Linux容器中（例如使用Docker）以提高部署效率,可伸缩性和可升级性。
在Tendermint共识之上运行的应用程序通常会被分解成微服务,例如,许多应用程序将使用一个键值对存储用于存储状态。为了利用数据存储的优势和某些特有功能,将键值存储作为独立运行的服务很常见,如高性能数据类型或默克而树。
应用程序的另一个重要的微服务是治理模块,它管理某个TMSP消息子集,启用该应用程序控制验证器集更改。这样的模块可以在BFT中变成强大系统治理范式。
某些应用程序可能为用户使用本机货币或帐户结构,因此,提供支持基本元素的模块是有用的,例如,处理数字签名和管理账户动态。用微服务构成复杂TMSP应用程序例子还有很多。实际上,人们甚至可以构建一个可以启动的,包含了使用交易中发送的数据的子应用程序的应用程序。例如,在交易中包含了一个存储docker镜像的哈希,以便从一些文件存储后端pull下来运行并作为未来的子应用程序运行共识中的交易以导致其运行。这是以太坊使用的方法,允许开发人员将一些代码部署到网络中可以通过上面的方式触发在以太坊虚拟机中运行交易（智能合约),以及IBM最近的OpenBlockChain（OBC）项目,它允许开发人员在交易中发送完整的docker上下文,定义运行任意代码以响应发往他们地址的交易的容器。
确定性
关于使用TMSP构建应用程序的最为严格的忠告是他们必须是确定性的,也就是说,对于复制状态机而言不保证安全。每个节点在执行时针对同一状态的同一交易必须获得相同的结果。这不是Tendermint的独特要求。比特币,raft,以太坊,任何其他分布式共识算法,以及锁步等多人游戏必须严格具有确定性,以免达成共识失败。编程语言中有许多非确定性的来源,最明显的是通过随机数和时间,但也可以通过使用浮点精度,并通过哈希表迭代（一些诸如Go之类的语言强制对哈希表进行随机迭代程序员明确何时需要有序数据结构）。对确定性机制的严格限制,以及确定性在每种主流编程语言中的缺失,促使以太坊开发自己的,图灵完备的,完全确定的虚拟机,它构成了应用程序开发人员在以太坊区块链之上构建应用程序的平台。虽然确定性,它有许多特别之处,例如32字节堆栈字,存储键和存储值,不支持字节位移操作,一切都是大数算术。确定性编程在实时世界中得到充分研究,例如锁步,多方游戏。这类游戏构成了另一个复制状态机的例子。并且在许多方面与共识算法非常相似。鼓励使用TMSP构建的应用程序开发人员进行学习使用他们的方法,并在实现应用程序时要小心。使用函数式编程语言和证明方法可以启用正确程序的构建。在另一方面,编译器也在构建以将可能的非确定性程序转换为规范化确定性的。
终止性
如果说确定性是为了保证安全很严格,那么交易执行的终止性就是为了严格的保证存活。然而,它不是一般的可以确定给定程序是否因单个输入而停止,更不用说所有这些问题,这个问题被称为停机问题。
以太坊的虚拟机通过计量解决问题,具体来说,在执行中的每个操作收费。这样,交易就保证在发起者资金不足时终止。这样的计量在更一般的情况下,可以通过编译程序的编译器实现计量他们自己的版本。
没有显着的开销就很难解决这个问题。在本质上,验证器无法判断执行是处于无限循环中还是只是缓慢,但几乎完成。可以使用Tendermint共识协议决定交易超时,超过三分之二的验证人必须同意交易超时,因此被视为无效（即对状态没有影响）。但是,我们没有在这里进一步实践这个想法,留待未来的工作。同时,预计应用程序将在进行全面测试之前部署在任何共识系统中,监控和治理机制在达成共识的情况下,将用来恢复系统失败。
举个例子
在本节中,将介绍和讨论越来越复杂的TMSP应用程序,特别是CheckTx和管理mempool。
Merkleeyes
TMSP应用程序的一个简单示例是基于Merkle树的键值存储。Tendermint提供Merkleeyes,这是一个包装的TMSP应用程序,一个自平衡的Merkle二元搜索树。交易的第一个字节确定交易是get,set还是delete操作。对于get,delete操作,剩余的字节是键(key)。对于set操作,其余字节是包含键和值的序列化列表。Merkleeyes可能使用CheckTx的简单实现对交易进行解码,以确保其格式正确。也可以实现更高级的CheckTx,get和delete操作对未知key无效。调用Commit后,将添加最新更新进入Merkle树,重新计算所有哈希值,树的最新状态也在磁盘上提交存储。
请注意,Merkleeyes被设计为其他TMSP应用使用的基于Merkle树的键值存储的模块。而不是单独的TMSP应用程序,虽然TMSP接口的简单性使它适用于两者。
货币应用
一个更重要的完整实例是一个简单的货币,用的账户结构由以太坊创立,每个用户都有一个公钥和一个基于该公钥的带有余额的账户,该帐户还包含一个序列号,等于帐户发送的交易数量。交易可以从账户发送资金,如果它们包括正确的序列号,并由正确的私钥签名。没有序列号,系统容易受到重放攻击,可以重播从帐户中扣除帐户的已签名交易,从而导致借记多次发生。此外,防止重放攻击在多链环境中,交易签名应包括网络或区块链标识符。
一个支持货币职能的应用程序自然具有比键值存储更多的逻辑。特别是,某些交易明显无效,例如签名无效,序列号不正确或发送超过发起人帐户余额的金额。这些情况都可以通过CheckTx检查。
此外,必须在CheckTx中维护补充应用程序状态是为了在更新时更新序列号和帐户余额当同时在mempool中有多个涉及相同帐户的交易时。调用commit时,将重置补充应用程序状态到最新的提交状态。任何仍在mempool中的交易都可以通过CheckTx重播最新状态。
以太坊
以太坊使用已经描述的机制来过滤掉mempool中的交易,但它也在虚拟机中运行一些交易,它会更新状态并返回结果。虚拟机执行没有在CheckTx中完成,因为它们包含在块中,它更昂贵且严重依赖交易的最终顺序。
总结
TMSP提供了一种简单而灵活的方法来构建任意应用程序,可以用任何编程语言,继承复制自Tendermint一致性算法的BFT状态机。它扮演的角色大致类似于共识引擎和一个应用程序。例如,CGI扮演为Apache和Wordpress。但是,应用程序开发人员必须特别注意确保他们的应用程序是确定性的,并确保交易执行终止。
相关阅读：
区块链时代的拜占庭容错：Tendermint（一）
区块链时代的拜占庭容错：Tendermint(二)
区块链时代的拜占庭容错：Tendermint（三） 「深度学习福利」大神带你进阶工程师,立即查看>>>
介绍一个EOS Chain/Wallet RPC API的PHP开发包。
开始
你可以查看EOS的 RPC API参考 ,但要注意缺少一些较新的方法。Wallet RPC API实现 EOS v1.1.0 of RPC API reference 。此外,这些文档中的一些示例也使用了过时的语法。
安装 composer require manamine/php-eos-rpc-sdk
配置
使用你最喜欢的RPC API主机和KEOSD在项目根目录中创建一个 dotenv.env 文件。你可以使用 env.example 作为模板： cp .env.example .env
有一个漂亮的工厂方法来自动化实例所有依赖项： $api = (new ChainFactory)->api(); $walapi = (new WalletFactory)->api(); $eos = (new EosRpc($api, $walapi));
示例
为了帮助你入门,运行一个简单的示例,它涵盖了所有API命令。
只需通过cli运行此命令即可查看所有命令的示例输出： cd examples php chain.php php wallet.php php eosrpc.php
API方法
涵盖了几乎所有区块链和钱包API方法。
区块链API
Get Info
获取与节点相关的最新信息 echo $api->getInfo();
Get Block
获取与区块相关的信息 echo $api->getBlock("1337");
Get Block Header State
获取与块头状态相关的信息 echo $api->getBlockHeaderState("0016e48707b181d93117b07451d9837526eba34a9a37125689fb5a73a5d28a38");
Get Account
获取与帐户相关的信息 $api->getAccount("blockmatrix1");
Get Code
获取智能合约代码 echo $api->getCode("eosio.token");
Get Table Rows
从帐户中获取智能合约数据 echo $api->getTableRows("eosio", "eosio", "producers", ["limit" => 10]);
Get Currency Balance
获取帐户的货币余额 echo $api->getCurrencyBalance("eosio.token", "eosdacserver");
Get Currency Stats
获取货币状态 echo $api->getCurrencyStats("eosio.token", "EOS");
Get ABI
获取账户ABI echo $api->getAbi("eosio.token");
Get Raw Code and ABI
获取原生代码和ABI echo $api->getRawCodeAndAbi("eosio.token");
Get Producers
列出生产者 echo $api->getProducers(10);
ABI JSON To Bin
将json序列化为二进制十六进制 echo $api->abiJsonToBin("eosio.token", "transfer", ["blockmatrix1", "blockmatrix1", "7.0000 EOS", "Testy McTest"]);
ABI Bin To JSON
将二进制十六进制序列化为json echo $api->abiBinToJson("eosio.token", "transfer", "10babbd94888683c10babbd94888683c701101000000000004454f53000000000c5465737479204d6354657374");
Get Required Keys
获取签署交易所需的密钥 echo $api->getRequiredKeys( [ "expiration" => "2018-08-23T05.00.00", "ref_block_num" => 15078, "ref_block_prefix" => 1071971392, "max_net_usage_words" => 0, "delay_sec" => 0, "context_free_actions" => [], "actions" => [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => "00000000007015d6000000005c95b1ca102700000000000004454f53000000000c757365722d3e746573746572" ] ], "transaction_extensions" => [] ], [ "EOS7ijWCBmoXBi3CgtK7DJxentZZeTkeUnaSDvyro9dq7Sd1C3dC4" ] );
Push Transaction
提交推送一个交易 echo $api->pushTransaction("2018-08-23T05:29:39", "15780", "90170226", [ "actions" => [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => "00000000007015d6000000005c95b1ca102700000000000004454f53000000000c757365722d3e746573746572" ] ], "signatures" => [ "SIG_K1_KaGHyi59BRqfaDUK6424TYEWcUhWxAG7BLCgYC8vwYNgaHgGLpduTUbNQEsfL8xLzboK8W9T2X69bNpqozTQVCbRSNJWFd" ] ] );
Push transactions
提交推送一些交易 echo $api->pushTransactions( [ [ "compression" => "none", "transaction" => [ "expiration" => "2018-08-23T06:27:26", "ref_block_num" => 22017, "ref_block_prefix" => 3920123292, "context_free_actions" => [], "actions" => [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => "00000000007015d6000000005c95b1ca102700000000000004454f53000000000c757365722d3e746573746572" ] ], "transaction_extensions" => [] ], "signatures" => [ "SIG_K1_JzN9DnpyhKfjoef3C2TZBTPA5b6ftwuEBnBpvzkueVXThJ34PFFpUFgqyayfXjeLRc15JmZmDiMYAFX99hUgX8vkGAYcnx" ] ], [ "compression" => "none", "transaction" => [ "expiration" => "2018-08-23T06:27:26", "ref_block_num" => 22017, "ref_block_prefix" => 3920123292, "context_free_actions" => [], "actions" => [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "tester", "permission" => "active" ] ], "data" => "000000005c95b1ca00000000007015d6881300000000000004454f53000000000c7465737465722d3e75736572" ] ], "transaction_extensions" => [] ], "signatures" => [ "SIG_K1_KZ2M4AG59tptdRCpqbwzMQvBv1dce5btJCJiCVVy96fTGepApGXqJAwsi17g8AQdJjUQB4R62PprfdUdRYHGdBqK1z9Sx9" ] ] ] );
钱包 Wallet APIs
Create
创建具有给定名称的新钱包 echo $walapi->create("testwallet");
Open
打开给定名称的现有钱包 echo $walapi->open("testwallet");
Lock
锁定给定名称的现有钱包 echo $walapi->lock("testwallet");
Lock All
锁定所有现有钱包 echo $walapi->lockAll();
Unlock
使用给定的名称和密码解锁钱包 echo $ walapi-> unlock（[“testwallet”,“PW5Jb8RAZP6CBjjMLPser3T8i8k9hZXZkMBJ8kb1p6f6hAg2n68jY”]）;
Import Key
将私钥导入给定名称的钱包 echo $walapi->importKey(["testwallet", "5Jmsawgsp1tQ3GD6JyGCwy1dcvqKZgX6ugMVMdjirx85iv5VyPR"]);
Remove Key
从给定名称的钱包中删除密钥对 echo $walapi->removeKey(["testwallet", "PW5Jb8RAZP6CBjjMLPser3T8i8k9hZXZkMBJ8kb1p6f6hAg2n68jY", "EOS7ijWCBmoXBi3CgtK7DJxentZZeTkeUnaSDvyro9dq7Sd1C3dC4"]);
Create Key
创建密钥对并导入 echo $walapi->createKey(["testwallet", "K1"]);
List Wallets
列出所有钱包 echo $walapi->listWallets();
List Keys
列出给定名称和密码的钱包中的所有密钥对 echo $walapi->listKeys(["testwallet", "PW5Jb8RAZP6CBjjMLPser3T8i8k9hZXZkMBJ8kb1p6f6hAg2n68jY"]);
Get Public Keys
列出所有钱包中的所有公钥 echo $walapi->getPublicKeys();
Set Timeout
设置钱包自动锁定超时（以秒为单位） echo $walapi->setTimeout(60);
Sign Transaction
签署交易 echo $walapi->signTransaction( [ "expiration" => "2018-08-23T06:35:30", "ref_block_num" => 22985, "ref_block_prefix" => 3016594541, "max_net_usage_workds" => 0, "delay_sec" => 0, "context_free_actions" => [], "actions" => [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => "00000000007015d6000000005c95b1ca102700000000000004454f53000000000c757365722d3e746573746572" ] ], "transaction_extensions" => [] ], [ "EOS7ijWCBmoXBi3CgtK7DJxentZZeTkeUnaSDvyro9dq7Sd1C3dC4" ], "cf057bbfb72640471fd910bcb67639c22df9f92470936cddc1ade0e2f2e7dc4f" );
EOS Wrapper APIs
Prerequisites
需要设置钱包名称和密码 $eos->setWalletInfo("testwallet", "PW5Jb8RAZP6CBjjMLPser3T8i8k9hZXZkMBJ8kb1p6f6hAg2n68jY");
Push Transaction
推送交易 echo $eos->pushTransaction( [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => [ "from" => "user", "to" => "tester", "quantity" => "1.0000 EOS", "memo" => "memo" ] ] ] );
Make Transaction
进行交易（对pushTransactions有用） $trx = $eos->makeTransaction( [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => [ "from" => "user", "to" => "tester", "quantity" => "1.0000 EOS", "memo" => "memo" ] ] ] );
Push Transactions
推送一些交易 $trx_ids = $eos->pushTransactions( [ $eos->makeTransaction( [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "user", "permission" => "active" ] ], "data" => [ "from" => "user", "to" => "tester", "quantity" => "1.0000 EOS", "memo" => "memo" ] ] ] ), $eos->makeTransaction( [ [ "account" => "eosio.token", "name" => "transfer", "authorization" => [ [ "actor" => "tester", "permission" => "active" ] ], "data" => [ "from" => "tester", "to" => "user", "quantity" => "0.5000 EOS", "memo" => "memo" ] ] ] ) ] ); foreach ($trx_ids as $key => $value) { echo $trx_ids[$key]['transaction_id'] . PHP_EOL; }
Push Action
推动一个操作 echo $eos->pushAction("eosio", "buyram", ["payer"=>"tester","receiver"=>"tester","quant"=>"1.0000 EOS"], ["actor"=>"tester","permission"=>"active"]);
Transfer
交易支付 echo $eos->transfer("user", "tester", "1.0000 EOS", "memo");
Create Key Pair
创建密钥对并返回 $keyPair = $eos->createKeyPair("K1"); echo "$keyPair[0], $keyPair[1]";
Tests
要运行测试套件,只需执行： vendor/bin/phpunit
如果您想获得想象并检查代码覆盖率： vendor/bin/phpunit --coverage-html tests/coverage
如果你真的很无聊,你可能想要运行一些静态分析： vendor/bin/phpmetrics --report-html="tests/static" .
======================================================================
另外,如果大家觉得开源后续支持和服务有问题,也可以选择这个商业的 PHP EOS SDK 开发服务
分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程： java以太坊开发教程 ,主要是针对java和android程序员进行区块链以太坊开发的web3j详解。 python以太坊 ,主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。 php以太坊 ,主要是介绍使用php进行智能合约开发交互,进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。 以太坊入门教程 ,主要介绍智能合约与dapp应用开发,适合入门。 以太坊开发进阶教程 ,主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战,适合进阶。 C#以太坊 ,主要讲解如何使用C#开发基于.Net的以太坊应用,包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。 EOS教程 ,本课程帮助你快速入门EOS区块链去中心化应用的开发,内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点,最后综合运用各知识点完成一个便签DApp的开发。 java比特币开发教程 ,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Java代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Java工程师不可多得的比特币开发学习课程。 php比特币开发教程 ,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Php代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Php工程师不可多得的比特币开发学习课程。 tendermint区块链开发详解 ,本课程适合希望使用tendermint进行区块链开发的工程师,课程内容即包括tendermint应用开发模型中的核心概念,例如ABCI接口、默克尔树、多版本状态库等,也包括代币发行等丰富的实操代码,是go语言工程师快速入门区块链开发的最佳选择。
汇智网原创翻译,转载请标明出处。这里是原文 EOS Chain/Wallet RPC API的PHP开发包 「深度学习福利」大神带你进阶工程师,立即查看>>>
目前对区块链网络安全威胁最大的3种攻击方式：Sybil攻击、Eclipse攻击和DDoS攻击。
本文将重点讲解上述三种攻击方式的原理,以供有关机构参考,在开发基于区块链网络的应用系统时采取措施加强防范。
1
基于区块链网络的 Sybil攻击
Sybil攻击最初是由Douceur在点对点网络环境中提出的,他指出这种攻击破坏了分布式存储系统中的冗余机制,并提出直接身份验证和间接身份验证两种验证方式。后来,Chris Karlof等人指出Sybil攻击对传感器网络中的路由机制同样存在着威胁。
Sybil攻击,又称女巫攻击,是指一个恶意结点非法地对外呈现出多个身份,通常把该结点的这些身份称为Sybil结点。Sybil攻击方式主要有以下几种类型：直接通信、间接通信、伪造身份、盗用身份、同时攻击、非同时攻击。
在区块链网络中,用户创建新身份或者新节点是不需要代价的,攻击者可以利用这一漏洞发动Sybil攻击,伪造自己的身份加入网络,在掌握了若干节点或节点身份之后,随意做出一些恶意的行为。例如误导正常节点的路由表,降低区块链网络节点的查找效率；或者在网络中传输非授权文件,破坏网络中文件共享安全,消耗节点间的连接资源等,而且不用担心自己会受到影响。图2示出了在区块链网络中攻击者进行Sybil攻击的原理。
Sybil攻击对区块链网络的影响主要体现在以下几个方面：
1. 虚假节点加入：在遵循区块链网络协议的基础上,任何网络节点都可以向区块链网络发送节点加入请求消息；收到请求消息的区块链节点会立即做出响应,回复其邻居节点信息。利用这个过程,Sybil攻击者就可以获取大量的区块链网络节点信息来分析区块链网络拓扑,以便更高效地对区块链网络进行攻击或破坏。
2. 误导区块链网络节点的路由选择：节点间路由信息的实时交互是保证区块链网络正常运行的关键因素之一。节点只需定时地向其邻居节点宣告自己的在线情况,就能保证自己被邻居节点加入到其路由表中。恶意的Sybil入侵者通过这个过程,可以入侵正常区块链节点的路由表,误导其路由选择,大大降低区块链节点的路由更新和节点查找效率,极端情况下,会导致Eclipse攻击。
3. 虚假资源发布：Sybil攻击者一旦入侵区块链网络节点的路由表,就可以随意发布自己的虚假资源。区块链网络的目的是实现用户间资源的分布式共享,如果网络中充斥着大量的虚假资源,那么在用户看来,这将是无法接受的。
2
基于区块链网络的Eclipse攻击
Moritz Steiner等人在Kad网络中提出了Eclipse攻击,并且给出了该攻击的原理。Eclipse攻击是指攻击者通过侵占节点的路由表,将足够多的虚假节点添加到某些节点的邻居节点集合中,从而将这些节点“隔离”于正常区块链网络之外。当节点受到Eclipse攻击时,节点的大部分对外联系都会被恶意节点所控制,由此恶意节点得以进一步实施路由欺骗、存储污染、拒绝服务以及ID劫持等攻击行为。因此,Eclipse攻击对区块链网络的威胁非常严重。
区块链网络的正常运行依赖于区块链节点间路由信息的共享。Eclipse攻击者通过不断地向区块链节点发送路由表更新消息来影响区块链节点的路由表,试图使普通节点的路由表充满虚假节点。当区块链节点的路由表中虚假节点占据了较高的比例时,它对区块链网络的正常行为,包括路由查找或者资源搜索,都将被恶意节点所隔绝开,这也是这种攻击被称为月食攻击的原因。图3示出了在区块链网络中攻击者进行
Eclipse攻击的原理。
Eclipse攻击和Sybil攻击密切相关,它需要较多的Sybil攻击节点相配合。为了实现对特定区块链节点群的Eclipse攻击,攻击者必须首先设置足够多的Sybil攻击节点,并且向区块链网络宣称它们是“正常”的节点,然后使用这些Sybil节点与正常的区块链节点通信,入侵其路由表,最终把它们从区块链网络中隔离出去。
Eclipse攻击对区块链网络的影响十分重大。对于区块链网络来说,Eclipse攻击破坏了网络的拓扑结构,减少了节点数目,使得区块链网络资源共享的效率大大降低,在极端情况下,它能完全控制整个区块链网络,把它分隔成若干个区块链网络区域。对于受害的区块链节点来说,它们在未知的情况下脱离了区块链网络,所有区块链网络请求消息都会被攻击者劫持,所以它们得到的回复信息大部分都是虚假的,无法进行正常的资源共享或下载。
3
基于区块链网络的DDoS攻击
DDoS攻击是一种对区块链网络安全威胁最大的攻击技术之一,它指借助于C/S技术,将多个计算机联合起来作为攻击平台,对一个或多个目标发动攻击,从而成倍地提高拒绝服务攻击的威力。
传统的DDoS攻击分为两步：第一步利用病毒、木马、缓冲区溢出等攻击手段入侵大量主机,形成僵尸网络；第二部通过僵尸网络发起DoS攻击。常用的攻击工具包括：Trinoo、TFN、TFN2K、Stacheldraht等。由于各种条件限制,攻击的第一步成为制约DDoS攻击规模和效果的关键。
新型的DDoS攻击不需要建立僵尸网络即可发动大规模攻击,不仅成本低、威力巨大,而且还能确保攻击者的隐秘性。图4示出了在区块链网络中攻击者进行DDoS攻击的原理。
区块链网络中具有数以百万计的同时在线用户数,这些节点提供了大量的可用资源,例如分布式存储和网络带宽。如果利用这些资源作为一个发起大型DDoS攻击的放大平台,就不必入侵区块链网络节点所运行的主机,只需要在层叠网络（应用层）中将其控制即可。理论上说,将区块链网络作为DDoS攻击引擎,如果该网络中有一百万个在线用户,则可以将攻击放大一百万倍甚至更多。
根据攻击方式的不同,基于区块链的DDoS攻击可分为主动攻击和被动攻击两种。基于区块链的主动DDoS攻击是通过主动地向网络节点发送大量的虚假信息,使得针对这些信息的后续访问都指向受害者来达到攻击效果的,具有可控性较强、放大倍数高等特点。这种攻击利用区块链网络协议中基于“推（push）”的机制,反射节点在短时间内会接收到大量的通知信息,不易于分析和记录,并且可以通过假冒源地址避过IP检查,使得追踪定位攻击源更加困难。此外,主动攻击在区块链网络中引入额外流量,会降低区块链网络的查找和路由性能；虚假的索引信息,会影响文件下载速度。
基于区块链的被动DDoS攻击通过修改区块链客户端或者服务器软件,被动地等待来自其它节点的查询请求,再通过返回虚假响应来达到攻击效果。通常情况下,会采取一些放大措施来增强攻击效果,如：部署多个攻击节点、在一个响应消息中多次包含目标主机、结合其它协议或者实现漏洞等。这种攻击利用了区块链网络协议中基于“取（pull）”的机制。被动攻击属于非侵扰式,对区块链网络流量影响不大,通常只能利用到局部的区块链节点。
4
小结
Sybil攻击是Eclipse攻击成功实施的基础。Sybil攻击的目标是单个物理节点在区块链网络上产生大量不同的身份,成功的Sybil攻击可以使发动Eclipse攻击变得更为容易。对单个节点进行DDoS攻击的前提是向区块链网络发布大量的虚假消息或被动地做出虚假响应,Eclipse攻击可以帮助攻击者劫持网络节点间传递的信息,增大成功实施DDoS攻击的可能性。
Sybil攻击只是冒充单个区块链网络节点,对区块链网络的影响是比较小的；Eclipse攻击使得部分区块链节点脱离区块链网络,这对受攻击的节点来说是无法接受的；DDoS攻击的目的是大量占用受害节点的资源,使其无法正常提供服务,因此DDoS攻击对区块链网络的影响是致命的。 内容来源：天下数据 整理：区块链兄弟
「深度学习福利」大神带你进阶工程师,立即查看>>> 如果你问我,学习掌握Linux最快的方式是什么？我认为是背Linux常用命令,因为你在服务器上面操作的时候,无论你想做什么,都是在使用命令。比如：当服务器的应用有问题的时候,你想查看日志使用cat或者tail –f；比如你需要批量替换一个文件里面的指定字符串的时候,你会使用sed；当你要使用docker的时候,依然是使用docker下面的对应的命令,不过很多命令你看名字,就会知道这个命令是干什么的。因而,假如你是一名学生,那么在进入互联网行业之前,想快速打下一个比较好的根底,那么可以采用背重要命令的方式来进行学习,就可以快速掌握 Linux 了。当然,并不是说你背了越多的Linux下面的命令,你会使用了,你就更精通了,还是需要了解一些Linux的系统知识、原理、理论的内容,比如Linux下面的FHS是怎么样的？文件系统有些什么格式？磁盘的常见分区技术等。还是必须理解了一些必要的理论知识,才能更加明白命令使用的原理,对命令有更深入的认识。 Linux入门篇： 很多刚入门的同学,就像无头的苍蝇一样,到处找视频、书籍、网站帖子之类的学习方式,视频虽然讲得详细,但是时间的投入也是巨大的,播放时间,练习时间,加起来很吓人,其实啊很少有人能坚持把一套视频看完；技术帖子之类的,一般都比较散乱,不成学习系统,学起来没有一个系统的框架,随意翻翻也还好；推荐一本书 《Linux就该这么学》 ,感觉还不错,建议新手入手。书籍从目录来看就非常有条理,看书可以系统化的学习、循序渐进,不会初学者不知道从哪儿开始的感觉。建议使用我上面的那本,如果有更好的,也你可以,但是一定要坚持,前期可以安装一个VMware或者virtualbox虚拟机,重复练习为主要手段,把一本书好好吃透,重点是吃透,那么你也就入门了。 那么具体需要掌握哪些命令呢？这里罗列一些必须掌握的命令： 目录类的命令是我们需要得最多的： | cd [24] | 改变工作目录 |
|---|
| chmod [25] | 改变文件或目录的文件权限 | | dirs [24] | 显示 / 清除目录栈中的内容 | | du [24] | 显示文件使用的磁盘空间量 | | file [24] | 分析文件的类型 | | ls [24/25] | 显示文件的各种类型的信息 | | mkdir [24] | 创建目录 | | mv [24/25] | 移动或重命名文件或目录 | | popd [24] | 改变工作目录,将名称从目录栈中弹出 | | pushd [24] | 改变工作目录,将名称压入到目录栈中 | | pwd [24] | 显示工作目录的路径名 | | rm [25] | 删除文件或目录
rmdir [24] | tree [24]
删除空目录 | 显示目录树的图表 |
构建块 | cat [16] | 组合文件,将标准输入复制到标准输出
tee [15] | xargs [25]
将标准输入复制到文件和标准输出 | 使用来自标准输入的参数运行命令 |
|---|
当你不知道需要查找命令的相关信息的时候,可能就需要下面的命令工具了： | alias [13] | 创建 / 显示别名 |
|---|
| type [8] | 定位命令：显示命令的路径名或别名 | | unalias [25] | 删除别名
whence [8] | which [8]
定位命令：显示命令的路径名或别名 | 定位命令：显示命令的路径名或别名 |
当我们需要显示内容的时候,需要我们的显示输出命令,非常重要： | cat [16] | 组合文件,将标准输入复制到标准输出 |
|---|
| echo [12] | 将参数写到标准输出 | | head [16/21] | 从数据的开头选择行 | | hexdump [21] | 显示二进制 ( 非文本 ) 文件 | | less [21] | 分页程序：每次一屏地显示数据 | | more [21] | 分布程序：每次一屏地显示数据 | | od [21] | 显示二进制 ( 非文本 ) 文件
print [12] | tail [21]
将参数写到标准输出 | 在数据的末尾选择行 |
当我们需要对服务器配置的时候,那么编辑命令就非常重要了： | sed [19] | 非交互式文本编辑 |
|---|
| vi [22] | vi 文本编辑器
view [22] | vim [22]
以只读模式启动 vi 文本编辑器 | vim 文本编辑器 |
当我们需要对文件的权限,搜索,操作之类的,那么就需要下面的命令了： | chmod [25] | 改变文件或目录的文件权限 |
|---|
| cp [25] | 复制文件；复制目录 | | du [24] | 显示文件使用的磁盘空间量 | | find [25] | 在目录树中搜索文件,处理结果 | | ln [25] | 创建文件的一个新链接 | | locate [25] | 搜索文件 | | ls [24/25] | 显示文件的各种类型的信息 | | mkfifo [23] | 创建命名管道 | | mv [24/25] | 移动或重命名文件或目录 | | rm [25] | 删除文件或目录 | | shred [25] | 安全删除文件 | | stat [25] | 显示 i 节点的信息 | | touch [25] | 更新文件的访问 / 修改时间；创建文件 | | umask [25] | 在文件创建过程中设置文件模式掩码
whence [8] | whereis [25]
定位命令：显示命令的路径名或别名 | 查看与命令关联的文件 |
那么我们知道了这么多命令,或者忘记了命令的参数和使用那万一忘记了,如何找到呢？下面就交大家几个必备命令： 神器一:man命令 格式： man[ 空格 ][ 需要查看的命令 ] 比如我们输入：man ls 就会看到man page 如下图 神器二：info命令 格式：info [需要查看的命令] 比如我们输入info ls 回车,就会看到下图： 最后,在给大家推荐学Linux网站,绝非广告,是背命令必用的：Linux命令大全(手册)_Linux常用命令行实例详解_Linux命令学习手册 ： http冒号//man点linuxde点net/ 「深度学习福利」大神带你进阶工程师,立即查看>>>
1. 开发包概述
EosTool 的目的是消除使用PHP开发EOS区块链应用的痛苦,例如： 通过Nodeos和Keosd的RPC接口调用其功能 离线生成EOS格式的私钥和公钥 使用本地私钥生成符合EOS要求的交易签名 将交易对象序列化为Nodeos要求的packed_trx格式
可以认为EosTool是PHP版本的 eosjs ,利用它可以完整地实现EOS官方客户端Cleos的功能, 也可以很方便地在PHP应用中增加对EOS区块链的支持能力,极大地提高开发效率。
有兴趣的朋友也可以直接访问这里,本文内容即转自该博客： EOS区块链PHP开发包
EosTool运行在**Php 7.1+**环境下,当前版本1.0.0,主要代码文件清单如下：
代码文件 说明 | eostool/src/client/NodeClient.php | 节点软件nodeos的rpc接口封装类 | eostool/src/client/WalletClient.php | 钱包软件keosd的rpc接口封装类 |
|---|
| eostool/src/client/RpcOutput.php | RPC返回结果封装类 | | eostool/src/Crypto/PrivateKey.php | EOS私钥类 | | eostool/src/Crypto/PublicKey.php | EOS公钥类 | | eostool/src/Crypto/Signature.php | EOS签名类 | | eostool/src/Serializer/AbiType.php | EOS的ABI类型封装类 | | eostool/src/Serializer/AbiTypeFactory.php | ABI类型工厂类 | | eostool/src/Serializer/SerialBuffer.php | 序列化缓冲区实现类 | | eostool/src/Serializer/Serializer.php | 序列化器实现类 | | eostool/src/Signer/Signer.php | 签名器接口 | | eostool/src/Signer/KeosdSigner.php | Keosd签名器实现类 | | eostool/src/Signer/LocalSigner.php | 本地离线签名器实现接口 | | eostool/src/Contract.php | 合约类 | | eostool/src/EosTool.php | 开发包入口类 | | eostool/tests | 单元测试用例目录 | | eostool/phpunit.xml | 单元测试配置文件
eostool/vendor | eostool/composer.json
第三方依赖包 | composer配置文件 |
2. 访问节点服务器
使用 NodeClient 类访问nodeos的rpc接口。例如,下面的代码访问本机运行的 Nodeos节点的 chain 插件的 get_info 接口： use EosTool\Client\NodeClient; $nc = new NodeClient(); $ret = $nc->chain->getInfo(); if($ret->hasError()) throw new Exception($ret->getError()); $info = $ret->getResult();
2.1 RPC调用分组
Nodeos采用了插件化架构,不同的插件的API也归入不同的分组,EosTool采用了保持一致的 命名方法,根据api即可推断出NodeClient的调用方法：API分组对应于NodeClient的一个同名 属性,API则对应与No的Client的分组同名属性下的一个经过 camelCase 转化的方法。例如：
插件 API分组 RPC API NodeClient方法 | chain_api_plugin | chain | get_info | $nc->chain->getInfo() | history_api_plugin | history | get_transaction | $nc->history->getTransaction()
net_api_plugin | producer_api_plugin | dbsize_api_plugin
net | producer | dbsize
status | get_runtime_options | get
$nc->net->status() | $nc->producer->getRunTimeOptions() | $nc->dbsize->get() |
|---|
RPC API的官方文档： https://developers.eos.io/eosio-nodeos/reference
2.2 RPC调用参数
对于Nodeos而言,有些调用需要传入额外的参数,例如chain插件的get_block接口, 使用EosTool进行调用时,将参数组织为一个关联数组即可,示例代码如下： $payload = [ 'block_num_or_id' => 1 ]; $ret = $nc->chain->getBlock($payload);
2.3 RPC调用返回值
所有RPC调用的返回结果都是一个 RpcOutput 实例,调用其 hasError() 方法可以 判断是否调用出错,进一步可以利用 getError() 方法获取错误信息。
RPC调用的响应则可以通过 getResult() 方法获取,它是一个由原始的JSON结果 转化出的StdClass对象,因此可以方便的提取属性信息,例如： echo 'chain id' . $info->chain_id . PHP_EOL;
2.4 访问主网/测试网节点
在创建NodeClient实例时,可以传入额外的参数执行来制定要访问的EOS主网或测试网节点。 例如,使用下面的代码访问某个主网节点： $nc = new NodeClient(['base_uri' => 'https://api.eosnewyork.io:443/v1/']);
或者访问jungle测试网的某个节点： $nc = new NodeClient(['base_uri' => 'https://jungle.eosio.cr:443/v1/']);
3、访问钱包服务器
新版的Keosd已经不提供RPC API文档,这可能意味着它在EOS软件栈中已经开始滑向边缘地位。 不过可以在这个地址访问老版的文档： https://developers.eos.io/eosio-nodeos/v1.1.0/reference
使用 WalletClient 类访问Keosd的rpc接口。例如,下面的代码访问本机运行的 Keosd的 list_wallets 接口： use EosTool\Client\WalletClient; $wc = new WalletClient(); $ret = $wc->listWallets(); if($ret->hasError()) throw new Exception($ret->getError()); $wallets = $ret->getResult();
由于Keosd的API不再分组,因此RPC对应的方法直接挂在WalletClient对象上,这是一个不同之处。 与NodeClient一样的是,WalletClient的调用返回结果也是一个RpcOutput对象。
1.4版的Keosd默认使用UNIX套接字而不是HTTP提供RPC接口,这可能是考虑到绝大多数情况下 Keosd都运行在本机,使用IPC会更安全一些。因此这也是WalletClient的默认实例化选项, 在绝大多数情况下,不需要传入额外的参数来实例化WalletClient。
4. 私钥与公钥
EOS的密钥算法类似于比特币,但做了一些调整,定义了自己的格式。
使用 PrivateKey 类的静态方法 new() 生成随机私钥。例如： use EosTool\Crypto\PrivateKey; $prv = PrivateKey::new(); echo $prv->toEos() . PHP_EOL; //类似：5Hu6nxM6s6UQ3nYkr1s1GKA17zPqpceUuWxH3JBwK8ZorMSRqGi
toEos() 方法用来将私钥对象转换为EOS的自定义格式。
4.1 公钥推导
从私钥可以推导出公钥,例如： $pub = $prv->getPublicKey(); echo $pub->toEos() . PHP_EOL; //类似：EOS6wQ6t3n148GfzLzgxq7cC8ARDKxeaB3hQXdXn7oZYdwEyAXiSv
同样,使用 toEos() 方法将公钥转换为EOS的自定义格式。
4.2 导入EOS私钥
可以将一个EOS格式的私钥转化为EosTool的PrivateKey对象,例如,下面的 代码将指定的EOS私钥导入,并显示其对应的EOS公钥： $prv = PrivateKey::fromEos('5Hu6nxM6s6UQ3nYkr1s1GKA17zPqpceUuWxH3JBwK8ZorMSRqGi'); echo $prv->getPublicKey()->toEos() . PHP_EOL;
4.3 权威签名
PrivateKey的 sign() 方法支持普通签名和EOS节点要求的权威签名。例如下面的代码返回一个 普通签名： $hex = '1234567890abcdef...'; $signature = $prv->sign($hex);
传入额外的参数来获得指定数据的权威签名： $hex = '1234567890abcdef...'; $signature = $prv->sign($hex,true);
5. 序列化
EOS要求交易在提交节点 push_transaction 之前先进行序列化,这也是在PHP中操作EOS交易 绕不过去的一个环节。
在EosTool中,使用 Serializer 类进行序列化操作。例如,下面的代码将一个EOS转账交易 序列化为可以提交给EOS节点旳16进制码流格式： use EosTool\Serializer\Serializer; $abi = json_decode(file_get_contents('transaction.abi'),true); $serializer = Serializer::fromAbi($abi); $tx = [ 'expiration'=>'2018-12-04T17:00:00', 'ref_block_num' => 2878, 'ref_block_prefix' => 29012031, 'max_net_usage_words' => 0, 'max_cpu_usage_ms' => 0, 'delay_sec' => 0, 'context_free_actions' => [], 'actions' => [[ 'account' => 'eosio.token', 'name' => 'transfer', 'authorization' => [[ 'actor' => 'eosio', 'permission' => 'active' ]], 'data' => '1122334455667788990011223344556677.....889900' ]], 'transaction_extensions' => [] ]; $hex = $serializer->serialize('transaction',$tx); echo 'serialized tx => ' . $hex . PHP_EOL;
Serializer的静态方法 fromAbi() 用来根据一个指定的abi构造序列化器实例,然后 利用实例的 serialize() 方法对指定类型的数据进行序列化操作,得到16进制码流。
6. 签名
EosTool提供了两种进行交易签名的方法：利用Keosd进行签名,或者使用本地私钥进行签名。
使用 KeosdSigner 类来利用钱包服务器完成签名。例如： use EosTool\Signer\KeosdSigner; $signer = new KeosdSigner(); $signatures = $signer->sign($tx,$pubKeys,$chainId);
利用 LocalSigner 类,则可以避免使用keosd,直接利用离线私钥签名。例如： use EosTool\Signer\LocalSigner; $prvKeys = ['5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3']; $signer = new LocalSigner($prvKeys); $signatures = $signer->sign($tx,$pubKeys,$chainId);
7. 交易提交
一个交易数据,需要经过规范化、序列化、签名、打包一系列操作,才可以提交给 Nodeos节点广播出去。 EosTool 类提供了 transact() 方法来隔离这些繁琐的操作。
例如,下面的代码使用NodeClient和LocalSigner创建一个EosTool实例,然后提交 一个交易： use EosTool\Client\NodeClient; use EosTool\Signer\LocalSigner; use EosTool\EosTool; $nc = new NodeClient(); $signer = new LocalSigner(['5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3']); $tool = new EosTool($nc,$signer); $tx = [ 'actions' => [[ 'account' => 'eosio.token', 'name' => 'transfer', 'authorization' => [[ 'actor' => 'eosio', 'permission' => 'active' ]], 'data' => [ 'from' => 'eosio', 'to' => 'tommy', 'quantity' => '200.0000 EOS', 'memo' => 'take care' ] ]] ]; $ret = $tool->transact($tx); echo $ret->getResult()->transaction_id . PHP_EOL;
可以很方便地将签名器改为KeosdSigner,例如： $nc = new NodeClient(); $signer = new KeosdSigner(); $tool = new EosTool($nc,$signer);
8. 调用单个合约动作
使用EosTool的 pushAction() 方法调用单个合约动作。例如,下面的代码调用tommy 账户托管合约的 hi() 方法： $tool = new EosTool(new NodeClient(),new KeosdSigner()); $ret = $tool->pushAction('tommy','hi',['user'=>'tommy']);
9. 部署合约
使用EosTool的 setContract() 方法部署合约,例如： $tool = new EosTool(new NodeClient(),new KeosdSigner()); $account = 'tommy'; $abi = file_get_contents('hello.abi'); $wasm = file_get_contents('hello.wasm'); $ret = $tool->setContract($account,$abi,$wasm);
有兴趣的朋友可以去这里： EOS区块链PHP开发包 「深度学习福利」大神带你进阶工程师,立即查看>>> EosTool 的目的是消除使用PHP开发EOS区块链应用的痛苦,例如： 通过Nodeos和Keosd的RPC接口调用其功能 离线生成EOS格式的私钥和公钥 使用本地私钥生成符合EOS要求的交易签名 将交易对象序列化为Nodeos要求的packed_trx格式 可以认为EosTool是PHP版本的 eosjs ,利用它可以完整地实现EOS官方客户端Cleos的功能, 也可以很方便地在PHP应用中增加对EOS区块链的支持能力,极大地提高开发效率。 原文链接： http://sc.hubwiz.com/codebag/eos-php-sdk/ EosTool运行在Php 7.1+环境下,当前版本1.0.0,主要代码文件清单如下： | 代码文件 | 说明 | | eostool/src/client/NodeClient.php | 节点软件nodeos的rpc接口封装类 | | eostool/src/client/WalletClient.php | 钱包软件keosd的rpc接口封装类 | | eostool/src/client/RpcOutput.php | RPC返回结果封装类 | | eostool/src/Crypto/PrivateKey.php | EOS私钥类 | | eostool/src/Crypto/PublicKey.php | EOS公钥类 | | eostool/src/Crypto/Signature.php | EOS签名类 | | eostool/src/Serializer/AbiType.php | EOS的ABI类型封装类 | | eostool/src/Serializer/AbiTypeFactory.php | ABI类型工厂类 | | eostool/src/Serializer/SerialBuffer.php | 序列化缓冲区实现类 | | eostool/src/Serializer/Serializer.php | 序列化器实现类 | | eostool/src/Signer/Signer.php | 签名器接口 | | eostool/src/Signer/KeosdSigner.php | Keosd签名器实现类 | | eostool/src/Signer/LocalSigner.php | 本地离线签名器实现接口 | | eostool/src/Contract.php | 合约类 | | eostool/src/EosTool.php | 开发包入口类 | | eostool/tests | 单元测试用例目录 | | eostool/phpunit.xml | 单元测试配置文件 | | eostool/vendor | 第三方依赖包 | | eostool/composer.json | composer配置文件 | 2. 访问节点服务器 使用 NodeClient 类访问nodeos的rpc接口。例如,下面的代码访问本机运行的 Nodeos节点的 chain 插件的 get_info 接口： use EosTool\Client\NodeClient; $nc = new NodeClient(); $ret = $nc->chain->getInfo(); if($ret->hasError()) throw new Exception($ret->getError()); $info = $ret->getResult(); 2.1 RPC调用分组 Nodeos采用了插件化架构,不同的插件的API也归入不同的分组,EosTool采用了保持一致的 命名方法,根据api即可推断出NodeClient的调用方法：API分组对应于NodeClient的一个同名 属性,API则对应与No的Client的分组同名属性下的一个经过 camelCase 转化的方法。例如： | 插件 | API分组 | RPC API | NodeClient方法 |
|---|
| chain_api_plugin | chain | get_info | $nc->chain->getInfo() | | history_api_plugin | history | get_transaction | $nc->history->getTransaction() | | net_api_plugin | net | status | $nc->net->status() | | producer_api_plugin | producer | get_runtime_options | $nc->producer->getRunTimeOptions() | | dbsize_api_plugin | dbsize | get | $nc->dbsize->get() | RPC API的官方文档： https://developers.eos.io/eosio-nodeos/reference 2.2 RPC调用参数 对于Nodeos而言,有些调用需要传入额外的参数,例如chain插件的get_block接口, 使用EosTool进行调用时,将参数组织为一个关联数组即可,示例代码如下： $payload = [ 'block_num_or_id' => 1 ]; $ret = $nc->chain->getBlock($payload); 2.3 RPC调用返回值 所有RPC调用的返回结果都是一个 RpcOutput 实例,调用其 hasError() 方法可以 判断是否调用出错,进一步可以利用 getError() 方法获取错误信息。 RPC调用的响应则可以通过 getResult() 方法获取,它是一个由原始的JSON结果 转化出的StdClass对象,因此可以方便的提取属性信息,例如： echo 'chain id' . $info->chain_id . PHP_EOL; 2.4 访问主网/测试网节点 在创建NodeClient实例时,可以传入额外的参数执行来制定要访问的EOS主网或测试网节点。 例如,使用下面的代码访问某个主网节点： $nc = new NodeClient(['base_uri' => 'https://api.eosnewyork.io:443/v1/']); 或者访问jungle测试网的某个节点： $nc = new NodeClient(['base_uri' => 'https://jungle.eosio.cr:443/v1/']); 3、访问钱包服务器 新版的Keosd已经不提供RPC API文档,这可能意味着它在EOS软件栈中已经开始滑向边缘地位。 不过可以在这个地址访问老版的文档： https://developers.eos.io/eosio-nodeos/v1.1.0/reference 使用 WalletClient 类访问Keosd的rpc接口。例如,下面的代码访问本机运行的 Keosd的 list_wallets 接口： use EosTool\Client\WalletClient; $wc = new WalletClient(); $ret = $wc->listWallets(); if($ret->hasError()) throw new Exception($ret->getError()); $wallets = $ret->getResult(); 由于Keosd的API不再分组,因此RPC对应的方法直接挂在WalletClient对象上,这是一个不同之处。 与NodeClient一样的是,WalletClient的调用返回结果也是一个RpcOutput对象。 1.4版的Keosd默认使用UNIX套接字而不是HTTP提供RPC接口,这可能是考虑到绝大多数情况下 Keosd都运行在本机,使用IPC会更安全一些。因此这也是WalletClient的默认实例化选项, 在绝大多数情况下,不需要传入额外的参数来实例化WalletClient。 4. 私钥与公钥 EOS的密钥算法类似于比特币,但做了一些调整,定义了自己的格式。 使用 PrivateKey 类的静态方法 new() 生成随机私钥。例如： use EosTool\Crypto\PrivateKey; $prv = PrivateKey::new(); echo $prv->toEos() . PHP_EOL; //类似：5Hu6nxM6s6UQ3nYkr1s1GKA17zPqpceUuWxH3JBwK8ZorMSRqGi toEos() 方法用来将私钥对象转换为EOS的自定义格式。 4.1 公钥推导 从私钥可以推导出公钥,例如： $pub = $prv->getPublicKey(); echo $pub->toEos() . PHP_EOL; //类似：EOS6wQ6t3n148GfzLzgxq7cC8ARDKxeaB3hQXdXn7oZYdwEyAXiSv 同样,使用 toEos() 方法将公钥转换为EOS的自定义格式。 4.2 导入EOS私钥 可以将一个EOS格式的私钥转化为EosTool的PrivateKey对象,例如,下面的 代码将指定的EOS私钥导入,并显示其对应的EOS公钥： $prv = PrivateKey::fromEos('5Hu6nxM6s6UQ3nYkr1s1GKA17zPqpceUuWxH3JBwK8ZorMSRqGi'); echo $prv->getPublicKey()->toEos() . PHP_EOL; 4.3 权威签名 PrivateKey的 sign() 方法支持普通签名和EOS节点要求的权威签名。例如下面的代码返回一个 普通签名： $hex = '1234567890abcdef...'; $signature = $prv->sign($hex); 传入额外的参数来获得指定数据的权威签名： $hex = '1234567890abcdef...'; $signature = $prv->sign($hex,true); 5. 序列化 EOS要求交易在提交节点 push_transaction 之前先进行序列化,这也是在PHP中操作EOS交易 绕不过去的一个环节。 在EosTool中,使用 Serializer 类进行序列化操作。例如,下面的代码将一个EOS转账交易 序列化为可以提交给EOS节点旳16进制码流格式： use EosTool\Serializer\Serializer; $abi = json_decode(file_get_contents('transaction.abi'),true); $serializer = Serializer::fromAbi($abi); $tx = [ 'expiration'=>'2018-12-04T17:00:00', 'ref_block_num' => 2878, 'ref_block_prefix' => 29012031, 'max_net_usage_words' => 0, 'max_cpu_usage_ms' => 0, 'delay_sec' => 0, 'context_free_actions' => [], 'actions' => [[ 'account' => 'eosio.token', 'name' => 'transfer', 'authorization' => [[ 'actor' => 'eosio', 'permission' => 'active' ]], 'data' => '1122334455667788990011223344556677.....889900' ]], 'transaction_extensions' => [] ]; $hex = $serializer->serialize('transaction',$tx); echo 'serialized tx => ' . $hex . PHP_EOL; Serializer的静态方法 fromAbi() 用来根据一个指定的abi构造序列化器实例,然后 利用实例的 serialize() 方法对指定类型的数据进行序列化操作,得到16进制码流。 6. 签名 EosTool提供了两种进行交易签名的方法：利用Keosd进行签名,或者使用本地私钥进行签名。 使用 KeosdSigner 类来利用钱包服务器完成签名。例如： use EosTool\Signer\KeosdSigner; $signer = new KeosdSigner(); $signatures = $signer->sign($tx,$pubKeys,$chainId); 利用__LocalSigner__类,则可以避免使用keosd,直接利用离线私钥签名。例如： use EosTool\Signer\LocalSigner; $prvKeys = ['5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3']; $signer = new LocalSigner($prvKeys); $signatures = $signer->sign($tx,$pubKeys,$chainId); 7. 交易提交 一个交易数据,需要经过规范化、序列化、签名、打包一系列操作,才可以提交给 Nodeos节点广播出去。 EosTool 类提供了 transact() 方法来隔离这些繁琐的操作。 例如,下面的代码使用NodeClient和LocalSigner创建一个EosTool实例,然后提交 一个交易： use EosTool\Client\NodeClient; use EosTool\Signer\LocalSigner; use EosTool\EosTool; $nc = new NodeClient(); $signer = new LocalSigner(['5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3']); $tool = new EosTool($nc,$signer); $tx = [ 'actions' => [[ 'account' => 'eosio.token', 'name' => 'transfer', 'authorization' => [[ 'actor' => 'eosio', 'permission' => 'active' ]], 'data' => [ 'from' => 'eosio', 'to' => 'tommy', 'quantity' => '200.0000 EOS', 'memo' => 'take care' ] ]] ]; $ret = $tool->transact($tx); echo $ret->getResult()->transaction_id . PHP_EOL; 可以很方便地将签名器改为KeosdSigner,例如： $nc = new NodeClient(); $signer = new KeosdSigner(); $tool = new EosTool($nc,$signer); 8. 调用单个合约动作 使用EosTool的 pushAction() 方法调用单个合约动作。例如,下面的代码调用tommy 账户托管合约的 hi() 方法： $tool = new EosTool(new NodeClient(),new KeosdSigner()); $ret = $tool->pushAction('tommy','hi',['user'=>'tommy']); 9. 部署合约 使用EosTool的 setContract() 方法部署合约,例如： $tool = new EosTool(new NodeClient(),new KeosdSigner()); $account = 'tommy'; $abi = file_get_contents('hello.abi'); $wasm = file_get_contents('hello.wasm'); $ret = $tool->setContract($account,$abi,$wasm); 「深度学习福利」大神带你进阶工程师,立即查看>>>
随着币价的一直下跌,有传言说,比特币价格此次崩盘,只是大 BOSS 吴忌寒为加速淘汰老旧矿机而祭出的绝招。
无论这个阴谋论真假与否,在整个区块链行业的凛冽寒冬中,价格的涨跌已经左右了太多的人头脑之中的理智。可是,众人之中,究竟有几个人真正理解了区块链技术的密码学机制与分布式计算？究竟有几个人还会关心区块链在技术上的创新？
尘归尘,土归土。可能只有巨大的泡沫消散之后,区块链才能通过技术创新显示出真正的影响力。让区块链回归技术与应用的本质,这也是我们一直以来的定位。然而,传播这样的内容和话题,离不开货真价实的技术干货,以及有感染力的人物和故事。
我们今天的内容就来自于这样一个女生：
她是工业与系统工程专业出身,做过顶级投行高盛的分析师,做过著名风投 a16z 的合伙人——这都是许多人梦寐以求的工作。但是,功成名就的路上,她却发现编程才是自己想要的生活。
笨办法学会编程？她没学会。如何用 HTML/CSS 做一个网页？她开始上瘾了。所以,没有选择斯坦福、MIT 的编程学位,她更喜欢 Hack Reactor 的全栈动手实践。先学 JavaScript、React,后面的想法是机器学习、计算机视觉……这个女生就是 Preethi Kasireddy。
接触区块链之后,金融从业背景和全栈编程能力让 Preethi 更加如鱼得水。从 Coinbase 工程师到智能合约设计的自由职业者,究根问底的天性让她开始用最浅显易懂的语言来向大家解释区块链技术的真相,篇篇爆款：
比如这篇,《 最全！写给技术小白的以太坊完整工作原理和运行机制！ 》,原文 “How does Ethereum work, anyway?” 在 Medium 获赞 45000+。 https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369
比如这篇,《 公有链的基本挑战 》,原文 “Fundamental challenges with public blockchains” 在 Medium 获赞 17200+,评论比原文还长。 https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428
比如这篇,《区块链尚无法扩展,至少现在不成,但希望犹在》,原文 “Blockchains don’t scale. Not today, at least. But there’s hope.” 在 Medium 获赞 13600+,由技术专栏 “Hacker Noon” 特别约稿。 https://medium.com/@preethikasireddy/why-im-leaving-silicon-valley-72919edb3297
但是,不了解分布式系统的工作原理,不了解人们如何能在分散的网络上达成共识,你始终无法真正理解区块链技术的创新之处。众所周知,密码学和分布式计算都不是什么新鲜事物；那为什么把它们整合在一起的区块链技术,却能够迫使科学家和工程师不得不去重新审视分布式计算的基本范式呢？
接下来,我们就听 Preethi 从分布式系统的基本概念说起,一步一步说到公式算法,特别是中本聪共识的真正精妙之处,进而抓住区块链技术不会随泡沫而飘散的真实内涵：
分布式系统其实不是一个新鲜的话题,有关这个课题的研究已经进行过几十年了。
随着比特币、区块链等话题在网络上风生水起,分布式系统也逐渐走进大众的视野。区块链始于比特币,它本身就是一种新型的分布式系统,它们的流行反过来又促使分布式计算领域的研究发生翻天覆地的变化。
想真正弄懂区块链,充分理解分布式系统是必不可少的。
那么,你又该如何去了解分布式系统呢？
这个话题很难三言两语说清楚,因为它所涉及的知识实在是太广泛、太琐碎了。关于分布式计算的资料文献要么晦涩难懂,要么不成体系。况且,随着应用场景不断拓展,分布式系统又衍生出数百种不同架构,分别服务于数百种不同的需求,这一切让整个问题愈显复杂。
而如何把复杂的问题简单化,把生僻的话题讲明白,也就难上加难了。所以,在区块链概念满天飞的今天,如何 Get 到分布式系统和共识机制的基本概念而不被忽悠,就显得愈加迫切了。
本文正是出于这样的目的来介绍入门区块链的这一基础： 一、什么是分布式系统？
二、分布式系统的基本性质
三、分布式系统中的共识问题
四、一些基本的共识算法（Paxos、Raft、DLS 和 PBFT）
五、中本聪共识为什么这么牛？
请记住,如果读读这篇文章,你就想成为行业大拿,这肯是不现实的。
1
什么是分布式系统？
分布式系统是一组不同、分散的的进程,它们之间能够互相协调,通过相互间的信息传递完成一个共同的目标。尽管这些进程是分开的,但呈现给用户的,是一个系统、一个整体。
分布式系统是围绕同一个目标而协同工作的一群计算设备。
进程可以是“节点”、“个体”、“计算机”或“组件”,在本文中,它们的意思都是一样的。与之类似,“网络”与“系统”表达的也是同一个意思。
前文中说过,分布式系统有数百种体系结构。
例如,一台计算机可以看作成一个分布式系统——CPU、内存 和 IO 设备都是独立的进程,它们相互协作完成同一个目标,比如上网、编程、游戏。
再比如,下图中飞机也可以看做是一个分布式系统,各单元共同协作,实现飞机的空间转移。
https://www.weetech.de/en/news-info/tester-abc/distributed-system-1/
类似的例子不胜枚举,在本文中,我们主要讨论进程是独立分散的计算机的分布式系统。
2
分布式系统的基本性质
分布式系统有一些基本的共性,它们包括：
2.1 并发性
系统中的进程是同时操作的,多个事件同时发生。换言之,网络中的每台计算机都在同时、独立地执行任务。
最大的难题在于协调。
Lamport, L (1978). Time, Clocks and Ordering of Events in a Distributed System
2.2 缺少全局时钟
在分布式计算机系统中,我们需要确定事件发生的先后顺序,但由于各台计算机在空间上是分开的,所以,我们缺少一个全局时钟。
在《分布式系统中的时间、时钟和事件顺序》这篇论文中,Leslie Lamport 展示了他的排序方法,首先需要记住以下两点： 消息发送在收到之前。 每台计算机都有一系列的事件。
通过确定某两个事件的先后,我们可以知道系统中事件的部分顺序。 译注：部分顺序——对应于总体顺序,例如：三个事件的特定顺序是 A＞B＞C,在一次计算中,我们只要求 A＞C,不在乎 B 何时发生,这就是部分顺序,那么 A > B > C, A > C > B 和 B > A > C 都满足部分顺序。
Lamport 的论文中阐述了一种算法,它要求每台计算机都能从另一台上收到信息。通过这种方式,得到部分顺序后,总体顺序也可以逐步推出来。
在这里,我们是完全根据每台计算机收到信息的时间来排序的,那就会产生一些异常状况。因为各地的时钟或多或少都会有差别,这就导致系统顺序与外部用户感知到的顺序是不同的。
为了处理这种异常,Lamport 想出一个办法,同步各地的物理时钟！
问题这样就能解决了吗？太天真了,年轻人！
同步大量独立的时钟绝不是一个简单的事情,而是一个非常复杂的计算机科学问题。即使你在最初精确地设置了一大堆时钟,由于时钟漂移的存在,随着时间推移,时钟一定会有所变化。 译注：时钟漂移——各个时钟的计时速度存在细微差别,随着时间推移,一个时钟的运行速度与其参考时钟不完全相同,失去同步。计算机中使用的以晶体为基础的时钟也会发生漂移。容易被定时攻击所利用。
因此,在分布式计算机系统中,时间和事件顺序是根本障碍。
2.3 独立进程故障
在分布式系统中,每个进程都可能发生故障,这些故障可能是进程崩溃或失控,可能是信息遗漏、歪曲或重复,也可能是恶意信息,还可能是网络延迟、断网断电。
单个进程的故障率其实很低,但随着系统中的进程越来越多,系统会发生故障就从一个偶然事件变为必然事件。我们要做的就是开发分布式协议,保证系统在各种异常情形下仍能正常工作。因此分布式系统也被称为“容错分布式计算”。
这些异常可大致分为三个类型： 崩溃：进程在没有任何警告的情况下停止工作,如计算机崩溃。属于非恶意行为。 遗漏：进程发送消息,但其他节点收不到,如消息丢失。属于非恶意行为。 拜占庭：进程的行为随机。如果是在受控环境（例如 Google 或 Amazon 的数据中心）中,这种情况可以不做考虑。我们主要关心故障发生在“冲突地带”中的情形,他们的行为相当随意,可能会恶意更改和阻断信息,或者根本就不发送。属于恶意行为。
为了控制网络中的分散个体,我们需要设计一项协议,让一定会产生异常的系统仍然能够提供服务,完成共同目标,即系统需要具备容错性。
因此,在构建分布式系统时必须做的核心假设是,在部分异常时系统还能否正常工作,异常是由于非恶意行为还是恶意行为。
一般来说,在构建分布式系统时,有两种模型需要考虑:
（1）简单容错
在简单的容错系统中,我们假设系统的所有进程的行为方式都是固定的：要么遵守协议,要么失败。这种类型的系统能够妥善处理脱机或故障节点,并且不必担心节点发出任意或恶意的行为。
但是,如果运行环境不受控,简单容错机制很难发挥作用。
（2a）拜占庭容错
在拜占庭容错系统中,我们假设节点可能产生故障或者恶意。在分散系统中,网络是开放的、不受限制的,节点由独立的个体控制,因此行为有很大的随意性,在设计系统模型时,这种情况必须考虑。
（2b）BAR 容错
还有一种故障叫做“理性”故障,即节点为了自身利益,可能会背离系统整体的目标。换句话说,节点可以老实,也可以不老实,这取决于其动机。如果“筹码”足够高,那么甚至大多数节点都会“叛变”。正所谓忠诚,取决于背叛的筹码。
这被正式定义为 BAR 模型,它考虑到了拜占庭式故障和理性故障。BAR 模型假设系统中有三种角色： 拜占庭节点：是恶意的,只想作恶 ——坏人 无私节点：诚实的,总是遵循协议 ——老实人 理性节点：符合自身利益才会遵循协议 ——普通人
2.4 信息传输
分布式系统中的计算机之间通过“信息传输”实现沟通和协调,信息传输协议可以任选,无论是 HTTP、RPC 还是特定场景中的自定义协议。
我们首先来了解一下信息传输环境：
（1）同步式
在同步信息传输系统中,假定信息传输时间是固定的、已知的。
概念上并不复杂,用户发送了消息,接收组件就会在固定的时间内得到消息。这样用户可以根据信息传输所需的固定时间上限来设计他们的协议。
然而,在分布式系统的实际操作中,这种传输环境应用有限。因为计算机可能崩溃或掉线,消息可能丢失、重复、延迟或乱序。
（2）异步式
在异步信息传输系统中,假定网络可能无限延迟消息的发送,或者大量重复或者乱序。这时候,对于信息传输所需时间是不确定的。
3
分布式系统中的共识问题
到这里,我们已经了解了分布式系统的下列特性： 并发性 缺少全局时钟 独立进程故障 信息传输
接下来,我们将重点理解在分布式系统中“达成共识”的意义。最常见的一种模型称为复制状态机。
复制状态机（Replicated state machine）
复制状态机,通俗点讲,就是多个节点从相同的初始状态开始,执行相同的一串命令,产生相同的最终状态。这一系列节点的状态都是相同的,就是所谓的“复制状态”。
在复制状态机中,如果某一事务是有效的,将其输入将导致系统的状态向下一个转换。在每个状态转换过程中,每个进程决定下一个输出值。
从一个有效状态转换到下一个有效状态的逻辑称为“状态转换逻辑”。
事务是数据库上的原子操作,这种操作一旦开始,就一直运行到结束,中间不会有任何切换。
换句话讲就是操作要么完全完成,要么根本不发生。在复制状态机中,这一系列被维护的事务集合称为“事务日志”。
所谓的“达成共识”意味着所有的计算机必须一致同意在每个状态转换过程中的输出值,也就是说,每台计算机上的事务日志都是相同的。
复制状态是一种确定性状态机,功能与单个状态机相同,状态机中的单个计算机可能发生故障,但整个状态机依然会正常运转。
故障主要有： 计算机崩溃。 网络不稳定,信息传递可能会延迟、乱序或者失败。 没有全局时钟,事件顺序难以确定。
即使是在局部故障的情况下,复制状态机仍然必须不断地接受新事务到事务日志,从而提供服务。这其实也是每一种共识算法的基本目标。
共识问题的定义
如果一个算法满足以下条件,它就会达到共识： 一致性：所有非故障进程必须决定相同的输出值。 终止性：所有非故障节点最后必须在某个值上终止,不能无限循环下去。 注意：不同的算法有不同的条件。例如,有些算法将一致性划分为稳定性和整体性,还有些算法具有合法性、完整性或高效性的概念。在这里,如此细微的差别,就不赘述了。
在共识算法中,系统中的进程分别担任这三种角色： 提议者（Proposers）——也称作领导者（Leader）,发出请求或信息 决策者（Acceptors）——接收提议者的请求,输出响应值的进程 学习者（Learners）——系统中的其他进程,获得系统决定的终止值
定义一个共识算法的过程,通常有以下三个步骤：
第一步,选择 在所有进程中选择一个领导者。 领导者提出下一个有效的输出值。
第二步,投票 无故障的进程接收领导者的输出值,经过验证,把它当作下一个有效值提出。
第三步,决策 所有非故障的进程必须达成共识,以此决定正确的最终值,具体根据所有进程的投票数是否达到预设值。 否则,重复步骤一、二、三,再来一次。
这里需要注意,各种共识算法在一些细节上有所区别,比如： 术语（例如：回合、阶段、轮次） 处理投票的程序 决定最终值的标准（例如：有效性条件）
上面是共识算法定义的一般过程,满足定义中的一般条件,我们就可以构建一种算法,从而创建一个能够达成共识的分布式系统。
好像很简单的样子,有木有?
FLP 不可能性（FLP impossibility）
还差得远呢,我们要面对的最大的难题就是——FLP 不可能性（FLP impossibility）
首先回顾一下同步系统和异步系统的区别: 同步环境——信息传输所用时间是固定的 异步环境——信息传输所用时间无法预估
这个区别很重要。
在同步环境中,我们可以设定信息传输所需的最大时间,允许系统中的不同节点轮流提出新的事务,然后投票确定一项,跳过没有提出事务的节点。这种环境中,达成共识是可能的。
但是,如果想在同步环境中操作,就需要一个信息风险可控的环境,比如说在一个配备原子钟的数据中心,现实中很难操作。 原子钟：一种高精度计时装置,利用原子吸收或释放能量时发出的电磁波来计时,精度可达每 2000 万年误差 1 秒。
然而异步环境中,信息传输时间是不固定的,如果有某个进程出故障的话,实现终止将非常困难。
这种情况,被正式称为**“FLP 不可能性结果”。**
其中,FLP 是 Fischer、Lynch、Patterson 这三位学者名字组合的简写。
他们在 1985 年发表过这样一篇论文——《分布式共识的达成毁于一个出错的进程》,论文指出——在一个异步系统中,即使只有一个进程出错,那么分布式共识就无法达成。因为进程出错的时间是随机的,如果恰巧在共识达成的时候,那么就枉费工夫了。
对于分布式计算领域来说,这无疑令人沮丧。尽管如此,科学家们仍在继续努力寻找规避 FLP 不可能性的方法。目前有两种： 方法一：使用同步假设 方法二：使用不确定性
方法一：使用同步假设
FLP 不可能性原理表明,在异步传输系统中,如果一个系统无法终止,那么就不能达成共识。
但是,如果不知道异步信息传输所需的时间,那该如何保证每个非故障进程都会决定一个输出值呢?
需要明确的是,这一发现并不代表共识无法达成,而是在异步传输环境中不能在固定的时间内达成。那就是说共识在某些时段还是可以达成的,只不过我们无法确定这个时间点。
解决这个问题的一种方法是使用超时。如果系统迟迟无法在一个值上终止,就等待一个超时,然后重新开始一轮运算。
这需要一些共识算法来支撑,其中的比较出名的是 Paxos 和 Raft。
4
一些基本的共识算法（Paxos、Raft、DLS 和 PBFT）
Paxos算法
Paxos 是由 Leslie Lamport 在上世纪 90 年代提出的,这是第一个实用的容错共识算法,它已被谷歌和亚马逊（Amazon）等互联网巨头用于构建分布式服务。
Paxos 的工作机制如下：
阶段1：准备请求（prepare request） 提议者选择一个新的提议版本号 n,然后向决策者发送 “prepare request”。 如果决策者接收到这个 prepare request（“prepare”,n）,如果 n 大于任何他们已经回应过的 prepare request 的版本号,决策者就会发出 (“ack,” n, n’, v’) 或 (“ack,” n, ^ , ^)。 决策者的答复是保证不接受任何版本号小于 n 的提议。 决策者把已接收到的最高版本号的提议中的值 v 作为建议值。否则,他们用 ^ 回应。
阶段2：接受请求（ accept request ） 如果提议者接收到多数决策者的响应,那么它可以发出一个 accept request (“accept,” n, v),其编号为 n,值为 v。 n 是 prepare request 中出现的数字。 v 是响应中编号最高的提议中的值。 如果决策者接收到 accept request (“accept,” n, v),则它通过该提议,除非它已经响应了一个大于 n 的 prepare request。
阶段3：学习阶段 当决策者通过一个提议时,它会对所有学习者进行响应 (“accept,” n, v)。 学习者收到大多数决策者发出的 (“accept,” n, v),就会以 v 为最终决定值,并把 (“accept,” n, v) 通知到所有其他的学习者。 学习者收到 (“accept,” n, v),把 v 作为最终决定值。
https://www.myassignmenthelp.net/paxos-algorithm-assignment-help
讲到这里,相信很多同学应该已经懵逼了,但是先别急,更让人懵逼的可能还在后头。
我们都知道,每个分布式系统都会有发生异常。在这种算法中,如果提议者由于信息丢失等原因出错,那么最终决定可能会被延迟,Paxos 算法在第一阶段中使用了一个新版本号,来避免之前的计算产生的影响。
Paxos 确实有些难以理解,许多操作细节都没有解释透彻。怎样知道提议者出错的时间点？何时重新开始下一轮计算？想确定这些时间点我们是否需要一个同步时钟来设置超时时间？这些问题,都需要我们去思考。
此外,为了在实际应用中更加灵活,Paxos 关键领域的不少规范都是开放式的。诸如领导者选择、故障检测和日志管理等概念都比较模糊或完全没有定义。
这样的设计理念成为 Paxos 最大的不足之一,理解难、实现难,驾驭分布式系统更难。
在 Paxos 中,虽然超时在算法中没有明确提及,但在实际操作中,想要实现终止,等待一个超时后,必须选择一个新的提议者。否则,决策者就不会输出下一个值,整个系统就停止了。
Raft算法
2013 年,Ongaro 和 Ousterhout 发布了一种新的共识算法,用于叫做 Raft 的复制状态机,主要注重协议的实用性和可理解性。
Raft 算法主要有两个过程,一个是领导者选举,另一个是日志复制。系统中的节点被分为三种角色： 领导者——负责与用户沟通和日志复制 跟随者——被动响应请求,类似于选民 候选者——临时角色,某节点想成为领导者,就要发起投票请求,同时自己变成候选者。如果选举成功,则成为领导者,否则退回为跟随者。
这三种角色都不是固定的,可以随着环境条件互相转换,但是在某一个时刻只能担任其中一种。
为了实现共识,候选者需要向跟随者发出信息,请求他们的投票,一旦被系统中大多数认可选定后,就成为领导者,跟随者们就跟随其操作。
假设系统中的节点总数为 n,故障节点为 x,正常节点只需要比故障节点多一个,即 x+1,系统就能达成共识。
因此,Raft 算法支持的最大故障节点数量是（n-1）/2。
Raft 算法的容错机制只支持故障节点,不能支持恶意节点,并且使用共享超时来实现终止。
如果进程崩溃并重新启动,在声明自己的领导者身份之前,至少需要等待一个超时时间,并保证会取得进展。
Paxos 和 Raft 是比较传统的共识算法,它们能够使用同步假设（即超时）在异步环境中一展身手,它们只对崩溃故障容错,面对拜占庭故障无能为力。
崩溃故障是更容易把控的,因为程序无法进行恶意行为。我们可以将进程建模,以 0 或 1 代表正常或崩溃。因此,在崩溃容错系统中,只要大多数进程能够达成共识,就可以构建分布式系统。
而在开放和分散的系统（如公链）中,网络中的节点是不受用户控制的,节点有不同的动机,可以撒谎、配合或随心所欲,一半以上的可靠节点可以约定好互相撒谎,互相之间必然发生冲突。
所以在拜占庭系统中,不是假设简单多数就可以达成共识的。
对于这种行为,Raft 应对乏力。举例来说,如果选出来的领导者是拜占庭节点,并且与其他节点有着紧密的联系,那么系统就危险了。之前讲过,我们建立的系统模型,要么对简单故障容错,要么对拜占庭故障容错。
总之,Raft 和 Paxos 具有简单的容错能力,但对拜占庭故障无能为力。
那么问题来了,拜占庭环境怎么办?！
在解决这个问题之前,我们先来了解一个概念——
拜占庭将军问题（Byzantine Generals Problem）
拜占庭将军问题由 Leslie Lamport、Robert Shostak 和 Marshall Pease 在同名论文中提出,分布式系统依靠交换信息来整体协作,然而其中的节点会作恶,网络会崩坏,因此系统不能达成一致。
拜占庭容错协议就是为了应对节点的恶意行为,论文为解决拜占庭将军问题提供了第一个证明：
如果一个系统共有 n 个节点,其中有 x 个是拜占庭节点,该系统如果想达成共识,n 必须满足：n＞3x + 1
原因如下：
如果出错节点个数为 x,系统如果想正常运转,必须先协调的节点个数为 n - x,（因为 x 个节点可能有问题/复杂,并且没有响应）。
然而不排除这种可能,不响应的x也许并不是出错了,也可能是有响应的只不过由于网络等原因未被察觉。如果我们想要非故障节点的数量多于故障节点,n 必要满足：
n- x - x > x,
即：n > 3x + 1
然而,该论文所演示的算法仅适用于同步环境,那貌似拜占庭环境、异步环境两者我们只能解决一个了,或者只能等待奇迹的发生。
学者们做了大量的研究工作,力求攻破在拜占庭和异步假设环境中的共识问题。
下面便是见证奇迹的时刻——
我全都想要！！！
接下来,我们将研究两种算法（DLS 和 PBFT）,打破拜占庭+异步的障碍的奇迹,我们在慢慢靠近。
DLS 算法
Dwork、Lynch 和 Stockmeyer（“DLS”算法的由来）在 1988 年曾发表论文《部分同步存在的共识》,文中阐述了关于拜占庭容错共识的一个重大进展： 在“部分同步系统”中达成共识 。
你可能还记得,在同步系统中,信息从发送到接收所需的时间是有固定上限的,而在异步系统中,该上限不存在。
这里的“部分同步”位于同步系统和异步系统之间。
本文解释了部分同步假设的两个版本: 假设信息传输所需的时间上限是存在的,但是是未知的。目标是达成共识,先不考虑实际的上限。 假设信息传输所需的时间上限是已知的,但是它只能保证在某个未知的时间（也称为“全球标准化时间”,GST）启动。目标是设计一个能够达成共识的系统,无论这个未知的时间在什么时候。
以下是 DLS 算法的工作原理：
运算的每一轮都被分为“试探”阶段和“锁定-释放”阶段。N 是系统的总节点数量,x 是系统的容错节点数量。 每一轮都有一个提议者,回合的开始时候,每个进程传输各自认为正确的值。 如果一个值最少被 N − x 个进程程传达过,那么提议者将把它作为建议值。 当某个进程从提议者接收到建议值时,它必须锁定该值,然后散布这个信息。 如果提议者接收到 x + 1 个进程发出的建议值,这个值将会作为最终值提交。
DLS 算法可以说是一个重大突破,因为它创造了一个新的网络假设类型,即部分同步,并证明了在部分同步中,实现共识是可能的。
那么如何实现呢, 我们关注两点：安全性和活跃性。
安全性
这是“一致性”（Agreement）的另一个术语。其中所有非故障进程都赞成相同的输出值。如果我们能保证足够的安全性,就能够保证整个系统保持同步；而如果安全性不够,将会导致需要更多的事务日志来终止这一轮的信息传输。我们希望所有节点都遵从事务日志的顺序,尽管故障和恶意进程是无法避免的。
活跃性
这是“终止性”（Termination）的另一个术语。其中每个非故障节点都会以某个输出值作为最终决定值。在区块链设置中,新的区块不断生成,区块链不断延伸,这就是活跃性。只有保持活跃,这个网络才有用处,否则,区块链就“烂尾”了。
从 FLP 不可能性中我们知道,在完全异步的系统中,共识是不可能达成的。DLS 的论文则认为,如果进行部分同步假设,就可以营造活跃环境,而这就足以攻克 FLP 不可能性。
因此,本文证明了该算法无需进行同步假设,安全条件都可以保证。
如果节点没有决定某个输出值,系统就会停止。为了保证终止,也就是保证活跃性,我们可以做一些同步假设（即超时）。但如果某一次同步假设失败,系统也会停止。
但是,如果我们设计一个算法,在这个算法中假设超时以保证安全性。可一旦如果同步假设失败,就有可能导致有两个有效的事务日志生成。
两个事务日志要比系统停止要危险得多——如果不安全,那么活跃无意义。
可以说,即使整个区块链停止,那也好过于生成两个不同的区块链。
分布式系统总是在权衡取舍。如果你想突破一个限制（比如 FLP 不可能性）,你必须在别的地方做出让步。在这种情况下,把关注点分成安全性与活跃性是非常合理的。这样我们可以构建一个在异步假设中的安全系统,但仍然需要超时来保证有新的值持续输出。
DLS 的论文已经讲得足够详细,但到如今,DLS 从未真正地被广泛应用,甚至没有在实际的拜占庭场景中使用。这可能因为 DLS 算法的核心假设之一是使用同步时钟,以便有一个共同的时间概念。实际上,同步时钟很容易受到多重攻击,在一个拜占庭容错假设中往往不够可靠。
PBFT（Practical Byzantine Fault-Tolerance）
Miguel Castro 和 Barbara Liskov 在 1999 年发表了论文《Practical Byzantine Fault-Tolerance》（《实用的拜占庭容错》）,其中提出了 PBFT 算法。对于拜占庭系统来说,这种算法正如其名——更加“实用”。
这篇论文认为,以前的算法虽然“理论上可行”,但要么太慢而无法使用,要么为了安全性必须做同步假设。我们前文中提过,这在异步环境中是非常危险的。
PBFT 中的 “P”（Practical）意味着该算法可以在异步环境中应用,并且做了一些优化,运行速度会更快。
在 PBFT 中,无论有多少故障节点,系统都能够提供安全性。如果系统内的节点总数是 n,那么算法的容错节点数量 x 的最大值是 (n-1)/3,而且消息延迟的增长速度不会超过一定的时间限制。
因此,PBFT 进行同步假设并不是为了安全,而是为了活跃,并以此规避 FLP 不可能性。
算法通过一系列“视图”（view）运行,每个视图都有一个“主”节点（即领导者）,其余的都是“备份”。下面是 PBFT 详细的工作步骤： 客户端有一项新事务,将其发送给主节点。 主节点将这项事务传递给所有备份。 各备份执行该事务并向客户端发送回复。 客户端收到来自 x+1 个节点的相同消息后,则该响应就是这次运算的结果,共识已经正确完成。
如果主节点不出错,协议就能正常运行。然而,如果主节点出错,或者恶意,备份节点能够通过 timeout 机制检测到主节点是否已经废掉。当出现这些异常情况时,这些备份节点就会触发视图更换（view change）协议来选举出新的主节点。但是这个过程非常缓慢,为了达成共识,PBFT 需要进行二次通信——每台计算机必须与网络中的所有计算机都进行通信。 注意：想要完整地解释PBFT算法,得非常大的篇幅！这里说一下关键部分就好。
虽然 PBFT 相比以前的算法已经有了长足的改进,但对于有大量参与者的实际场景（如公链）来说,它还不够实用。但是,至少在故障检测和领导者选举方面,它给出了一些具体的做法,这要比 Paxos 强多了。
PBFT 的贡献是举足轻重的,它整合了一系列重要的有变革意义的算法思想,不少新的共识协议从中受益匪浅,尤其是后区块链时代（post-blockchain world）。
比如,Tendermint 是一种新的共识算法,从 PBFT 中获益颇丰,且设计更加实用。在“验证”阶段,Tendermint 使用两个投票步骤来决定最终值；Tendermint 每轮都会更换新领导者。如果当前一轮的领导者在一段时间内没有响应,那么它就会被跳过,算法直接进入下一轮,并产生新的领导者。而在 PBFT 中,每次视图更换选新的领导人,都需要一次繁琐耗时的点对点连接,相比起来,Tendermint 运行更简洁,更有实用意义。 方法一小结
Paxos 和 Raft,具有简单容错能力,对系统崩溃或网络延迟等故障容错,需要同步信息传输环境,适用于严格受控的私链环境。
DLS 和 PBFT,可对拜占庭故障容错,在异步信息传输环境中需要做某种形式的同步假设（超时）,适用于新加入节点需要验证的联盟链。
方法二：使用不确定性
下面我们来介绍另一种克服 FLP 不可能的方法：不确定性。所谓不确定性,就是用概率论和不确定的方式来解决共识问题。
中本聪共识（Nakamoto Consensus.）
传统的共识中,算法的定义是这样的：一个提议者和一群决策者必须协调和沟通,才能决定下一个值。
这太复杂了,因为它需要知道网络中的每个节点,而且各个节点之间都必须沟通,即二次通信消耗。简单地说,它的拓展性有限,也不能在开放的、没有限制的系统中工作,在这种系统中,任何人都可以随时加入和离开。
中本聪共识使上述的难题成为概率性的事件,这是其高明之处所在。用不着每个节点都同意一个值,只需要所有节点都同意这个值为正确的可能性。
我们从一下几个板块来理解：
1、拜占庭容错机制——工作量证明（PoW,proof of work）
在比特币网络中,区块链本质上是去中心化的账本,用区块记录每一笔交易,每个节点都拥有这个账本,每个节点都拥有记账权。那么谁来记账呢？
在中本聪共识中,记账的节点是不确定的,哪个节点解决难题最快,算力最强,它就能够在区块链中添加新区块。而这个需要节点们去解决的难题也没有确定的公式去解决,只能依靠穷举法。
抢到了记账权,系统就会告知全网节点,获得全网确认后,这个区块便会被正式添加,这就是达成共识的过程。
每个区块的生成会在区块链上加盖一个时间戳,网络就在这个链条上延续构建。
规范链是指累积了最多工作量,也就是花费了最多的计算量的链条,也就是最长的链条。它不仅可以证明该链堆积了最多的 CPU 算力,还可以作为区块序列的证明。因此,只要大多数 CPU 资源是由诚实的节点掌控的,它们就能继续生成最长的链。
2、区块奖励
网络中的节点通过算力的竞争来争夺下一个区块的记账权,那么如何使节点们都能心甘情愿地消耗巨大的算力去争夺呢？中本共识的算法设计了区块奖励（比特币）,争夺到记账权就可以获得比特币奖励,这样是节点们的目标都能保持一致且相对单纯。
3、抵抗女巫攻击（Sybil Attack） 女巫攻击：在 P2P 网络中,节点是可以随时加入和退出的。为了维持网络稳定,同一份数据通常需要备份到多个分布式节点上,这就是数据冗余机制。单个恶意节点伪装多重身份,把原来要备份到多个节点上的数据欺骗到了同一个恶意节点,这种攻击数据冗余机制的手段,就叫做女巫攻击。
中本聪共识采用工作量证明（PoW）,节点要证明自己是节点,只能依靠其计算能力,不能依靠分裂或伪装,这样极大地增加了攻击的成本。因此中本聪共识本身具有 sybil 抵抗能力,不需要 PKI 或任何其他花哨的身份验证方案。
4、点对点流言协议（P2P gossip）
中本聪共识的一个主要贡献是使用了流言协议（gossip protocol）,它更加适合 P2P 网络环境。在网络中,一个节点如果想传递信息,它会随机选择周围的几个节点进行散播,收到嘻嘻的节点重复上述过程,最终全网所有节点都能收到信息。简单的说,就是一传十、十传百。
流言协议本身具有分布式系统的容错性,因为网络中任何节点发生故障,都不影响信息传输。
在异步环境中“技术上”不再安全
在中本聪共识中,安全保证是概率性的。新区块不断生成,区块链在不断加长,恶意节点能够建立有效的替代链的概率会随之降低。
概率低不代表不会发生,不是吗？
所以,中本聪共识在“技术上”并不能保证异步假设中的安全性。这是为什么呢？
因为比特币区块链中可能存在一个网络分区,在网络分区中,如果攻击者的算力足够强大,那他就可以在此分区建立一条比规范链还长的“替身链”,这样的话,交易发生所在的规范链就可能废掉,而“替身链”成为主链,攻击者就改变了自己的那笔交易,支付出去的钱又回到了自己手中。
然而,这需要攻击者获得全网算力的 51%,如此巨大的算力需要耗费巨额的经济成本,试问又有谁能承担得起呢？而且即使攻击者掌握了 51% 的算力,还需要与另外的 49% 展开 6 次区块的争夺,只有连续 6 次成功,才能成功创建“替身链”。
从本质上讲,“替身链”理论上是可以创建的,但是可能性非常低,这也是前面为什么说“技术上”不安全的原因。
但这个可能性低到可以忽略不计,比特币区块链的不可篡改性就来源于此。
5
中本聪共识为什么这么牛？
中本聪共识 vs 传统共识
从实际应用来看,中本聪共识本身是一种拜占庭容错机制。但很明显,它并没有达到传统意义上的共识。因此在最初,它被认为完全脱离了拜占庭容错世界。
我们应当感谢中本聪的这一项伟大创造。
中本聪共识允许任意数量的节点都可以公开参与进来,任意进入,任意退出,而且没有人必须得知道其他的参与者都是谁。
中本聪共识比以往的共识算法更简单,消除了以前算法在点对点连接、领导者选举、二次通信消耗等方面的复杂性。简单到在一台计算机上启动比特币协议软件,就可以挖矿。
正因为它简单且有效,所以在现实中有着很广阔的应用场景,可以说是 PBFT 的更“实用”的版本。
6
结语
长篇大论之后,前面的一些细节你可能已经忘了,这里我们小小总结一下：
这篇文章中,我们首先介绍了分布式系统的概念和特性,然后讲到了分布式系统中最重要的问题——如何达成共识。达成共识面临的最大障碍是FLP不可能性。要跨越这个障碍,我们有两种途径。
第一种是使用同步假设,其中 Paxos 和 Raft 都是在同步环境中,对简单的故障容错；而 DLS 和 PBFT 是在异步环境中,使用某种形式的同步假设（即超时）,实现都拜占庭故障容错。
但是在开放（如：公链）网络中,实用性依然有限。
第二种是利用不确定性。其中中本聪共识是显著的代表,它给予诚实节点获利的机会,让系统达成共识成为一个概率性（不确定性）的事件,同时也让恶意节点造成损害的结果的概率低到可以忽略不计。适用于节点可以任意进入和退出的开放式网络。
读懂中本聪共识后,区块链技术的其他进展,我们也就更容易 Get 到了,比如 POS、Plasma、Casper,等等。Preethi 说她将在下一篇文章中详解 Proof-of-Steak 的概念和原理,它真的会比中本聪共识更好吗？
（你没看错,是 Proof-of-Steak）
相信这篇长文,会有助于大家来区分区块链领域资本方面的缺点与技术方面的优点。资本逐利的狂热总会制造出一些迷惑人的泡沫与假象,但总有一些爱好技术的年轻人,喜欢默默无闻地创新出一些很酷的产品或服务。假以时日,当这些很小的产品或服务长成参天大树的时候,大多数人才会后知后觉地感受到——这个世界要变天了！
毕竟,任何时候,肯沉下心来钻研技术本质的,始终只是那聪明的一小撮人。
参考： https://medium.com/s/story/lets-take-a-crack-at-understanding-distributed-consensus-dad23d0dc95 https://techglider.github.io/review/time-clocks-and-ordering-of-events-in-a-distributed-system/ http://www.cs.utexas.edu/~dahlin/projects/bft/#BAR https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf http://pages.cs.wisc.edu/~sschang/OS-Qual/reliability/byzantine.htm https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf https://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf http://pmg.csail.mit.edu/papers/osdi99.pdf https://bitcoin.org/bitcoin.pdf 内容来源：区块链大本营（ID：blockchain_camp）
译者 | 李晓泉
编辑 | 波波
「深度学习福利」大神带你进阶工程师,立即查看>>>
话说,还有26天就要跟2018说再见了,在这里想衷心地问一句： “年初的愿望实现了吗？事到如今只好祭奠吗？”
不过话说回来,这一年区块链的发展继续加速,只是没有像预想中的那么快。今天,就跟老铁们一起简单回顾一下2018年的历程,然后从这一脉络中谈谈2019年的区块链及加密货币的走向。
比起2017年,2018年整个区块链行业的发展都越加趋于理性,说的直白点就是稍有降温。从39度2退烧到了38度7,不管怎么说都是更「健康」的表现。
这一年,玩币的人哭了。除了比特币,几乎所有加密货币的价值都被砍到了脚脖子,下跌了近80%。只有比特币坚挺依旧,让一众山寨币望尘莫及,但最近的情况……好了,啥也不说了。
大起大落之下,持币的人哀鸿遍野,加密货币末日论也甚嚣尘上, 然而加密货币真的走到头了吗？区块链技术明年（2019年）又会是什么样？接下来,我们就从5个方面逐一进行分析。
不过,分析2019年之前,我们不妨先来梳理一下2017和2018年加密货币的一些基本情况。
1
2017-2018：从惊涛骇浪到波澜不惊
2018年的加密货币市场没有出现预期的上涨,预计在年底之前也不会泛起大的波澜。但对于加密货币和区块链行业来说,还是有一些重要的表现值得我们欣慰。
市场趋于稳定和成熟 。在比特币初期,由于技术不发达,规则不完善,导致比特币市场乌烟瘴气,混乱不堪,人们只是掌握了一份白皮书从而知道了比特币的概念,把区块链作为一项能挖矿赚钱的新技术,而至于比特币的原理和未来应用一无所知。10年过去了,我们甚至还是没有搞清楚中本聪到底是谁。如今一波跌宕起伏之后,这个市场趋于稳定,人们的投资也会更加理性。
**行业关注度提升。**一个领域从陌生到被认知直到熟悉,总是需要花一段时间。直到2017年加密货币市场的这一波爆炸式增长,区块链的概念才吸引了更多的关注。回顾这一历程,2017年很明显是先达到了一个峰值,之后一波暴跌,最后平缓在一个相对较低且让人放心的价格。经历了大起大落之后,让人不胜唏嘘。
政府力度加大 。日益高涨的加密货币热潮,不仅能够吸引更多散户的投资,同时也导致非理性投资行为,很多投机客想趁热打铁分一杯羹。面对这种情况,政府不能忽视,但如何利用这个新市场,仍是一筹莫展。是加密货币还是股票证券,也是模棱两可。
2018年在阿根廷的G20峰会期间政府还针对加密货币提出了一些监管建议。各个国家态度不一：有些国家一禁了之,有些则明令禁止,但这些禁止的国家中,大部分是仅禁止ICO；而另一些国家则默默吃瓜,静观其变。
新技术不断涌现,旧难题亟待解决 。比特币区块链的可拓展性很低,随着交易量暴涨,交易速度越来越慢,再加上高达2000%的交易费用,最终催生了Segwit（隔离见证）协议,该协议也成为比特币现金的催化剂（这也是比特币相对成功的一个硬分叉）。
此外,为了提高区块链的可扩展性,解决交易扩容问题,比特币开发了闪电网络,以太坊开发了 Plasma 和 Casper。不过,这并没有解决加密货币的根本问题,我们面前依然迷雾重重——ICO中骗子遍布横行,加密货币交易中黑客依然猖獗。 译者注：
闪电网络：一种分布式网络,通过智能合约功能以支持跨参与者网络的即时付款,同时利用区块链的特性消除将资金托管给第三方带来的风险。主要作为安全地进行链下交易用于即时、高容量的微支付。
Casper：提出了更现代的权益证明（PoS）模型,用来替代以太坊传统的工作量证明（PoW）算法,大大加快网络中的交易处理时间。
Plasma：子母链,以太坊的另一个项目,主要思想是提供一种能够执行链下交易的模型,同时依赖于基础以太坊区块链来保证其安全性。
巨头进驻,热度不减 。随着技术的突飞猛进和基础设施的不断完善,我们看到区块链引起了很多巨头的注意。国外有高盛（Goldman Sachs）IBM、星巴克和IEC等巨头企业开始在其平台上接受加密货币支付。国内有BAT、小米等巨头也在积极试水。
大浪淘沙,沉者为金 。虽然市场起伏较大,但这也成为了企业的试金石,能够将投机者与实干家区分开来。很多打着区块链旗号的企业中途夭折,项目烂尾,也有不少企业脱颖而出,前途无量。这波浪潮退去之后,我们才能知道哪些项目只是在蹭热度、博眼球、骗投资,哪些项目真正有创新、有潜力、有前景。
说完了去年和今年的情况,接下来就来说说2019年区块链的发展预测。
2
区块链2019：金融与电子商务的融合
中本聪创立比特币的初衷是为了改变金融业,但最初由于区块链的低拓展性,应用并不是十分广泛。然而如今时过境迁,区块链在逐渐向金融业“渗透”,目前可以通过链下交易和主节点的应用集成到支付网关中。
比如Ripple基金会的XRP（瑞波币）,XRP可是说是表现最好的加密货币之一,就与多家银行签订了合作协议,让银行可以实时跨境支付服务,并大大提升了交易处理速度。这为加密货币技术银行业的融合开启了先河。
这一趋势正在延续,现在我们看到了更多加密货币具备货币功能的可能性,这是时代的巨大进步,这也可能是加密货币最好的结局。因此,在2019年如何创建一个功能性的加密货币金融系统,值得我们关注。
3
区块链2019：去中心化交易所
虽然关于熊市汹涌的负面情绪,听起来很可怕,但加密货币的交易和投资似乎毫无波动,交易所每天的交易额仍能达到数十亿美元。
据CoinMarketCap的一份24小时交易排行榜显示,仅OKEx、Binance和ZB.COM在24小时内的交易额就超过了10亿美元。这表明,在加密货币领域中,交易仍是十分重要的场景,而交易所仍扮演着至关重要的角色。
大量的加密资产在交易所沉淀,这造成了一个问题,那就是如何保证交易所的安全。要知道黑客的一次攻击,就能造成百万美元级别的损失。中心化交易所的弊端越来越明显,因此,在2019年去中心化的交易所势在必行。
中心化交易所的经典攻击
在此之前,一些公司已经开始试水,比如Binance就宣布在2019年初将推出去中心化交易所DEX的测试版。他们认为,托管钱包一定会是未来潮流。托管钱包将允许P2P交易,同时仍将交易在区块链上广播。这将大大减少本地费用,比目前的交易费便宜得多。
随着去中心化交易所的成熟,交易所被攻击的事情势必减少。但这里还是提醒大家加密货币投资有风险,加密货币也不是区块链最终的形态和最核心的价值。
4
区块链2019：社交网络
近来,不少寻求开发改进的第三代网络的区块链项目正进行得如火如荼,这些项目志在解决第二代网络的痛点。相信通过区块链打通实际业务与社交是2019年的重头戏之一。
Steemit社区是这类项目中最知名的应用项目之一。但运营之初,一路磕磕绊绊,效果不佳并不理想。
Seemit页面
致力于为区块链带来突破的另外一个社交媒体平台叫Indorse,它通过出售广告并用IND代币（IND token）奖励用户,这些代币用于创建用户活动索引。Indorse在ICO中筹集了900万美元,并计划用于2019年的持续开拓。其他使用奖励模式的平台还有Nexus和Synereo。
另一个有趣的平台是Humans.net,它致力于为用人单位和求职者之间搭建桥梁,为他们提供一个全球性的一站式服务平台,实现点对点的网络沟通。
Humans.net页面
其核心业务基于DNA验证系统,以确保用户的合法性。平台完全免费的,同时可以有效地确保数据安全。广告中使用的数据必须经过用户明确许可,并且用户在广告收入中享有25%的份额。Humans.net是一个实用性很强的平台,它不像其他平台把特定职业群体作为主要目标客户,覆盖人群非常广泛,既有程序员、医疗专家,也有清洁工。
5
区块链2019：社交平台与用户权益
2018年,Facebook网络安全事故频发,小扎一度被刷了屏。
3月媒体曝出Facebook大规模数据泄露的丑闻。一家名为“剑桥分析”的公司(Cambridge Analytica)非法盗取了5000万Facebook用户的数据,据说这些数据被用来操纵美国和肯尼亚的大选。Facebook被指控将用户数据用于向第三方出售,一时被推向风口浪尖。
9月份,又有5000万Facebook用户账户被黑,扎克伯格本人也未能幸免,而Facebook自身却对黑客信息一无所知。
接二连三的事件表明,数据管理中心化存在弊端,一旦被攻击,后果不堪设想,不仅极度依赖网络安全,而且还考验机构负责人的道德与责任心。
在这样的背景下,去中心化社交平台的优势就很明显了,因此2019年这样的平台势必会越来越多。
个人数据个人掌握 ——Civic Network是一个开源的社交平台,在其中用户能够分享文件,管理项目,与他人沟通合作。一旦用户删除其数据,在其他网络上被会被删除。因此,用户不必担心他们的数据掌握在其他人手中。
用户能够获得社区酬劳 ——Steemit网站上的部分内容是这样的：
“虽然大多数社交媒体网站都是在为股东赚钱,但Steemit相信,平台用户也应该获利,因为他们的关注和使用对平台来讲也是莫大的贡献。”
保护隐私权和言论自由 ——Obsidian是一个主要通过提供咨询和技术支持,来帮助孵化区块链初创企业的平台。平台确保用户的匿名性,并且对用户账户不做任何要求,不需要任何形式的身份证明。它可以保障用户的隐私权和言论自由,尤其是在那些审查用户在社交平台上的发布内容的国家。
「卖家多挣钱,买家少花钱」 ——以Humans.net为例,通过去中心化,用户之间可以直接沟通,执行合同和付款,完全抛开了经纪人或者中介,能够从自己的原创内容中赚到更多。因为第三方不仅要从费用中抽成,还可能转头出卖你。
交易去中介化 ——目前大多数网络都想要在自己的平台上集成支付服务,但第三方的问题总是不可避免。有第三方的参与,不仅使交易费用提高,还使交易依赖于第三方应用程序。这种情况下,如果交易发生意外,解决过程耗时耗力。而在区块链网络上,交易可以以实用性代币为媒介,手续费很低甚至免费。此外,区块链上的交易无需双方彼此信任,因为交易的执行有智能合约做保证。
6
区块链2019：个人信息掌控
OnG.Social创始人/CEO Christopher J. Kramer,在解释区块链社交网络的全貌时,这样说： “区块链正在通过抵制审查、全球化账本技术来改造社交媒体,让每个人都能控制自己的数据和利益,而不需要掌握在中心化的公司手里。”
而 另一方面,区块链也开始与其他热门技术相结合,如AI 。上文提到的Indorse是一个与Humans.net类似的技能匹配平台。它就是使用共识机制和人工智能机器人来验证和确认用户技能。
如果某人自称是NodeJS的专家,他可以发布自己的专业成就并附上证明（如GitHub repos）,相同领域内的其他Indorse用户会来验证。根据用户共识,如果是真的他会得到「indorsed」,假的就会被要么被mark。目前Indorse已经有超过7万用户。
随着人们越来越重视个人数据安全,而且大数据风险在不断增大,人们更愿意相信区块链技术更可靠、更透明、更道德。
而区块链社交网络与其他不断涌现的区块链项目相比,用户数量可能并不高,因为它紧迫感没那么强。例如,健康行业很容易吸引区块链网络的发展,因为这个领域敏感且脆弱。
不管如何,**主流社交网络上数据窃取、篡改等乱象,将吸引更多的用户转向基于区块链的网络。**而在中心化社交网络中,不计其数的障碍可以成为用户的痛点,同时更可以成为去中心化竞争对手的发展契机。
7
写在最后
通过上面的分析,相信你对2019年的区块链发展有了一个全面的了解。但毕竟区块链刚刚萌芽,计划赶不上变化,存在很多的可能性。
但无论如何,希望2019年区块链能应用到更多的实际场景中。无论是融入到各个行业,还是去推动新的信息时代的革命,都无疑是值得期待的。
2019年,我们期待找到答案。 内容来源：区块链大本营（ID：blockchain_camp）
作者 | Gerald Fenech
译者 | 李晓泉
责编 | Aholiab
「深度学习福利」大神带你进阶工程师,立即查看>>>
微服务和容器目前比较流行,相信很多小伙伴都比较熟悉docker, 如果你不是太了解,可以查看文档 docker学习手册 。那如何用docker搭建比原链(Bytom)的节点呢?
在操作之前,请自行安装docker。然后在你的终端输入(windows对应cmd)： docker
出现如下图说明你已经安装成功了docker：
获取bytom的docker镜像 docker pull bytom/bytom:latest
用docker images 查看自己下载的bytom镜像 docker images
然后出现如下图说明已经获取到了镜像：
#初始化： docker run -v < Bytom / data / directory / on / host / machine >：/ root /.bytom bytom：latest bytomd init --chain_id < chainId >
默认的Bytom数据目录（在主机上）是：
Mac： ~/Library/Bytom
Linux： ~/.bytom
windows： %APPDATA%\Bytom
chainId 有三种选择：
mainnet：连接到主网
testnet：连接到测试网
solonet：单节点
如下例（mac/testnet）： docker run -v ~/Library/Bytom:/root/.bytom bytom/bytom:latest bytomd init --chain_id testnet
#开启docker终端交互模式： docker run -it -p 9888:9888 -v ~/Library/Bytom:/root/.bytom bytom/bytom:latest
#开启守护进程模式： docker run -d -p 9888:9888 -v ~/Library/Bytom:/root/.bytom bytom/bytom:latest bytomd node --web.closed --auth.disable
查看正在运行的容器： docker ps
下图中我们可以看到我们在运行的容器：
最后在浏览器中请求： http://0.0.0.0:9888 ,可以就可以查看我们钱包。
「深度学习福利」大神带你进阶工程师,立即查看>>> 本文首发于 深入浅出区块链社区 原文链接: 深入理解Plasma（四）Plasma Cash 原文已更新,请读者前往原文阅读 这一系列文章将围绕以太坊的二层扩容框架 Plasma,介绍其基本运行原理,具体操作细节,安全性讨论以及未来研究方向等。本篇文章主要介绍在 Plasma 框架下的项目 Plasma Cash。 在 上一篇 文章中我们已经理解了 Plasma 的最小实现 Plasma MVP 如何使用 UTXO 模型实现 Plasma 链下扩容的核心思想。但由于 Plasma MVP 本身过于简单,并不能用于实际的生产环境中。2018 年 3 月,在巴黎举行的以太坊开发者大会上,Vitalik 发布了 Plasma Cash 模型 [1] ,可以视为对 Plasma MVP 的改进。Plasma Cash 与 Plasma MVP 的主要区别是每次存款操作都会产生一个唯一的 coin ID 对应转移到侧链上的资产,并使用一种称为稀疏梅克尔树（Sparse Merkle Tree）的数据结构存储交易历史。由此带来的好处是用户不需要关注子链上的每个动态,只需要关注跟自己的 token 有关的动态。在下文中将介绍具体细节。 存款（Deposits） Plasma Cash 中的每次存款操作都会对应产生一个 NFT（non-fungible token） [2] 。NFT 可以简单理解为“不可互换的 token”,即每个 token 都是独一无二的,由唯一的 ID 标记。以太坊官方为 NFT 提供了 ERC721 标准 [3] ,在之前火爆到阻塞以太坊的 CryptoKitties 就是由 ERC721 合约实现的。 在 Plasma Cash 中,当用户向 Plasma 合约发送存款交易时,合约会生成一个与存款等值的 token,并给这个 token 分配一个唯一的 ID。如果一个用户分别执行两次存款操作,且每次存款都是 5 ETH,那么他将得到相等价值的两个完全不同的 token。和 Plasma MVP 一样,每次存款操作都会使得 Plasma 合约产生一个只包含这个存款交易的区块。 Plasma Cash 区块 Plasma Cash 中的每个 token 都被分配唯一的 ID,因此可以按 ID 的顺序存储每个 token 的交易历史。Plasma Cash 的区块按 token ID 的顺序给每个 token 分配了一个插槽（slot）,每个插槽会记录这个 token 是否被交易的信息。例如在下图（来源 [4] ）的区块中,包含 4 个 token,id 分别是 #1,#2,#3,#4。其中 #1,#2,#3 被标记为没有被花费,而 #4 由用户 A 发送给用户 B。  从上面这个例子中我们可以看到,每个插槽记录了其所对应的 token 在当前区块中的交易状态,所有存储了某个 token 的交易状态的区块按时间顺序连在一起就构成了这个 token 的全部交易历史。每当一个 token 被分配了一个 id,之后的所有交易状态都会被保存在每个区块相同的插槽中,也不会被其它 token 取代。因此,用户只需要关注每个区块中存储属于自己的 token 的状态,完全不用关心别的插槽存储的内容。 交易与验证 由于 Plasma Cash 中的节点只追踪属于自己的 token 的交易历史,因此当有交易发生时,token 的发送者要向接收者提供关于这个 token 所有的交易历史（从存款交易开始）以便接收者验证。从下图（来源 [4] ）的例子中可以看到 4 个区块中所记录的 4 个 token 的交易历史。  截止到区块 #4,可以看到token #1 和 token #3 始终没有被交易。token #2 在区块 #2 被 E 发送给了 F,在区块 #4 被 F 发送给了 G,在其它区块没有发生交易,token #2 的最终所有权归 G。token #4 在区块 #1 被 A 发送给了 B,在区块 #3 被 B 发送给了 C,在其它区块没有发生交易,token #4 的最终所有权归 C。F 为了向 G 证明 token #2 的合法性,需要向 G 提供 token #2 在前 4 个区块中的所有交易历史,也就是说不仅需要包括区块 #2 中 E => F 的交易证明、区块 #4中 F => G 的交易证明,还要包括在区块 #1 和 #3 中没有被交易的证明。到这里可能感觉有点奇怪,为什么还要包括没有被交易的证明？这是为了防止双花,因为 G 并不知道在区块 #1 和 #3 中 token #2 是否被交易给了其它人。假如 F 在区块 #3 中将 token #2 发送给了 H,并且对 G 隐瞒了这个交易,那么发生在区块 #4 中的 F => G 就是非法（双花）的。因此,在 Plasma Cash 中,完整且合法的交易历史是一个 token 被安全交易的前提。 稀疏梅克尔树（Sparse Merkle Tree） 在上文中我们已经了解到一个交易的成功的前提是需要发送方提供关于一个 token 的完整交易历史。完整的交易历史既包括这个 token 在哪些区块被交易的信息,也包括这个 token 在哪些区块没有被交易的信息。我们都知道,在区块链中,使用梅克尔树（Merkle Tree,MT）构造梅克尔证明（Merkel Proof, MP）可以在 O(logN)的时间复杂度验证一个交易是否存在一个区块中。但想要证明一个交易没有存在一个区块中,使用标准的梅克尔树却没那么容易。因此,Plasma Cash 中使用了一种称为稀疏梅克尔树（Sparse Merkle Tree,SMT）的数据结构存储交易数据,能够在O(logN)的时间复杂度验证一个交易不存在。 SMT 实际上一点都不复杂,它的叶子节点是按数据集中的元素序号顺序排列的。如果某个叶子节点对应的元素为空,那么该叶子节点将存储一个特定的值（例如 0 的哈希值）。一个简单的 SMT 示例如下图（来源 [5] ）所示。  扩展到 Plasma Cash 中,SMT 的叶子节点对应了区块中给每个 token 分配的插槽,按照每个 token 的 ID 排序。每个叶子节点存储对应的 token 的交易信息,如果 token 在这个区块中没有被交易,则相应的叶子节点存储的值为 null 。 以上图为例,如果需要证明交易 A 存在,就像在标准的 MT 中一样,需要构造 MP：H(null) 和 H(H(null) + H(D))。如果需要证明 B 不存在,同样很简单,我们已经知道 B 的位置是第二个叶子节点,如果 B 不存在,那么该节点存储的值应该为 null 。因此就像在标准的 MT 中证明存在的 MP 一样,只不过需要加上 H(null) 作为 MP 的一部分,即 MP：H(null)、H(A)和 H(H(null)+H(D))。 取款/退出（Withdrawl/Exit） Plasma Cash 中的取款操作在流程上跟 Plasma MVP 大体相同,都要从提交取款申请开始,经历争议期之后才能完成。由于 Plasma Cash 中采用的数据结构不同,在取款时需要提交的 token 所有权证明不同,因此当争议发生时需要提交的争议证明也不同。 提交取款申请 在向 Plasma 合约提交关于某个 token 的取款申请时,需要提供关于这个 token 最近的两次交易证明。例如,在上图中,假如 G 想要取走 token #2 到主链,那么他需要提交关于 F => G 以及 E => F 的 Merkle Proof。 提交争议 取款者在提交了取款申请之后同样需要支付一定的保证金,并等待一段时间的争议期。在这期间如果有其它节点提交了有效的争议证明,那么取款者不但无法完成取款操作,也会损失全部或部分的保证金。 目前 Plasma Cash 支持三种争议证明,分别应对三种不同的攻击场景（具体会在后文分析）： 已花费证明。如果能证明正在取款的 token 已经被花费,那么取款立即被取消； 双花证明。如果能证明取款申请中提供的两次交易证明中间还有别的交易,即发生了双花,那么取款立即被取消； 非法交易历史证明。用户还可以对正在取款的 token 的其它交易历史提出争议。这种争议不会立刻阻断取款,而是强制取款者提交其它交易证明来反驳争议,如果没有在规定时间内反驳,则取款被取消。 攻击场景 在这一节将讨论已有的 3 种攻击场景以及如何构造争议分别应对这些攻击 [6] 。在这里假设 Plasma Cash 中存在不可信的 operator 接收所有的交易并构造区块。 发送交易后立即退出 如下图（来源 [7] ）所示,假设攻击者 Alice 向 Bob 发送了一个 token A,且 Bob 已经验证了 A 的交易历史没有问题,交易在区块 N+X 得到确认。在这之后,Alice 立即提交取款申请,企图将 token A 取回主链,并提交 A 在区块 N 以及之前的交易证明。为了应对这种情况,Bob 必须及时发现 Alice 的取款行为,并且在争议期结束前提交在区块 N+X 中 token A 被 Alice 发送给 Bob 的证明。这里需要注意的是,如果 Bob 在区块 N+Y 将 token A 发送给 Charlie 的交易是不能被当做争议证明的,只有最接近被争议的交易的下一个交易证明有效。  双花攻击 双花攻击需要 operator 配合,将含有已经被花费的 token 的交易打包入下一个区块中。如下图所示（来源 [7] ）,攻击者 Alice 和 Charlie 是同谋,Alice 向 Bob 发送一个 token A 在区块 N+X 被确认,之后 Alice 又将 token A 发送给 Charlie,并在区块 N+Y 被确认。这时在主链看来,Bob 和 Charlie 都是 token A 的合法拥有者。接下来,Charlie 立即提交取款申请,企图取走 token A。Bob 为了防止自己的 token 被盗,可以在争议期内提交在区块 N+X 被确认的交易,表明自己在 Charlie 之前已经拥有了 token A。  取款包含非法交易历史 这种攻击需要联合比较多的同谋者。如下图所示,Alice 在区块 N 拥有 token A。Bob 联合 operator、Charlie 以及 Dylan 企图盗走 Alice 的 token。首先,operator 伪造 Alice 将 token A 发送给 Bob 的交易,并在区块 N+X 得到确认,之后 Bob 将 token 发送给 Charlie,在区块 N+Y 确认。同样地,Charlie 接着将 token 发送给 Dylan,在区块 N+Z 确认。这是,Dylan 提出取款申请,企图取走 token A。Dylan 用于取款申请的两个交易证明 Charlie => Dylan 和 Bob => Charlie 都是合法的,但 token A 的交易历史中有一部分是伪造的。Alice 为了证明自己是 token A 的最新合法拥有者,可以提出争议,要求 Dylan 提供 Alice => Bob 的交易证明,同时 Alice 需要提交一部分保证金（否则任何人都可以随便提出争议）。Dylan 必须在一定的时间内提供合法的交易证明,否则取款失效。  相关项目 Talk is cheap, show me your code. 目前已经有许多机构和公司已经实现了 Plasma Cash,但实现的语言和细节有所不同： Loom Network [8] Omisego [9] Wolk [10] Lucidity [11] 总结 本篇介绍了 Plasma 框架下的基于 NFT 的项目 Plasma Cash。Plasma Cash 给每个新转移的 token 分配一个唯一的 token ID,并且用稀疏梅克尔树存储交易,使得用户可以只关注跟自己的 token 有关的动态,而不需要关注其它 token。Plasma Cash 可以被看作 Plasma 逐渐迈向成熟的一步,已经有很多公司使用 Plasma Cash 搭建自己的平台和应用,例如 Loomnetwork 公司搭建了自己的 Plasma Cash 子链并且编写了 SDK 支撑开发者在上面开发新的应用。然而 Plasma Cash 本身仍然存在较多的问题,例如 token 无法被分隔合并、需要提交的证明过长等。在接下来的文章中还会继续跟进 Plasma 最新的进展。 相关资源 https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298 https://en.wikipedia.org/wiki/Non-fungible_token http://erc721.org/ https://github.com/ethsociety/learn-plasma https://medium.com/@kelvinfichter/whats-a-sparse-merkle-tree-acda70aeb837 https://karl.tech/plasma-cash-simple-spec/ https://github.com/loomnetwork/plasma-paper/blob/master/plasma_cash.pdf https://github.com/loomnetwork/plasma-cash https://github.com/omisego/plasma-cash https://github.com/wolkdb/deepblockchains/tree/master/Plasmacash https://github.com/luciditytech/lucidity-plasma-cash 本文的作者是盖盖,他的公众号: chainlab 深入浅出区块链 - 系统学习区块链,打造最好的区块链技术博客。 「深度学习福利」大神带你进阶工程师,立即查看>>>
上周末去参加了几场与区块链无关的活动,惊喜的是,听到了新零售、金融、数字营销等领域都在讲区块链会成为技术趋势,邓白氏在“2019年数据驱动营销和广告展望”的报告中强调区块链有可能成为数字广告的主要技术生态系统。
当区块链进入落地应用时代,在技术落地上有哪些策略和要规避的问题呢？
12月8日,HiBlock区块链社区联合磨链、一线区块链技术社区、中青创业区块链研究院、 区块链兄弟、BlockGeek、BitRUN在杭州发起一场主题为“区块链商用落地的策略与技术坑”的分享。
邀请瑞石科技产品总监刘源老师分享Dapp应用中必须要考虑的状态通道技术,解决区块链可扩展性问题及因交易量过大产生的交易延时过长的问题。同时,邀请趣链科技高级架构师/超级账本源码贡献者宣章炯老师分享超级账本社区发展及架构演变,从超级账本的技术本源介绍其在商业领域中的应用价值。
1
时间地点
主题：应用与落地|区块链商用落地的策略与技术坑
**时间：**12月08日 13:30-17:00
地址 ：杭州市西湖区文二路391号西湖国际科技大厦D南2楼 星沅空间
2
分享内容
分享话题1：状态通道技术介绍
话题简介：任何一个曾经开发过DApp的程序员都必须考虑到当前公共区块链的局限性,其中区块链局限性的最重要和最明显的两个问题就是有限的吞吐量和超高的时延,即：每秒处理的交易量过少且交易时延过大。为了运行一个能够满足商业应用需求的DApp,就必须想办法改进当前区块链的可扩展性问题。
当前行业内基于区块链可扩展性的解决思路有哪些？各自的优缺点是什么？哪些思路已经被验证并落地了？已落地的关键技术是什么？
分享大纲：
1: dapp商业落地的痛点
2: 可扩展性的对策
3: 状态通道的关键技术
4: trinity链下扩容的技术实现
5: 基于状态通道的dapp展示
分享嘉宾：刘源
瑞石科技产品总监
分享话题2：超级账本社区发展及fabric架构演变
话题简介：本次分享讲解Hyperledger社区发展及架构演变,讲解fabric 1.0之后的新特性,介绍fabric在商业领域中的应用价值
分享大纲：
1:Hyperledger社区
2:fabric 架构演变
3:fabric 在商业领域的应用价值
分享嘉宾：宣章炯
浙江大学软件工程硕士,趣链科技高级架构师,曾就职于网易杭州研究院 阿里巴巴-蚂蚁金服事业群 ,完整参与过大型金融区块链项目,有丰富的经验,目前从事Hyperledger Fabric开源项目的研究工作,并为其贡献源代码,对其有较深理解 ,Hyperledger TWG-China大中华区技术工作组成员,负责社区发展与创新工作及翻译工作, meet up杭州地区组织者 ,担任过meet up讲师。
3
流程安排
13:30-14:00 签到
14:00-14:05 开场及主办方介绍
14:05-15:05 刘源：状态通道技术介绍
15:15-16:15 宣章炯：超级账本社区发展及fabric架构演变
16:25-17:00 合影 交流
4
主办方及合作伙伴
5
报名流程
扫描二维码或点击“ 阅读原文 ”即可报名
「深度学习福利」大神带你进阶工程师,立即查看>>>
区块链作为一项冉冉升起的技术,很多人的一个疑问就是,有没有什么应用,或什么问题可以用区块链来解决。诚然,在这个过程中,有很多生搬硬套的解决方案。 12月4日,北京技术工坊,Bob老师将会结合自己在以太坊生态内收集到的应用及其分类,和大家一起分享一下区块链都能用来做什么。
1
时间地点
**时间：**12月04日 19:00 - 21:30
地点 ：北京市朝阳区白家庄东里23号锦湖中心B1 P2联合创业办公社
线下分享+交流 9.8元/人
参会人员要求：
1） 技术背景人员,对区块链开发有兴趣；
2） 活动限额15人,报满截止。
2
活动流程
19:00-20:00 签到,自我介绍
20:00-21:00 区块链应用场景畅想
21:00-21:30 互动交流
3
分享主题及嘉宾
分享话题：区块链应用场景畅想
分享大纲： 区块链和以太坊普及 以太坊应用分类 以太坊典型应用介绍 头脑风暴,区块链可以用到什么场景
分享嘉宾：姜信宝（Bob Jiang） HiBlock区块链社区（hiblock.one）发起人 中国北方的第一位CST（Certified Scrum Trainer） 国内的敏捷（Agile）大咖 敏捷变革中心（Center for Agile Transformation）合伙人 敏捷一千零一夜社区合伙人 敏捷之旅核心组织者 《Scrum精髓》译者
4
赞助支持
感谢NEM及HPB芯链对北京技术工坊的赞助支持。
5
报名参加
识别下图二维码或点击“ 阅读原文 ”即可报名参加。
「深度学习福利」大神带你进阶工程师,立即查看>>>
本文首发于 深入浅出区块链社区 原文链接: Fabric网络环境启动过程详解 原文已更新,请读者前往原文阅读
这篇文章对fabric的网络环境启动过程进行讲解,也就是我们上节讲到的启动测试fabric网络环境时运行network_setup.sh这个文件的执行流程
fabric网络环境启动过程详解
上一节我们讲到 fabric网络环境的启动测试,主要是使用 ./network_setup.sh up 这个命令,所以fabric网络环境启动的重点就在network_setup.sh这个文件中。接下来我们就分析一下network_setup.sh这个文件 network_setup.sh其中包括两个部分,一个是利用generateArtifacts.sh脚本文件配置组织关系和颁发证书、公/私钥、通道证书等,另一个是docker-compose-cli.yaml用于根据配置启动集群并测试chaincode的示例代码。下面是具体的流程图介绍： 首先看下generateArtifacts.sh脚本文件,它包含三个函数,分别是： 1.generateCerts： 该函数使用cryptogen工具根据crypto-config.yaml来生成公私钥和证书信息等。 2.replacePrivateKey： 将docker-compose-e2e-template.yaml文档中的ca私钥替换成具体的私钥。 3.generateChannelArtifacts： 使用configtxgen工具根据configtx.yaml文件来生成创世区块和通道相关信息,更新锚节点。
接着是docker-compose-cli.yaml文件 docker-compose-cli.yaml文件根据组织关系启动docker集群,并在cli容器中执行command命令运行./scripts/script.sh脚本文件。 那./scripts/script.sh脚本具体做了什么呢？ 1.createChannel：创建channel。 2. joinChannel：将每个peer节点加入channel。 3. updateAnchorPeers：更新锚节点 4. installChaincode：部署chaincode。 5. instantiateChaincode：初始化chaincode。 6. chaincodeQuery：chaincode查询
另外docker-compose-cli.yaml这个文件还有一个配置项是需要注意的地方,那就是： file: base/docker-compose-base.yaml
这里的docker-compose-base.yaml其实就是Orderer和peer的基础配置文件,包括指定端口等。
几个重要的配置文件
1.crypto-config.yaml
基于crypto-config.yaml（此文件在../fabric/examples/e2e_cli中） 生成公、私钥和证书信息,并保存在crypto-config文件夹中 。另外crypto-config.yaml还定义了组织成员以及组织下的peer节点个数。 crypto-config.yaml文件讲解： 字段Name和Domain就是关于这个组织的名字和域名,这主要是用于生成证书的时候,证书内会包含该信息。而Template.Count=2是说我们要生成2套公私钥和证书,一套是peer0.org1的,还有一套是peer1.org1的（也就指定了org中存在peer0和peer1两个节点）。最后Users.Count=1是说每个Template下面会有几个普通User（注意,Admin是Admin,不包含在这个计数中）,这里配置了1,也就是说我们只需要一个普通用户User1@org1.example.com 我们可以根据实际需要调整这个配置文件,增删Org Users等。文件内容如下： # --------------------------------------------------------------------------- # Orderer # --------------------------------------------------------------------------- - Name: Orderer Domain: example.com # --------------------------------------------------------------------------- # "Specs" - See PeerOrgs below for complete description # --------------------------------------------------------------------------- Specs: - Hostname: orderer # --------------------------------------------------------------------------- # "PeerOrgs" - Definition of organizations managing peer nodes # --------------------------------------------------------------------------- PeerOrgs: # --------------------------------------------------------------------------- # Org1 # --------------------------------------------------------------------------- - Name: Org1 Domain: org1.example.com # --------------------------------------------------------------------------- # "Specs" # --------------------------------------------------------------------------- # Uncomment this section to enable the explicit definition of hosts in your # configuration. Most users will want to use Template, below # # Specs is an array of Spec entries. Each Spec entry consists of two fields: # - Hostname: (Required) The desired hostname, sans the domain. # - CommonName: (Optional) Specifies the template or explicit override for # the CN. By default, this is the template: # # "{{.Hostname}}.{{.Domain}}" # # which obtains its values from the Spec.Hostname and # Org.Domain, respectively. # --------------------------------------------------------------------------- # Specs: # - Hostname: foo # implicitly "foo.org1.example.com" # CommonName: foo27.org5.example.com # overrides Hostname-based FQDN set above # - Hostname: bar # - Hostname: baz # --------------------------------------------------------------------------- # "Template" # --------------------------------------------------------------------------- # Allows for the definition of 1 or more hosts that are created sequentially # from a template. By default, this looks like "peer%d" from 0 to Count-1. # You may override the number of nodes (Count), the starting index (Start) # or the template used to construct the name (Hostname). # # Note: Template and Specs are not mutually exclusive. You may define both # sections and the aggregate nodes will be created for you. Take care with # name collisions # --------------------------------------------------------------------------- Template: Count: 2 # Start: 5 # Hostname: {{.Prefix}}{{.Index}} # default # --------------------------------------------------------------------------- # "Users" # --------------------------------------------------------------------------- # Count: The number of user accounts _in addition_ to Admin # --------------------------------------------------------------------------- Users: Count: 1 # --------------------------------------------------------------------------- # Org2: See "Org1" for full specification # --------------------------------------------------------------------------- - Name: Org2 Domain: org2.example.com Template: Count: 2 Users: Count: 1
注： peer： Fabric 网络中的节点,表现为一个运行着的docker容器。可以与网络中的其他peer进行通信,每个peer都在本地保留一份ledger的副本。它是org下的组织成员。 org: 一个组织,它可以由一个或多个peer组成。 Orderer : 联盟成员共享的中心化节点。用来对交易进行排序,是 Fabric 共识机制的重要组成部分。
2.configtx.yaml
基于configtx.yaml（此文件在../fabric/examples/e2e_cli中） 生成创世区块和通道相关信息,并保存在channel-artifacts文件夹。还可以指定背书策略。 configtx.yaml文件讲解： 1.官方提供的examples/e2e_cli/configtx.yaml这个文件里面配置了由2个Org参与的Orderer共识配置TwoOrgsOrdererGenesis,以及由2个Org参与的Channel配置：TwoOrgsChannel。 2.另外我们可以在此文件的Orderer部分设置共识的算法是Solo还是Kafka,以及共识时区块大小,超时时间等,我们使用默认值即可,不用更改。而Peer节点的配置包含了MSP的配置,锚节点的配置。如果我们有更多的Org,或者有更多的Channel,那么就可以根据模板进行对应的修改。 3.Policies配置也要特别注意,该配置项定义了不同角色的权限,Reader,Writer以及Admin分别对应读,写,以及admin权限,读权限角色只能从别的peer节点同步账本而不能发起交易,只有writer定义项下的角色才拥有发起交易的也就是调用chaincode的invoke方法的权限(不一定都是invoke方案,只要涉及到chaincode中状态修改的方法,都只有拥有writer权限或admin权限的角色才能调用)。以该配置的Organizations配置下的Org1配置为例,"OR('Org1MSP.admin', 'Org1MSP.client')",表示org1的msp服务中的admin或者client角色拥有发起交易的权限。文件内容如下： # Copyright IBM Corp. All Rights Reserved. # # SPDX-License-Identifier: Apache-2.0 # --- ################################################################################ # # Profile # # - Different configuration profiles may be encoded here to be specified # as parameters to the configtxgen tool # ################################################################################ Profiles: TwoOrgsOrdererGenesis: Orderer: <<: *OrdererDefaults Organizations: - *OrdererOrg Consortiums: SampleConsortium: Organizations: - *Org1 - *Org2 TwoOrgsChannel: Consortium: SampleConsortium Application: <<: *ApplicationDefaults Organizations: - *Org1 - *Org2 ################################################################################ # # Section: Organizations # # - This section defines the different organizational identities which will # be referenced later in the configuration. # ################################################################################ Organizations: # SampleOrg defines an MSP using the sampleconfig. It should never be used # in production but may be used as a template for other definitions - &OrdererOrg # DefaultOrg defines the organization which is used in the sampleconfig # of the fabric.git development environment Name: OrdererOrg # ID to load the MSP definition as ID: OrdererMSP # MSPDir is the filesystem path which contains the MSP configuration MSPDir: crypto-config/ordererOrganizations/example.com/msp - &Org1 # DefaultOrg defines the organization which is used in the sampleconfig # of the fabric.git development environment Name: Org1MSP # ID to load the MSP definition as ID: Org1MSP MSPDir: crypto-config/peerOrganizations/org1.example.com/msp AnchorPeers: # AnchorPeers defines the location of peers which can be used # for cross org gossip communication. Note, this value is only # encoded in the genesis block in the Application section context - Host: peer0.org1.example.com Port: 7051 - &Org2 # DefaultOrg defines the organization which is used in the sampleconfig # of the fabric.git development environment Name: Org2MSP # ID to load the MSP definition as ID: Org2MSP MSPDir: crypto-config/peerOrganizations/org2.example.com/msp AnchorPeers: # AnchorPeers defines the location of peers which can be used # for cross org gossip communication. Note, this value is only # encoded in the genesis block in the Application section context - Host: peer0.org2.example.com Port: 7051 ################################################################################ # # SECTION: Orderer # # - This section defines the values to encode into a config transaction or # genesis block for orderer related parameters # ################################################################################ Orderer: &OrdererDefaults # Orderer Type: The orderer implementation to start # Available types are "solo" and "kafka" OrdererType: solo Addresses: - orderer.example.com:7050 # Batch Timeout: The amount of time to wait before creating a batch BatchTimeout: 2s # Batch Size: Controls the number of messages batched into a block BatchSize: # Max Message Count: The maximum number of messages to permit in a batch MaxMessageCount: 10 # Absolute Max Bytes: The absolute maximum number of bytes allowed for # the serialized messages in a batch. AbsoluteMaxBytes: 98 MB # Preferred Max Bytes: The preferred maximum number of bytes allowed for # the serialized messages in a batch. A message larger than the preferred # max bytes will result in a batch larger than preferred max bytes. PreferredMaxBytes: 512 KB Kafka: # Brokers: A list of Kafka brokers to which the orderer connects # NOTE: Use IP:port notation Brokers: - 127.0.0.1:9092 # Organizations is the list of orgs which are defined as participants on # the orderer side of the network Organizations: ################################################################################ # # SECTION: Application # # - This section defines the values to encode into a config transaction or # genesis block for application related parameters # ################################################################################ Application: &ApplicationDefaults # Organizations is the list of orgs which are defined as participants on # the application side of the network Organizations: 「深度学习福利」大神带你进阶工程师,立即查看>>>
从零开始讲解Solidity智能合约编程,从编程语句到高级技巧。
以太坊是一个分布式的平台,可以运行智能合约：应用程序按照既定程序运行,不会出现停机,审查,欺诈或第三方干扰的可能性。这些应用程序运行在定制构建的区块链上,这是一个功能强大的全球共享基础架构,可以通过数字流转来代表财产的所有权。
以太坊EVM是当前区块链行业应用最为广泛的虚拟机,其所支持的Solidity智能合约语言是图灵完备的。应用Solidity智能合约语言,原本在真实世界中的复杂商业逻辑和应用都能在区块链上轻松实现。这也使得Solidity编程成为基于以太坊的应用开发中最为活跃的领域。
为提高广大开发者学习以太坊Solidity智能合约的效率,系统并快速学习智能合约开发,金色学院联合区块链行业知名技术讲师郑嘉文共同推出《以太坊Solidity智能合约开发速成》课程。
课程从零开始讲解Solidity智能合约编程,内容从最基础的编程语句开始,到智能合约编程的高级技巧。每一个知识点的讲解都辅以相应的示例。适合至少使用或者掌握了至少一门编程用户的开发者学习。
课程大纲
讲师简介
嘉文
《白话区块链》作者之一,曾长期担任贝尔公司在线营销部门与大数据产品部门的经理和技术架构师。专注于大数据分析和研究,以及与分布式数据库系统的分析和研究,从2012年开始先后对比特币、以太坊、雷欧币、瑞波、超级账本进行了代码级研究,并开发了基于瑞波的支付网关,基于以太坊的智能合约产品等。现从事区块链社交,基于区块链的量化交易平台的设计和开发。
教育背景：
华中科技大学计算机硕士,加拿大麦吉尔（McGill）大学信息学硕士、多伦多大学罗特曼（Rotman）商学院MBA。擅长中文,英文,日文和法文等多国语言。
注：本课程为连载课程,将陆续更新,欢迎广大开发者持续关注和学习！
进入课程>> 《以太坊Solidity智能合约开发速成》 「深度学习福利」大神带你进阶工程师,立即查看>>>
本文首发于 深入浅出区块链社区 原文链接: Fabric1.0 交易流程 原文已更新,请读者前往原文阅读
这篇文章详细介绍fabric的交易流程,以图片加文字的形式呈现。
Fabric 1.0交易流程
fabric中的所有交易都是通过chaincode执行 1.应用程序客户端通过SDK调用证书服务（CA）服务,进行注册和登记,并获取身份证书。
2.应用程序客户端通过SDK创建好交易提案（Proposal）,交易提案把带有本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等信息发送给背书（Endorser）节点。
3.背书（Endorser）节点收到交易提案（Proposal）后,开始进行验证,验证的内容如下： 交易预案是完好的 该预案以前没有提交过(防止重放攻击) 携带的签名是合法的 交易发起者是否满足区块链写策略, 即ACL 权限检查
满足以上要求后,背书节点把’交易预案’作为输入参数,调用chaincode中的函数,chaincode根据当前的账本状态计算出一个’交易结果’,该结果包括返回值,读写集。此时,区块链账本并不会被更新。’交易结果’在被签名后与一个是/否的背书结果一同返回,称之为’预案回复’。
4.应用程序客户端收到背书（Endorser）节点返回的信息后,判断提案结果是否一致,以及是否收到足够多的背书节点返回的结果（参照指定的背书策略执行）,如果没有足够的背书,则中止处理,这个交易就会被舍弃。否则,将交易提案、模拟交易结果和背书信息打包组成一个交易并签名发给Orderer节点（一个排序服务）。
5.Orderer节点对来自客户端（SDK）的交易信息进行共识排序,分通道对’交易消息’按时间排序,并按通道将交易打包成块,发送给提交（Committer）节点。
6.提交（Committer）节点收到区块后,会对区块中的每笔交易进行校验,检查交易依赖的输入输出是否符合当前区块链的状态,验证背书策略是否满足,验证完成后将区块追加到本地的区块链,更新账本,并修改世界状态。具体过程如下： 运行验证逻辑（VSCC检查背书策略） 在区块中指明哪些交易是有效和无效的。 在内存或文件系统上把区块加入区块链 将区块内的有效交易写入状态数据库。 发出Event消息,使得客户端通过SDK监听知道哪些交易是有效的或无效的。 「深度学习福利」大神带你进阶工程师,立即查看>>>
欢迎来到使用Unity游戏引擎制作的NEO区块链游戏的’A-Z’多系列讲解教程的第3部分。在 第2部分 中,我们设置了自己的私有网络并将其连接到我们的Unity场景中。 在第3部分中,我们会进行一些设置,以便我们的玩家可以输入他们自己的私钥然后开始与NEO区块链进行交互。
我们将保证每个系列内容的简洁清晰,从而对整体的工作流程做出全面地演示说明。某些内容我们会做出快速的讨论,有任何不清楚的地方,随时欢迎你发表评论,我很乐意为你解答。
免责申明
至此,我们将开始添加更多自定义的逻辑并与NEO区块链进行交互。 对于任何熟悉这个领域的人来说,这些是不言自明的,但是这个应用程序仅用于教学目的。一款游戏在很多方面来说就像一个钱包,作为用户和开发者,在最终将应用连接到主网或者将应用程序交付给用户时,都必须非常的谨慎。在这个领域中,大多数面向用户的项目都经过了彻底的测试和审核,以便发现代码漏洞和恶意代码。我建议你多花时间与社区合作然后做这些工作。本教程只介绍一些基本知识,为简单起见,我们会直接将私钥等内容保存在本地存储中,这是不安全的。不要在生产环境中这么做。
钱包管理
下一部分会更多地涉及到Unity特定的工作流的内容,所以我会给你提供一个预置和脚本文件,你可以直接导入到你的项目中,这样可以节省一些时间。你可以直接在 这里下载 。这个脚本会管理你的NEO钱包的实例,如果你还没有这个实例的话,它会帮你新建一个。我提供这个脚本的原因是为了证明拥有良好入门体验的重要性。许多的加密货币项目(以及一些游戏)都会要求用户进行大量的学习从而学会如何使用这个应用程序。长远上来说,我们需要更好地了解如何引入新用户,同时在这么做的时候尽可能地减少摩擦。用户已经投入时间下载游戏了,当开始要求占用他们更多时间的时候,如果能在开始玩游戏的时候,有着越少的必要的点击操作和学习要求,他们就越不可能立马删除游戏。不要让用户去思考。
理想情况下,我是希望能完全移除第一个界面,只需将用户直接放入游戏中即可。但持有资产的问题是很明显的,你必须非常清楚何时以及如何处理这些资产。当用户忘记或者丢失他们的密钥时,你无法直接进入后台帮助用户重置和检索他们的数据。一个好的中间解决方案是游戏的开始部分不用涉及到任何钱包内容,只有用户想要更好地尝试你的钱包功能时,才会提示用户输入这些钱包信息。希望你们能自行尝试探索自己的解决方案。
发送通证
在后面的教程中,我们将更深入地研究智能合约,但是现在我们只想快速与NEO区块链进行交互。当玩家得分超过某个阈值时,我们会给他们代币作为奖励。GAS在某种程度上是NEO区块链中的实际代币,所以我们会使用它来作为奖励。
在创建一个真正的游戏时,你将不得不与攻击作斗争,而斗争的同时又要保持游戏的趣味性和经济的流动性并不是一件容易的事情。出于演示的目的,我们在这里会进行简化。在真正的在线游戏中,你需要多种反作弊机制,但最终在游戏中,我们知道我们永远都无法避免所有的攻击。某个地方的某个人会下定决心去破坏你的游戏。否则的话你会遗漏一个关键的代码漏洞。我们试图通过防止最为常见的攻击和睡眠不足来找到平衡,我们经常以这样一种方式分割经济,以便其他玩家的游戏体验不会在这个过程中受到损害。
创建一个名为NEORewardManager的游戏对象GameObject,将它作为其他NEO管理器的子对象。创建一个名为NEORewardManager的脚本并复制粘贴以下代码： using System; using System.Collections; using UniRx; using UnityEngine; public class NEORewardManager : MonoBehaviour { [SerializeField] private NEOManager neoManager; [SerializeField] private CompleteProject.PlayerHealth playerHealth; [SerializeField] private int rewardThreshold = 50; private bool isGameOver; private void Update() { if(playerHealth.currentHealth <= 0 && !isGameOver) { StartCoroutine(OnGameOver()); isGameOver = true; } else if(playerHealth.currentHealth > 0 && isGameOver) { isGameOver = false; } } private IEnumerator OnGameOver() { yield return new WaitForSeconds(1); Time.timeScale = 0; if(CompleteProject.ScoreManager.score >= rewardThreshold) { StartCoroutine(TrySendGAS(1)); } else { Time.timeScale = 1; } } private IEnumerator TrySendGAS(int amount) { yield return null; try { var tx = neoManager.API.SendAsset(neoManager.MasterKeyPair, neoManager.PlayerKeyPair.Value.address, NEOManager.AssetSymbol, (decimal)amount); if (tx == null) { Debug.LogError("Null Transaction returned"); Time.timeScale = 1; } else { Debug.Log("TX received, checking sync..."); Observable.FromCoroutine(SyncBalance).Subscribe().AddTo(this); } } catch (NullReferenceException exception) { Debug.LogError("There was a problem..."); Time.timeScale = 1; } catch (Exception exception) { Debug.LogError("There was a problem..."); Time.timeScale = 1; } } private IEnumerator SyncBalance() { yield return null; try { //var balances = neoManager.API.GetAssetBalancesOf(neoManager.PlayerKeyPair.Value); //neoManager.GASBalance.Value = balances.ContainsKey(NEOManager.AssetSymbol) ? balances[NEOManager.AssetSymbol] : 0; //if (Mathf.Approximately((float)NEOManager.GASBalance.Value, GameDataSystem.Coins.Value)) //{ // Debug.Log("GAS transferred successfully"); //} //else //{ // Debug.LogWarning("Something's not right." + // //"\nCoins: " + GameDataSystem.Coins.Value + // "\nGAS: " + NEOManager.GASBalance.Value); //} Debug.Log("Balance synced!"); Time.timeScale = 1; } catch (NullReferenceException exception) { Debug.LogWarning("Something's not right." + //"\nCoins: " + GameDataSystem.Coins.Value + "\nGAS: " + neoManager.GASBalance.Value); Time.timeScale = 1; } } }
系统会等待游戏结束状态,游戏结束后如果玩家得分超过某个特定的阈值,系统就会从主账户中转账GAS到本地玩家账户中。 通过拖放场景中的引用来连接NEOManager和PlayerHealth。 你还可以将奖励阈值设置为你想要的任何值; 玩玩看看。 在随后的回放中,你可以看到数量的更新,这可以反映出GAS已经转账正常了。恭喜,我们现在已经可以与NEO区块链进行一些基本的交互了,耶。
在接下来的教程中,我们将更深入地探讨智能合约,并探索系统能够提供的其他功能。
原文链接： https://medium.com/@tbriley/making-a-game-with-neo-unity-part-3-df4edc3b3546
翻译：包子
NEOFANS：neofans.org
NEOFANS 微博：https://www.weibo.com/neofanscommunity
NEOFANS telegram群：https://t.me/NEOfansCN 「深度学习福利」大神带你进阶工程师,立即查看>>>
今天我们推出了一个全新的系列,Hacking the Blockchain！它适用于刚刚开始开发EOSIO的所有开发人员。它也适用于所有EOS Blockchain爱好者,他们不是完全技术性的,但想要搞清楚该技术的工作原理。
在每篇文章中,我们将探讨区块链的特定部分。我们从EOS通信模型开始,希望能坚持下去！
今天,我们将探索EOS通信模型。我们将深入探讨不同类型的沟通模式和行动。对于dessert,我们将看到如何在我们的代码中使用它,并在我们要开发一个自动化的演示中使用它。
但首先,让我们从EOS智能合约的内容开始。这将奠定基础。
EOS 智能合约
每个EOS智能合约都有一组操作和类型。 action 表示单个操作。你可以将其视为JavaScript中的函数或C#中的方法。 type 定义合约中使用的所需内容和结构。大多数时候我们将它们用于我们的表。
EOSIO中的合约可以相互通信。它是通过基于消息的通信架构实现的。
EOS通信模型就是他们沟通的方式。通信模型有两种类型：Inline Communication Model（内联通信模型）和Deferred Communication Model（延时通信模型）。
内联操作（内联通信模型）
内联操作是内联通信模型的一部分。如果你了解它们,就能理解内联通信。
我们来看看下图：
用户从 智能合约A执行操作（Action #1） 。当操作开始执行时,它会触发另外两个操作： 来自智能合约B的操作Action #1.1 和 来自智能合约C的操作Action #1.2 。一切都在当前交易中完成。
在当前交易中执行并与其完成相关的操作,称为 inline action 即 内联操作 。
重要的是要记住内联操作是作为调用操作的一部分执行的。因此,它们与原始交易的范围和权限相同。这是他们将被执行的保证。如果其中一个操作失败,则整个交易将失败。
所以,你应该已经知道内联通信是什么意思了吧。
请求将执行操作作为调用操作的一部分是 inline communication 即 内联通信 的示例。
延时操作（延时通信模式）
第二种类型是延时通信模型。表示模型的延时操作非常有趣,因为它们不在同一交易中执行。我们来看看下图：
我们有相同的交易工作流程。这里唯一的区别是从智能合约C执行的第二个操作不是内联而是延时。延时操作计划在将来运行。
根据生产者的判断,延时的操作最好可以安排在稍后的时间运行。无法保证延期操作将执行。
即使它们不属于同一交易,它们也具有发送它们的合约的权限。
所以基本上,延时通信在概念上采用发送给对等交易的操作通知的形式。
交易与操作
在继续演示之前,让我们检查一些有趣的东西。
在EOSIO中,交易和操作之间存在差异。操作表示单个操作,而交易是一个或多个操作的集合。
交易可以包含N个操作。但是,每个交易必须在 30ms或更短 的时间内执行。如果交易包含多个操作,并且这些操作的总和大于30毫秒,则整个交易将失败。
机器人工厂
我们要做个机器人。你可以在我们的 GitHub 中找到包含所有智能合约和代码的项目。
作为一家创造未来的机器人公司,我们希望一切都是完美的。新建新的机器人时,应发送出售信息,并在终端上打印相关信息。为了实现这三个操作,我们将使用内联操作。
看一下下面的代码片段。 void RobotFactory::create(account_name account, robot newRobot) { robotIndex robots(_self, _self); auto iterator = robots.find(newRobot.series_number); eosio_assert(iterator == robots.end(), "Robot with this series number already exists"); robots.emplace(account, [&](auto& robot) { robot.series_number = newRobot.series_number; robot.model = newRobot.model; robot.operating_system = newRobot.operating_system; robot.profession = newRobot.profession; robot.owner = name{account}.to_string(); robot.manufactured = now(); }); // Execute INLINE ACTION from another contract // action({permission_level}, {contract_deployer}, {contract_action}, {data_to_pass}).send(); action(permission_level(account, N(active)), N(market), N(forsale), make_tuple(account, newRobot.series_number, newRobot.model, newRobot.manufactured )).send(); // Execute INLINE ACTION from another contract // action({permission_level}, {contract_deployer}, {contract_action}, {data_to_pass}).send(); action(permission_level(account, N(active)), N(messenger), N(printmessage), make_tuple(newRobot.model)).send(); }
首先,我们开始创建一个新的机器人。操作完成后,它将出现第一个内联操作。我们让发送机器人一个出售信息,所以我们要求 RobotMarketplace 智能合约的 forsale 。
请注意,当我们要求智能合约A从智能合约B执行操作时,应首先添加适当的权限。我们将在下一部分介绍,目前,请务必遵循 README.md 中的指南。
第一个内联操作完成后,第二个内联操作就会完成。这次我们从 Messenger 智能合约中请求 printmessage 。 同样应该添加适当的权限。
在这两种情况下,当我们通过终端执行创建操作时,我们已收到操作已完成（或失败）的通知。 cleos push action weyland create '{"account":"weyland","newRobot":{"series_number":14441992,"model":"A330","operating_system":"DX42","profession":"engineer","owner":"","manufactured":0}}' -p weyland executed transaction: 9874a8a5f516ca540c44cafd8b9b371c856fe7958be1fc6268641cc7ab67fdaf 136 bytes 6000 us # weyland <= weyland::create {"account":"weyland","newRobot":{"series_number":14441992,"model":"A330","operating_system":"DX42",... # market <= market::forsale {"account":"weyland","robotForSale":{"series_number":14441992,"model":"A330","manufactured":0}} # messenger <= messenger::printmessage {"message":"A330"} >> ==== For sale | Robot model: A330
让我们将 printmessage 操作从内联更改为延时。为此,我们需要使用EOSIO的 transaction.hpp 标头。 void RobotFactory::create(account_name account, robot newRobot) { robotIndex robots(_self, _self); auto iterator = robots.find(newRobot.series_number); eosio_assert(iterator == robots.end(), "Robot with this series number already exists"); robots.emplace(account, [&](auto& robot) { robot.series_number = newRobot.series_number; robot.model = newRobot.model; robot.operating_system = newRobot.operating_system; robot.profession = newRobot.profession; robot.owner = name{account}.to_string(); robot.manufactured = now(); }); // Execute inline action from another contract // action({permission_level}, {contract_deployer}, {contract_action}, {data_to_pass}).send(); action(permission_level(account, N(active)), N(market), N(forsale), make_tuple(account, newRobot.series_number, newRobot.model, newRobot.manufactured )).send(); // Execute DEFERRED ACTION from another contract eosio::transaction tx; tx.actions.emplace_back(permission_level{account, N(active)}, N(messenger), N(printmessage), make_tuple(newRobot.model)); tx.delay_sec = 12; tx.send(N(newRobot.model), account); }
要创建延时交易,我们首先从类型交易声明一个变量 tx 。然后我们在其操作集合中添加一个新操作。我们可以选择设置延时。如果它为0,则延时交易将在调用之后立即进行。
设置完所有后,我们只需调用send方法即可。
但是,不保证将执行延时交易。此外,我们 不会 像在内联操作中那样收到有关其成功或失败的任何通知。 cleos push action weyland1 create '{"account":"weyland1","newRobot":{"series_number":14441993,"model":"A330","operating_system":"DX42","profession":"engineer","owner":"","manufactured":0}}' -p weyland1 executed transaction: 5f45b48877aac9d03172616a2443b7a9079ee9f74a124a0976d2fcf0b756e985 176 bytes 2722 us # weyland1 <= weyland1::create {"account":"weyland1","newRobot":{"series_number":14441993,"model":"A330","operating_system":"DX42",... # market <= market::forsale {"account":"weyland1","robotForSale":{"series_number":14441993,"model":"A330","manufactured":0}} # No notification for printmessage action
正如你在12秒后看到的那样,执行延时交易。
总结一下它们是EOS中的两种通信模型：内联和延时。内联通信期间使用的操作称为内联操作,在延时通信中使用时称为延时操作。
分享一个EOS区块链相关的交互式在线编程实战教程：
EOS教程 ,本课程帮助你快速入门EOS区块链去中心化应用的开发,内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点,最后综合运用各知识点完成一个便签DApp的开发。
汇智网原创翻译,转载请标明出处。这里是原文 EOS区块链的通信模型 「深度学习福利」大神带你进阶工程师,立即查看>>>
我们生活的环境充满了随机性。一直以来,运气,概率和命运这些概念都与随机性紧紧联系在一起。所有人类无法理解或无法预测的事物往往都被归类为随机事物。从生理上来说,我们也是沉浸在了随机海洋中。从云的运动到粒子和波浪的行为,随机性简直无处不在。
然而,尽管人类接触到了各种各样的随机事物,对随机性很熟悉,但依然难以将它转化为计算机可以使用的东西。当我们谈论计算机系统中的随机性时,我们真正指的是伪随机性,即尽可能模拟出现实世界应有的随机性,使之近乎于“真正的随机性”。以密码学安全伪随机数生成器为例,这是一个非常强大的随机性模拟。
随机数在隐私技术和密码学中发挥着重要作用。令人惊艳的是,通过生成一个随机数来对一条消息进行异或运算（XOR）,提供了一种简单但十分强大的加密方案。即使是双方之间最简单的私人通信形式（即双方提前共享密钥的对称加密方案）也要求共享的密钥是随机的。如果此共享密钥不是随机的,则加密就毫无用处,因为任何知道密钥生成算法的人都可以确定密钥然后解密该条消息。
随机数的重要性不仅体现在安全通信渠道的建立上,还体现在确认通信对象上。如果多个人试图通过有限带宽的频道来互相通信,则可以利用随机数来确定频道携带消息的合理顺序。
随机数能够有效帮助团体或计算机达成一致协议或共识。随机共识协议就是这样一个例子。本文将探讨随机数在区块链中的作用。
区块链就是一个多方尝试就全局视角的某种更新达成一致（共识）的成功案例。更新通常在一轮内完成,也就是在一个周期性离散时间间隔内。
在互联网上,特定时间段内发送的消息数量是有上限的（即吞吐量）,并且发送消息必将花去一定的时间（ 即延迟）,这都对共识造成了一定的限制。任何区块链共识协议的目标是在上述限制范围内达成一致协议 。在公链上有数千个节点参与了区块链的维护,如果每个节点需要向所有其他节点发送消息并获得其反馈,那么网络的限制会大大增加达成共识的成本。这是因为在一轮时间内通过网络发送的消息数量太大。因此,为了确保共识,则需要通过减少在互联网上发送消息的数量来优化通信方案。
比特币达成此协议（中本聪共识）的方式是通过使用 工作证明（PoW）作为随机数源来确定每一轮中哪一个区块将会被添加到区块链中,从而减少消息传递的费用。因为 PoW 设置的题目在算法上非常难解决,只有最先算出来的人才能将他们的区块添加到分类帐中。由于多个人同时解开难题的概率非常低,因此 PoW 可以作为一种限制网络消息传递数量的机制。
理论上,任何试图取代 PoW 的共识机制都需要找到一种方法来限制网络传递消息的数量。 大多数权益证明（PoS）协议用于解决该问题的方法是根据验证者持有的代币数量来选出一组验证者（维护与管理区块链的节点）组成一个小组委员会,然后这组验证者可以在网络限制内相互通信并及时达成一致。
当然,为了公平选举出小组委员会的成员,保证没有人会提前知道成员的身份,算法必须能够融入一些公平、无偏倚的（unbiasable）随机数源。一旦该组验证者在下一个区块上达成了一致,那个区块就会被广播给网络中的每一个人。
在 PoS 协议中用于小组委员会选举的理想随机数源必须是不可支配的（unbiasable）,即没有人可以随意改变随机种子（seed）。为了实现不可支配性,随机性协议需要确保以下两点： 随机函数总会生成一些随机数； 随机函数生成的随机数没有被操纵
（注意：我们在之后的博客文章中将会探讨 i）与ii） 之间的权衡,以及这种权衡与网络同步模型的关系）
我们在 Mechanism Labs （一个推特号）上分析过的所有小组委员会选举协议都没有满足上面提到的两点 。因此,鉴于上述权衡,区块链共识协议应该使用能不断产生随机数的随机数源,而不是使用仅能一次性产生不可支配的随机数的随机数源。因为区块链协议需要确保区块链保持增长、不能让随机数源成为瓶颈。即使是偏好一致性的协议,随机数源也不应该成为区块链停滞的原因。无论如何,随机数源都应该确保协议能够专注于应付其他攻击,比如对验证者组成的小组委员会实施 DoS 攻击使得区块链停滞等等。
如果区块链由于随机函数输出的随机数出现了偏差而完全停止运行,那么社交层就得付出巨大的协调成本来重新启动区块链 。这将要求社区通过外部的社交媒体平台就区块链实际上是什么的问题达成一致,而这会是一个非常耗时的讨论,此成本可与当初解决 DAO 黑客攻击的成本相当。社交层的巨额成本也会动摇社区对区块链协议安全性的信心,但只要偏差非常小并且具备从偏差状态恢复的机制,那么几轮的小偏差对区块链安全性的影响就比较微弱,因为公有区块链协议每一轮给予验证者的所有协议奖励是相对较少的。每一轮或每一个时期（每几轮）进行小组委员会选举时,随机函数中的偏差必须非常显著,验证者才能以欺骗协议来牟利并降低区块链协议的安全性。
而在另一个领域内,那些用到随机数的彩票游戏必须保证随机数源绝对不被操纵,因为即使出现一点偏差也会完全改变中奖结果。由于中奖者能够获得大量的即时奖励,所以篡改彩票结果带来的影响是巨大的。因此,这种彩票游戏偏好于一次性生成不可支配随机数的函数,即使这意味着随机函数的输出有时会停止。
本文将探讨基于区块链协议设计的背景下公正无偏的随机数源的重要性。接下来的文章中,当我们考虑不可篡改的协议时,我们是倾向于不会被中止的协议。
理想的委员会选举方案 应该满足 i）不可被支配,ii）只在新一轮开始时显示随机种子 。随机函数必须如前文讨论的定义那样做到不可被偏转。如果随机数被操控（并存在协议内奖励分配机制）,就会造成不公平的奖励分配。不恰当的奖励分配意味着一些人将获得更丰厚的奖励。由于只有拥有权益的人才能成为验证者,并且投票权与验证者所拥有的权益成正比,那么不公平的分配将导致区块链最终只掌控在少数验证者手里。因此,协议的不可操纵的程度,决定了是否有人可以长期作为验证者维护部分网络。另一方面,种子在新一轮开始之前提前多久显示,决定了谁可以首先成为网络的一部分。由此可见,上述两个属性将决定区块链的去中心化程度。
由于每一轮（或每一个时期）都会进行小组委员会的选举,因此从公布随机函数输出的随机数到那一轮（或那一个时期）开始所需的时间是至关重要的。在此时间范围内,攻击者可以利用随机函数输出的随机数得知哪些验证者获选。如果此输出被隐藏,则试图攻击区块链协议的攻击者将无法提前得知获选的验证者。此时间范围的长短决定了协议对攻击的承受能力。较强的攻击者,即具有较多计算能力和资源去攻击网络的人,能够在短时间内计算出获选的验证者。如果攻击者有足够的时间,他们会通过运行选举委员会所用的算法以及该轮给定的随机数种子来确定哪些验证者当选,然后对该轮获选的验证者进行拒绝服务（DoS）攻击,导致空白区块的产生,令该轮无任何进展。对区块链来说,即使是停止一轮,后果也是毁灭性的。设想一下,如果几小时内世界上没有人可以进行任何交易,比特币会变成什么样！因此,有能力抗 DoS 攻击的节点才应该首先成为验证者。另外,提前显示种子也意味着共识协议只能应对较弱的攻击者,这弱化了区块链的去中心化性质。
基于我们曾在 替代性共识协议的元分析 中剖析的不同区块链协议的使用案例,下面我们会从技术角度详细介绍各种随机数的生成机制。
Tendermint
Tendermint 是使用一种确定的循环协议方案来选出提议者的；该协议不具备随机性。提议者是根据投票权和验证者被选次数的堆排序算法选出的。攻击者只能通过添加或删除权益来干预协议,但这种干预不能立即生效,因为验证者在系统中移除或者添加权益所需的时间很长。尽管如此,攻击者就可以有更长的时间提前计划好如何操纵提议者的选择。
使用确定性的随机算法意味着随机种子会在远早于每一轮之前公布,提议者也能被提前确定。
Algorand
Algorand 的随机数方案如下：被选为提议者的每一位验证者 v 使用公式 < seedr, π > ← VRFskv (seedr−1||r) 来计算 r 轮的种子,其中 skv 是验证者 v 的密钥,seedr-1 是前一轮的随机种子。
VRF 是用来证明 r-1 轮中接受的区块包含了 π 以及 r 轮的种子。如果给定的 VRF 证明未能验证给定的种子,则每个人计算新一轮的种子 H(seedr−1||r),其中 H 是哈希函数。这意味着必须提前选好每位验证者的密钥,确保他们无法干预随机种子。
当网络不能很好地同步时,攻击者完全控制了消息传递链接（校对注：感觉这里像在说“异步”假设）,因此可以删除提议的区块并强制用户支持空白的区块,从而计算出未来用于选举的随机种子。因此,Algorand 要求 弱同步 假设,即在每个时间长度为 u 的周期中,必须存在时间长度为 s（s < u）的强同步来保证协议的不可操纵性。只要 s 值足够大,使得在时间段 b 内至少产生一个诚实的区块,则选择密钥 skv' 的攻击者 v' 就不能操控 r 轮的随机种子。
只有当一个区块被提议之后,才会生成一个新的随机数种子,和一个可用来验证的公开 VRF 证明。这确保了提议者和随机种子没有被提前泄露,同时保证 Algorand 能够抵御针对提议者的 DoS 攻击,即使在节点离线甚至瞬间腐化的模式下都能实现自适应安全。
Dfinity
对于大部分协议,攻击者通常会中止协议来调用回退机制,从而操纵随机数。但 Dfinity 使用的门限签名方案（threshold scheme）是不可操纵的,因为选择阈值的原则就是确保攻击者无法通过阻止生成 门限签名 来中止协议（因为随机数种子是从门限签名中推导出来的）。因此阈值 t 必须根据以下公式进行选择：t∈[f + 1,n - f],其中 f 是攻击者控制的签名数,n 是方案中的总签名数,t 是用于生成随机数的签名阈值。选择该阈值是为了确保攻击者既无法预测签名生成的结果,也无法阻止签名的生成。
需要注意的是,在任何 BLS 方案中,只要攻击者拥有 50％ 以上 的保证金,他们就能够操控最终的签名与随机数。然而,如果一名攻击者拥有如此大份额的权益,也会出现其它类型的攻击,这种情况就违反了 Dfinity 协议的基本假设。
一旦诚实的验证者进入到第 r 轮,随机种子就会被揭示。虽然从诚实的验证者进入到新一轮正式开始之间的时间差很小,但这个时间差足以让具有大量计算资源的攻击者识别出提议者并对其进行 DoS 攻击。这就是为什么 Dfinity 只能应对温和的攻击者而无法应对瞬时瘫痪的状况。
Thunderella
在哈希函数实例化的随机数预言机方案中,提议者将依据以下公式来确定：H_nonce(pk,q) < Dp,其中 H 是用作随机数预言机的哈希函数,pk 是验证者的公钥, q 是给定的迭代时间,nonce 是哈希函数的熵来源。Nonce 由前一个区块的提议者选择。设置难度参数 D_p 是为了在单个迭代时间内,委员会成员被选为提议者的概率为 w。
如果攻击者提议了一个区块,她可以操控为下一轮哈希函数生成熵的 nonce 值,从而影响下一个区块的提议者的人选。然而,为了降低随机数方案的可篡改性,在哈希函数中相同的 nonce值不仅仅用于选择下一轮的提议者,也会用于选择接下来 r 个轮次的提议者。这使得攻击者在计算上很难通过强制改变 nonce 值来让自己连续成为接下来 r 个轮次的提议者。虽然这种策略仅损失了多项式安全性,但它具有可预测性的弊端（后面也会讨论到）。该方案仅能够应对慢速自适应的攻击者。
在上述算法中,当重复使用相同的 nonce 值给哈希函数喂送种子时,就会导致攻击者能够提前预测到谁是提议者。由于在一时期中相同的 nonce 值被重复用作熵,从而导致随机种子在新一轮开始之前被泄露,使得攻击者可以对提议者进行腐化或者实施 DoS 攻击。
Casper FFG
Casper FFG 计划使用的随机数方案是基于以下算法：
一个时期开始时,每个验证者承诺 H (H (H (..Sv )))),其中 S 是验证者承诺的种子。 R 赋值为 R 与哈希函数内原象的异或运算（R := R⊕ Pre-image of the inner layer of hash）。在一轮中,验证者可以创建或中止一个区块。
如果在回退机制中没有生成随机数,这可能会造成比可预测或可操纵的随机数更大的问题,因为你将不再需要 1/3 的恶意者来中止协议,1个人就足够了。
作为当前提议者的验证者是知道下一轮的随机种子的。
随机数是密码学和区块链的重要部分。不良的随机数方案会通过以下方式破坏区块链的安全性：i）停止区块链协议；ii）导致中心化。 因此,在理解区块链的安全性时,探究随机性在该区块链协议中的角色乃是重中之重！ 内容来源：公众号-以太坊爱好者
原文链接:
https://www.tokendaily.co/blog/randomness-in-blockchains
作者: Aparna Krishnan
翻译&校对: 哲妹 & 阿剑
「深度学习福利」大神带你进阶工程师,立即查看>>>
1
链码概念 网络运行环境我们已经启动完成,现在我们从开发者的角度来认识一下完成交易所必须的智能合约（在 Hyperledger Fabric 中被称之为 Chaincode,也就是链上代码）的相关知识,以便于理解账本中的数据到底是通过什么方式进行操作。
Chaincode：链上代码,简称链码,一般是指由开发人员使用Go语言（也支持Java等语言）编写的应用程序代码,提供分布式账本的状态处理逻辑。链码被部署在Fabric的网络节点中,能够独立运行在具有安全特性的受保护的 Docker 容器中,以 gRPC 协议与相应的 peer 节点进行通信,以操作（初始化或管理）分布式账本中的数据。可以根据不同的需求开发出不同的复杂的应用。
链码分类
在 Hyperledger Fabric 中,链码一般分为： 系统链码 用户链码
2
Fabric提供了什么－系统链码
负责 Fabric 节点自身的处理逻辑, 包括系统配置、背书、校验等工作
系统链码仅支持 Go 语言, 在 Peer 节点启动时会自动完成注册和部署
系统链码共有五种类型：
配置系统链码(CSCC)
CSCC：Configuration System Chaincode,负责处理 Peer 端的 Channel 配置。
生命周期系统链码(LSCC)
LSCC：Lifecycle System Chaincode,负责对用户链码的生命周期进行管理。
查询系统链码(QSCC)
QSCC：Query System Chaincode,提供账本查询 API。如获取区块和交易等信息。
背书管理系统链码(ESCC)
ESCC：Endorsement System Chaincode,负责背书(签名)过程, 并可以支持对背书策略进行管理 对提交的交易提案的模拟运行结果进行签名,,之后创建响应消息返回给客户端
验证系统链码(VSCC)
VSCC：Validation System Chaincode,处理交易的验证,包括检查背书策略以及多版本并发控制
3
什么是用户链码
由应用程序开发人员根据不同场景需求及成员制定的相关规则,使用 Golang（或Java等）语言编写的基于操作区块链分布式账本的状态的业务处理逻辑代码,运行在链码容器中,通过 Fabric 提供的接口与账本状态进行交互。
用户链码在整个应用程序中处于重要地位。因为它下可对账本数据进行操作,上可以给企业级应用程序提供调用接口。所以一个没有链码的企业级应用程序,不能称之为是基于区块链的企业级应用程序。
4
链码的生命周期管理
链码开发编写完成后,并不能立刻使用,而是必须经过一系列的操作之后才能应用在 Hyperledger Fabric 网络中进而处理客户端提交的交易。这一系列的操作是由链码的生命周期来负责管理。
管理 Chaincode 的生命周期共有五个命令： install：将已编写完成的链码安装在网络节点中。 instantiate：对已安装的链码进行实例化。 upgrade：对已有链码进行升级。链代码可以在安装后根据具体需求的变化进行升级。 package：对指定的链码进行打包的操作。 singnpackage：签名。 安装、实例化、升级这三项操作不适用于系统链码
链码的生命周期管理命令现阶段只有这五个,但未来还会支持 stop 和 start 命令, 用来停止和启动链码。
链代码成功安装和实例化后,则处于活动状态（正在运行）,时刻准备执行处理提交的交易提案。
下一节开始我们会使用这些生命周期管理命令来实现对链码的相关操作。
5
FAQ
文中所说的状态与账本数据是什么关系？
状态其实指的就是账本中的数据。没有其它另外的含义。
链码可以访问所有账本中的状态吗？
一个链码对应一个账本,所以一般情况下链码是不可以访问其它账本中的数据的。 内容来源：区块链兄弟
作者：韩小东
课程推荐
「深度学习福利」大神带你进阶工程师,立即查看>>>
随着智能制造与工业互联网的不断发展,工业互联网领域与其它新兴技术体系是否可以挖掘出更多的有效结合方式,区块链在实体经济建设过程中如何体现其特有价值,区块链的BaaS服务形态,怎样才能更灵活的服务多种项目需求,上海亿喆网络公司试图通过工业互联网领域的实际案例了解,为以上问题找到一些有价值的思考方向和解答角度。
工业互联网是全球工业系统与高级计算、分析、感应技术以及互联网连接融合的结果。它通过智能机器间的连接并最终将人机连接,结合软件和大数据分析,重构全球工业、激发生产力,让世界更美好、更快速、更安全、更清洁且更经济。
工业互联网的用途有：
产品质量/生产过程管理和追溯的挑战：
技术升级需求：
技术实现物理架构：
真实场景下的区块链环境管理手段：
数据采集对接-区块链部署：
数据采集对接-设备采集：
节点层次图：
网络层次图：
创新尝试：
价值体现：
现实意义：
本次活动照片：
本文作者：HiBlock区块链技术工坊讲师- 郝振亚
郝振亚,亿喆网络技术总监, 13年IT经验,运营商支撑系统建设,电商与云计算相关平台及区块链应用项目落地相关经验,参与工信部区块链参考架构草案与评审,区块链技术白皮书合作编写等。
本次实录纪要由辉哥(王登辉,创业股平台CTO,HiBlock上海合伙人)记录,转发务必注明出处及本段信息。
「深度学习福利」大神带你进阶工程师,立即查看>>>
sudo apt install git
sudo apt install pkg-config
git clone https://github.com/OmniLayer/omnicore.git
sudo apt install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils
sudo apt install libboost-all-dev
sudo apt install software-properties-common
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt update
sudo apt install libdb4.8-dev libdb4.8++-dev
cd omnicore/
./autogen.sh
./configure
make
复制 ~/omnicore/contrib/debian/examples/bitcoin.conf 到 ~/.bitcoin
/.bitcoin没有则新增
在bitcoin.conf增加以下：
server=1
txindex=1
rpcuser=r1p2c3
rpcpassword=r1p2c3f4
rpcallowip=127.0.0.1
rpcport=8332
paytxfee=0.00001
minrelaytxfee=0.00001
datacarriersize=80
logtimestamps=1
omnidebug=tally
omnidebug=packets
omnidebug=pending
sudo ln -s ~/omnicore/src/omnicore-cli /usr/bin/
sudo ln -s ~/omnicore/src/omnicored /usr/bin/
omnicored -regtest //启动测试网络
omnicore-cli "generate" 1 //挖一个区块 「深度学习福利」大神带你进阶工程师,立即查看>>>
$ git clone https://gitee.com/zpc/eos.git --recursive //获取代码
修改~/eos/scripts/eosio_build_ubuntu.sh文件：
修改if [ "${MEM_MEG}" -lt 7000 ]; then,把下面的exit 1注释掉；
修改if [ "${DISK_AVAIL%.*}" -lt "${DISK_MIN}" ]; then,把下面的exit 1注释掉；
看系统环境中有无${JOBS},如没有则修改if ! make -j"${JOBS}" install为if ! make -j2 install；
$ cd eos
build过程会安装一些东西,很慢,可以先手工下载到磁盘再修改eosio_build_ubuntu.sh文件相应脚本即可,这里提供我当前用到的一些资源
链接: https://pan.baidu.com/s/1bq9cVA-298Q3v4zBmUpKGA 提取码: uy4x
$ ./eosio_build.sh
$ sudo ./eosio_install.sh
$ cd ~/eos/build
$ sudo make install
nodeos配置文件：~/.local/share/eosio/nodeos/config/config.ini
keosd配置文件：~/eosio-wallet/config.ini
数据存储地址：~/.local/share/eosio/nodeos/data 「深度学习福利」大神带你进阶工程师,立即查看>>>
连了两个远程测试节点
const rpcUrl = 'http://jungle2.cryptolions.io:80'
const actionUrl = 'http://junglehistory.cryptolions.io:18888' //只找到这个测试节点能够提供actions记录
//处理账户交易记录,判断从上一次扫描之后账户新增记录,并根据备注给用户充值
async function dealActions(accountName) {
let rpcH = new JsonRpc(actionUrl, { fetch });
let actionHistory = await rpcH.history_get_actions(accountName);
let latestTime = 'select TRANS_TIME from RECHARGE where IFLAST=yes' //伪代码
for (let i in actionHistory.actions) {
var block_time = actionHistory.actions[i].block_time
if(block_time > latestTime){
let memo = actionHistory.actions[i].action_trace.act.data.memo
let quantity = actionHistory.actions[i].action_trace.act.data.quantity
let from = actionHistory.actions[i].action_trace.act.data.from
let to = actionHistory.actions[i].action_trace.act.data.to
let trx_id = actionHistory.actions[i].action_trace.trx_id
let global_action_seq = actionHistory.actions[i].global_action_seq
let block_num = actionHistory.actions[i].block_num
let producer_block_id = actionHistory.actions[i].producer_block_id
//let to = actionHistory.actions[i].action_trace.act.data.to
console.log('memos'+i+'='+memo)
//insert into RECHARGE values() //插入充值表
//update USER_ACCOUNT set BALANCE AVAILABLE_BALANCE where USER_ID = 0 //更新账户
}
};
return actionHistory
}
//转账操作 转账到账户accountName 'eosaccountb2';转账数额quantity '1.1234 EOS'
async function transfer(accountName,quantity) {
let signatureProvider = new JsSignatureProvider([pkeys[0].privateKey]);
let api = new Api({ rpc, signatureProvider, textDecoder: new TextDecoder(), textEncoder: new TextEncoder() });
let result = await api.transact({
actions: [{
account: 'eosio.token',
name: 'transfer',
authorization: [{
actor: pkeys[0].actor,
permission: 'active',
}],
data: {
from: pkeys[0].actor,
to: accountName, //提现地址
quantity: quantity, //提现数量
memo: '',
},
}]
}, {
blocksBehind: 3,
expireSeconds: 30,
});
console.dir(result);
let transaction_id = result.transaction_id
let receipt= result.processed.receipt //抵押的net和cpu,记到数据库备份
console.log('receipt===='+JSON.stringify(receipt))
//insert into WITHDRAW()
}; 「深度学习福利」大神带你进阶工程师,立即查看>>>
CCXT(CryptoCurrency eXchange)交易库,一个JavaScript/Python/PHP加密货币交易库,支持超过100种山寨币与比特币交易所。
用于加密货币交易和电子商务的JavaScript/Python/PHP库,支持许多比特币/以太网/山寨币交易所和商家API。
CCXT库用于连接和交易全球的加密货币/山寨币交易所和支付处理服务。它可以快速访问市场数据,用于存储,分析,可视化,指标开发,算法交易,策略回溯测试,机器人编程,网上商店集成和相关软件工程。
它旨在供编码人员,开发人员,技术熟练的交易员,数据科学家和金融分析师用于构建交易算法。
当前功能列表： 支持许多交易市场,甚至即将推出的 为所有交易提供完整的公共和私人API 所有货币,山寨币和标记,价格,订单,交易,代码等... 提供用于交叉交换或跨货币分析和套利的可选标准化数据 开箱即用的统一的一体化API,非常易于集成 适用于Node7.6+,Python2和3,PHP5.4+,Web浏览器
认证交易所
支持的加密货币交易所
ccxt库目前支持以下131个加密货币交易所和交易API(太多了想看的直接到github看吧,就不列出来了)：
https://github.com/ccxt/ccxt
上面的列表经常更新,新的加密市场,山寨币交换,错误修复,API端点定期引入和添加。有关详细信息,请参阅 手册 ,如果你没有在上面的列表中找到加密货币交易市场和/或想要添加其他交易所,请通过GitHub或通过电子邮件在 此处 发布问题来发布或向我们发送链接。
该库受到MIT许可,这意味着任何开发人员都可以完全免费构建商业和开源软件,但使用它需要你自担风险且无需担保。
安装
安装ccxt库的最简单方法是使用内置包管理器： NPM中的ccxt （JavaScript/Node v7.6+） PyPI中的ccxt （Python 2和3.5.3+） Packagist/Composer 中的ccxt（PHP 5.4+）
该库作为一体化模块实现提供,具有最小的依赖性和要求： js/ 在JavaScript中 python/ 在Python中（从JS生成） PHP/ PHP（从JS生成）
也可以从ccxt GitHub存储库将其克隆到项目目录中： git clone https://github.com/ccxt/ccxt.git
将此库安装到代码中的另一种方法是将单个文件手动复制到工作目录中,并使用适合你环境的语言扩展名。
JavaScript（NPM）
CCXT的JavaScript版本适用于Node和Web浏览器。需要ES6和 async/await 语法支持（节点7.6.0+）。使用Webpack和Babel进行编译时,请确保在 babel-loader 配置中 not excluded 它。 npm install ccxt var ccxt = require ('ccxt') console.log (ccxt.exchanges) // print all available exchanges
JavaScript（用于script标记）：
一体化浏览器捆绑包 （包括依赖项）,由 unpkg CDN 提供服务,这是一个快速的全球内容交付网络,适用于NPM上的所有内容。
创建全局ccxt对象： console.log (ccxt.exchanges) // print all available exchanges
Python pip install ccxt import ccxt print(ccxt.exchanges) # print a list of all available exchange classes
该库支持在Python 3.5.3+中使用 asyncio 和 async/await 的并发异步模式： import ccxt.async_support as ccxt # link against the asynchronous version of ccxt
PHP
它需要常见的PHP模块： cURL mbstring（强烈推荐使用UTF-8） PCRE iconv gmp（这是PHP 7.2+中的内置扩展） include "ccxt.php"; var_dump (\ccxt\Exchange::$exchanges); // print a list of all available exchange classes
使用
ccxt库由公共部分和私有部分组成。任何人都可以在安装后立即使用公共部分即插即用。公共API可以从所有交易所市场开放访问公共信息,无需注册用户帐户,也无需拥有API密钥。
公共API包括以下内容： 市场数据 工具/交易对 价格（汇率） 订单 交易历史 行情 用于制图的OHLC（V） 其他公共端点
对于使用私有API进行交易,你需要从交换市场获取API密钥。这通常意味着注册交易并使用你的帐户创建API密钥。大多数交易所需要个人信息或身份证也可能需要某种验证。如果你想交易,你需要自己注册,此库不会为你创建帐户或API密钥。一些交易API公开了用于在代码本身内注册帐户的接口方法,但大多数交易不会。你必须在其网站上注册并创建API密钥。
私有API允许以下内容： 管理个人帐户信息 查询帐户余额 通过制造市场和限价订单进行交易 存入和取出法定和加密资金 查询个人订单 获得总账历史 在账户之间转移资金 使用商家服务
此库为所有交换实现完整的公共和私有REST API。即将推出JavaScript,PHP,Python和其他语言的WebSocket和FIX实现。
ccxt库支持 camelcase 表示法（在JavaScript中是首选）和下划线表示法（在Python和PHP中首选）,因此所有方法都可以用任何语言的符号或编码方式调用。 // both of these notations work in JavaScript/Python/PHP exchange.methodName () // camelcase pseudocode exchange.method_name () // underscore pseudocode
javascript 'use strict'; const ccxt = require ('ccxt'); (async function () { let kraken = new ccxt.kraken () let bitfinex = new ccxt.bitfinex ({ verbose: true }) let huobi = new ccxt.huobi () let okcoinusd = new ccxt.okcoinusd ({ apiKey: 'YOUR_PUBLIC_API_KEY', secret: 'YOUR_SECRET_PRIVATE_KEY', }) const exchangeId = 'binance' , exchangeClass = ccxt[exchangeId] , exchange = new exchangeClass ({ 'apiKey': 'YOUR_API_KEY', 'secret': 'YOUR_SECRET', 'timeout': 30000, 'enableRateLimit': true, }) console.log (kraken.id, await kraken.loadMarkets ()) console.log (bitfinex.id, await bitfinex.loadMarkets ()) console.log (huobi.id, await huobi.loadMarkets ()) console.log (kraken.id, await kraken.fetchOrderBook (kraken.symbols[0])) console.log (bitfinex.id, await bitfinex.fetchTicker ('BTC/USD')) console.log (huobi.id, await huobi.fetchTrades ('ETH/CNY')) console.log (okcoinusd.id, await okcoinusd.fetchBalance ()) // sell 1 BTC/USD for market price, sell a bitcoin for dollars immediately console.log (okcoinusd.id, await okcoinusd.createMarketSellOrder ('BTC/USD', 1)) // buy 1 BTC/USD for $2500, you pay $2500 and receive ฿1 when the order is closed console.log (okcoinusd.id, await okcoinusd.createLimitBuyOrder ('BTC/USD', 1, 2500.00)) // pass/redefine custom exchange-specific order params: type, amount, price or whatever // use a custom order type bitfinex.createLimitSellOrder ('BTC/USD', 1, 10, { 'type': 'trailing-stop' }) }) ();
Python # coding=utf-8 import ccxt hitbtc = ccxt.hitbtc({'verbose': True}) bitmex = ccxt.bitmex() huobi = ccxt.huobi() exmo = ccxt.exmo({ 'apiKey': 'YOUR_PUBLIC_API_KEY', 'secret': 'YOUR_SECRET_PRIVATE_KEY', }) kraken = ccxt.kraken({ 'apiKey': 'YOUR_PUBLIC_API_KEY', 'secret': 'YOUR_SECRET_PRIVATE_KEY', }) exchange_id = 'binance' exchange_class = getattr(ccxt, exchange_id) exchange = exchange_class({ 'apiKey': 'YOUR_API_KEY', 'secret': 'YOUR_SECRET', 'timeout': 30000, 'enableRateLimit': True, }) hitbtc_markets = hitbtc.load_markets() print(hitbtc.id, hitbtc_markets) print(bitmex.id, bitmex.load_markets()) print(huobi.id, huobi.load_markets()) print(hitbtc.fetch_order_book(hitbtc.symbols[0])) print(bitmex.fetch_ticker('BTC/USD')) print(huobi.fetch_trades('LTC/CNY')) print(exmo.fetch_balance()) # sell one ฿ for market price and receive $ right now print(exmo.id, exmo.create_market_sell_order('BTC/USD', 1)) # limit buy BTC/EUR, you pay €2500 and receive ฿1 when the order is closed print(exmo.id, exmo.create_limit_buy_order('BTC/EUR', 1, 2500.00)) # pass/redefine custom exchange-specific order params: type, amount, price, flags, etc... kraken.create_market_buy_order('BTC/USD', 1, {'trading_agreement': 'agree'})
PHP include 'ccxt.php'; $poloniex = new \ccxt\poloniex (); $bittrex = new \ccxt\bittrex (array ('verbose' => true)); $quoinex = new \ccxt\quoinex (); $zaif = new \ccxt\zaif (array ( 'apiKey' => 'YOUR_PUBLIC_API_KEY', 'secret' => 'YOUR_SECRET_PRIVATE_KEY', )); $hitbtc = new \ccxt\hitbtc (array ( 'apiKey' => 'YOUR_PUBLIC_API_KEY', 'secret' => 'YOUR_SECRET_PRIVATE_KEY', )); $exchange_id = 'binance'; $exchange_class = "\\ccxt\\$exchange_id"; $exchange = new $exchange_class (array ( 'apiKey' => 'YOUR_API_KEY', 'secret' => 'YOUR_SECRET', 'timeout' => 30000, 'enableRateLimit' => true, )); $poloniex_markets = $poloniex->load_markets (); var_dump ($poloniex_markets); var_dump ($bittrex->load_markets ()); var_dump ($quoinex->load_markets ()); var_dump ($poloniex->fetch_order_book ($poloniex->symbols[0])); var_dump ($bittrex->fetch_trades ('BTC/USD')); var_dump ($quoinex->fetch_ticker ('ETH/EUR')); var_dump ($zaif->fetch_ticker ('BTC/JPY')); var_dump ($zaif->fetch_balance ()); // sell 1 BTC/JPY for market price, you pay ¥ and receive ฿ immediately var_dump ($zaif->id, $zaif->create_market_sell_order ('BTC/JPY', 1)); // buy BTC/JPY, you receive ฿1 for ¥285000 when the order closes var_dump ($zaif->id, $zaif->create_limit_buy_order ('BTC/JPY', 1, 285000)); // set a custom user-defined id to your order $hitbtc->create_order ('BTC/USD', 'limit', 'buy', 1, 3000, array ('clientOrderId' => '123'));
======================================================================
分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程： java比特币开发教程 ,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Java代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Java工程师不可多得的比特币开发学习课程。 php比特币开发教程 ,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Php代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Php工程师不可多得的比特币开发学习课程。 java以太坊开发教程 ,主要是针对java和android程序员进行区块链以太坊开发的web3j详解。 python以太坊 ,主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。 php以太坊 ,主要是介绍使用php进行智能合约开发交互,进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。 以太坊入门教程 ,主要介绍智能合约与dapp应用开发,适合入门。 以太坊开发进阶教程 ,主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战,适合进阶。 C#以太坊 ,主要讲解如何使用C#开发基于.Net的以太坊应用,包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。 EOS教程 ,本课程帮助你快速入门EOS区块链去中心化应用的开发,内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点,最后综合运用各知识点完成一个便签DApp的开发。 tendermint区块链开发详解 ,本课程适合希望使用tendermint进行区块链开发的工程师,课程内容即包括tendermint应用开发模型中的核心概念,例如ABCI接口、默克尔树、多版本状态库等,也包括代币发行等丰富的实操代码,是go语言工程师快速入门区块链开发的最佳选择。
汇智网原创翻译,转载请标明出处。这里是原文 比特币与山寨币的数字货币交易库CCXT——CryptoCurrency eXchange 「深度学习福利」大神带你进阶工程师,立即查看>>>
12月6日,本期技术工坊,钟老师将以具体的项目实践和使用场景为基础,带大家探索以太坊的底层实现,深度解读以太坊,进一步思考区块链的未来。
1
时间地点
**时间：**12月06日 19:00 - 21:30
地点 ：深圳市南山区宝深路科陆大厦A座 8层
线下分享+交流 9.8元/人
参会人员要求：
1） 技术背景人员,对区块链开发有兴趣；
2） 活动限额30人,报满截止。
2
活动流程
19:00-19:30 签到
19:30-20:00 自我介绍
20:00-21:00 以太坊零手续费及其安全防御的实现
21:00-21:30 互动交流
3
分享主题及嘉宾
分享话题：以太坊零手续费及其安全防御的实现
分享大纲：
1、手续费的作用
2、零手续费的必要性
3、零手续费的实现
4、零手续费带来的安全问题及其解决方案
5、零手续费的副作用
分享嘉宾：钟瑞仙
十二年编程开发和网络安全防御经验,从事游戏行业多年,以太坊早期开发者,专注以太坊底层实现和DAPP应用,现任以太零研发团队技术总监,实现了MPOS共识机制、零手续费及其安全防御的以太零公链。
4
主办方及合作伙伴
5
报名方式
识别下图二维码或点击“ 阅读原文 ”即可报名参加。
「深度学习福利」大神带你进阶工程师,立即查看>>>
在本文中,我们将讨论通过 RSK 网络部署和交互 Smart-Contracts 智能合约。我们的合约将是一个基于OpenZeppelin库的ERC20代币,我们将把它直接部署到Mainnet中。
创建合约
我们需要做的第一件事就是知道如何使用 Truffle 。
当我们这样做 $ truffle init
在一个空文件夹中,除了创建配置文件外,我们还为项目和迁移合约创建了文件夹,以记录对同一合约的更改。
合约的 .sol 代码文件位于 ~/Truffle/contracts
迁移脚本在 ~/Truffle/migrations
已编译的合约在 ~/Truffle/build
测试合约在 ~/Truffle/test
我们现在只处理前两个文件夹。
在Truffle文件夹中,我们从 OpenZeppelin 导入库 $ npm install -E openzeppelin-solidity
这些库不仅会安装我们代币token的主要类库,还会安装所有权相关,安全数学运算和许多其他设施的库。值得一提的是,这些库已经过审核以实现高标准的安全性,因此依赖于它们的合约在正确使用时不易受到黑客攻击。
我们的库将安装在 ~/Truffle/node_modules/openzeppelin-solidity/contracts
之后,我们可以将库 ABCD.sol 导入到我们的合约中,如下所示： import 'zeppelin-solidity/contracts/token/ERC20/ABCD.sol';
要创建我们的ERC20代币,我们将从该存储库导入2个库： StandardToken.sol ,它具有代币的主要功能,并且已经更多地导入了一堆库,例如 SafeMath.sol ； Ownable.sol ,这些允许我们设置所有者对合约中的功能控制。
要继承库属性和函数,我们只需使用“is”关键字以这种方式将合约定义为 StandardToken 和 Ownable ： contract CoinFabrikToken is StandardToken, Ownable { }
之后,我们拥有这些库和导入库中的所有功能。
接下来,我们将代币的名称定义为 CoinFabrik ,这是它的符号,18个小数位,用于代币的精度（以太坊类网络中的标准,使我们有可能使用web3的以太转换功能）并将代币的初始供应量设置为1000,像这样： string public name = 'CoinFabrik'; string public symbol = 'CF'; uint8 public decimals = 18; uint public INITIAL_SUPPLY = 1000;
我们还将创建另一个字符串,一个与代币功能无关的非公共变量,以显示 Ownable 库属性的用法,该属性仅允许创建者与某些指定的函数进行交互。我们稍后会看到。
已经定义了我们的参数,现在是时候通过构造函数将它们分配给Token变量了。到目前为止,构造函数被定义为一个与智能合约同名的函数,但是从现在开始,将会有一个名为 constructor() 的函数,它将替换旧方法。如果你像以前一样调用构造函数,Solidity编译器将发出警告。
INITIAL_SUPPLY 乘以小数精度的次方将分配给 BasicToken 合约的 totalSupply_ ： totalSupply_ = INITIAL_SUPPLY * (10**uint(decimals));
并将它们存入创作者的帐户： balancesb [msg.sender] = totalSupply_;
有了这个,我们就可以使用一个简单而标准的代币,但正如我们所说,我们将使用 Ownable 合约添加一些功能。首先,我们将定义一些函数：一个修改我们的非公共变量的状态,但只有你拥有权限,而另一个函数返回字符串的消息。定义如下： function setON(string _n) public onlyOwner returns (bool) { Owner = _n; return true; } function getON() public view returns (string) { return Owner; }
两者都是公开的,所以任何人都可以尝试调用他们,但对于第一个,只有所有者的地址不会导致恢复。如果你是所有者并且调用了函数,则字符串将保存在我们的变量 Owner （带有大写字母）中,并且它还将返回一个我们可以在交易中检查的true值。
由于 Owner 变量不是公共的并且没有Getter,我们需要一个函数来返回变量的值而不改变区块链的状态。这是第二个功能。
我们还将创建一个回调函数,如果有人错误地调用我们的合约,则会发出事件： function () public payable { if (msg.value > 0) { emit Yes('Thanks for donating SBTC! :)'); } else { emit No('Error 404: Function not found :P'); } }
最后,我们在合约中添加了一个可销毁的功能,其中所有者是唯一可以执行它的人。
我们的简单代币已经完成。所有代码应该是一样的： pragma solidity ^0.4.17; import 'zeppelin-solidity/contracts/token/ERC20/StandardToken.sol'; import "zeppelin-solidity/contracts/ownership/Ownable.sol"; contract CoinFabrikToken is StandardToken, Ownable { string public name = 'CoinFabrik'; string public symbol = 'CF'; uint8 public decimals = 18; uint public INITIAL_SUPPLY = 1000; string Owner; event Yes(string); event No(string); constructor() public { totalSupply_ = INITIAL_SUPPLY * (10**uint(decimals)); balances[msg.sender] = totalSupply_; } function setON(string _n) public onlyOwner returns (bool) { Owner = _n; return true; } function getON() public view returns (string) { return Owner; } function () public payable { if (msg.value > 0) { emit Yes('Thanks for donating SBTC! :)'); } else { emit No('Error 404: Function not found :P'); } } function destroy() public onlyOwner { selfdestruct(owner); } }
创建迁移
对于每个合约,我们需要告诉Truffle哪个合约是我们想要部署的合约以及我们可以在哪里找到合约。这是通过 /Truffle/migrations 文件夹中的迁移文件完成的。
迁移脚本 02_deploy_token.js 应如下所示 var CoinFabrikToken = artifacts.require("./CoinFabrikToken.sol"); module.exports = function(deployer) { deployer.deploy(CoinFabrikToken); };
我们已配置Truffle,我们的节点已同步,我们的合约已经编写并且我们的迁移已配置,完成部署就是个时间问题。
部署
如果我们之前停止了我们的节点,我们将恢复在线状态,然后我们将与Truffle连接： $ sudo service rsk start $ cd ~/Truffle/ && truffle console --network rsk
之后编译合约： truffle(rsk)> compile --all
不应该对我们的合约有任何错误或警告。然后我们转移合约： truffle(rsk)> migrate --reset
为了节约时间,我们可以在一行中执行两个命令 truffle(rsk)> migrate --all --reset
将首先部署迁移合约。Truffle为我们提供了每个操作的交易哈希,因此我们可以稍后检查详细信息或日志。这是我收到的完整输出 truffle(rsk)> migrate --all --reset Compiling ./contracts/CoinFabrikToken.sol... Compiling ./contracts/Migrations.sol... Compiling zeppelin-solidity/contracts/math/SafeMath.sol... Compiling zeppelin-solidity/contracts/ownership/Ownable.sol... Compiling zeppelin-solidity/contracts/token/ERC20/BasicToken.sol... Compiling zeppelin-solidity/contracts/token/ERC20/ERC20.sol... Compiling zeppelin-solidity/contracts/token/ERC20/ERC20Basic.sol... Compiling zeppelin-solidity/contracts/token/ERC20/StandardToken.sol... Writing artifacts to ./build/contracts Using network 'rsk'. Running migration: 1_initial_migration.js Deploying Migrations... ... 0xf00d4ecf2b5752022384f7609fe991aa72dda00a0167a974e8c69864844ae270 Migrations: 0x1dc2550023bc8858a7e5521292356a3d42cdcbe9 Saving successful migration to network... ... 0x3e759e8ff8a7b8e47a441481fa5573ccf502b83f3d591ad3047e622af0f9169e Saving artifacts... Running migration: 2_deploy_token.js Deploying CoinFabrikToken... ... 0x300c8bb1e434e2aa4b13dcc76087d42fcbe0cb953989ca53a336c59298716433 CoinFabrikToken: 0xc341678c01bcffa4f7362b2fceb23fbfd33373ea Saving successful migration to network... ... 0x71771f7ee5d4e251e386979122bdda8728fa519d95a054572751bb10d40eb8c5 Saving artifacts...
如果我们检查交易,我们可以计算所有部署过程的gas成本。在我这里的情况,它是2340788gas（277462+42008+1994310+27008）。
因此将其更改为真实的SBTC,我们得到2340788*183000000/10^18=0,000428364 SBTC。在撰写本文时,这大约是4美元左右。
我们的合约现在部署在0xc341678c01bcffa4f7362b2fceb23fbfd33373ea。
恭喜！
与合约互动
通过Truffle迁移给出的地址,以及合约的ABI,我们创建了一个实例,因此简化语法更容易处理函数。为此,在我们部署之后,我们写了 truffle(rsk)> var cfToken = web3.eth.contract(CoinFabrikToken.abi).at(CoinFabrikToken.address)
如果合约已经部署,并且知道它的地址和ABI,我们就可以做到 truffle(rsk)> var cfToken = web3.eth.contract(‘Contract_ABI’).at(‘Contract_ADDRESS’)
其中 Contract_ABI 是简化为一行ABI, Contract_ADDRESS 不需要解释。
我之前创建了2个帐户,现在为方便起见,我们将它们重命名： truffle(rsk)> var acc0 = web3.eth.accounts[0] truffle(rsk)> var acc1 = web3.eth.accounts[1]
acc0 是部署合约的人。 Acc0 被添加到 truffle.js 和 node.conf 配置文件中。
所有权控制
我们将首先使用我们讨论过的库来测试合约的所有权功能。
如果我们从任何帐户调用 getON 函数,只要它是公开的并且没有任何所有权问题,我们就会得到： truffle(rsk)> cfToken.getON() ''
现在,setON函数具有所有权属性。任何来自其他帐户的交易都将被驳回。例如,我们看到,试图用我的名字从 acc1 签订合约不会改变它的价值。 truffle(rsk)> cfToken.setON('Andres Bachfischer', {from: acc1}) 0x5f115190b60238240bedf36d1c5bb69a443a0f8ee971b0fc40fe5ca9c727d47c
使用交易的哈希,我们看到返回的值为false,并且函数未正确执行。再次调用getON函数,我们看到变量没有改变它的值。
现在签署相同的交易但是从所有者的帐户acc0,我们得到状态'0x01'并且该功能正确执行。 truffle(rsk)> cfToken.setON('Andres Bachfischer', {from: acc0}) 0x0c894fa7e5369573fb14addeaed4cd9d5b6cd1425cb4eeeae16cb4e1fa8e0364
再次调用函数 getON ,我们看到所有权库按照我们希望的那样工作。 truffle(rsk)> cfToken.getON()
Ownable.sol 还具有允许我们将合约所有者更改为其他地址的功能。我们不会用它。然而,它的用法如下： truffle(rsk)> cfToken.transferOwnership(acc1, {from: acc0})
有了这个,acc1将成为合约的新所有者。
让我们转到代币。
代币操作
我们要做的第一件事是检查在创建合约时是否正确分配了代币的余额。
我们检查每个帐户的余额如下： web3.fromWei(cfToken.balanceOf(acc0).toString(10)) // = ‘1000’ web3.fromWei(cfToken.balanceOf(acc1).toString(10)) // = ‘0’
因此,我们可以看到所有代币都已正确分配到我们的初始帐户。
我们要做的第一笔交易是将一些代币转移到第二个帐户 acc1 ,进行三次。
为第一笔交易这样做： truffle(rsk)> cfToken.transfer(acc1, web3.toWei(88.8), {from: acc0}) 0xd45437b777f1430e7cec57bd80b261ce8f87bf8a3f9a113fecd20563403c4d9c
truffle(rsk)> web3.fromWei(cfToken.balanceOf(acc0).toString(10)) // = '733.6' truffle(rsk)> web3.fromWei(cfToken.balanceOf(acc1).toString(10)) // = '266.4'
我们看到从我们的部署帐户中获取的代币与在acc1中收到的代币数量相同。
使用 StandardToken 合约,我们还获得了代表某个帐户（在本例中为acc1）支出代币的权限。如果我们想在获得批准之前执行此操作,则交易将失败（状态为“0x00”） truffle(rsk)> cfToken.transferFrom(acc1, acc0, web3.toWei(5), {from: acc0}) 0x5cee7cf60849283a0088d71483a606ba2101b500e13f972abada4f75781596bf
检查后, acc0 不允许从 acc1 发送： truffle(rsk)> web3.fromWei(cfToken.allowance(acc1, acc0, {from: acc0}).toString(10)) // = '0'
我们授权 acc0 从 acc1 的交易中以 acc1 的名义花费10个代币： truffle(rsk)> cfToken.approve(acc0, web3.toWei(10), {from: acc1}) 0x6e1a202f4ca7f43dfb28034952d54a572993b986a55857790aa51854afbc1fb4
在输出日志中,我们看到函数已成功完成,并且日志显示允许 acc0 用于支出的金额。检查allowance： truffle(rsk)> web3.fromWei(cfToken.allowance(acc1, acc0, {from: acc0}).toString(10)) // = '10'
现在,如果我们再次执行支出交易： truffle(rsk)> cfToken.transferFrom(acc1, acc0, web3.toWei(5), {from: acc0}) 0x41f750eabb6e0d3ab576aac0333b0d337ca61808aae1eeafa9d8e2a0b81b979b
我们得到状态为“0x01”的成功交易。
再检查一下余额： truffle(rsk)> web3.fromWei(cfToken.balanceOf(acc0).toString(10)) // = '738.6' truffle(rsk)> web3.fromWei(cfToken.balanceOf(acc1).toString(10)) // = '261.4'
最后,如果我们签署一个调用不可用函数的事务,我们将调用我们的回退函数。 签署一个像这样的交易： truffle(rsk)> web3.eth.sendTransaction({from: acc0, to: cfToken.address}) 0x4106a287fc60669bf9682a73ec4c457b094c086ec7408a5dea95d200688c4ee9
将返回一个日志,其数据表示字符串 Error 404：Function not found：P （十六进制: '0x00 ... 00204572726f72203430343a2046756e6374696f6e206e6f7420666f756e64203a50' ）。
我们的最后一个功能,即我们不会因为显而易见的原因而执行,就是销毁功能。我们需要合约不被销毁才能显示交易。要调用,所有者应该这样做： truffle(rsk)> cfToken.destroy({from: acc0})
结论
在演练的第二部分中,我展示了在RSK网络中开发简单智能合约的示例。 我们已经看过： 从OpenZeppelin套件导入库和合约, 使用这些库创建一个简单的代币, 配置Truffle的迁移过程, 将我们的合约部署到RSK主网络, 通过不同的账户与合约互动, 检查块的日志以获取有关事务的反馈。
正如我们所看到的,RSK网络用于Solidity Smart Contracts部署和交互的用法几乎与以太坊节点中的相同。当然,这仍然是一个测试网络,预计会出现问题和错误,主要是在节点中,但RSK Labs团队在他们出现时尽可能快地解决它们。随着时间的推移,将实现稳健性。
======================================================================
分享一些以太坊、EOS、比特币等区块链相关的交互式在线编程实战教程： java以太坊开发教程 ,主要是针对java和android程序员进行区块链以太坊开发的web3j详解。 python以太坊 ,主要是针对python工程师使用web3.py进行区块链以太坊开发的详解。 php以太坊 ,主要是介绍使用php进行智能合约开发交互,进行账号创建、交易、转账、代币开发以及过滤器和交易等内容。 以太坊入门教程 ,主要介绍智能合约与dapp应用开发,适合入门。 以太坊开发进阶教程 ,主要是介绍使用node.js、mongodb、区块链、ipfs实现去中心化电商DApp实战,适合进阶。 C#以太坊 ,主要讲解如何使用C#开发基于.Net的以太坊应用,包括账户管理、状态与交易、智能合约开发与交互、过滤器和交易等。 EOS教程 ,本课程帮助你快速入门EOS区块链去中心化应用的开发,内容涵盖EOS工具链、账户与钱包、发行代币、智能合约开发与部署、使用代码与智能合约交互等核心知识点,最后综合运用各知识点完成一个便签DApp的开发。 java比特币开发教程 ,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Java代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Java工程师不可多得的比特币开发学习课程。 php比特币开发教程 ,本课程面向初学者,内容即涵盖比特币的核心概念,例如区块链存储、去中心化共识机制、密钥与脚本、交易与UTXO等,同时也详细讲解如何在Php代码中集成比特币支持功能,例如创建地址、管理钱包、构造裸交易等,是Php工程师不可多得的比特币开发学习课程。 tendermint区块链开发详解 ,本课程适合希望使用tendermint进行区块链开发的工程师,课程内容即包括tendermint应用开发模型中的核心概念,例如ABCI接口、默克尔树、多版本状态库等,也包括代币发行等丰富的实操代码,是go语言工程师快速入门区块链开发的最佳选择。
汇智网原创翻译,转载请标明出处。这里是原文 使用OpenZeppelin在RSK上进行ERC20代币开发 「深度学习福利」大神带你进阶工程师,立即查看>>>
WebAssembly, 简称WASM, 是一种以安全有效的方式运行可移植程序的新技术,其具有以下优势：
1. 性能高效：WASM采用二进制编码,在程序执行过程中的性能优越；
2. 存储成本低：相对于文本格式,二进制编码的文本占用的存储空间更小；
3. 多语言支持：用户可以使用 C/C++/RUST/Go等多种语言编写智能合约并编译成WASM格式的字节码
12月5日,本期技术工坊Bottos区块链底层系统工程师张伟老师将重点介绍WASM基本原理,着重探讨应用在区块链VM领域的技术改造要求。通过bottos案例,阐述改造过程重点要求和技术难点,以及未来发展方向。
1
时间地点
**时间：**12月05日 18:30 - 21:00
地点 ：（上海徐汇）上海市市辖区徐汇区龙华中路596号A308室
线下分享+交流 9.8元/人
参会人员要求：
1） 技术背景人员,对区块链开发有兴趣；
2） 活动限额15人,报满截止。
2
活动流程
18:30-19:30 签到,自我介绍
19:30-20:30 WASM应用区块链虚拟机的技术实践
20:30-21:00 互动交流
3
分享主题及嘉宾
分享话题：WASM应用区块链虚拟机的技术实践
介绍WASM基本原理,着重探讨应用在区块链VM领域的技术改造要求。通过bottos案例,阐述改造过程重点要求和技术难点,以及未来发展方向。
大纲：
1. WASM技术特点和优势
2. WASM 基本原理和执行过程
3. Bottos对WASM适应性改造
4. Bottos对wasm安全增强；
分享嘉宾：张伟
Bottos区块链底层系统工程师,负责Bottos区块链底层的研发设计工作,熟悉区块链的智能合约设计,区块链领域优秀技术专家。
在中兴、华为公司工作十多年,从事移动通信产品的研发设计工作,丰富的产品研发经验。
4
报名方式
识别下图二维码或点击“ 阅读原文 ”即可报名参加。
「深度学习福利」大神带你进阶工程师,立即查看>>>
针对 EOS、NEO 等大公链平台的多个双花攻击漏洞的案例,360 区块链实验室总结出了多种造成数字货币双花攻击的多种原因,并提出了一种通用的安全减缓措施。各种大公链项目实际上都产生过能够产生双花攻击之类的严重安全问题,盗取加密货币对黑客来讲不是难事。
而在几个月的区块链安全研究中,360 区块链实验室收到了来自各个项目方价值超过 30 万美金的数字货币漏洞报告奖励。
2008 年,中本聪提出了一种完全通过点对点技术实现的电子现金系统（比特币）。该方案的核心价值在于其提出了基于工作量证明的解决方案,使现金系统在点对点环境下运行,并能够防止双花攻击。如今比特币已经诞生十年,无数种数字货币相应诞生,但人们对双花攻击的讨论似乎仍然停留在比特币 51% 攻击上。实际上,我们的研究发现,实用的数字货币双花攻击还有很多种其他形式。在本文中,我们通过介绍我们发现的针对 EOS、NEO 等大公链平台的多个双花攻击漏洞,总结出多种造成数字货币双花攻击的多种原因,并提出一种高效的减缓措施。
1
工作量证明和双花攻击
2008 年,中本聪提出了一种完全通过点对点技术实现的电子现金系统,它使得在线支付能够直接由一方发起并支付给另外一方,中间不需要通过任何的金融机构。虽然数字签名部分解决了这个问题,但是如果仍然需要第三方的支持才能防止双重支付的话,那么这种系统也就失去了存在的价值。比特币的工作量证明机制 (PoW) 的本质,就是要使现金系统在点对点的环境下运行,并防止双花攻击。
工作量证明机制的原理如下：网络中每一个区块都包含当前网络中的交易和上一个区块的区块头哈希。新区块产生,其区块头哈希必须满足工作量证明条件（需要进行大量的哈希计算）。整个网络将满足工作量证明的哈希链连接起来,从而形成区块链。除非攻击者重新完成全部的工作量证明,否则形成的交易记录将不可更改。最长的区块链不仅将作为被观察到的交易序列的证明,而且被看做是来自算力最大的群体的共识。只要整个网络中大多数算力都没有打算合作起来对全网进行攻击,那么诚实的节点将会生成最长的、超过攻击者的链条,从而实现对双花攻击的抵抗。
双花攻击实际上是一个结果。如果一个攻击者 A 将同一个比特币同时支付给 B 和 C 两个用户,并且 B 和 C 两个用户都认可了这笔交易。那么我们说 A 将该比特币花了两次,A 实现了一次双花攻击。针对工作量证明机制的双花攻击中,51% 攻击是被讨论的最多的一种攻击形式。但针对工作量证明机制的双花攻击实际上有多种形式,包括芬妮攻击、竞争攻击、Vector76 攻击等。这些攻击实际上也得到了充分的关注和讨论,本文中不做赘述。实际上,实用的数字货币双花攻击还有很多种其他形式。下文中,我们将通过多个我们发现的多个安全漏洞,讨论多种数字货币双花攻击的多种原因,并提出一种高效减的缓措施。
2
双花攻击的新分类
智能合约平台,本质上是要在全网共享一个账本。这可以看成是一个分布式状态机复制问题。当前的账本状态,我们可以认为是 State_n。当一个新交易 Tx_ 产生的时候,Tx_ 将对 State_n 产生一个作用。从而使 State_n 状态过渡到 State_ 状态。这个过程我们可以用公式表示：
State_n × Tx_{n+1} → State_{n+1}
智能合约平台共识机制,本质上是将所有的交易【Tx_1 Tx_2 ……. Tx_n】按顺序作用到初始 State_0 上,使全网始终保持相同的状态。区块链中的每一个区块,实际上将交易序列【Tx_1 Tx_2 ……. Tx_n】按顺序拆分成不同的区块 Block1,Block2 并按顺序链接起来。在全网状态机复制的过程中,如果一旦因为某些原因产生了全网状态不一致,则我们可以认为全网产生了一个分叉。分叉被攻击者利用,可进一步实现双花攻击。
本文中,我们将我们发现的这些双花攻击漏洞分成 3 类： 验证不严格造成的双花攻击。 状态机 State_n × Tx_{n+1}→State_{n+1}不一致执行造成的双花攻击。 共识机制造成的双花攻击。
验证不严格造成的双花攻击,主要原因在于具体实现逻辑校验问题。比特币的漏洞 CVE-2018-17144 实际上就是这样一个漏洞。
状态机不一致执行造成的双花攻击,主要是由于智能合约虚拟机因为各种原因导致直接结果不一致,从而在整个网络中创造分叉,造成双花攻击。
共识机制漏洞可能产生整个网络的分叉,从而进一步造成双花攻击。人们常说的 51% 攻击,实际上就是 PoW 共识机制的分叉漏洞。
3
验证不严格造成的双花攻击
验证不严格造成的双花攻击,主要原因在于具体实现逻辑校验问题。这里我们介绍两个关于区块与交易绑定时校验不严格,从而产生双花攻击的漏洞。
在区块链项目中,一笔交易 Tx_1 被打包的某个区块 Block_1 中的方式如下：首先计算交易 Tx_1 的哈希值 Hash_1,然后用 Hash_1 与其他交易的哈希值 Hash_2…Hash_n 组合构成 Merkle Hash Tree。计算出哈希树的根节点 root,然后将 root 打包到 Block_1 中。这样即形成一笔交易与区块的绑定。一般来讲,除非攻击者能够攻破哈希函数的抗碰撞性,否则无法打破一笔交易与区块的绑定。如果攻击者能够打包交易与区块的绑定,则攻击者能通过造成全网的分叉从而实现双花攻击。下面我们介绍两个我们在 NEO 上发现的双花攻击漏洞：
3.1 NEO 虚拟机 GetInvocationScript 双花攻击漏洞：
区块链项目中,一个交易一般是由未签名的部分（UnsignedTx,交易要执行的内容）和签名的部分（交易的 witness）构成的。在如比特币之类的区块链项目中,交易的 hash 计算实际上是包含了该交易的签名部分的。而在如 NEO、ONT 等多种区块链平台中,交易的计算公式为 hash=SHA256(UnsignedTx)。即交易的哈希是由未签名的部分计算的来的,与交易的 witness 无关。而 NEO 智能合约在执行的时候,能够通过 Transaction_GetWitnesses 方法,从一个交易中获得该交易的 witnesses。其具体实现如下：
某个合约交易获得自己的 witness 之后,还能够通过 Witness_GetVerificationScript 方法获得该 witness 中的验证脚本。如果攻击者针对同一个未签名交易 UnsignedTx1,可以构造两个不同的验证脚本。则可以造成该合约执行的不一致性。正常情况下,合约的 VerificationScript 是由合约的输入等信息决定的,攻击者无法构造不同的验证脚本并通过验证。但是我们发现在 VerifyWitness 方法中,当 VerificationScript.length=0 的时候,系统会调用 EmitAppCall 来执行目标脚本 hash。
所以当 VerificationScript=0,或者 VerificationScript 等于目标脚本的时候,均可满足 witness 验证条件。即攻击者可以对于同一个未签名的交易 UnsignedTx_1,构造两个不同的 VerificationScript。攻击者利用这个性质,可以对 NEO 智能合约上的所有代币资产进行双花攻击, 其具体攻击场景如下：
步骤 1：攻击者构造智能合约交易 Tx_1（未签名内容 UnsignedTx_1, 验证脚本为 VerficationScript_1）。在 UnsignedTx_1 的合约执行中,合约判断自己的 VerficationScript 是否为 VerficationScript_1。如果为 VerficationScript_1,择发送代币给 A 用户。如果 VerficationScript 为空,则发送代币给 B 用户。
步骤 2：Tx_1 被打包到区块 Block_1 中。
步骤 3: 攻击者收到 Block_1 后,将 Tx_1 替换成 Tx_2(Tx_1 具有与 Tx_1 相同的未签名内容 UnsignedTx_1,但验证脚本为空) 从而形成 Block_2。攻击者将 Block_1 发送给 A 用户,将 Block_2 发送给 B 用户。
步骤 4：当 A 用户收到 Block_1 时,发现自己收到攻击者发送的代币。当 B 用户收到 Block_2 时,也会发现自己收到了攻击者发送的代币。双花攻击完成。
可见,该漏洞的利用门槛非常低,且可以对 NEO 智能合约上的所有代币资产进行双花攻击。危害非常严重。
3.2 NEO MerlkeTree 绑定绕过造成交易双花攻击漏洞：
智能合约交易与区块的绑定,通常通过 MerkleTree 来完成。如果攻击者能绕过该绑定,则能实现对任意交易的双花。这里我们看看 NEO 的 MerkleTree 的实现如下：
在 MerkleTreeNode 函数中,NEO 进行了 MerkleTree 叶节点到父节点的计算。但这里存在一个问题,当 leaves.length 为奇数 n 的时候。NEO 的 MerkleTree 会将最后一个叶节点复制一次,加入到 MerkleTree 的计算中。也就是说当 n 为奇数时,以下两组交易的 MerkleRoot 值会相等：
【Tx_1 Tx_2 …… Tx_n】
【Tx_1 Tx_2 …… Tx_n Tx_】其中 Tx_= Tx_n
利用这个特性,攻击者可以实现对任意 NEO 资产的双花攻击。 其具体攻击场景如下：
步骤 1：假设正常的一个合法 Block_1,包含的交易列表为【Tx_1 Tx_2 … Tx_n】。攻击者收到 Block_1 后,将交易列表替换为【Tx_1 Tx_2 … Tx_n Tx_】,形成 Block_2。然后将 Block_2 发布到网络中去。
步骤 2：一个普通节点收到 Block_2 后,会对 Block_2 的合法性进行校验。然而因为【Tx_1 Tx_2 … Tx_n Tx_】与【Tx_1 Tx_2 … Tx_n】具有相同的 MerkleRoot。所以 Block_2 能够通过区块合法性校验,从而进如区块持久化流程。NEO 本地取消了普通节点对合法区块中交易的验证（信任几个共识节点）。则 Tx_n 交易可以被普通节点执行两次,双花攻击执行成功。
可见,该漏洞的利用门槛非常低,且可以对 NEO 上的所有资产进行双花攻击。危害非常严重。
4
虚拟机不一致性执行
智能合约平台共识机制,本质上是将所有的交易【Tx_1 Tx_2 ……. Tx_n】按顺序作用到初始 State_0 上,使全网始终保持相同的状态。在状态机复制过程中,我们要求 State_n × Tx_èState_ 是决定性的。State_n × Tx_èState_ 实质上就是智能合约虚拟机对 Tx_ 的执行过程,如果智能合约虚拟机中存在设计或者实现漏洞,导致虚拟机不一致性执行（对相同的输入 State_n 和 Tx_,输出 State_ 不一致）。则攻击者可以利用该问题在网络中产生分叉和并进行双花攻击。下面我们介绍多个 EOS 和 NEO 上我们发现的虚拟机不一致执行漏洞和其产生原因。
4.1 EOS 虚拟机内存破坏 RCE 漏洞:
此前,我们公开了文章《EOS Node Remote Code Execution Vulnerability --- EOS WASM Contract Function Table Array Out of Bound》( http://blogs.360.cn/post/eos-node-remote-code-execution-vulnerability.html )。在该文中,我们发现了一个 EOS WASM 虚拟机的一个内存越界写漏洞,针对该漏洞我们编写的利用程序可以成功利用该漏洞使 EOS 虚拟机执行任意指令,从而完全控制 EOS 所有出块和验证节点。
究其本质而言,是在 State_n × Tx_{n+1} → State_{n+1}过程中。攻击者能让 EOS 虚拟机完全脱离原本执行路径,执行任意指令,自然可以完成双花攻击。 其攻击流程如下：
步骤 1：攻击者构造能够实现 RCE 的恶意智能合约,并将该合约发布到 EOS 网络中。
步骤 2：EOS 超级节点解析到该合约后,触发漏洞,执行攻击者自定义的任意指令。
步骤 3：攻击者实现双花攻击。
该漏洞的危害非常严重,且是第一次智能合约平台受到远程代码执行攻击事件。读者可以阅读该文章了解相关细节,在此不再赘述。
4.2 EOS 虚拟机内存未初始化造成双花攻击：
我们在编写《EOS Node Remote Code Execution Vulnerability --- EOS WASM Contract Function Table Array Out of Bound》的利用程序的过程中,还利用了 EOS 中当时的一个未公开的内存未初始化漏洞。在内存破坏攻击中,内存未初始化漏洞通常能够造成信息泄露、类型混淆等进一步问题,从而辅助我们绕过如 ASLR 之类的现代二进制程序的缓解措施,进一步实现攻击。然而在智能合约虚拟机中,内存未初始化漏洞有更直接的利用方式,可以直接造成双花攻击。以下为我们在 EOS RCE 中利用的一个内存未初始化漏洞的细节,其可以被用来直接实现 EOS 智能合约代币资产双花攻击。
当 WASM 虚拟机通过 grow_memory 伪代码来申请内存新的内存。在 EOS WASM grow_memory 最初的实现中,未对申请到的内存进行清零操作。该块内存的空间实际上是随机的（依赖于合约执行机器的内存状态）。则攻击者可以构造恶意合约,实现对 EOS 上任意合约资产的双花攻击。 其攻击流程如下：
步骤 1： 攻击者构造恶意智能合约。合约中通过 grow_memory 获得一块新的内存地址。
步骤 2：合约中读取该地址中的某个 bit 内容（此时该 bit 可能为 0,也可能为 1,依赖于合约执行机器的状态）。
步骤 3：合约判断该 bit 的内容,如果为 1 则发送代币给 A 用户,如果为 0 则发送代币给 B 用户,从而实现双花攻击。
4.3 EOS 虚拟机内存越界读造成双花攻击:
在传统的内存破坏中,内存越界读漏洞主要将会导致信息泄露,从而辅助我们绕过如 ASLR 之类的现代二进制程序的缓解措施,进一步与其他漏洞一起实现攻击。然而在智能合约虚拟机中,内存越界读漏洞有更直接的利用方式,可以直接造成双花攻击。下面为一个我们发现的 EOS 内存越界读漏洞,我们可以利用该漏洞实现双花攻击。
当 EOS WASM 将一个 offset 转换内 WASM 内存地址时,其边界检查过程如下：
在这里|ptr|的类型实际上是一个 I32 类型,它可以是一个负数。那么当： -sizeof(T) < ptr < 0
的时候,ptr+sizeof(T) 是一个很小的数可以通过该边界检查。在之后的寻址中,我们看到代码： T &base = (T)(getMemoryBaseAddress(mem)+ptr);
|base|的地址将会超过 WASM 的内存基址,从而让智能合约实现内存越界读（读到的内存地址内容取决于虚拟机当前执行状态,可被认为使随机的）。攻击者可以利用该漏洞实现双花攻击。 其攻击过程如下：
步骤 1： 攻击者构造恶意智能合约。合约中利用内存越界读漏洞,读取超越 WASM 内存基址的某个 bit）此时该 bit 可能为 0,也可能为 1,依赖于合约执行机器的状态）。
步骤 2：合约判断该 bit 的内容,如果为 1 则发送代币给 A 用户,如果为 0 则发送代币给 B 用户,从而实现双花攻击。
4.4 标准函数实现不一致造成双花攻击：
总结上面双花攻击两个例子的本质,实际上是 EOS 合约在执行过程中因为某些内存漏洞原因读取到了随机变量,从而打破了原本虚拟机执行的一致性,造成了双花攻击。事实上,合约执行的不一致性,不一定完全依赖于随机性。这里我们介绍一个因为各个平台（版本）对标准 C 函数实现不一致造成的双花攻击。
在 C 语言标准定义中,memcmp 函数的返回时被要求为：小于 0,等于 0,或者大于 0。然而各种不同的 C 版本实现中,具体返回的可能不一样（但依然符合 C 标准）。攻击者可以利用该标准实现的不一致性,造成运行在不同系统上的 EOS 虚拟机执行结果不一致,进而实现双花攻击。 其攻击流程如下：
步骤 1：攻击者构造恶意智能合约,在合约中调用 memcmp 函数,并获取返回值。
步骤 2：此时,不同的平台和版本实现 Memcmp 的返回值不一致（即使 EOS 虚拟机的二进制代码是相同的）。恶意合约判断 Memcmp 的返回值,决定转账给 A 或 B,从而完成双花。
该漏洞的具体修复如下：
EOS 强制将 memcmp 的返回值转换为 0,-1 或者 1,从而抵抗这种不一致执行。
Memcmp 这个问题,是同一种语言对相同标准实现的不一致性造成的。事实上,同一个区块链项目经常会有多个不同版本语言的实现。
不同语言对相同标准的实现通常也会有偏差,比如一个我们发现的因标准定义实现不一致造成不一致执行是 ECDSA 函数。ECDSA 签名标准中要求私钥 x 不为 0。如 python、JS 中的多个密码学库中对该标准由严格执行,但是我们发现部分 golang 的 ECDSA 库允许私钥 x=0 进行签名和验证计算,恶意攻击者利用该问题可以对同一个区块链平台的不同版本实现（比如 golang 实现和 python 实现）构造不一致执行恶意合约,从而进一步完成双花攻击。
4.5 版本实现不一致造成双花攻击：
同一个区块链项目经常会有多个不同版本编程语言的实现。不同编程语言的实现同样存在着各种这样的不一致执行的可能性。上面 ECDSA 是一个例子。大整数运算也是一个常见的例子。比如在曾经的 NEO 的 C# 版本实现和 python 版本实现中,大整数 (BigInteger) 除法运算可导致不同编程语言实现版本见的不一致执行现象,从而造成双花攻击。类似的现象在多个区块链项目中产生过。
4.6 其他问题不一致性问题
系统时间、随机数、浮点数计算等因素也是可以造成虚拟机不一致执行的原因。但是在我们的审计中,并没有发现此类漏洞在大公链项目中出现。多数区块链项目在设计之初就会考虑到这些明显可能造成的问题。
但可能造成不一致执行的因素可能远远超过我们上面发现的这些问题。事实上,一些主观因素（取决于机器当前运行状态的因素,我们称之为主观因素）都可能造成虚拟机的不一致执行。举个例子,比如在 4G 内存,8G 内存的机器在执行过程中产生内存溢出 (OOM) 的主观边界就不一样,攻击者利用 OOM 可能造成虚拟机的不一致执行。
5
共识机制造成的双花攻击
共识机制造成的双花攻击实际上是在业界中获得充分讨论的一个问题,然而各种公链方案在共识机制实现上仍然可能存在分叉问题,从而造成双花攻击。
5.1 ONT vBFT VRF 随机数绕过漏洞
Long range attack 是目前所有 PoS 共识机制都面临的一种分叉攻击方法。攻击者可以选择不去分叉现有的链,而实回到某个很久之前的链状态（攻击者在这个状态曾占有大量货币）,造一跳更长的新链出来让网络误以为是主链,从而完成双花。目前业界针对 Long range attack 并没有根本的解决办法,只能保证在“Weak Subjectivity”不发生的情况下,防止分叉发生。
ONT 的 vBFT 共识算法提出了一种依靠可验证随机函数（VRF）来防止恶意分叉扩展的方法。网络首先基于 VRF 在共识网络中依次选择出一轮共识的备选区块提案节点集,区块验证节点集和区块确认节点集,然后由选出的节点集完成共识。由于每个区块都是由 VRF 确定节点的优先级顺序的,对于恶意产生的分叉,攻击者很难持续维持自己的高优先级（如果攻击者没有控制绝大多数股权的话）,因此恶意产生的分叉将很快消亡,从而使 vBFT 拥有快速的状态终局性。
然而我们发现 vBFT 中的 VRF 实现存在一个漏洞,导致私钥为 0 的用户的可对任意区块数据生成相同的 vrfValue。具体的,vBFT 中的 vrf 是对由波士顿大学提出的 VRF 标准草稿 ( https://hdl.handle.net/2144/29225 ) 的一个实现。具体在该草案的 5.1 和 5.2 章节中,我们可以看到证明生成,和随机数计算的算法。如图：
漏洞在于 x=0 时候,此时从计算上 y 仍然为一个合法的公钥,且能通过 vBFT 实现中 ValidatePublicKey 的校验。gamma 为椭圆曲线上固定的点（无穷远点）。即对任意输入 alpha,该 vrf 产生的值为固定一个值。完全没有随机性。该问题可导致攻击者利用固定 vrf 破坏共识算法随机性,从而长期控制节点选举。
5.2 NEO dBFT 共识分叉
NEO 的 dBFT 共识机制,本质上可以看成是一个 POS+pBFT 方案。在原版 NEO 代码中,我们发现 NEO 和 ONT 在实现其 dBFT 共识机制的时候存在分叉问题。恶意的共识节点可以产生一个分叉块,从而造成双花的发生。具体细节可以参考我们之前的文章：《Analysis and Improvement of NEO’s dBFT Consensus Mechanism》( http://blogs.360.cn/post/NEO_dBFT_en.html ),在此我们不做赘述。
6
一种针对虚拟机执行不一致双花问题的高效减缓措施
对于校验绕过之类的逻辑漏洞和共识机制问题产生的双花漏洞,还是需要深入到业务逻辑中具体问题具体分析。这里我们提出一种针对虚拟机执行不一致的减缓措施。
一种简单的解决虚拟机执行不一致造成的双花问题的方法是由出块者将运行完交易后的全局状态 State_ 进行哈希散列,然后将该散列打包到区块中。普通节点在收到区块后,将本地运行完交易后的状态 State’_ 的哈希散列与 State_ 的哈希散列进行对比。如果相等,则说明没有分叉产生。然而由于本地数据是先行增长的,所以每次对全局状态进行散列计算的开销极大。针对这个问题,以太坊使用了 MekleTree 的结构来提高性能,同时应对分叉回滚问题。但以太坊的方案并不适用于采用其他数据结构存储状态信息的区块链项目。这里我们提出一种新的解决方案,其工作流程如下： 区块生产者在区块打包阶段,将该区块中所有的交易运行过程中的对数据库的写操作序列【write_db_1 write_db_2 …. write_db_n】记录下来,并计算该序列的哈希值 write_db_hash。 普通节点收到新的区块后,对区块进行校验。然后在虚拟机中执行交易。同时本地记录这些交易对数据库的写操作序列【write_db_1’ write_db_2’ …. write_db_n’】,然后计算 write_db_hash’。判断其与 write_db_hash 是否相等。如果相等,则认为没有不一致执行发生。如果不等,则拒绝对该写操作序列进行 commit。
本方法的核心思路在于,智能合约平台虚拟机执行不一致产生的原因在于：合约中各种功能函数和图灵完备性的支持中,可能引入多种不确定因素,从而造成执行不一致。各种各样复杂的小原因,可能导致这种不一致执行防不胜防。但是我们退一步看,双花攻击的本质是要对全局状态 State_ 进行修改,本质上就是一系列的简单写操作（简单的写操作往往并不会产生二义性）。要防止双花,只需要对所有的写操作序列进行匹配校验便可。本地对这些写操作进行匹配和记录的开销非常小,同时本地记录这些写操作序列,也方便应对分叉回滚等其他因素。
7
后记
在本文中,我们通过介绍我们发现的针对 EOS、NEO 等大公链平台的多个双花攻击漏洞的案例发现,总结出多种造成数字货币双花攻击的多种原因,并提出了一种通用的安全减缓措施。从上面的分析中,我们可以看到,区块链安全目前的形式仍然十分严峻。各种大公链项目实际上都产生过能够产生双花攻击之类的严重安全问题。我们的职业道德经受住了无数次的考验。 make a billion or work hard? Of course, work hard. 不过幸运的是,在几个月的区块链安全研究中,我们收到了来自各个项目方价值超过 30 万美金的数字货币漏洞报告奖励,感谢。hard work pay off。
本文中所有提到的漏洞均已被修复。在漏洞报告和解决的过程中我们发现 EOS 与 NEO 项目方对于安全问题处理专业高效,反应及时。项目安全性也一步一步得到完善。我们会继续关注和研究区块链相关技术的安全问题,推动区块链技术向前发展。 内容来源：360区块链实验室
作者:Zhiniang Peng
课程推荐
「深度学习福利」大神带你进阶工程师,立即查看>>> 原文题目： 《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》
原文作者： Ethan Buchman
翻译： 杜满想
校对： 饶云坤
本文为节选
Tendermint子协议
上一章中对Tendermint共识的介绍省略了有关用于广播区块（blocks）,投票(votes),交易(transactions)和其他节点信息的gossip协议的一些细节。之所以这样做是为了聚焦在共识协议本身,而不让工程实践的细节分散注意力。本章讲述一种特定的用来填充这些细节的方法,通过把这些组件实现为相对独立的反应器（reactors）,在这些反应器中每个对等连接（peer connection）是复用的。
P2P网络
在启动时,每个Tendermint节点都会收到一份需要拨号的对等节点的初始列表（initial list）。对于每个对等节点,节点会保持一个持久的TCP连接(persistent TCP connection),在该连接上以速率受限的方式复用了多个子协议（subprotocols）。消息被序列化为紧凑的二进制表示,并且通过认证的加密协议对连接进行加密。
本章的其余部分的每一小节分别描述了一个独立的反应器,该反应器在每一个对等链接进行了复用。有一个额外的对等节点交换反应器（peer exchange reactor）,该反应器允许节点彼此请求其他对等节点地址,并跟踪它们先前连接到的对等节点,以便保持连接其他对等点的最小数量。
共识Gossip
共识反应器（consensus reactor）封装了共识状态机(consensus state machine),用来确保当每个节点的状态发生变化时都向其所有对等节点广播其当前状态。以这种方式,每个节点跟踪所有对等节点的共识状态,只发送对等节点此刻需要的信息,或者对等节点没有的信息,以此来优化消息的gossip过程。对于每个对等节点,本地节点维护来两个例程（routine）来不断检查发送给对其等节点的新信息,即提议（proposals）和投票(votes)。信息应该以“第一稀有”（ratest first）的原则来最大限度地提高gossip的效率,并尽量减少某些信息变得不可用的概率。
区块数据
在上一章节中,假设提议信息是包含区块的。然而由于区块是从一个验证节点发出的,并且可以相当大,对于块提议节点来说把数据上传到所有其他节点的方式压力过大；如果把区块分成若干块后再广播出去会快很多。
一个常用来保证数据被安全广播的方法,就是利用Merkle树,此方法也被各种P2P协议所采用,具体方法就是允许每一段数据伴随一个简短的证明（原数据的对数级大小）,用来证明该片段是整体的一部分。为了使用这种方法,根据区块大小和验证者的数量,区块被序列化并分割成适当大小的块（chunks）,块（chunks）被散列成Merkle树。被签名的提议（proposals）不再包含整个区块,而是只包含Merkle的根哈希（root hash）,允许网络通过协作来广播被分割后的块（chunks）。节点每次收到块(chunks)时都会通知它的对等节点,来避免把同一个块对一个节点传输多次,以此来节省带宽。
一旦接收到所有块,就对块进行反序列化和验证,以确保它正确地指向前一个块,并且其各种校验和（用Merkle树实现）是正确的。虽然先前假定验证者在接收到提案（包括块）之前不预先投票,但是通过允许验证者在收到提案之后,在接收到完整的块数据之前进行投票,可以提升性能。这意味着预先投票到最后证明是无效的块也是可以的。不管怎么样,对一个无效区块进行预提交（pre-commit）被认为是拜占庭行为。
节点通过接受块（chunks）的方式同步到最新的高度,以一次一个区块的方式进行同步（progress one block at a time）。
投票
在共识状态机中,一个块被提议以后,节点就会开始等待投票（或者本地计时器过期）以往前推进。如果一个节点刚好进入了下一个区块高度的状态下收到一个对上一个块的pre-commits投票,而这个节点如果同时是这轮区块的提议者,它也许会把pre-commits投票当作下一个块的中的LastCommit值存入区块。如果一个对等节点（peer）已经预投票,但尚未预先提交,或者已经预先提交,但尚未进入下一轮,则其被分别发送预投票（pre-votes）或预提交(pre-commits)。如果一个节点是在同步区块的情况下,它将会收到在它当前的高度下预提交（pre-commits）。
内存池
交易独立地在内存缓存中被管理,这个缓存沿用比特币的叫法就是内存池。交易被业务逻辑验证合法后加入内存池,并用有序组播算法发送给相邻节点。一个节点会为每个相邻节点维持一个例程（routine）,用来确保发送交易的顺序是和自己处理的顺序是一致的。
块提议者会把内存池的有序交易列表中的交易打包进新的区块。一旦一个区块被确认提交,区块中的所有交易都会被从内存池中删除,而留下来的交易会被业务逻辑重新验证,因为账户中的其他交易被确认提交,导致它们的有效性也许会改变。
区块同步
共识反应器(consensus reactor)提供一种相对较慢的区块同步方法,这是为了实时共识而设计的,也就是说节点在处理下一个块之前,会等待接受到所有的信息来确认当下的一个块。为了适应一个节点远落后与当前高度的情况,有一个区块链反应器（blockchain reactor）,这个反应器允许节点同时并行地下载多个区块,使节点可以百倍于共识反应器的速度来同步区块数据。
当一个节点链接一个新的对等节点时,这个对等节点需要把它当前区块高度发送给对方。节点并行的从所有比自己高度高的对等节点中循序的请求区块,并下载区块加入到自己的区块池(block pool)。另一个例程不断尝试从池中删除块并通过验证和执行将它们添加到区块链中,一次两个块,相对于区块链的最新状态。必须每次同时处理两个区块,因为一个区块的提交确认被包含在下一个区块的LastCommit字段中。
节点持续的查询它所有对等节点的当前高度,同时不断的并行请求区块,直到同步到其所有对等节点的最高高度,一旦同步到最高高度就会停止请求区块,并开启共识反应器。
总结
实现Tendermint区块链涉及很多子协议。这些子协议包括包括gossip区块数据和交易的共识数据（投票和提议）,和新节点快速同步区块链状态的方法。
相关阅读：
区块链时代的拜占庭容错：Tendermint（一）
区块链时代的拜占庭容错：Tendermint(二)
「深度学习福利」大神带你进阶工程师,立即查看>>>
央行网站公布最近工作论文,徐忠和邹传伟在论文中表示,目前真正落地并产生社会效益的区块链项目很少,除了区块链物理性能不高以外,区块链经济功能的短板也是重要原因。
不要夸大或迷信区块链的功能,区块链应用要立足实际情况,目前区块链投融资领域泡沫明显。应在持续研究和试验的基础上,理性客观评估区块链能做什么、不能做什么。
目前区块链投融资领域泡沫明显,投机炒作、市场操纵甚至违规违法等行为普遍,特别是涉及公开发行交易的Token的项目。政府有关部门应加强监管,防范金融风险。
1
区块链的经济功能
论文中对区块链应用场景所属行业进行分类,比如Goldman Sachs（2016）。文章根据区块链应用对Token的使用情况提出一个新的分类方法,并讨论这些应用涉及的经济学问题。
区块链应用分成了4 类。
第一类应用不涉及 Token ,主要将区块链作为分布式数据库或去中心化数据库来使用。代表性案例是中国人民银行数字货币研究所的湾区贸易金融区块链平台和基于区块链技术的资产证券化信息披露平台。
第二类应用以 Token 代表区块链外的资产或权利 ,以改进这些资产或权利的登记和交易流程。代表案例是数字票据交易平台设计方案。
第三类应用以 Token 作为计价单位或标的资产 ,但依托区块链外的法律框架和主流经济合同。一个重要方向是所谓的稳定加密货币（stable token 或 stable coin）。
第四类应用试图用区块链构建分布式自治组织有从业者提出分布式自治组织能替代现实中公司的功能 。这方面至今没有广受认可的成功案例,主要受制于：公有链的物理性能不高,支撑不了大规模交易；智能合约的功能短板；oken 价格的高波动性限制了 Token 作为支付工具和激励手段的有效性；加密经济学（token economics 或 crypto economics）模型设计不合理等。
2
区块链的治理功能
区块链能支持一些有别于传统的治理机制。
比如,对分布式自治组织,不存在传统意义上的资产负债表,也不存在代表股东权益的股票,但可以通过智能合约赋予某些Token以收益权和治理权,其中收益权通过分红、回购等方式实现,治理权通过参与治理投票来实现。这类股权型Token还可以兼具功能属性,代表是一些加密货币交易所发行的所谓平台币。平台币持有者可以用平台币向加密货币交易所支付交易费用,有时还能享受打折的交易费用。平台币给予其持有者通过投票参与加密货币交易所治理的权利。加密货币交易所承诺定期拿出一定比例的利润,回购平台币并销毁。股权型Token与公司股票有显著差异。
但区块链存在一些不容忽视的治理短板。
第一,Token价格波动对基于Token的激励机制的影响 。在公有链的共识算法（特别是POS型）、分布式自治组织以及侧链项目中,出现了很多精巧的机制设计,用Token激励区块链有关参与者的行为趋向预期目标。如果Token价格波动性很高,期权估值也会很高,意味着需要给Token持有者很高的奖励才能激励他们锁定Token9。
第二,智能合约的功能短板使现实世界中一些普遍使用的治理机制很难移植到区块链场景中。
首先,在区块链内根据智能合约构造贷款、债券和衍生品等金融工具是比较困难的,而这些金融工具有重要的治理功能。因为不存在负债,分布式自治组织不存在破产问题（尽管其活跃用户数、经济活动量以及发行Token的价格可以趋零）,其发起者和运行者也不会像公司所有者和管理者那样面临来自债权人的约束。对分布式自治组织,也无法引入债转股和优先清算等条款。其次,对赌条款是保护投资者权益的重要手段之一,是投融资双方针对未来不确定情况（主要体现为融资方业绩）的一种约定。但因为去中心化预言机的缺失,很难可信地将区块链外的业绩信息写入区块链,也就很难用智能合约实现对赌条款。
第三,Token的快速变现机制影响了区块链项目投融资双方的利益绑定 。现实中很多投融资条款的前提是股权不能转让,股权的非流动性将投融资双方的利益绑定在一起,激励他们共同努力,直到公司上市后他们的股权才可能变现退出。
第四,链内治理（on-chain governance）和链外治理（off-chain governance）的结合问题 。链内治理的特点是地址匿名、去信任化环境以及智能合约自动执行,链外治理的特点是真实身份、诚信记录、重复博弈形成的信任和声誉、非正式的社会资本和社会惩罚以及正式的法律保障。两类治理能否有效结合,是一个复杂、有待进一步研究的问题。
3
区块链系统的性能和安全性
一些学者从经济学角度对区块链系统的性能和安全性做了有价值的研究。
第一,关于区块链的“三元悖论” ,即没有一个区块链系统能同时具有准确、去中心化和成本效率这三个特征。Abadi和Brunnermeier(2018)的理论分析表明,中心化账本具有准确性和成本效率,其维护者可以获得垄断租,特许权价值激励它们准确记账。分布式账本给予记账节点奖励以激励它们准确记账,但通过POW选出记账节点又牺牲了成本效率。信息在区块链分叉之间的可转移性以及“矿工”之间的竞争,会促成“分叉竞争”。“分叉竞争”有助于消除单个区块链系统享有的垄断租,但也可能带来不稳定性和不协调性。
第二,关于POW的利弊 。以比特币为代表的POW仍是区块链中占主流地位的共识算法,POS的安全稳定性还没有像POW那样经受长时间检验。Biais et al.(2018)认为,在基于POW的公有链中,随着“挖矿”总算力上升,“挖矿”难度将往上调,单个“矿工”对算力的投资将构成对其他“矿工”的负外部性。这样就会引发“挖矿”算力的“军备竞赛”,并造成“挖矿”领域的过度投资。Ma etal.(2018)的理论分析发现,比特币“矿工”可自由进入的安排,是比特币“挖矿”消耗资源的主要决定因素,而比特币算法内嵌的“挖矿”难度调整机制对“挖矿”消耗资源影响不大。
第三,POW“挖矿”的经济学问题 **,特别是交易费率的影响因素。**Houy(2014)从理论上研究了比特币“矿工”在打包交易时面临的经济学问题。一方面,打包的交易越多,“矿工”越有可能获得手续费。但一方面,打包的交易越多,区块越大,区块在分布式网络中传播并成为区块链共识所需的时间越长,就越有可能成为“孤块”。
第四,关于区块链的经济安全边界 。Budish(2018)从经受攻击的角度,研究了以比特币为代表的基于POW的公有链的安全性,并提出了若干提高安全性的经济激励措施。作者认为,这类区块链的经济重要性越高（比如,设想比特币市值接近黄金）,那么恶意攻击它们的可能性也越高,因此要对公有链的大规模应用持怀疑和审慎态度,企业和政府在数据安全方面有比公有链更便宜的技术。
4
真正落地并产生社会效益的区块链项目很少
总的来说,目前真正落地并产生社会效益的区块链项目很少,除了区块链物理性能不高以外,区块链经济功能的短板也是重要原因。应在持续研究和试验的基础上,理性客观评估区块链能做什么、不能做什么。
一是不要夸大或迷信区块链的功能 。这些年的行业实践已经证明一些区块链应用方向是不可行的。特别是,现代金融体系在发展过程中不断吸收各种技术创新。技术创新只要有助于提高金融资源配置效率以及金融交易的安全性、便利性,就会融入金融体系。迄今为止,还没有一项技术创新对金融体系产生过颠覆性影响,区块链也不会例外。加密货币供给没有灵活性,缺乏内在价值支撑和主权信用担保,无法有效履行货币职能,不可能颠覆或取代法定货币。区块链的匿名特征反而会增加金融交易中反洗钱（AML）和“了解你的客户”（KYC）的实施难度。但也要看到,我国的一些国情提供了实践区块链的机会,比如数字票据交易平台有助于缓解我国票据市场分散化的问题。
二是区块链应用要立足实际情况,不要拘泥于一些过于理想化的宗旨 。比如,用科技来替代制度和信任是非常困难的,在很多场景甚至就是乌托邦。再比如,去中心化与中心化各有适用场景,不存在优劣之分。现实中完全的去中心化和完全的中心化场景都不多见。很多区块链项目从去中心化宗旨出发,但后期或多或少引入了中心化成分,否则就没法落地。比如,区块链外信息写入区块链内,往往需要一个可信任的中心化机构,完全的去中心化是不可能的。
三是目前区块链投融资领域泡沫明显,投机炒作、市场操纵甚至违规违法等行为普遍 **,特别是涉及公开发行交易的Token的项目**。政府有关部门应加强监管,防范金融风险。 内容来源：每经网
作者: 徐忠、邹传伟
整理：区块链兄弟
课程推荐
「深度学习福利」大神带你进阶工程师,立即查看>>>
通用标准和新工程带来的网络效应
因特网又变了。
在过去的几十年里,基于互联网的服务朝着中心化的方向发展。今天,那少数几个大公司,掌握着我们用于信息搜索、存储个人数据、管理个人线上身份、公开或秘密交流的平台。
同时,一些看起来不相关的边缘科技正在发展,包括从加密信息到数字货币。 在松散的社区里,“Web 3” 成为了一个包罗万象的术语,描述了一个新一代更好的互联网 ：一个支付和资金为数字原生的互联网、一个”去中心化“应用程序与中心化应用程序竞争的互联网、一个用户能对自己的身份和数据有更多控制权的互联网。
然而,我们通常难以清楚的表达这一切意味这什么。Web 3 与之前的互联网时代有什么不同？什么是“去中心化”,为什么“去中心化”这么重要？这些新技术如何应用到实际当中？我们花了好几年的时间构建让区块链更具扩展性的基础架构,但谁会实际应用这些基础架构,用它们来干什么,以及为什么有人用？
**本文试图用清晰简单的语言解释 Web 3 的愿景。**我们将讨论构成 Web 3 项目的核心生动的理念,并调查三个主要趋势。
本文不是对未来的预测。未来不是固定的：我们必须做出正确的选择,才能得到我们想要的世界。本文的重点是描述一个可能的未来,一个足够吸引值得建设的未来,一个足够清晰让我们知道第一步怎么走的未来。
1
Web 3 变革
互联网之前已经经历过重大的换代,扩展了网路性能、功能和规模。网络已经从纯文本网站变为流媒体视频,从静态网页变为通过浏览器远程提供服务的功能齐全的应用程序,从仅有的几个服务器变为能推动现代政治和文化发展的全球社交网络。
随着网络的成熟,我们越来越多地依赖少数几家大公司。 谷歌打造了又快又方便的搜索引擎,控制了 74％ 以上的搜索流量。 Facebook 打造了非常受欢迎的社交网络,获得了 22 亿人线上身份的控制权。
Web 3 与之前的互联网换代 不同, Web 3 的核心不在于速度、性能或便利性。实际上,至少到目前为止,许多 Web 3 应用程序比现有产品更慢而且更不方便。
而 Web 3 关注的是所有权 ,是关于谁能 控制 我们天天都在使用的技术和应用程序的。它**打破了过去十年互联网发展的动态平衡：便利与控制之间的权衡。**我们已经习惯了这种状态,这似乎不可避免的：当然,上网就意味着被监视,当然,注册一个社交网络账号将意味着把个人数据卖给广告商或者会更糟。怎么还会其他办法呢？
Web 3 对这种说法是拒绝的 。我们可以在 不 把控制权交给那几个大公司的前提下,上网。上述动态平衡并不是网络的铁律,它只是当时可用技术的产物,也是我们在发展过程中做出的选择。
“Web 3”是一场构建不同技术并做出更好选择的改革。 我们不是试图 取代 现在的网络,而是在改变基础架构的同时保留我们喜欢的东西——是改革,而不是革命。
里面的项目看起来毫不相干,但它们都有一个共同的主题。 Web 3 是一套重组互联网控制权的技术 ,从金融项目（加密货币）,到基本通信技术（端到端加密消息传递）,到大众消费者用例（开放社交网络和P2P市场）,到互联网主要基础设施（去中心化 DNS）,Web 3都包括。
Web 3 不仅有加密货币,区块链以及其他加密经济产品产品,它包含任何改革集中式互联网的技术,让用户重新控制他们的数字世界。但我们认为这些技术是当今 Web 3 改革的最重要贡献者,因此本文将重点放在这些技术上。
2
Web 3 的三个趋势
在本文中,我们调查了三种趋势,并讨论了它们如何随着时间的推移而发展： 首先,货币将成为互联网的一个原生功能。 其次,“去中心化”应用程序将为用户提供新功能。 第三,用户将对他们的数字身份和数据信息有更多地控制权。
重要的是要记住,上述的趋势都是我的猜测。不可避免地,Web 3 将包含我们无法预测到的技术和应用,而且我们下面讨论的技术和应用将来可能会与我们今天能想象到的不一样。
2.1 货币
在 Web 3 中,货币将是互联网的一个原生功能。
在过去,互联网只是线下传统金融系统的门户。但加密货币本质上就是数字化的——发送一笔交易不需要与某些线下系统交互,它 仅仅 需要在网上发送一个消息。我们很快就会习惯,”钱“就是由网络产生的： 收付款现在是 任何软件 都可以做的事情,并且通过扩展,任何人有一部联网的手机就能完成。 数字支付将解锁以前无法实践的新商业模式。它们将大大降低某些交易（例如跨境汇款）的成本,实现新的用例（例如机器支付）,并可用于大型新市场（例如以前无法进入传统金融系统的人）。 一个由基本金融原语组成的生态系统——贷款、衍生品、交易所——提供了任何人都能使用的、更复杂的金融应用程序的基本构件。 随着技术人员对加密经济设计领域的探索,我们将创造 新的货币类型。我们才刚开始探索新货币,例如协议代币和不可替代数字资产。
加密货币之所以成为可能,是因为Satoshi发明了一种支持加密货币支付的网络,而且无需将控制权交给任何一家集中式的公司。比特币是 去中心化 的,因为它是由多个参与者“控制”的,包括从大型挖矿公司到个体节点运营者,再到核心协议开发者。他们都以不同方式、不同程度影响着整个网络,但没有一个个体拥有独占网络的权力。
“去中心化”已成为 Web 3 的核心理念 。但是,通常它更多地用作口号而不是精确的技术描述。去中心化可以指代各种各样的可能性。如果一个平台由20个实体控制,那么它是去中心化的吗？100个实体呢？或者1万个？ 我们考虑的是什么样的去中心化呢？
去中心化不是二元状态——它是一系列可能性的方向。说一个系统应该“去中心化”就有点像告诉工程师一座桥应该建得很“大”。毫无疑问,但它本身不是一个非常有用的信息——我们还需要知道你想要跨的河和你需要承受的负载。
**Web 3 的要点并不在于所有系统都应该尽可能地去中心化,而在于我们能够在去中心化上探索出更多的重点。**有用或者说必要的去中心化程度取决于具体的应用程序。比特币就是一个例子：其去中心化程度足以抵抗支付审查,且很难改变加密货币的基本参数,即通货紧缩的货币政策：比特币的总量是有限的。其他人尝试过创造类似的全球加密货币,对其他特征进行去中心化,例如 Dai 这样试图解决币值波动问题的稳定币。
因为比特币是第一个出现的加密货币,有人认为这是加密货币 唯一 可行的设计。结果,“加密货币”已成为某些对于货币的特定政治观点的同义词,例如通货紧缩货币的优点。
理解数字解密货币有许多可能的设计是非常重要的,不同的加密货币可能有不同的用途。 比特币神教认为,加密货币的目的是让人们选择加入他们喜欢的货币政策,其优势是不言而喻的。一个更为谦虚的解释是,加密货币的创新是,人们可以选择任何一种货币政策,什么样的政策都有可能。 他们所需要的只是一个互联网和一部手机。
2.2 去中心化应用和服务
现如今构成互联网的产品和服务往往由个别公司生产和控制。如果你用一个基于互联网的应用程序,很可能有个合法的实体在某个地方控制着它。这个公司会雇员工,确定优先功能,控制托管应用程序数据的服务器,并决定如何更新产品。
Web 3 的承诺是,可能还有其他选择。也许我们可以构建不受任何一家公司控制的产品和服务,但仍然具有与集中式公司相当的实用性。正如比特币一样,这些产品将是“去中心化”的,尽管不同产品的去中心化理由及其带来的好处可能会大有不同。
例如,想象一下,“去中心化发布平台”可能是什么样子。 这将是一个像 Twitter 或 Medium 这样的社交平台,允许用户分享内容、评论,并对他们喜欢的内容“点赞”。
这个平台有内置的激励机制,鼓励用户做出贡献。除了点赞,用户还可以互相发送小额支付,或者为他们想要支持的作者设置定期付款。最好的 Twitter 和 Medium 账户可以直接从平台中获得报酬,而不必通过其他方式来兑现其巨大的关注量。即使每点一个赞只值几美分,这仍然是对像 YouTube 这样的中心化平台的改进,在中心化平台中,每百万次浏览作者只能赚几千美元。在我们去中心化的平台上,没有任何一个中心实体能窃取用户交易的钱。平台甚至可以用通胀资金创造一个奖励池,奖励最高推送。
管理我们的去中心化服务的核心规则是在开源协议中定义的。用户使用他们选择的客户端软件与协议进行 交互。换句话说,会有各种各样的APP,虽然这些APP是由不同的人开发的,但都连到同一个社交网络中。这些客户端软件可能会提供互不相同的功能,但都符合相同的协议,类似于电子邮件客户端使用相同标准收发邮件的方式。
用户可以选择任何一种客户端,不同客户端可以实现不同的功能或三方服务。因为我们建立在去中心化协议的基础上,所以客户端开发者不需要寻求任何中心实体的同意,他们可以安心的构建他们的产品,而不必担心有一天他们的 API 访问会被撤销。用户无需等待 Twitter 公司添加新的反垃圾邮件或反骚扰功能,他们只需要选一个有这种功能的客户端即可。一个服务的生态系统正逐渐在开放协议的基础上发展,让用户可以做在 Twitter 上能做的一切,甚至比 Twitter 能做的更多。
**这说明了去中心化平台的一个被低估的好处：可持续的三方服务生态系统。**应用程序开发者可以在去中心化协议的基础 之上 构建有用的产品,而不用担心有一天他们的 API 访问将被关掉,因为没有人 可以 关了它。平台保持中立,这意味着会有更多的开发者在它上面将投入时间和金钱,开发属于自己的服务。Chris Dixon 的《为什么分布式重要》深入探讨了这一论点。
当然,我们仍将使用中心化公司创建的产品和服务。但这些公司也有可能减少他们对产品的控制 类型,将更多的控制权交给用户。
这在加密的消息通信 APP 中已经存在,其中像 Signal（由 Open Whisper Systems 打造的）这样的应用,这些应用看不到、也不保留任何客户通信。通过使用端到端加密方式设计他们的应用程序,他们有意 限制 了自己对用户的控制。
相比致力于“不作恶”的早期互联网初创公司,Web 3 公司有更高的目标,尝试并确保它们无法作恶——至少在特定的方面。Web 3包含一些技术,通过事先拒绝开发者的一些权力来限制他们对客户控制。这并不意味着我们不必在某种程度上信任中心化公司,但这意味着我们对他们的信任无需那么多。
2.3 用户对身份和数据的控制
在 Web 3 中,用户对他们的身份和数据有更多的控制权。
今天,我们的大多数线上身份属于其他人,比如 Gmail 地址或 Facebook 帐户。 Web 3 正在为个人控制线上身份奠定基础。
在某种程度上,这是加密货币基础架构构建的结果。持有加密货币要求持有私钥,数百万人会使用允许他们这样做的应用程序。**但是同样的技术可以让人管理任何基于区块链的数据,包括个人身份信息。**我们把这种 APP 叫做 “钱包” 并不是巧合,将来他们存的不仅仅是你的钱,还有你的 ID。
同时,Web 3 使得用户可以保留对自己数据的控制。首先,因为用户有选择使用自己身份而不是由第三方提供的权力,这样就限制了像 Facebook 这样的三方提供者捕获用户数据的机会。其次,由于去中心化服务的出现,意味着在某些情况下,当你用社交媒体、租房或者打车回家时,没有一家中心化公司能收集、存储、售卖你的信息。一般来说,我们将要用的大部分的系统平台收集不到我们的数据。
最后,Web 3 技术提供的新能力,即控制我们的身份和数据信息、以及全球可用的支付网络,将使得个人用户更容易获取内容的价值,使社交媒体公司成为10亿美元企业的价值。
你的数据因为它是有价值的。**而在 Web 3 中,是用户收集了这些价值。**如果你想卖掉你个人的浏览习惯数据,你可以直接卖掉,是你拿到这些数据信息的报酬,而不是像 Facebook 这样的公司。而且随着我们对数字资产所有权新机制的实验,个人用户会得到实际拥有他们每天用的技术的新方法——目前只有企业家、风险资本家和授权投资者才有机会。
3
结论
Web 3 不是不可避免的。上述对潜在未来的描述还面临许多障碍,其中一些可能永远无法克服。Web 3 中的一些要解决的问题： 企业家是否真的有动力去构建去中心化应用？谁给他们资金支持？现在,这些应用的盈利和风险回报的途径尚不明确,而传统的“中心化”商业模式更可靠。 去中心化 APP 会比中心化的差吗？由单个公司控制的 APP 可能具有更加一致的产品愿景,并且能快速的迭代更新。中心化 APP 可能会有更好的用户体验,更易于安装。 去中心化应用的加密组件对大多数用户来说是否太具有挑战性？用户如何以一种安全可恢复的方式管理私钥？如果不回到中心化的服务,这有可能吗？ 去中心化应用的使用成本会更高吗？低层次的去中心化系统（如文件存储、计算、可信数据喂养）是有许多冗余的。这些层会使去中心化的应用程序过于昂贵吗? 用“智能合约”构建的去中心化应用程序有意义吗？是否有可能编写永久性满足程序需求的“不可变”代码？如果我们要升级智能合约,那么谁来决定这些升级,它又与中心化应用程序有什么不同？ 如何“管理”去中心化系统？由拥有完全控制权的中心化公司进行决策,要比在一群拥有不同利益和优先级的参与者之间达成共识容易得多。基础层的治理将如何在不同的政治意识形态和文化下发挥作用? 是否有足够的用户真正关心隐私、个人数据的控制或开放金融服务的访问？还是说Web 3 的目标总是一个小众的关注点？ 政府和监管机构将对 Web 3 做出怎样的反应？实现新功能的技术不可避免的给人们带来紧张。Web 3 里包含避免审查和监管的技术,并且能用来逃避金融监管和执法。 Web 3应用程序所使用的底层区块链能够扩展到为数百万或数十亿用户服务吗？
即使有这些不确定之处,Web 3 也是一个有价值的未来愿景。**对于加密货币和区块链的爱好者的批评正中要害,我们不应该短视地把注意力集中在技术上,而应该放在技术可以解决的问题上。**加密货币和区块链本身不会自己结束：它们只有在解决问题时才是有价值的。Web 3 的愿景很有帮助,因为它使我们重新定位到这个问题：互联网已经变得过于中心化,需要开放。
关注 Web 3 的愿景而不是任何特定的技术也能帮助我们走出仅限于加密货币领域里的党派政治。Web 3 并不知道最终使用的是谁的平台,Web 3 的重点在于这种技术 在现实中能做什么,为人们解决了什么问题。
**以太坊和比特币可能会失败,但即使失败了,web 3 的愿景也不会消亡。**我们将使用过去 8 年来我们开发的应用知识体系——加密经济学——来构建新这些系统的新的更好的版本,这将持续下去。
Web 3 不会是一个乌托邦,我们不应该自我幻灭,认为它将会是乌托邦。如果非说有什么,那么过去 20 年应该已经教会了我们,技术不是什么灵丹妙药,人类面临的问题在互联网上同样也到处都存在。政治、权力与控制并没有随着网络的发明而消失,它们只是以不同的形式出现在网络中。
**Web 3 的承诺是,至少在这一次,对权力和控制权的限制是设计上的要求,而不是事后的补救。**我们有第二次机会来构建互联网,可能,不会有第三次机会了,所以让我们充分利用这次机会。 内容来源：公众号-以太坊爱好者
原文链接:
https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae
作者: Josh Stark、Pannshe Mahachi 和 Liam Horne
翻译&校对: 刘艳安 & Elisa
| 
.png)
大数据引擎.png)
大数据应用.png)
大数据底层技术.png)
ForeSpider软件
.png)
采集服务.png)
软件学习.png)
智能分析.png)
特征提取.png)
智能计算.png)
数据可视化.png)
数据分析应用.png)
系统集成服务.png)
代码工具.png)
金融方案.png)
制造业&物流.png)
企业数字化.png)
医疗方案.png)
政务方案.png)
实时监测.png)
智能分析.png)
数据智能挖掘.png)
全网自动采集.png)
场景智慧采集.png)
主题识别采集
022-2345 2937
185 2247 0110
business@forenose.com
022-2345 2937
185 2247 0110
business@forenose.com
前嗅大数据
津公网安备12010102001008号