seafooler的专栏

文章目录1. 写在前面2.两/三阶段共识中的锁定机制3.共识协议中Leader可信度的不同4.Single-modal类共识中锁定机制的设计4.1 对锁定机制中规则2活性的理解4.2 为什么Tendermint在进行leader切换的时候要等待Δ\DeltaΔ4.2.1 Tendermint不等待Δ\DeltaΔ导致的Hidden Lock问题4.2.2 为什么等待Δ\DeltaΔ可以解决Hidden Lock问题4.3 为什么HotStuff不需要等待Δ\DeltaΔ1. 写在前面在HotStuff的

文章目录1.写在前面1.1 前置阅读1.2 instance.skipInProgress字段2. 标记需要进行“状态同步”3. 启动“状态同步”操作4. retryStateTransfer函数的实现细节5. simpleConsumer.skipTo函数的实现细节参考文献1.写在前面1.1 前置阅读本篇博客是建立在之前一些博客的基础上。一切重复的知识介绍，笔者在这篇博客中就不再赘述了。因此，强烈建议读者先去阅读一下以下这几篇博客。Fabric中PBFT源码解读 （1）Fabric中PBFT

文章目录1. 写在前面1.1 前置阅读1.2 对TestCheckpoint函数的测试2. 对TestCheckpoint函数运行流程的解读2.1 Checkpoint和Water mark的概念解释2.2 sendPrePrepare函数中对sequence的检查2.3 Commit请求时生成Checkpoint2.4 recvCheckpoint函数的实现细节（1）2.4 recvCheckpoint函数的实现细节（2）3. 小结参考文献1. 写在前面1.1 前置阅读本篇博客是建立在之前一些博客的

文章目录0. 写在前面1. Prepare阶段为何需要2f+1?2. Commit阶段为何需要2f+1?参考文献0. 写在前面关于PBFT中为什么需要2f+1个Prepare/Commit的问题，网上其实有很多博客和文献来阐述，如这篇博客PBFT中的几个重要参数以及这本书"Introduction to reliable and secure distributed programming"。这些博客和文献大都采用了比较理论的证明方式，使用了Quorum的概念。即拜占庭网络中的Quorum值是2f+1

文章目录1. 写在前面：一个问题2. Prepared数据作为可执行证明3. 假设不存在Commit阶段4. Commit阶段如何解决上述问题参考文献1. 写在前面：一个问题我们首先来思考一个问题：对于BFT类型的共识，每个正确节点在执行一条交易（客户端发出的执行请求）之前中需要满足什么样的条件？或者说它应该在何时执行一条交易？笔者的理解是：它需要利用一个确切的机制/算法，去检查一种时机/条件。该算法保证满足了该时机/条件后，其他正确节点也会做出相应的执行操作，此时其便可执行该交易。这便暗含着一个要求

文章目录9. 节点对reqBatch的执行流程9. 节点对reqBatch的执行流程在上一篇博客中第7节的最后，我们介绍到节点在接收到execDoneEvent类型的Event后，将调用instance.execDoneSync()对该event对应的reqBatch进行执行。为方便后面的表述，我们假设reqBatch代表了一批交易。为方便读者理解，我们将相关代码再次摘录如下：// [pbft-core.go] ProcessEventfunc (instance *pbftCore) Proce

文章目录7. Commit消息的接收以及后续执行8. 测试的优雅结束7. Commit消息的接收以及后续执行本系列的第一篇博客介绍了源代码的获取和测试用例的选择；第二篇博客介绍了Primary节点对repBatch的处理，以及对PrePrepare消息的发送；第三篇博客介绍了Preprepare消息的接收以及Prepare消息的发送、Prepare消息的接收以及Commit消息的发送。强烈建议读者先阅读上述三篇博客，再来阅读当前这篇。第三篇博客的第6节介绍了节点2中对Commit消息的发送，本节介绍

5. Preprepare消息的接收以及Prepare消息的发送本系列的第一篇博客介绍了源代码的获取和测试用例的选择，第二篇博客介绍了Primary节点对repBatch的处理，以及对PrePrepare消息的发送。强烈建议读者先阅读上述两篇博客，再来阅读当前这篇。4.2小节介绍了节点0中Preprepare消息的发送过程，本小节介绍其他节点（以节点1为例）接收Preprepare消息的过程和发送Prepare消息的过程。由4.2小节的最后介绍可知，节点0的Preprepare消息最终发送到了节点1

