分类 行业报告 下的文章 - 六币之门

平行链起源：“平行链” 这个方案是如何产生的？ 这份文档主要描述了波卡平行链功能宿主的实现，主要针对的是波卡平行链宿主的实现者。该文档分为以下部分：1、平行链起源2、协议概览3、架构概览4、Runtime 架构5、Runtime APIs6、节点架构7、数据结构与类型本文是由 PolkaWorld 翻译的第一部分 “平行链起源”。有兴趣的同学可以在文末找到原文档来阅读和进一步了解。本文档旨在描述 Polkadot 的平行链功能宿主（为组成平行链提供安全性和先进性的软件）的目的、功能和实现。该文档不是针对特定平行链实现者，而是针对平行链宿主（Parachain Host）实现者。实际上，此文档通常是针对 Polkadot 的实现者的。还有其他一些文档更详细地描述了这项研究。所有参考文档都放在了该文档中，并应与本文档一起阅读，以便更好地理解全文。不过，这是唯一一份旨在描述 Polkadot 的特定实例关键因素，并将该研究拆解为了较底层的技术细节和软件结构的文档。平行链起源平行链是一种问题的解决方案。与任何解决方案一样，如果不首先理解问题，就无法理解它。因此，让我们从区块链技术所面临的问题开始，这些问题导致我们开始探索像平行链这样的设计空间。问题 1：可扩展性几年前，一个明显的现象是，比特币、以太坊和其他一些简单工作量证明（PoW）区块链的交易吞吐量太低。TODO：如果有更多的区块链会怎么样呢...？权益证明（PoS）系统可以实现比 PoW 区块链更高的吞吐量。PoS 系统由绑定的资本担保，而不是花费精力 —— 流动性机会成本 VS 燃烧电力。他们的工作方式是选择一组具有已知经济身份的验证人，他们锁定代币，以换取获得“验证”或参与共识过程的权利。如果发现它们错误地执行了这一过程，它们将被 slash 惩罚，这意味着部分或全部锁定的代币将被销毁。这对不良行为有很强的抑制作用。由于这种共识协议不会浪费资源，区块时间和协议可以更快地发生。PoW 挑战的解决方案不必在创建区块之前就找到，因此创建区块的成本减少到只需要创建和分发区块的成本。但是，要达成 PoS 链共识，就必须有大于三分之二的验证人对 Layer1 上发生的所有事情达成完全一致，所有逻辑都是作为区块链状态机的一部分执行的。这意味着每个人仍然需要检查所有的事情。此外，基于通过异步网络接收到的信息，验证人可能对系统有不同的看法，这使得就最新状态达成一致更加困难。平行链是分片协议的一个例子。分片是从传统的数据库架构中借鉴而来的概念。我们不是要求每个参与者检查每个交易，而是要求每个参与者检查交易的某个子集，这样就有足够的冗余，使得拜占庭式 (任意恶意的) 参与者无法悄悄混入无效的交易 —— 至少无法在不被检测到和被 slash 的情况下，将这些交易逆转。通过分片和权益证明的相互配合，即使没有所有参与者检查所有状态转换，平行链宿主也可以在许多平行链上提供全面的安全性。TODO：注意网络影响和桥接问题 2：灵活性/专业化“不聪明” 的虚拟机无法为你提供灵活性。任何工程师都知道，能够专业地解决某个问题会给他们和他们的用户带来事半功倍的作用。TODO：做到更加事半功倍认识到这些问题后，我们开始寻找解决这些问题的方案，这将允许开发人员在统一的安全来源下创建和部署特定目的区块链，并具有在它们之间传递消息的能力。这是一种异构分片解决方案，我们称之为平行链。阅读完整文档：https://w3f.github.io/parachain-implementers-guide/index.html

干货 | Eth1.x 术语表（上） 目录数据区块链历史状态见证数据节点类型P2P 协议数据Header（区块头）即以太坊协议所定义的 Header 对象。（译者注：区块头包含一个区块的元信息）Block（区块）一个区块由两部分数据组成：区块头Block Body（区块体）；区块体又由两部分内容组成：Transactions（交易，事务）Uncles（叔块信息）Block Body（区块体）就是一个区块中的事务和叔块信息的集合。事务即以太坊协议所定义的 Transaction 对象。（译者注：事务可视为触发以太坊协议状态变更的操作的基本单元）事务的构建创建一条完全签名的事务的过程：必须知道发起事务的 Account（账户）的 nonce（流水号）。一般来说需要使用 eth_estimateGas 方法来确定该事务需要使用的 gas 消耗量。需要该账户的私钥，用于生成数字签名。叔块信息即被该区块视作叔块的区块的区块头。（译者注：对于任一区块来说，叔块指的是那些上溯 7 代及以内、并非其祖先区块的有效区块；一个区块可标记两个叔块；标记叔块可使区块挖出者获得额外的 “侄块奖励”，也会使叔块挖出者获得奖励，奖励大小随叔块与侄块之间的代际距离递减；叔块内的所有事务视作没有上链，除非另一些区块中包含了这些事务，否则都回到待打包事务的内存池中）区块链历史Header Chain（全部区块头）所有历史区块的区块头的集合截至 2021 年 1 月 29 日，约有 1100 万个区块头截至 2021 年 1 月 29 日，全体区块头约占用 5 GB 的存储空间是验证其余大部分链数据所必需的数据如果使用 Header Accumulator（区块头累加器），我们将能证明某个区块头存在于主链上Block Body History（区块体历史）所有由事务和叔块信息所组成的历史区块的集合截至 2021 年 1 月 29 日，约有 1100 万个区块体截至 2021 年 1 月 29 日，所有区块体需占用约 120 GB 的存储空间Receipt History（收据历史）由历史事务所产生的所有收据的集合截至 2021 年 1 月 29 日，约有 10 亿条收据截至 2021 年 1 月 29 日，所有收据需占用约 60 GB 存储State（状态）所有账户及 contract storage（合约存储项）的集合账户由 Header.state_root 所代表的主状态树的一部分字段：balance/nonce/state_root/code_hash合约存储项每个账户的 Account.state_root 标识的单个存储值所有数据都以 0 - 2^^256-1 范围内的整数作为键 （该整数也被当作存储槽的序号）Contract Code（合约代码）合约代码仅使用 Account.code_hash 来指代；并非状态的显式部分。Archive State（归档状态）所有历史状态的集合。详见 Archive Node（归档节点）使用 Naive Database Layout，存储归档状态需占用约 7 TB 的存储使用一些基于 Flat Database Layout 的高级技巧，Trube Geth 客户端使用约 800 GB 实现了归档状态存储Recent State（近期状态）指作为 近期 状态根一部分的状态。“近期” 一般来说是 128～256 个区块内维护这一数据需要某种形式的垃圾回收技术，以清除不再是近期状态一部分的状态对象Cold State（冷状态）指的是很长一段时间没有被触及（访问 及 修改）的状态对象Database Layouts（数据库布局）Naive Database Layout该数据库实现将所有的状态对象都存储为单个的树节点，通过节点哈希值来访问导致性能低下以及高硬盘读写开销相对易于理解和实现此方案下的垃圾回收算法更加复杂Flat Database Layout将所有的状态对象都存储为树的路径，某种程度上有点类似于 键值对 存储性能更高、硬盘开销更小更难以理解和实现Witness（见证数据）即以一种可验证的形式存储的状态数据Block Witness（区块见证数据）一种类型的见证数据，提供了执行区块所需的所有状态数据Transaction Witness（事务见证数据）一种类型的见证数据，提供了一笔事务的 EVM 执行所需的所有状态数据Node Type（节点类型）Full Node（全节点）指一个满足了下列要求的节点：存储了所有的区块头存储了全部区块体历史存储了全部收据历史存储着近期状态维护者一个主链区块索引系统维护者一个主链事务索引系统参与 ETH DevP2P 协议（译者注：该协议用于在以太坊网络的对等节点之间传输数据，如区块、事务、状态数据等；以太坊交易的广播就是靠这个协议实现的）Archive Node（归档节点）其他特点与全节点都一样，但归档节点会存储全部归档状态。一般都需要执行 Full Sync（全量同步）。LES Light Node（LES 轻节点）连接到 LES DevP2P 协议的客户端，意图是跟上区块链并暴露 JSON-RPC API。此类客户端依赖于链接到至少一个 LES Server（LES 服务器）来满足对数据的需求。Stateless Node（无状态节点）一个仍在计划中的客户端类型，如果能够实现区块见证数据的话，就可使之成真。此类客户端不需要状态数据来执行区块，因为它们可以使用见证数据（TODO：还需增加对其他功能所需技术的描述）Ultra Light Node（极轻节点）增加这个术语只是为了区分当前类型的轻节点和一种新类型的轻节点 —— Piper一种仅暴露 JSO-RPC API 的节点。P2P 协议ETH DevP2P 协议DevP2P 网络中所用的点对点协议，是所有主网客户端的基石作为这个点对点网络中的一部分，一个节点需要：参与 Transaction Gossip（事务广播）参与 Block Gossip（区块广播）拥有近期状态拥有完整的区块链历史LES DevP2P 协议作为轻客户端基础的 DevP2P 网络所用的点对点协议LES 服务器参与 LES 网络、向 LES 客户端提供数据的节点。在这个网络中成为一个服务器需要：完整的近期状态全部区块链历史主链 区块索引/事务索引有能力参与事务广播有能力参与区块广播LES 客户端参与 LES 网络、向 LES 服务器请求数据的节点。（未完）原文链接: https://github.com/ethereum/stateless-ethereum-specs/wiki/Glossary作者: Piper Merriam翻译: 阿剑

