Tendermint

搞了三个月联盟链，基本上算是告一段落，大概梳理下所做的东西，希望能对要做联盟链的人有所帮助。 在写这篇文章前，简单介绍下联盟链的功能。 国密和国际算法切换 参数toml配置 有币无币 支持Gmssl P2P的证书准入 委员会成员更新 Solc编译器 Tendermint共识 权限准入 交易校验 Rpc 状态存储 系统合约 加密算法 国密和S256,P256 支持国密sm2,sm3,sm4,国际的支持p256，比特币和以太坊都使用的s256.刚开始做的时候计算支持p256和国密，因为go sdk里面证书使用了p256。后在做的过程中发现国外证书很多还需要支持RSA，遂引入了gmssl，委员会中的PK公钥和证书做了分离。 统一的接口，外部调用同一签名验签方法 国密里面有个问题，无法 recover公钥 ，校验签名比较慢。 Toml文件配置 toml文件的优点在于不需要在启动的时候指定一系列参数 节点信息 网络ID 同步模式 委员会私钥 IP和端口 txpool gas门槛 txpool账户数 节点rpc端口api 存储目录 ipc websocket 开放api rpc 端口 p2p节点配置 证书 节点私钥 节点连接数 监听地址 创世区块 创世里面指定了 UseGas 指定有无币， KindOfCrypto 指定加密类型， PermisionWlSendTx ，

1. 前言 HotStuff提出了一个三阶段投票的BFT类共识协议，该协议实现了safety、liveness、responsiveness特性。通过在投票过程中引入门限签名实现了 O ( n ) 的消息验证复杂度。Hotstuff总结出对比了目前主流的BFT共识协议，构建了基于经典BFT共识实现pipeline BFT共识的模式。 HotStuff是基于View的的共识协议，View表示一个共识单元，共识过程是由一个接一个的View组成。在一个View中，存在一个确定Leader来主导共识协议，并经过三阶段投票达成共识，然后切换到下一个View继续进行共识。假如遇到异常状况，某个View超时未能达成共识，也是切换到下一个View继续进行共识。 Basic hotStuff基础版本的共识协议，一个区块的确认需要三阶段投票达成后再进入下一个区块的共识。pipeline hotStuff是流水线的共识协议，提高了共识的效率。 2. 协议内容 2.1. 协议基础 2.1.1. 名词解释 BFT: 全称是Byzantine Fault tolerance， 表示系统可以容纳任意类型的错误，包括宕机、作恶等等 SMR: 全称是State Machine Replication， 一个状态机系统，系统的每个节点都有着相同的状态副本 BFT SMR protocol:

区块链作为一种崭新的、颠覆性的技术，是国内外活跃的研究领域和毕业设计选题方向。本文列出最新的一组区块链方面的论文，希望可以对选择区块链毕业设计的同学们有所帮助，这是 汇智网 编辑整理的区块链毕业设计论文系列中的第22篇。 区块链开发教程链接： 以太坊 | 比特币 | EOS | Tendermint | Hyperledger Fabric | Omni/USDT | Ripple 本文整理了最新的可用于区块链毕业设计的参考论文，如果需要访问区块链毕业设计必读论文系列的最新文章，可以持续关注我们的 博客 ，或加入QQ群： 532241998 。 1、SoK：基于区块链的取证解决方案 当今社会数字化程度越来越高，随之而来的一个担忧就是如何应对日益增多的网络犯罪问题。执法部门和安全公司目前使用复杂的数字取证技术来分析调查网络犯罪。然而，由于大量证据的搜集和处理涉及到多方参与，这阻碍了数字取证正当性的实现。区块链技术已经被视为开发鲁棒的数字取证机制的可行方案。 本论文对现有的基于区块链的数字取证工具进行了综述和分类，并描述了这些工具的主要特性。论文作者同时对区块链技术和其他数字取证手段的关系以及其面临的挑战进行了详细的分析。基于各方面信息的综合，论文指出了目前存在的研究机会，并给出了进一步研究方向的建议。 论文PDF下载： SoK: Blockchain Solutions for

PBFT论文断断续续读了几遍，每次读或多或少都会有新的理解，结合最近的项目代码，对于共识的原理有了更清晰的认识。虽然之前写过一篇整理PBFT论文的博客，但是当时只是知道了怎么做，却不理解为什么。现在整理下思路，写一篇关于PBFT的理解。 1. 前提假定 1.1 同步模型 在分布式系统中谈论共识，首先需要明确系统同步模型是 synchrony , asynchrony 还是 partial synchrony ? synchrony : 节点所发出的消息，在一个确定的时间内，肯定会到达目标节点； asynchrony : 节点所发出的消息，不能确定一定会到达目标节点； partial synchrony : 节点发出的消息，虽然会有延迟，但是最终会到达目标节点。 synchrony是十分理想的情况，如果假设分布式系统是一个同步系统，那么共识算法的设计可以简化很多，在同步系统中只要超时没收到消息就可以认为节点除了问题。asynchrony是更为贴近实际的模型，但是根据 FLP Impossibility 原理，在asynchrony假定下，共识算法不可能同时满足 safety 和 liveness 。为了设计能够符合实际场景的共识算法，目前的BFT类共识算法多是基于 partial synchrony 假定，这在PBFT论文中被称为"weak synchrony"。