文章目录4. Primary节点对repBatch的处理4.1 通道变量events和测试网络变量net4.2 Preprepare消息的发送过程4. Primary节点对repBatch的处理由上一篇博客Fabric中PBFT源码解读(1)的第3节可知，测试数据repBatch传入到了Primary节点（节点0）的events通道中。本节介绍Primary节点如何取出repBatch测试数据，并基于该数据构建及广播PrePrepare消息。在介绍Primary节点的操作之前，首先介绍两个非常重要的变

1. 写在前面笔者一直以来想学习一下PBFT的完整工程实践。但在网上搜了很多源码和博客，都没能找到一份比较独立且完整的PBFT实现。无奈之下，只能从Hyperledger Fabric的代码中学习其PBFT共识部分的代码。因此，接下来的系列博客中，笔者将介绍在Fabric中是如何实现PBFT共识算法的。1.1 源码版本及获取Fabric在0.6版本中采用了PBFT，因此在从github中clone了源代码后，需要首先切换到v0.6.0-preview分支。PBFT共识相关的代码主要包含在fabric

文章目录1. 前言2. 事实3. 解释4. 处理4.1. 如何让矿工不生成相同`TxID`的`coinbase`？4.1.1. `BIP30`4.1.1.1. 特殊情况的考虑4.1.2. `BIP34`4.2. 如何处理已有的两起事件？参考文献1. 前言我们知道，比特币中使用交易ID (TxID) 来作为交易在全网的唯一标识。在此语境下，绝大多数人都认为TxID一定是全网唯一的。2. 事实...

文章目录5. 构造解锁脚本5.1. `SignTxOutput`函数5.2. `PubKeyHashTy`类型的解锁脚本5.2.1. `ExtractPkScriptAddrs`函数5.2.1.1. `typeOfScript`函数5.2.1.2. `NewAddressPubKeyHash`函数5.2.2. SignatureScript函数5.2.2.1. `RawTxInSignature`...

文章目录5. 签名流程——源码层5.1. 特殊情况的处理5.2. 删除`OP_CODESEPARATOR`操作码5.3. `input`部分的通用处理5.4. 针对无修饰类具体类型的处理5.4.1. `SIGHASH_NONE`类型5.4.2. `SIGHASH_SINGLE`类型5.4.3. `SIGHASH_ALL`类型5.5. 针对有修饰类具体类型的处理5.6. 生成`message`5....