波卡联合创始人解读平行链：它是区块链的一种更简单的形式 作者：Robert Habermeie翻译：PolkaWorldPolkadot 是一个用于可扩展的去中心化计算和互操作性的区块链。在本文中，我们将研究这个网络的一个主要部分：平行链。今天的区块链以一种相当标准的形式出现，由两部分组成。第一部分是共识算法，它提供了安全性。第二部分是状态机，它提供了值得在其上获得安全性的链的各个方面。以太坊、比特币、Zcash 和其他加密货币都受到工作量证明（PoW）与其各种变体共识的保护，但它们处理的交易类型和账户（构成其唯一状态机的事物）都是不同的。想象一下，一个开发者想出了一个新区块链的好想法，它可以提供有效的隐私保护、财富分配或其他一些令人兴奋的功能。当开发人员致力于实现这个独特的状态机时，他们还必须实现某种共识算法，并且当他们启动链时，它必须与其他链竞争安全资源。这给开发新的区块链项目带来了成本和不安全感。我来介绍一下平行链。平行链（可并行化的链）是区块链的一种更简单的形式，它连接到由“中继链”提供的安全性上，而不是自己提供安全性。之所以称之为中继链，是因为它不仅为附加的平行链提供了安全性，而且还提供了它们之间安全消息传递的保证。平行链的一个关键特性是它们执行的计算本质上是独立的。图灵完备的智能合约的完全通用的系统在确定哪些交易将彼此“冲突”时会遇到问题，这意味着可能并行化的交易会按顺序运行，从而浪费了宝贵的计算时间。在平行链之间划清界限意味着我们可以一次执行所有的平行链而不用担心“冲突” —— 如果我们有 10 个平行链，我们可以使用相同的安全源执行 10 倍的工作。高度专业化的平行链还有另一个目的：它们可以针对其问题领域以最有效的方式实现数据存储和交易操作，而不会陷入特定于区块链的脚本语言或虚拟机中。在他们的核心，诸如比特币脚本和 EVM 之类的模型在设计时就考虑到了互操作性的目标，但是，使用这些模型的系统要为其实现的所有部分支付更高的执行成本，而不仅仅是那些可以从运行在同一网络上的其他系统访问的部分。相比之下，Polkadot 平行链通过异步消息传递相互通信，因此只在平行链相交的边界处支付数据一致性的成本。请注意，你仍然可以创建一个为完全通用的、图灵完备的智能合约提供框架的平行链。一个简单的例子是由 EVM 驱动的平行链。基于上述原因，在这个平行链部署的合约既会受益于以太坊智能合约的通用性和互操作性，也会因其而带来不便。最主要的区别是，它是完全选择加入的。我们认为 Polkadot 能够集成重点解决方案的同时，还可以保留使用非常通用的框架作为其最强大特性之一 —— 可选性。平行链的一个最有趣的用例是作为可伸缩性的工具。可以创建具有自己的平行链的平行链，等等。这创建了一个树状结构，可以用于执行高度分布式的计算，而不会减少根中继链本身的总体负担。主要的问题是确保数据的可用性 —— 平行链区块意味着要有一个有效性的证明，任何人都可以在至少一段时间内检查。验证人负责确保他们验证的块证明仍然可用。不幸的是，如果没有在链上删除消息，就无法（或者至少非常困难）证明应该被发送的消息没有被发送。我们可以在很大程度上通过声誉保证来避免这个问题：当相对可信的一方指出验证人隐瞒数据时，他们可能会受到惩罚。这也可以推广到硬币投票制度或多层法院。为了降低恶意虚假报道的有效性和实用性，每一次不良行为的报道都应该伴随着不可退还的资金销毁。当有足够多的人在计算时，就像在一级平行链的情况下，通常会获得必要的数据。另一种缓解策略是设计平行链，当链出现停滞或受到攻击时，存储的价值可以被提取，尽管当链执行智能合约锁定资金或自动管理自己的费用时，这是困难的。对于可伸缩性，一种更有趣的方法可能是使用零知识(ZK)证明。现代的非交互式 ZK 证明，如ZK- snarks 或 ZK- starks，允许我们检查具有一些已知输入和一些未知输入的已知程序是否正确执行的证明，并在不泄露任何关于私人输入的信息的情况下了解该程序的输出是什么。最常见的，像这样的 ZK 证明被称为隐私工具，但它们也可以用于性能。令人惊讶的是，不管程序本身的复杂性如何，检查这种零知识证明的时间或多或少是恒定的，有些证明在比相应程序执行所花费的时间更少的时间内进行证明！这意味着，即使是可能需要数小时处理的极其复杂的交易，链的验证人也可以在很短的时间内验证。不幸的是，创建 ZK 证明的计算和内存成本仍然高于普通用户的可行性。在这些成本降低之前，实践 ZK 证明仍将是未来的事情。但是，关于平行链的伟大之处在于它们是如此的通用。通过允许每个平行链定义其自身有效性的概念，我们可以从当前的庞大证明无缝过渡到将来的更轻，更高级的证明。随着分片研究的发展，可以轻松添加实施最新技术的平行链。最终，这就是 Polkadot 的价值主张：它处于正确的抽象层，可以在现在和将来使用，而没有任何不必要的成本。该系统的设计不仅可以适应任意进度，而且还具有可扩展性，可以毫不费力地集成可扩展性方面的最新发展。原文链接：https://medium.com/polkadot-network/polkadot-the-parachain-3808040a769a