PBFT论文断断续续读了几遍，每次读或多或少都会有新的理解，结合最近的项目代码，对于共识的原理有了更清晰的认识。虽然之前写过一篇整理PBFT论文的博客，但是当时只是知道了怎么做，却不理解为什么。现在整理下思路，写一篇关于PBFT的理解。 1. 前提假定 1.1 同步模型 在分布式系统中谈论共识，首先需要明确系统同步模型是 synchrony , asynchrony 还是 partial synchrony ? synchrony : 节点所发出的消息，在一个确定的时间内，肯定会到达目标节点； asynchrony : 节点所发出的消息，不能确定一定会到达目标节点； partial synchrony : 节点发出的消息，虽然会有延迟，但是最终会到达目标节点。 synchrony是十分理想的情况，如果假设分布式系统是一个同步系统，那么共识算法的设计可以简化很多，在同步系统中只要超时没收到消息就可以认为节点除了问题。asynchrony是更为贴近实际的模型，但是根据 FLP Impossibility 原理，在asynchrony假定下，共识算法不可能同时满足 safety 和 liveness 。为了设计能够符合实际场景的共识算法，目前的BFT类共识算法多是基于 partial synchrony 假定，这在PBFT论文中被称为"weak synchrony"。

在本文中，我们将讨论通过 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 导入到我们的合约中，如下所示：

在这篇文章中，我们将了解同态加密的基本概念，介绍常用的同态加密开发库，学习同态加密应用开发的一般步骤，了解如何在Web应用中添加同态加密支持。 <!--more--> 区块链开发教程链接： 以太坊 | 比特币 | EOS | Tendermint | Hyperledger Fabric | Omni/USDT | Ripple 1、同态加密概述 同态加密改变了隐私保护的游戏规则，它允许直接操作加密数据而无需先进行解密。这一概念可以追溯到RSA加密 —— RSA也具备有限的同态加密功能。不过同态加密很长时间都局限在学术界，直到2009年Craig Gentry的论文发表后，才涌现了大量的同态加密库。 现在已经有很多可用的同态加密库了。下面列出了一些比较流行的同态加密开发包以及它们支持的方案类型，当然这个清单是不完整的： Microsoft SEAL: BFV, CKKS (C++) HElib: BGV (with GHS), CKKS (C++) PALISADE: BFV, BGV, CKKS, FHEW (C++) TFHE: Ring-variant of GSW (C++) HEAAN: CKKS (with bootstrapping) (C++) 为你的web'应用找到合适的同态加密开发包以及方案类型需要进行大量的研究工作： 这些不同的同态加密实现代码有什么区别？

原文题目： 《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》 原文作者： Ethan Buchman 本文为节选 客户端的考量 这章回顾了客户端的考量（consideration），该客户端直接与一个基于Tendermint的应用进行交互。 发现 网络节点发现机制(network discovery)是简单地通过TCP连接向种子节点拨号的方式进行。P2P网络使用了认证加密技术，然而验证者公钥需要通过带外数据验证。确实，在这些系统中，创世状态（genesis state）必须通过带外同步，理想情况下，这也是唯一需要进行通讯的数据，因为其已经包含了验证者在认证加密中使用的公钥，这与共识中用来签名投票的公私钥不同。 对于一个会随时间变化的验证者集合，可以通过DNS来注册所有的验证者，可以在他们真正成为验证者之前注册一个新的验证者，可以将它们作为验证者移出后将其删除。或者，验证者位置可以通过其他的拜占庭容错分布式数据存储来注册，包括可能的其他的Tendermint集群。 广播交易 作为一个通用的应用层平台，Tendermint提供了一个简单的接口用来为客户端广播交易。通用的范例是客户端通过代理连接到Tendermint共识网络中，代理既可以是本地的也可以是远端的。代理可以作为一个网络中的非验证者节点

原文题目： 《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》 原文作者： Ethan Buchman 本文为节选 性能和容错 Tendermint被设计为拜占庭容错的状态机复制算法。只要不超过总量的三分之一的验证人是拜占庭节点，就能保证网络的安全性，并且只要网络消息最终得到传递，即使对于gossiping提议的网络同步性假设很弱，它也能保持运行。在发生此类故障时，Tendermint共识的落实不会影响安全性，它会对性能产生最小的影响，并且可以快速恢复。 可以通过几种关键的方式来评估Tendermint算法的性能。最明显的衡量指标是块提交时间，它是衡量最终延迟的指标，也是衡量交易吞吐量的网络容量指标。我们在网络上收集每个分布在地球上的验证人节点的测量值，其中验证人的数量范围是2的倍数，从2到64。 概览 可以使用https://github.com/tendermint/network_testing 上的代码库重现本章中的实验。 所有实验都在t2.medium或c3.8xlarge的Amazon EC2实例上运行的docker容器中进行。 t2.medium有2个CPU和4GB RAM，c3.8xlarge有32个CPU和60GB RAM。 实例分布在七个数据中心，跨越五大洲。

原文题目： 《Tendermint: Byzantine Fault Tolerance in the Age of Blockchains》 原文作者： Ethan Buchman 本文为节选 软件实现 Tendermint采用Go语言实现，代码在https://github.com/tendermint/tendermint。Go是一个类C的语言，带有强大的标准库，可以很轻易的启动大量轻量级并发，并且提供了简单并安全的开发环境。 该代码使用了许多软件包，这些软件包足够模块化，可以作为自己的库进行隔离。这些软件包大部分由Jae Kwon编写，包含错误修复，测试以及作者提供的临时功能。以下小节将介绍这些软件包中最重要的软件包。 二进制序列化 Tendermint使用针对简单性和确定性而优化的二进制序列化算法。它支持所有整数类型（包括用一个字节长度前缀编码的varints），字符串，字节数组和时间（unix时间，精度为毫秒）。它还支持任何类型的数组和结构体（编码为有序值列表，忽略键）。它受到Go类型系统的启发，特别是它对接口类型的使用，它可以作为许多具体类型之一实现。可以注册接口，并且每个具体实现在其编码中给出前导类型字节。请在https://github.com/tendermint/go-wire中查看更多细节。 加密 诸如Tendermint之类的共识算法使用三种主要加密原语