文章目录4. 签名流程——原理层4.1. 无修饰类4.1.1. `SIGHASH_ALL`类型4.1.2. SIGHASH_NONE类型4.1.3. SIGHASH_SINGLE类型4.2. 有修饰类4.2.1. `SIGHASH_ALL | SIGHASH_ANYONECANPAY`类型4.2.2. `SIGHASH_NONE | SIGHASH_ANYONECANPAY`类型4.2.3. `S...

文章目录1. 写在前面2. 签名流程简述2.1. 签名的数目2.2. 签名的对象3. 签名类型介绍3.1. 基本类型3.2. 组合类型3.3. 源码&字节码分析3.3.1. 定义3.3.2. 举例1. 写在前面在前面的比特币源码分析中，我们有意忽略了签名机制部分的介绍。但比特币的签名机制远非我们想象的那么简单，正如这篇博客Bitcoin contracts所言：Bitcoin a...

文章目录4.3. 创建input4.3.1. “创建交易”的请求4.3.2. 生成“创建交易”的请求4.3.3. txToOutputs函数4.3.3.1. makeInputSource函数4.3.3.2. NewUnsignedTransaction函数4.3.3.3. AddAllInputScripts函数4.3. 创建input前一篇博客btcd源码解析——交易创建中的4.2节介绍了...

1. 写在前面从本节开始，我们从源码层面关注比特币交易的构建过程。其中，我们尤其会关注比特币解锁脚本（为了使用UTXO）和新的锁定脚本（为了生成新的UTXO）的创建细节。我们相信通过跟踪两种脚本的创建过程，我们将对于比特币的交易细节理解得更为深入。新交易的创建会涉及到两个代码仓库（btcd和btcwallet）编译生成的三个可执行文件（btcd，btcctl，和btcwallet）。btc...

1. 写在前面一直觉得Ethereum相关的开发工具挺繁杂的，网上关于怎么“编写、部署和调用智能合约”的教程也比较多，但这些教程基本上都是基于truffle框架、geth终端等工具进行合约的部署的调用。既然web3只是nodejs环境下的一个JavaScript模块，我一直想通过最简单、纯粹的nodejs环境去直接使用web3，这样能够对web3模块有个比较立体的认识。于是，便有了这篇博文。为...

这里写自定义目录标题1.写在前面2. 实验环境1.写在前面因为学习的需要，这一年半和接下来更长的时间都会与Bitcoin打交道。不可避免地，需要对Bitcoin的源码进行修改。网上找过一些Bitcoin源码分析的资源，但大多都是基于C++实现的源码。笔者对C++并不是很熟悉，相反，用Go语言用得更多一些。所以，这个系列的博客会针对Go语言实现的Bitcoin进行分析，也即btcd。因为btc...

1. 写在前面我们从‘新区块的生成“开始我们的btcd源码之旅。2. 相关命令# start btcd./btcd -u seafooler -P 123456 --simnet --miningaddr=SRgBmewVAfaVzqKMPHeFYwkiAGD8jKBWFz# start btcwallet./btcwallet -u seafooler -P 123456 --si...

4.2 作为客户端的btcwallet我们接着上一篇博客，继续来讲解作为客户端的btcwallet是如何工作的。也即，作为客户端的btcwallet是如何与btcd进程交互的。// walletMain[btcwallet.go] -> rpcClientConnnectLoop[btcwallet.go]func rpcClientConnectLoop(legacyRPCServ...

文章目录1. 写在前面2. 从peer A发起数据请求开始1. 写在前面从这一篇博客开始，我们将介绍btcd节点之间的数据同步。考虑到内容太长，分为上下两篇博客来讲解。源码解析是基于btcd仓库c26ffa870fd817666a857af1bf6498fabba1ffe3的commit id 版本。我们假设peer B是先启动的节点，peer A后启动。peer A在启动后需要从peer...

文章目录1. 写在前面2. peer A 发送"获取区块头"的请求3. peer B 响应"获取区块头"的请求4. peer A 处理 "获取区块头"的返回数据5. peer A 发送 "获取区块"的请求1. 写在前面上一篇博客btcd源码解析——peer节点之间的区块数据同步 (1)中，我们介绍了peer A是如何发起数据同步的请求的，当时讲到存在两种模式：headersFirstMode模...

文章目录1. 写在前面2. 非headersFirstMode模式下的数据同步过程2.1 peer A 发送“获取区块哈希”的请求2.2 peer B 响应“获取区块哈希”的请求2.3 peer A 处理“获取区块哈希”的返回数据，并发送“获取区块”的请求2.4 peer B 响应“获取区块”的请求2.5 peer A 处理“获取区块”的返回数据3. 小结1. 写在前面上一篇博客btcd源码解...

1. 写在前面从这一篇博客开始，我们将介绍btcd节点之间P2P连接建立的过程。考虑到内容太长，分为上下两篇博客来讲解。这两篇博客之后，我们将继续介绍节点之间数据的同步过程。源码解析是基于https://github.com/btcsuite/btcd仓库c26ffa870fd817666a857af1bf6498fabba1ffe3的commit id 版本。2. 从节点的“启动”说起b...

文章目录4. 与其他peer建立P2P连接4.2 主动连接的管理4.2.1 negotiateOutboundProtocol函数4.2.2 peerDoneHandler函数4.3 被动接受连接4. 与其他peer建立P2P连接我们接着上一篇博客，继续来讲解P2P主动连接的管理和被动接受连接的过程。4.2 主动连接的管理前面介绍到Start [connmanager.go]函数中调用的c...

1. 写在前面前两篇博客headersFirstMode模式和非headersFirstMode模式主要介绍了区块数据同步过程中两个节点如何交互。但我们当时遗留下一个问题：在peer A接收到区块数据之后，是如何将这个区块存储到本地的。回忆我们在headersFirstMode模式的2.6小节最后提到的由于block的数据存储过程比较复杂，我们在后面会再写一篇博客介绍：从P2P连接中接收到的...