波卡的随机性如何产生？｜Polkadot Wiki 原文：https://wiki.polkadot.network/docs/en/learn-randomness翻译：PolkaWorld加入 PolkaWorld 社区，共建 Web 3.0！波卡作为一条 PoS 链，随机性至关重要。波卡的随机性如何产生？为什么要选择这种方案呢？在本章 wiki 中给出了说明。Polkadot Wiki 是波卡官方文档，PolkaWorld 目前正在翻译和连载中。随机性在权益证明（PoS）区块链中，随机性对于验证人职责的公平且不可预测分配很重要。计算机并不擅长随机数，因为它们是确定性设备（相同的输入始终会产生相同的输出）。通常大家在计算机上（例如在游戏应用程序中）所说的 “随机数” 实际上是伪随机的。也就是说，它们依赖于用户或其他类型的 Oracle（预言机）提供的足够随机的种子，例如气象站的大气噪声、你的心律，甚至是熔岩灯，它都可以从中产生一系列看似随机的数字。但是给定相同的种子，将始终生成相同的序列。然而，这些输入将根据时间和空间而变化，而且不可能将相同的结果输入到全球特定区块链的所有节点中。如果节点获得不同的输入并用它来出块，则会发生分叉。显然，现实世界的无序状态不适合用作区块链随机性的种子。如今生产环境中有两种主要的解决区块链随机性的方法：RANDAO 和 VRF。Polkadot 使用 VRF。VRF可验证随机函数（VRF）是一种数学运算，需要一些输入并产生一个随机数以及该提交者生成该随机数的真实性证明。任何挑战者都可以验证该证明，以确保随机数生成有效。Polkadot 中使用的 VRF 与 Ouroboros Praos 中使用的 VRF 大致相同。Ouroboros 的随机性对于出块来说是安全的，并且对于 BABE 也运行得很好。它们的不同之处在于，Polkadot 的 VRF 不依赖于中央时钟（问题变成了 “谁控制中央时钟？”），而是取决于它自己的过去结果来确定现在和将来的结果，并且它使用时隙号（slot number）作为时钟仿真器来估计时间。具体操作如下：时隙（slots）是时间的离散单位，长度为六秒。每个时隙可以包含一个块，但也可以不包含一个块。时隙构成了时期（epochs）—— 在Polkadot上，2400个时隙构成了一个时期，即每个时期为 4 小时。在每个时隙中，每个验证人都会 “掷骰子”。他们执行将以下内容作为输入的函数（VRF）：密钥 - 专门为 “掷骰子” 制作的钥匙Epoch 随机值 - 上一个（N-2) 之前的 epoch 中各个块的 VRF 值的哈希值，因此过去的随机性会对当前的待确认随机性（N）产生影响时隙数（slot number）输出为两个值：RESULT（随机值）和 PROOF（证明随机值已正确生成的证明）。然后将 RESULT 与在协议（具体来说是在 Polkadot Host 中）的实现中定义的阈值进行比较。如果该值小于阈值，那么得出此数字的验证人将是该插时隙的可行出块候选者。然后，验证人尝试创建一个块，并将该块与先前获得的 PROOF 和 RESULT 一起提交到网络中。钓鱼人（fisherman）- 监视网络的收集人和验证人错误行为的节点，将验证中继链区块。由于非法投掷将产生非法区块，并且由于钓鱼人将在验证人产生的每个区块中访问 RESULT 和 PROOF，因此他们很容易自动报告作弊的验证人。总结一下：在 VRF 下，每个验证人都会为自己掷出一个数字，并根据阈值对其进行检查，如果随机掷出的骰子低于该阈值，则会生成一个区块。观察网络并报告不良行为的钓鱼人事后会验证这些投掷的有效性，并向系统报告任何作弊行为（例如，有人尽管掷出的数量超过阈值，但仍然假装成出块者）。精明的读者会注意到，由于这种工作方式，某些时隙可能没有验证人作为出块候选者，因为所有验证人候选者的得分都太高而错过了阈值。我们阐明了如何解决此问题，并确保与 Wiki 页面的共识部分 的 Polkadot 出块时间保持几乎一致。RANDAO另一种获取链上随机性的方法是以太坊的 RANDAO 方法。RANDAO 要求每个验证人通过对某些种子执行数千个哈希来进行准备。之后验证人在回合中发布最终的哈希值，并且从每个参与者进入游戏中得出随机数。只要一名诚实的验证人参加，随机性就被认为是安全的（在经济上进行攻击不可行）。RANDAO 可以选择使用 VDF 进行增强。VDFs可验证延迟函数（ Verifiable Delay Functions ）是指即使在并行计算机上也要花费规定时间才能完成的计算。它们产生独特的输出，可以公用共设置独立有效地对其进行验证。通过将 RANDAO 的结果输入 VDF，会引入延迟，从而使任何攻击者企图影响当前随机性的尝试都将过时。VDF 一般需要通过 ASIC 设备来实现，这类设备需要与其他类型的节点分开运行。尽管只有一台就足以保证系统的安全，并且它们将是开源的并且几乎免费分发，但是运行这类设备既不便宜也不受激励，对于选择这种方法的区块链用户而言将产生不必要的摩擦。扩展资料Polkadot 在随机数和抽签上的研究 - 包含了在证明机制之间作出选择的理由：https://research.web3.foundation/en/latest/polkadot/BABE/Babe.html关于 Pokadot 中用到的随机数的讨论 - W3F 研究员讨论波卡中的随机性及其使用场景和假设：https://github.com/paritytech/ink/issues/57关注 PolkaWorld发现 Web 3.0 时代新机遇

