block chain DAY 3¶
约 4729 个字 3 张图片 预计阅读时间 24 分钟
Consensus 基础¶
共识的定义：¶
- 普遍同意，达到一致。
- 由大多数相关方做出的判断。
- 共识算法协调系统节点，就应用程序输入（如日志、账本、值、命令、交易、区块）达成一致。
- 共识需要维护事件的全局顺序。
何时需要共识：¶
- 操作、事件的顺序。
- 复制日志的内容。
- 决定领导者。
- 写入分布式账本（DL）的区块和交易。
容错（Fault Tolerance）：¶
- 系统（节点）需要容忍故障，即在发生（部分）故障时仍能正常运行。
- 故障类型：
- 良性故障（Benign Failures）/CFT共识：服务器崩溃、消息丢失、重排序、重复。
- 应用：文件系统（HDFS、GFS）、数据库（Spanner、etcd）、领导者选举/协调（Chubby、Zookeeper）。
- 拜占庭故障（Byzantine Failures）/BFT共识：任意行为；故障节点（故意或无意）、节点可能撒谎、发送错误消息（不遵循协议、存在bug）。
- 应用：安全关键系统（指挥控制系统、飞机等）、分布式账本（Diem、CCF等）。
- 良性故障（Benign Failures）/CFT共识：服务器崩溃、消息丢失、重排序、重复。
系统故障示例：¶
* “蓝屏死机”：是一种崩溃故障。
* 通信线路中断、信号衰减、打猎“事故”（指物理线路被切断）：属于通信中断。
* 加密货币黑客攻击：
* Ronin Bridge攻击：损失6.24亿美元，原因是验证者节点被攻陷，攻击者控制了多数（5/9）验证者。
* Poly Network攻击：损失6.11亿美元，原因是智能合约漏洞导致访问控制不足，跨链消息存在关键错误。攻击者后来返还了资金。
* Wormhole攻击：损失3.2亿美元，原因是Solana VAA验证失败，未验证“守护者”账户，未打补丁的Rust智能合约被利用。
* 这些加密黑客攻击通常是由于协议设计问题、验证者被排除在验证集之外（协议缺陷）等引起。
PrestigeBFT：基于声誉的主动视图变更¶
问题：¶
传统基于领导者的BFT共识存在被动视图变更的问题。
- 当领导者节点崩溃时，需要等待超时才能发现，导致延迟。
- 如果新选的领导者日志落后于其他节点，需要先同步日志，进一步增加延迟。
- 拜占庭服务器可能会撒谎并启动选举活动。
目标：¶
在BFT中实现主动视图变更，节点可以主动竞选领导者，从而避免不可用或缓慢的领导者。
- 没有固定的领导者调度。
- 检测到领导者故障的节点可以启动选举。
- 只选举最新（up-to-date）的节点。
PrestigeBFT方案：¶
- 声誉机制：将节点行为转换为声誉分数，反映节点行为正确的可能性。
- 奖惩制度（受美国侵权法中的“威慑和赔偿”理论启发）：
- 惩罚（Penalization）：对每个竞选者施加惩罚。
- 补偿（Compensation）：奖励最新日志复制（计算增量日志响应度
δtx），奖励过去惩罚没有或仅逐渐增加的节点（计算过去视图变更中所有惩罚的Z分数δvc），并扣除惩罚。
- 效果：
- 行为良好（遵守协议）的节点获得高声誉，更有可能成为新领导者。
- 行为不端（可疑故障）的节点获得低声誉，更不可能成为新领导者。
- 逐步区分拜占庭服务器和正确服务器。
- 通过施加计算工作，随着时间推移抑制故障服务器。
主动视图变更协议的状态和转换：¶
- Follower（跟随者）可以触发视图变更（VC）。
- Redeemer（赎回者）计算声誉惩罚，可能超时并重复VC。
- Candidate（候选者）接收来自 \(2f+1\) 个服务器的投票，如果发现更高视图，则转换。
- Leader（领导者）接收投票，生成vcBlock，并将信息提供给Prestige BFT Reputation Engine。
性能：¶
- 正常运行下：PrestigeBFT在吞吐量方面优于SBFT、HotStuff和Prosecutor，性能提高约5.4倍。
- 节点数量影响：随着节点数量增加，PrestigeBFT的吞吐量和延迟变化与HotStuff类似，但总体性能更好。
- 故障下（攻击场景）：
- 静默参与者（Quiet participants）：不响应任何请求（类似崩溃故障）。
- 含糊其辞（Equivocation）：通过发送错误消息响应查询。
- 重复视图变更攻击（Repeated view-change attacks）：在非领导者时竞选领导者。
- 总结：PrestigeBFT是第一个用于BFT共识的主动视图变更协议，实现了鲁棒性和效率的独特结合。故障服务器在攻击后声誉下降，无法篡夺领导权。
V-Guard：动态成员变化的分布式账本设计¶
动机：¶
- 当前的BFT共识算法假设一个稳定的环境，即预先固定、静态的节点集合。
- 车联网（V2X）无法保证稳定环境，车辆会频繁加入/离开，在线/离线。
- V2X分布式账本必须能够在动态环境中运行，成员资格频繁变化。
车辆自动化的问题：¶
- 制造商的自动驾驶（Autopilot、SuperCruise）等数据仅由制造商收集，是中心化模式。
- 消费者对自己的数据访问受限。
- 中心化的数据处理造成数据垄断，损害数据完整性。
- V2X需求推动了以DL为中心的设计，通过共识保证数据完整性。
- 车辆固有可识别，因此适用于许可型DL。许多汽车制造商都在进行DL计划。
V-Guard设计理念：¶
- 将成员资格配置绑定到交易中。
- “展台（booth）”是描述符，指定一组参与车辆的成员配置。
- 展台组合器（Booth composer）准备一个有效展台队列，作为共识的目标（
<t1, B1, O1, Q1>：交易、展台、排序、法定人数）。
V-Guard架构：¶
- 基础设施层（Infrastructure Layer）：数据收集、网络。
- V-Guard框架（V-Guard Framework）：
- 共识模块（Consensus Module）：包含Ordering（排序）和Consensus（共识）子模块，并通过Booth Composer连接。排序与共识分离，可以在不同的展台中进行。
- 存储模块（Storage Module）：包含Temporary（临时）和Permanent（永久）存储。
- Gossip模块（Gossip Module）：包含Sender（发送者）和Receiver（接收者），用于进一步传播已提交的交易。
- 应用层（Application Layer）：分布式账本、证据链等。
性能：¶
- 峰值性能（静态排序、共识）：
- V-Guard的峰值吞吐量比HotStuff高22倍，比ResilientDB高9.5倍，比Narwhal高1.8倍。
- V-Guard的延迟显著低于HotStuff和ResilientDB。
- 动态性下的吞吐量/延迟：V-Guard在成员变化数量增加时，吞吐量下降幅度较小，延迟增加幅度也相对可控。
总结：¶
- V-Guard快速：将排序与共识分离。
- V-Guard动态：在动态变化的成员资格下运行。
- V-Guard多功能：适用于在不稳定网络（如间歇性连接）下运行的应用。
Prism协议：去中心化智能合约平台共识瓶颈的移除¶
背景：¶
- 现有许可链智能合约平台（如以太坊）的性能受限于共识层。
- 最长链协议（如比特币、以太坊所用）在保持高安全性的同时，存在吞吐量和延迟差的缺点，导致网络拥堵（例如CryptoKitties事件）。
- 去中心化金融（DeFi）应用的快速增长使得智能合约平台的性能扩展变得紧迫。
现有扩展方案：¶
- 改进虚拟机执行速度：优化操作码或设计新操作码（如Libra的MoveVM），或并行执行智能合约（通过锁或乐观并发+回滚）。这些方法有性能提升，但可能引入新的攻击，且未解决计量问题。
- 设计高吞吐量共识协议：
- 从无许可转向许可型共识（如Facebook的Libra/HotStuff、IBM的Hyperledger Fabric）。这些牺牲了无许可特性。
- Prism、OHIE、Algorand、Bitcoin-ng等协议也走这条路，但通常没有在这些协议上运行智能合约的实现。
- Plasma和分片（Sharding）：
- Plasma：链下扩容方案，是二级链网络，通过欺诈证明解决冲突。安全性较弱，易受“大逃亡”攻击。
- 分片：以太坊2.0、NEAR、Polkadot等采用，通过运行多个区块链实例并汇集它们来水平扩展吞吐量。安全性优于Plasma，但仍低于纯共识协议。
Prism的核心贡献：¶
- 一种新的工作量证明（PoW）区块链协议。
- 同时实现：
- 安全性：可抵御高达50%的恶意哈希算力攻击。
- 吞吐量：达到网络容量C的 \((1-\beta)C\) 吞吐量（接近最优）。
- 确认延迟：诚实交易的确认延迟与传播延迟D成比例，确认错误概率随带宽-延迟积指数级减小。
- 最终总排序：所有交易的最终总排序。
- 核心思想：通过将中本聪区块链分解为基本功能（交易提案、验证、确认），并系统地扩展这些功能以接近物理限制。
- 将区块分解为三种类型：提案者区块（proposer blocks）、交易区块（transaction blocks） 和 投票者区块（voter blocks）。
- 提案者区块树：锚定Prism区块链骨架，包含对交易区块和父提案者区块的引用链接。诚实节点在最长链上挖矿，但最长链不决定最终确认的提案者区块序列（领导者序列）。
- 投票者区块：在m个独立投票者链上挖矿，每个投票者区块通过引用链接投票给一个提案者区块。领导者区块是获得最多票数的提案者区块。
- 交易区块：包含交易，并由提案者区块引用。
- 解耦：通过解耦这些区块类型，Prism可以实现低延迟和高吞吐量，同时保持高安全性。
- 增加交易吞吐量：通过增加提案者区块指向的交易区块数量，而不影响安全性。
- 提供快速确认：通过增加并行投票树的数量，并行投票提案区块，从而提高投票率，直至达到光速延迟和极高可靠性的物理极限。
Prism的设计与实现：¶
- 用Rust语言实现了Prism全节点客户端，集成了EVM和MoveVM虚拟机。
- 架构：
- Prism共识模块：负责与对等节点交换区块，遵循Prism共识确认区块，并将确认的区块推送到VM执行器。
- Blocktree Manager（区块树管理器）：维护客户端的区块链视图，与对等节点交换区块，验证PoW，检查数据可用性，处理排序和交易签名，并将区块插入Prism区块树。
- Ledger Manager（账本管理器）：定期查询Blocktree Manager以获取新的确认区块，遵循Prism的确认规则，并将区块推送到VM执行器。
- Miner（矿工）：维护一个内存池，收集待处理交易并组装成新区块。通过泊松过程模拟挖矿，并将新区块广播给对等节点。
- VM Executor（虚拟机执行器）模块：维护已确认账本的状态数据库。接收来自Ledger Manager的确认区块，从区块中检索交易并顺序执行，更新状态。无效交易会被清理出账本。
- Prism共识模块：负责与对等节点交换区块，遵循Prism共识确认区块，并将确认的区块推送到VM执行器。
- 设计亮点：
- 确认机制：仅维护最后确认区块的状态，因为Prism以极高概率保证确认，且确认区块不太可能被取消。在收到新区块时，仅当区块被确认时才更新状态，并定期进行确认程序。
- 交易验证与状态更新解耦：Prism矿工不进行交易验证或状态更新。只有在区块被确认后，其中的交易才被验证，状态才相应更新。这与Hyperledger Fabric类似，但Prism是“order-execute-validate”范式，而Hyperledger Fabric是“execute-order-validate”范式。Prism的验证不需要背书，而是每个节点复制执行和验证。
- 无待处理交易交换：由于Prism的挖矿速率很高，矿工无需在对等节点之间交换待处理交易。交易区块直接广播，这减少了网络带宽的浪费，并有助于高吞吐量。
- 共识中的签名验证：将交易签名验证移至Prism共识模块中并行执行，减轻了VM执行器的负担，有助于提高吞吐量。
评估：¶
- 实验设置：在Amazon EC2上使用100个c5d.4xlarge实例，形成4-regular拓扑，引入120ms的传播延迟和300Mbps的速率限制。
- 应用程序：
- 基本应用：Native Payment（原生代币支付）、Do Nothing（空函数合约）。
- 基准应用：CPU Heavy（CPU密集型）、IO Heavy（IO密集型）。
- 实际应用：ERC20（以太坊代币标准）、CryptoKitties（计算密集型游戏）。
- 吞吐量和延迟（EVM Prism）：
- EVM Prism的吞吐量接近EVM Executor Only（单节点无共识）的85%，表明Prism移除了共识瓶颈，虚拟机本身成为瓶颈。
- Prism Consensus Only（无智能合约平台，原始交易吞吐量）的吞吐量很高（超过80K tx/s），说明如果虚拟机未来更快，Prism也能支持。
- 与以太坊的21 tx/s相比，Prism的吞吐量显著更高。
- 确认延迟：所有Prism实验（包括EVM Prism）的确认延迟不超过130秒，远低于以太坊（需要2670秒才能达到相似安全性）。
- 资源利用率：Prism共识模块使用多线程，VM执行器单线程。CPU平均使用率不超过50%。签名验证占用CPU时间高达39.2%。
- 区块数据：交易区块占总生成区块数据的71.2%，表明大部分带宽用于高吞吐量交易，Prism开销（提案者和投票者区块）很小。
- 吞吐量和延迟（MoveVM Prism）：
- MoveVM Prism的基本应用吞吐量（1.1K-2.2K tx/s）比EVM低一个数量级，但基准应用（CPU Heavy、IO Heavy）吞吐量高于EVM，表明MoveVM在执行指令方面更高效。
- MoveVM Prism的吞吐量接近MoveVM Executor Only的81%，再次确认Prism移除了共识瓶颈，虚拟机是瓶颈。
- 确认延迟与EVM Prism类似，不超过130秒。
- 资源利用率：内存使用低于3.2GB，CPU平均使用不超过32%，因吞吐量较小且签名验证更高效（MoveVM采用Ed25519签名，比EVM的ECDSA更快）。
- 可扩展性：
- Prism能够扩展到大量网络参与者（例如300个节点），只要底层点对点网络提供合理的区块传播延迟。
- 在100和300节点情况下，吞吐量和延迟非常相似，分叉率略有增加但仍可接受。
- 每个节点的资源利用率也相似。
总结：¶
- 区块链研究之前是模块化的，协议（尤其是共识）与上层应用（虚拟机、应用编程）分离。Prism协议受到中本聪比特币设计的启发，是一个完整的系统。
- Prism无缝集成了EVM和MoveVM，在多种应用中实现了接近最佳的虚拟机吞吐量。
- Prism不仅消除了裸金属吞吐量和延迟的共识瓶颈，而且在与两个流行智能合约平台交互时也做到了这一点。
- 未来智能合约性能的进一步提升需要虚拟机和编译器的新设计以及支持并行执行智能合约的架构。
Smart Contract Kill Switch¶
简单来说，智能合约的"自毁开关"是一个预先设定好的功能，允许合约的创建者或特定授权方在紧急情况下禁用或销毁合约。 想象一下，你开发了一个非常重要的软件，但万一软件出现严重漏洞或被恶意攻击，你需要一个紧急停止的按钮，对吧？"自毁开关"在智能合约中就扮演了类似的角色。
为什么需要"自毁开关"？¶
智能合约一旦部署到区块链上，通常是不可更改的。这意味着，如果合约代码中存在错误（bug）、安全漏洞，或者出现不可预见的紧急情况（比如，市场剧烈波动导致合约行为异常，或者被黑客攻击），传统的做法很难及时止损。
有了"自毁开关"，合约的管理者可以在以下情况下采取行动：
- 修复漏洞： 如果发现合约有重大安全漏洞，可以通过触发"自毁开关"停止合约运行，防止更多损失，然后部署一个修复后的新合约。
- 应对攻击： 在遭受恶意攻击时，可以迅速禁用合约，阻止攻击者进一步窃取资产或破坏系统。
- 紧急情况处理： 应对一些极端但未预料到的市场或外部事件，避免合约按照原定逻辑造成不可挽回的损失。
- 升级合约： 在某些设计中，它也可以作为一种升级机制的一部分，旧合约被禁用后，用户可以迁移到新合约。
"自毁开关"如何工作？¶
通常，"自毁开关"会作为智能合约代码的一部分进行编写。它会包含以下几个关键点：
- 触发条件： 只有满足特定条件才能触发。例如，只有合约的所有者（创建者）才能调用这个功能，或者需要多方签名才能激活（比如，需要3个密钥中的2个才能触发）。
-
执行动作： 一旦触发，合约会执行预设的动作。这可能包括：
- 阻止新的交易： 合约不再接受新的资金或操作。
- 将合约中的资产转移到安全地址： 将所有剩余的加密货币转移到一个安全的地址，防止被盗。
- 让合约无法执行： 使合约进入一个"锁定"状态，所有功能都无法使用。
- 销毁合约本身： 从区块链上移除合约代码，释放存储空间（这个操作在以太坊等区块链上被称为
selfdestruct）。
"自毁开关"的优缺点¶
优点：
- 增强安全性： 提供应对紧急情况的"安全网"，降低风险。
- 提高灵活性： 在一定程度上为不可更改的智能合约增加了可控性。
- 保护用户资产： 在遭受攻击时，可以及时止损，避免用户资产损失。
缺点：
- 中心化风险： 如果"自毁开关"的权限过于集中在一个人或少数几个人手中，可能会带来中心化风险。这些拥有权限的人可能会滥用权力，随意禁用合约，损害用户利益。
- 信任问题： 用户需要信任合约的创建者不会滥用这个功能。
- 复杂性增加： 设计一个安全且有效的"自毁开关"需要额外的代码和考虑，增加了合约的复杂性。