以太坊清扫机器人肆虐，一文了解三种解决方案 注：你是否遇到过这样的情况，当你发送一笔以太坊资金，然后就发现钱包里的钱立即被清空了，你可能被清扫器（sweeper）盯上了，这篇文章旨在帮你解决这个问题，原文作者是MyCrypto安全&反钓鱼工程师Harry Denley。当你的秘密遭到泄露时，恶意方通常会给你的账户设置一个清扫器（sweeper），以利用将来该地址上所发生的任何事情，比如当用户存入ETH以尝试提取一些代币，发生空投或其它情况时。本文概述了用户的资金是如何被清扫走的，以及三种独特的方法来挽救任何未被清扫的资金（例如质押资金）。用户是如何被钓鱼的近期，我们看到有大量用户在冒充Telegram群管理员，这些假的管理员会向在主频道中请求帮助的用户提供帮助（尽管他们不是真正的管理员，他们复制了管理员简介信息，但用户名有一些小的差异）。这些冒名顶替者经常会说很多行话来迷惑用户，并分享一个看似合法网站的链接，但它最终会要求你输入助记词或私钥。然后，你的加密资产就不见了，上面有一个清扫器。这是这些假网站之一的示例：清扫器的工作方式清扫器是一些监控区块链（包括txpool，从技术上讲，它没有在链上）的代码，其以编程方式对一组规则的特定事务进行签名的反应，要比人类更快。这意味着，对于你在区块链浏览器上查看你的地址或将其“连接”到dapp的UI，清扫器（sweeper）是看不见的。只有在你签名并向网络广播交易后，清扫器（sweeper）才能看到你的活动。随着时间的推移，我们看到了清扫器（sweeper）和利用它们的活动的演变。清扫器的演变2017年期间，有相当一部分活动利用了具有锁定功能（即，你无法成功调用transfer() ）但包含喂价的代币。Dave Appleton发表了一篇关于这些活动的文章。恶意方利用这种骗局的方式是，他们会将私钥发布到这个地址（以某种看起来无辜或错误的方式），并等待人们将ETH存入该地址（以转移地址中的代币）。然后恶意方会有一个该账户的清扫器程序，以将存入该地址的ETH快速转移到他自己的账户。从理论上来说，锁定的代币被认为是毫无价值的，因此他们试图从那些毫无戒心的“贪婪”用户那里获取利润。如今，遭泄露的的地址基本被部署了ETH清扫器程序，一些组织则使用更高级的清扫器程序逻辑来清扫基于喂价的ERC20代币。今年早些时候，我对一个泄露地址做了一些侦察研究，发现清扫器在不断进化：清扫器偏爱美元价值最高的资产，即使这意味着需要花费更多的交易费用来清扫；清扫器将使用所有可用的ETH最大化清扫价值，同时也有很高的百分比是nonce的“获胜”交易。清扫器有一个匹配引擎，将质押代币（即：xKNCa=KNC）与其原生代币匹配，以便喂价反映在质押代币上。清扫器有自己的内部nonce计数器，如果其最高nonce随机数未在一个时间范围内得到确认（或被另一个丢弃/替换），则定期将nonce随机数重置为eth.getTransactionCount（）输出。如果存在清扫器所针对的高价值资产，则有一些活动会建议运行者通过资助地址来“牺牲”一些ETH，以尝试从账户中快速清扫高价值资产。如果美元价值低于某个阈值，则某些清扫器就不会清扫资产，这意味着你可能并不知道自己的账户被清扫器盯上了，这是很可怕的。描述清扫器的文章，第一次出现是在2017年，而现在我们观察到的清扫器已变得更加先进，它们的设计目的是最大化运行者的利润，同时对受害者造成最大的损失。如何击败清扫器？首先，作为人类，我们是无法比代码更快的，所以我们的解决方案只能涉及编码。你可以选择几条不同的路线，它们均无法提供100%的保证，但对我们而言是有利的。你需要创建一个想要尝试抢救的代币列表，按优先级排序，这样你就可以轻松地确定你的计划，你需要列出：代币合约地址；代币是否质押（以及解除质押是否是时间锁定的）；代币是否可转让；代币价值（以美元计算）；关键是你要有条不紊地完成这件事，这样你才能快速有效地执行。正如一句名言：“如果你疏于计划，那你就是计划走向失败”。使用TAICHI清扫器的工作方式是监视txpool中转到其清扫地址的传入交易，而TAICHI允许你将签名的交易直接提交给矿工（SparkPool），而无需通过公共txpool进行广播，这意味着清扫器程序将是看不到的，并且很可能你的交易不会被清扫程序机器人抢先完成（至少以我的经验来看）。图片来自TAICHI.NETWORK这里的方法是让你的所有交易预先以nonce顺序签名，并以编程方式提交给TAICHI。大多数清扫器只监视公共txpool/mempool以获取传入的ETH交易，并且不在每个新区块上调用eth_getBalance（以节省CPU周期和RPC方法调用的成本），这意味着它们将对通过专用txpool路由发送到帐户的ETH视而不见，也就不会对其进行清扫。这需要你做一些数学工作，如果正确执行了数学运算，则尝试抢先交易的清扫器程序可能会失败！（通常，我默认gas价格比GasNow上的“快速”类别高几个百分点，因此矿工将更有可能在下一个区块中确认你的交易。）你可以离线使用MyCrypto来生成已签名的交易，并在准备就绪时将其推送到TAICHI，或者使用ethers.js（或其他库）创建代码来创建已签名的交易。方法2:使用一个自毁智能合约就像使用TAICHI方法一样，我们可以使用智能合约让ETH进入账户，而不会在公共txpool中显示出来。我们通过从安全地址部署智能合约来做到这一点，然后在结构上将ETH发送到被泄露的地址（这将是一笔内部交易）。通过部署这个合约，我们可以在构造函数参数中发送ETH以及遭泄露的地址字符串。该合约通过在同一交易中创建合约并自毁来工作。使用selfdestruct（）意味着我们清除了区块链状态（因为它是一次性使用合约），并且在一次交易中将ETH转发到了泄露地址。示例：https：//goerli.etherscan.io/tx/0x82ccb222eae55aaea73dd0efee1ea6ed7320f880889f280d4a343b8823f86692请注意，这种方法虽然有效，但它会增加额外的成本，因为我们要做的操作不仅仅是将ETH从一个帐户发送到另一个帐户。这种方法的成本约为70,000 gas，在高昂的gas价背景下，使用这种方法的手续费成本就可能达到0.0112ETH。方法3:使用Flashbots一般而言，我们需要支付ETH才能让一笔交易被确认（因为交易费用是由发送方支付的）。然而，由于Flashbots‌的出现，我们可以更轻松地从EOA中通过用另一个帐户中的资金“贿赂”矿工，以0 gas价格（即0美元交易费用）确认交易，这意味着我们可以将代币从泄露的地址中转移出来，而无需用ETH支付gas费用，是的，就是这样。该策略需要用到2个账户，一个是泄露账户，以及另一个贿赂矿工的帐户。Flashbots小组已发布了一个名为Flashbots / searcher-sponsored-tx‌的项目，其具有设置此策略以从两个帐户中确认你的交易的基本原理。由于我们将使用另一个帐户支付交易费用，因此不需要向受损害的帐户存入ETH。为了确保泄露帐户中没有ETH，我们强烈建议你运行一个Burner机器人。我们通常建议在每个实例上使用不同的RPC节点，在一台以上的计算机上运行这个burner 机器人。例如，使用Infura在本地运行burner 机器人，并在具有其他提供商（例如Quiknode）的远程服务器上运行一个burner机器人。这样，你就有了一个备案计划，以防出现高网络延迟或节点问题（速率限制、同步问题）。Flashbots/searcher-sponsored-tx中的代码需要根据你的特定需求进行修改，但这个引擎可以帮助你将代币从泄露的地址中解救出来。这个Flashbots引擎足够灵活，可支持单个 transfer()调用，或者unstake() 以及 transfer()调用。如果你不太熟悉代码，你也可以尝试使用@kendricktan/flashbots.tools ‌网站。

V神提出新型密钥分享方案，可用于脑钱包和社交恢复设计应用 注：原文作者是以太坊联合创始人Vitalik Buterin，在这篇文章中，他描述了一种新型的M-of-N密钥分享方案，并提出了脑钱包和社交恢复设计的两种应用案例。假设你希望生成一个秘密 s，而s可通过将N个密钥分享中的M个放在一起来恢复，其中所有N个密钥分享是预先知道的。那么这种方案有两个用例：一种脑钱包，其中N个密钥分享是N个安全问题的答案，并且你希望仅通过M个安全问题的答案就可以恢复资金（单独的安全问题会很糟糕，但如果你将20个安全问题组合起来，你可以获得相当多的熵）；一种社交恢复设计，其中你希望使用阈值解密而不是智能合约钱包，因为你正在尝试恢复访问私人数据，而不是加密货币，并且你希望你的恢复合作伙伴能够使用他们已经拥有的密钥（以减少有丢失这些密钥的风险）；普通的 M-of-N 密钥分享方案不适用于这些用例中的任何一个，因为它只允许预先选择 M 个密钥分享，剩余的 （N-M） 个密钥分享必须使用一种确定性算法从原始的M个中产生，并且看起来像随机数据（在脑钱包的情况下，它们不适合作为安全问题的答案，在社交恢复的情况下，需要用户使用特殊软件来存储它们，而不是从现有的HD钱包中衍生出来）。所以这就是我们要去改进的，我们制定了一个 N-of-(2N-M) 阈值方案，从原N个密钥分享生成（ N-M） 个附加密钥分享。然后我们在区块链上发布所有N-M 个附加密钥分享。如果需要，在社会恢复案例中，人们可以简单地给每个参与者一份所有附加密钥分享的副本。这会导致附加密钥分享变成有效的公共信息：它们丢失的风险可以忽略不计，但任何攻击者都会拥有它们。而结果是，在未发布的 N个密钥分享中，只要有M个密钥分享与 N-M 个附加密钥分享结合并揭示数据，我们就有了一个M-of-N方案，这正是我们想要的。2021年7月18日更新：社交恢复用例的替代机制在社交恢复用例中，我们希望设置过程尽可能简单，因为用户是懒惰倾向的，如果设置困难，他们将不可避免地选择不安全的小型恢复伙伴集。这意味着以去中心化方式生成密钥分享所需的分布式密钥生成 (DKG) 可能是一个坏主意，因为它需要 2 轮通信（这意味着额外的区块链交易或每个人同时在线并拥有同步通信通道）。相反，我们可以利用账户持有人自己拥有他们的私钥这一事实。他们可以简单地向每个恢复伙伴询问他们的公钥（例如，通过 pk = G * hash(ecdsa_sign(msk, nonce))，其中 msk 是恢复伙伴的主要密钥），然后在链上发布一笔包含 nonce 的交易，并为每个 i 加密(share_i, pk_i) （注：其中 share_i 是第 i 个密钥分享，pk_i 是第 i 个参与者的公钥）。如果我们避免重复使用nonce随机数，从而不重用密钥（例如，设置nonce = hash(secret, maddr_1 ... maddr_n)，其中secret是放入恢复的值，maddr_i是第i个恢复伙伴的地址，应该就足够了），我们可以使用基础的Diffie-Hellman加密算法进行加密，这意味着仅具有 32 * (n+1) 个字节calldata数据的单笔交易，就足以保存恢复信息。对此方案，ethresear.ch 论坛成员kelvin评论称：“这很有趣！ 我猜在社交恢复设计中，N个参与者会给他们的私钥附加一些公共盐（salt，指通过在密码任意固定位置插入特定的字符串），然后将其哈希生成N个预先知道的密钥分享？否则他们将不愿意泄露自己的密钥分享，以让N−M个附加密钥分享被计算，并且他们还必须透露 M 个密钥才能恢复秘密。此外，你认为人们会用这种方式来分发哪些类型的私人数据呢？”而Vitalik则回复称：“1、实际上，他们会使用 hash(ecdsa_sign(key, salt))作为哈希函数来生成子密钥，因为 ecdsa_sign 方法在 web3 API 中公开并且具有标准化的确定性输出。 但这是一个实现细节， 效果是一样的。2、我只是在考虑‘以太坊电子邮件’以及像Status这样的去中心化消息传递应用的加密密钥。另一个用例当然是其他区块链的私钥。”。

白帽黑客samczsun：针对NFT资产的攻击会越来越频繁 注：原文作者是拥有“审计上帝”之称的白帽黑客samczsun，同时他也是Paradigm的研究合伙人，其最近出手拯救了BitDAO MISO荷兰拍卖资金池中的3.5亿美元资产，而在这篇文章中，他提醒了关于NFT代币标准的潜在安全风险，他还预测称，随着ERC-721和ERC-1155代币标准变得越来越流行，针对NFT的攻击很可能会越来越频繁。如果你从事软件工程方面的工作，很可能你听说过至少一条软件工程原则。虽然我不主张严格遵守每一条原则，但有一些确实是值得关注的。我今天要讲的就是最小惊讶原则，它有一个奇特的名字，但却是一个非常简单的想法。它所说的是，当呈现声称要做某件事的代码时，大多数用户都会假设它是如何完成这件事的。因此，作为开发人员，你的工作是编写符合这些假设的代码，这样你的用户就不会感到意外。这是一个很好的原则，因为开发人员喜欢对事物进行假设。如果你导出一个名为calculateScore(GameState) 的函数，很多人就会假设该函数只会从游戏状态中读取。如果你还改变了游戏状态，你会使得很多人面临困惑的状态，他们试图弄清楚为什么他们的游戏状态会随机被破坏。即使你把它放在文档中，仍然不能保证人们会看到它，所以最好首先确保你的代码不会令人惊讶。“6小时的调试工作，可以为你们节省5分钟的文档阅读时间。”越安全越好，对吗？早在 2018 年初，当ERC-721 标准被起草出来时，有人就提出了实施转账安全性‌的建议，以确保代币不会被卡在不用于处理代币的接受者合约中。为此，提案作者修改了transfer函数的行为，以检查接收方是否能够支持代币转账。他们还引入了unsafeTransfer函数，如果发送者愿意，该函数将绕过这个检查。然而，由于担心向后兼容性，这个函数在随后的提交中被重命名了。这使得ERC-20 和 ERC-721 代币的transfer函数表现相同。但是，现在需要将接收方检查转移到其他地方。因此，标准作者就引入了safe类函数：safeTransfer 以及 safeTransferFrom。这是一个关于正当性问题的解决方案，因为有许多 ERC-20 代币被意外转移到从未期望收到代币的合约的例子（一个特别常见的错误是将代币转移到代币合约中，将其永久锁定）。而在起草 ERC-1155 标准时，提案作者从ERC-721标准汲取了灵感，不仅在转账时，而且在铸造（mint）也纳入了接收方检查，这一点也不足为奇。在接下来的几年里，这些标准大多处于休眠状态，而 ERC-20代币标准保持了它的流行状态，而最近gas成本的飙升，以及社区对NFT兴趣的增强，自然而然导致开发者越来越多地使用ERC-721和ERC-1155代币标准。有了这些新的兴趣，我们应该庆幸这些标准的设计考虑了安全性，对吗？越安全越好，真的吗？Ok，但对于转帐和铸造来说，安全意味着什么呢？不同的当事人对安全有不同的解释。对于开发人员来说，一个安全函数可能意味着它不包含任何bug或引入额外的安全问题。而对于用户来说，这可能意味着它包含额外的护栏，以保护他们不被意外射中自己的脚。事实证明，在这种情况下，这些函数更多的是后者，而较少会是前者。这是特别令人遗憾的，因为在transfer和safeTransfer函数之间进行选择时，你为什么不选择安全的那个函数呢？名字都体现出来了！好吧，其中的一个原因可能是我们的老朋友reentrancy（可重入性），或者我一直在努力将其重命名为：不安全的外部调用。回想一下，如果接收方是攻击者控制的，则任何外部调用都可能不安全，因为攻击者可能会导致你的合约转换为未定义状态。根据设计，这些“安全”函数执行对代币接收者的外部调用，通常在铸造或转移期间由发送者控制。换句话说，这实际上是不安全外部调用的教科书示例。但是，你可能会问自己，如果允许接收方合约拒绝他们无法处理的转账，那最坏的后果是什么？好吧，让我通过两个案例研究来回答这个问题。例子1: HashmasksHashmasks是一个供应有限的 NFT头像项目，用户每次交易最多可以购买 20 个mask NFT（尽管它们已经售罄数月了）。下面是购买mask的函数：你可能觉得这个函数看起来非常合理。然而，正如你可能已经预料到的，在 _safeMint 调用中隐藏着一些险恶的东西。 让我们来看看。为了安全性，这个函数对token的接受者执行了一次callback回调，以检查他们是否愿意接受转账。然而，我们是token的接收者，这意味着我们刚刚得到了一次callback回调，在这个点上我们可以做任何我们想做的事情，包括再次调用mintNFT函数。如果我们这样做，我们将在仅铸造了一个mask后重调用该函数，这意味着我们可以请求再铸造另外19个mask。这导致最终铸造出了39个 mask NFT，尽管规则允许铸造的最大数量只有20个。例子2: ENS域名封装器最近，来自ENS 的Nick Johnson联系了我，他想让我看看他们正在进行的ENS域名封装器工作。这个域名封装器允许用户用新的ERC-1155 token代币化他们的ENS域名，这提供了对细粒度权限以及更一致的 API 的支持。概括地说，为了封装任何ENS域名（更具体地说，除了 2LD.eth 之外所有的ENS域名），你必须首先批准域名封装器以访问你的ENS域名。然后，你调用wrap(bytes,address,uint96,address)，它既为你铸造一个ERC-1155 token，也负责管理底层的ENS域名。下面就是这个wrap函数，它相当简单。首先，我们调用_wrap，它执行一些逻辑并返回哈希域名。然后，我们确保交易发送方确实是ENS域名的所有者，然后再接管该域名。请注意，如果发送方不拥有底层的ENS域名，则整个交易应还原，撤销在_wrap 中所做的任何更改。下面是_wrap函数本身，这里没有什么特别的。不幸的是，正是这个 _mint 函数，它可能会给毫无戒心的开发者带来可怕的惊喜。ERC-1155 规范规定，在铸造token时，应咨询接收者是否愿意接受该token。在深入研究库代码（该代码库根据OpenZeppelin的基础稍作了修改）后，我们发现情况确实如此。但这到底对我们有什么好处呢？好的，我们再一次看到了一个不安全的外部调用，我们可以用它来执行重入攻击。具体地说，请注意，在callback回调期间，我们拥有了代币ENS域名的ERC-1155 token，但域名封装器尚未验证我们拥有基础ENS域名本身。这使我们能够在不实际拥有ENS域名的情况下对其进行操作。例如，我们可以要求域名封装器解开我们的域名，燃烧掉我们刚刚铸造的token并获取底层的ENS域名。现在我们拥有了底层的ENS域名，我们可以用它做任何我们想做的事情，比如注册新的子域名或者设置解析器。完成后，我们只需退出callback回调。域名封装器将和底层ENS域名的当前所有者（即我们）交互，并完成交易。就像那样，我们已经取得了域名封装器被批准用于的任何ENS域名的临时所有权，并对其进行了任意更改。结论令人惊讶的代码可能会以灾难性的方式破坏事物。在本文的两个案例下，开发人员合理地假设safe函数类可以安全地使用，却无意中增加了他们的攻击面。随着ERC-721和ERC-1155代币标准变得越来越流行及广泛，这类攻击情况很可能会越来越频繁。开发人员需要考虑使用safe类函数的风险，并确定外部调用如何与他们编写的代码进行交互。

技术贴：如何用Signet 测试网尝鲜体验Taproot 注：原文来自bitcoinops。Taproot是Bitcoin网络最重要的升级之一，而从区块709,632开始（预计在今年11月份），Bitcoin用户将能够安全地发送和接收Taproot交易。那如何抢先体验Taproot呢？你可以通过testnet或signet测试网使用Taproot。与使用 Bitcoin Core 的 regtest 模式创建本地测试网络相比，使用testnet 或 signet 可以更轻松地测试你的钱包如何与其他人的钱包进行交互。在这篇文章中，我们将使用Bitcoin Core 的内置钱包在 signet 上接收和花费一笔Taproot交易。你应该能够调整这些指令，以测试你自己的钱包和Bitcoin Core之间的收入与支出。尽管在技术上可以使用Bitcoin Core 22.0中的内置钱包接收和花费Taproot交易，但我们还是建议你改为构建 Bitcoin Core pull request #22364，这使得taproot成为descriptor钱包‌的默认值。构建完成后，启用signet:如果这是你第一次使用signet，则需要同步它的区块链（目前包含的数据不到200 MB），大概一分钟左右的时间就可以完成同步（你可以使用getblockchaininfo RPC 监控同步进度）。同步完成后，创建一个descriptor钱包：现在，你就可以创建一个 bech32m 地址：有了这个地址，你就可以从 signet 水龙头‌申请测试用的“凭证”。然后你需要等待确认，这将花费大约30 分钟的时间（有时也可能会更长）。如果你查看交易，你会注意到你创建的 P2TR 脚本。然后，你可以创建第二个 bech32m 地址，并将资金发送到那里以测试支出。对于这笔花费，我们可以查看其中一个输入，并看到它的witness只包含一个 64 字节的签名。如果这是 P2WPKH支出或任何其他类型的旧比特币支出，那么所需要的witness会更大。

zkRollup改进提案：无需tx历史数据，以实现gas效率和隐私提升 注：原文来自ethresear.ch，作者是leohio（Leona Hioki）。感谢Alex Gluchowski（zkSync）以及 Barry Whitehat提供的意见和看法。一: 长话短说本文介绍了一种无需来自运营方tx历史数据的zkRollup，这具有在L1上使用txcalldata 的gas 效率，并且还具有智能合约执行及资产隐私的特性。每个batch只需要在txcalldata 中记录一个状态改变的所有者的账户列表。缺点是每个用户在将资金退出到L1时，需进行客户端zkp计算，而另一个缺点是在EVM兼容性方面带来困难。二、背景和动机对于Rollup的运营商和交易者而言，他们在使用txcalldata时仍然会产生消耗。这种限制仅仅是因为需要恢复作为交易结果的状态，以免用户无法生成其资金的 Merkle 证明。Rollup 的大部分规范要求运营商将所有交易历史数据转储到 L1 上的 txcalldata。交易历史数据的这种透明度，不仅增加了 txcalldata 的 gas 成本，而且还破坏了交易的隐私。据推测，交易历史数据的累加器，既解决了效率问题，也解决了隐私问题。三、方法简而言之，在第一步中，我们构造了一个 zkRollup，其中运营商将最终状态差异直接写入 txcalldata。交易历史数据将在一个zkp 电路的隐私输入中。第二步，我们通过分离常用存储和用户状态存储从 txcalldata 中删除最终状态差异。这使用户可以使用非包含证明（如 Plasma Prime 的状态版本）退出。用户保留其用户存储并仅公开其Merkle根。用户可以用 zkp 证明根转换，并且可以更新智能合约的常用存储。详细步骤如下：3.1) 第一步，zkRollup 中 txcalldata 使用选项使用 txcalldata 恢复完整状态有两种选择。选项 1：将所有交易历史数据记录到 txcalldata。选项 2：记录由于区块（批处理）中的交易而导致的最终状态的差异。在选项2中，由于txcalldata中没有要记录的内容，数以百万计具有相同结果的交易使用0 gas进行txcalldata使用。Merkle根转换的可靠性由zkp保证。而采用“选项 2”是第一步。3.2）第二步，优化“选项2”当批次/区块中的交易更改合约中的相同存储值时，上述选项 2 会花费更少的 gas。这种共享和更改的值就像 ERC20 的总供应量、swap协议的总资产池量等。而且这种存储值也会影响到所有资产持有者，这种数据的丢失会导致 zkRollup 的活性损失。另一方面，其他不常共享和更改的数据大多是个人资产数据。这类数据的丢失，直接意味着资产持有者损失了资金。这种风险是分开的，不会影响到对方的资金。然后分离用户的状态，并提供其状态的用户数据及其证明作为运营商对其交易的收据，从而降低了大量 gas 成本。（1）交易者向运营方发送交易；（2）运营商将其用户状态的merle 证明作为交易的收据；（3）交易者签署这个收据；（4）电路中只接收带有签名收据的交易数据；如果一个用户进行了交易，并且多个用户的余额发生了变化，并且他们知道自己的状态，包括这些余额和Merkle 证明，那么他们中的任何一个都可以随时通过 zkp退出其资金。这证明这是其余额的最后一个状态，可以通过每个批次的更改状态所有者的每个帐户列表的不包含证明来确定。更改状态所有者的帐户列表的稀疏 Merkle 树可用于有效证明。有两种方法可以让更改状态的所有者知道他们最近的更改。如果他们在线，运营商发送最后一个差异，接收签名的差异，并将其放入zkp 电路的输入，这样的gas成本是最低的。如果他们不在线，运营商会将其发布到txcalldata 或链下去中心化存储。通过这种状态分离，运营商不再需要将最终状态的任何差异都放在txcalldata 中，因为用户的帐户状态对于退出来说足够安全，而丢失共同共享的数据，只是意味着运营商无法更新zkRollup 的Merkle根，他们将简单地停止服务。然后，公共共享存储和用户存储都可以在链外分发。每批只需要在 txcalldata 中记录一个状态改变的所有者的账户列表。3.3）第三步，隐私智能合约执行用户的交易不在链上，但运营商仍然可以看到并需要看到用户状态（包括余额），以进行zkp证明。如果用户在其一边进行zkp以证明其用户状态的Merkle根和公共共享存储的转换，则运营商只需更改该Merkle根和存储，余额的秘密仍然存在。（1）用户向运营商发送交易；（2）运营商返回余额和更新后的公共共享存储的差异；（3）用户对更新后的用户状态和公共共享存储的 Merkle 根进行 zkp 证明；制作每个批次（区块）的运营商可通过更改批次中共享存储的变化知道余额差异，但其无法知道其他批次的余额差异，因为运营商之间只共享最终差异。这具有混合级别的隐私。这种机制需要用到递归zk。四、更详细的讨论4、1 在链下与离线状态改变者通信这只是一种选择。该协议可以在没有这部分的情况下构建。即使在最坏的情况下，状态更改器处于离线状态，这种情况下的数据可用性风险也非常有限。离线用户可以在其在线时获取数据以安全退出，其可以设置代理而不是自己接收数据。并且我们可以构造退出方法，以便上次状态更新不会因为数据可用性问题而使之前的状态变得危险。典型的去中心化存储结构如下所示：（1）提交哈希（存储）（2）证明preimage(hash(storage)) = preimage(hash(storage, last-Ethereum-block-header)) - last-Ethereum-block-header（3）继续观察有多少节点可以完成（2）4.2 账户链上gas费用每个帐户都可以获得一个比地址本身短得多的 ID。每个batch只需要一个账户列表，这样就可以省略重复项，这比 txcalldata 中使用的交易历史要高效得多。4.3 公共共享存储的进一步优化在以太坊L1上，你无法擦除 txcalldata。我们可以修改它，因为公共共享存储不需要在链上。与交易历史数据不同，我们只需要最后的状态数据，不需要任何之前的状态。然后运营商可以放弃之前在网络中共享的“最终状态数据”。运营商可以通过 zkp 逻辑知道可以丢弃的数据。五、结论分离用户状态使得 zkRollup 智能合约执行既高效又隐私，几乎所有的 txcalldata 成本都从 zkRollup 中移除了。

比特币Taproot升级终于要来了！一文了解它的过去、现在与未来 大约两周后，比特币将迎来它最重要的技术升级之一：Taproot。什么是Taproot？维基百科上给出的普通定义是：“主根（taproot）是一个大的、中心的、占优势的根，而其它的根会从其侧面发芽。通常，主根有些直，然后形状逐渐变细，并直接向下生长。在例如胡萝卜这样的植物中，主根是一种非常发达的贮藏器官，其已被作为蔬菜栽培。"那比特币即将采用的Taproot技术方案到底是什么？它的名字是如何来的？比特币Taproot名字的由来“我一直认为这个名字的由来是‘利用Merkle根‘，但我实际上并不知道Gregory Maxwell的想法是什么。’ —— Pieter Wuille（来源）“我最初不得不查这个词，但我把它理解成了关键路径，因为它是你制作美味的胡萝卜汤的核心，而默克尔化的脚本将是你希望忽略的其他较小的根。” —— Anthony Towns （来源‌）而Taproot方案提出者Gregory Maxwell给出的答案‌则是：“这个词起源于一棵树的形象化，这颗树的中央有一个像蒲公英主根一样粗壮的中心（这项技术非常有用，因为假设有一条高概率路径，其余的路径就模糊化了）。我认为这是一个很好的方法，因为它通过利用根中隐藏的commitment来验证脚本路径的花费。……唉，将具有已排序内部节点的哈希树称为“桃金娘树”（Myrtle tree）并没有流行起来。 （Myrtle tree是包括Melaleuca树、茶树（tea-tree）在内的树家族，这听起来像'merkle'。:p)”因此，当谈论比特币taproot时，我们脑海中浮现出来的图像应该是下面这个样子的：来源：SHUTTERSTOCKTaproot升级对比特币的影响是什么？早在18年初，在Gregory Maxwell提出Taproot方案之后，国内比特币社区便对该方案进行了早期的报道‌，当时社区的关注点在于：“实施taproot升级后，闪电网络将变得更加私密，这使得LN交易与所有比特币交易无法区分开来，因此人们将无法区分比特币的链上交易和闪电网络的链下交易”。而要应用Taproot的前提，是需要先让Schnorr签名方案落地。到了2019年，除了提高比特币的隐私性之外，Taproot方案又被社区赋予了新的使命 —— 扩展比特币智能合约的灵活性。也因此，Taproot升级以及Schnorr签名被提升为“比特币在下一阶段的重要技术‌”。2020年1月份，Bitcoin core代码库维护者之一Pieter Wuille 正式发布了包含Taproot/Schnorr 软分叉升级的BIP 340‌、BIP 341‌以及BIP 342‌，由此，这两个升级提案开始逐渐进入比特币用户们的视野。今年6月份，比特币全网支持Taproot升级的算力超过了90%，达到了锁定升级的最低要求，这也意味着 Taproot将在比特币区块高度达到709,632（预计将在北京时间11月13日前后）时正式与大家见面。关于Taproot和Schnorr签名的一些趣事1、比特币最初使用的是ECDSA签名方案，但实际上Schnorr签名要比ECDSA签名更早诞生，我们说Schnorr 签名是对比特币原始 ECDSA 签名的升级，是因为其可以更容易地实现各种密码学技巧。在时间顺序上，Schnorr签名算法的诞生，要早于ECDSA 所基于的 DSA 算法。而中本聪使用DSA的部分目的是为了规避 Claus Peter Schnorr 的 Schnorr签名专利，而他的专利在 2011 年到期了。2、虽然没有成功，但在比特币采用Schnorr签名的早期发展中，有人建议不应将Claus-Peter Schnorr的名字与比特币关联起来，因为他的专利导致这种有价值的密码学技术在20多年的时间里没有被广泛使用。Pieter Wuille曾表示‌：“我们确实考虑过用DLS（离散对数签名）来称呼BIP340，但我们最终没有这样做，因为Schnorr的名字已经被谈论得太多了。”3、Pay to contract：Ilja Gerhardt 和 Timo Hanke 创建了一个名为Pay to contract‌的协议，该协议由Hanke 在 2013 年的圣何塞比特币会议上提出，其允许一笔支付承诺其合约的哈希值。任何拥有该合约副本和用于避免某些攻击的nonce的人，都可以验证这个承诺（commitment），但对其他人来说，这种付款看起来与其他的比特币付款类似。2014 年关于侧链的论文‌中包含了对这种pay-to-contract (P2C)协议的轻微改进，其中承诺还包括原始的支付公钥，而Taproot 使用了相同的结构。Taproot落地之后，未来可能的比特币共识改变那在激活Taproot之后，开发者们会在它的基础之上对比特币进行哪些共识层的改进呢？1、交叉输入（Cross-input）签名聚合：Schnorr签名使几个不同的公钥和私钥对的所有者可轻松地创建单个签名，以证明所有密钥所有者在创建签名时都进行了协作。随着未来共识的变化，这可能允许交易包含单个签名，该签名可用于证明在该交易中使用的所有UTXO的所有者已授权使用。在第一次输入后，这将为每个密钥路径（keypath） 花费节省大约 16 虚拟字节（vbytes），从而为整合以及coinjoin节省开销。它甚至可使基于coinjoin‌的支出比常规的支出更便宜，从而提供一种温和的激励，以鼓励人们更多地去使用隐私交易。2、SIGHASH_ANYPREVOUT：每一笔正常的比特币交易都包含一个或多个输入，并且这些输入中的每一个都使用其 txid 引用前一笔交易的输出。这告诉了全验证节点（例如Bitcoin Core）这笔交易可以花费多少钱，以及需要满足哪些条件才能证明支出是经过授权的。为比特币交易生成签名的所有方式，无论有没有taproot，要么提交到prevout中的txid，要么根本不牵扯到prevout。对于不想使用精确的预先安排的一系列交易的多用户协议来说，这是一个问题。如果任何用户可以跳过特定交易，或更改除witness验证数据之外的任何交易的任何细节，这将更改任何后续交易的 txid。而更改 txid 会使之前为以后交易创建的任何签名无效。这迫使链下协议实施机制来惩罚任何提交旧交易的用户（例如 LN 的惩罚机制）。而SIGHASH_ANYPREVOUT‌可通过允许签名跳过提交到prevout txid 来消除这个问题。这使得为闪电网络（LN） 实施 eltoo 层‌以及对vault金库‌和其他合约协议的改进成为可能。3、委托（Delegation）和归纳：在你创建一个脚本（taproot或其它）之后，除了将私钥授予其他人（非常危险），你几乎无法授权他人使用该脚本。此外，对于想要使用密钥路径（keypath）花费加上少量基于脚本条件的用户来说，可以使taproot变得更经济。开发者们已经提出了几种通过归纳和提供签名者委托来增强 taproot的方法：（1）Graftroot：在taproot的想法诞生后不久，Graftroot就被提出了，该方案将为任何能够制作taproot路径的人提供一项额外的功能。密钥路径（keypath）签名者可以签署一个脚本，描述资金可使用的新条件，将支出权限委托给任何能够满足该脚本要求的人，而不是直接支出资金。签名、脚本以及满足脚本所需的任何数据，都将在支出交易中提供。 密钥路径（keypath）签名者可通过这种方式委托给无限数量的脚本，而无需创建任何链上数据，直到发生实际支出。（2）广义taproot (g’root): 几个月后，Anthony Towns提出‌了一种使用公钥点（public key points）来承诺多种不同支出条件的方法，而不必使用类似 MAST 的结构。这种广义taproot (g’root)构造“在taproot假设不成立的情况下可能更有效”，此外，它还提供了一种构建软分叉安全交叉输入聚合系统的简单方法。（3）Entroot：Graftroot和g'root的最新合成方案‌，它简化了许多情况，使它们更具带宽效率。4、新的和旧的操作码（opcode）：taproot 软分叉包含了对tapscript 的支持，它提供了一种向比特币添加新操作码的改进方法，即 OP_SUCCESSx 操作码。一些拟议的新操作码包括：（1）恢复旧操作码：由于担心安全漏洞，2010 年开发者禁用了一些数学和字符串操作的操作码。许多开发人员希望在安全审查后重新启用这些操作码，并且（在某些情况下）可能会扩展操作码以处理更大的数字。（2）OP_​​CAT：值得特别提及的一个先前禁用的操作码是OP_​​CAT‌，研究人员发现它可单独在比特币上实现各种有趣的行为，或者它还能以有趣的方式与其他新操作码进行组合。（3）OP_TAPLEAF_UPDATE_VERIFY：当与taproot的密钥路径和脚本路径功能一起使用时，OP_TLUV操作码能以一种特别高效和强大的方式启用契约（covenants‌）。这可用于实现JoinPool‌、Vault以及其他安全和隐私改进。它还可以与OP_CHECKTEMPLATEVERIFY‌很好地结合。注意，以上所有的想法仍然只是提议，没有人能保证它们会成功应用，这需要研究人员和开发人员完成每一项提案，然后由用户决定这些功能是否值得去改变比特币的共识规则。相关资料：1、https://bitcoinops.org/en/newsletters/2021/10/27/2、https://bitcoinops.org/en/newsletters/2021/10/20/3、https://www.8btc.com/article/2236814、https://www.8btc.com/article/351969