heyuan 发布的文章 - 六币之门

波卡的随机性如何产生？｜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

Taproot激活前瞻，一文了解Bitcoiner该做什么 注：原文来自bitcoinops。Taproot激活时会发生什么？在这篇文章发布后不到两周的时间，Taproot将于区块高度达到709,632时在比特币网络激活，关于它的期待点，我们已经有所了解，而现在，我们有必要来了解一些可能存在的故障模式。最好（也是最可能）的结果就是一切顺利，发生的任何事都不应该对普通用户可见，只有那些仔细监控自己的节点，以及试图创建Taproot交易的人才能注意到任何事情。在区块高度达到709,631时，我们知道的几乎所有全节点都将执行相同的共识规则，一个区块之后，运行Bitcoin Core 0.21.1，22.0 或相关版本的节点将强制执行早期版本软件未强制执行的附加Taproot规则。而这带来的一个风险是，早期和后期版本的节点软件会接受不同的区块，早在2015年BIP66 软分叉激活期间，就曾发生过这样的事，这导致了一次6个区块的链分裂，以及多次较短的链分裂。为了防止该问题再次发生，工程师们已投入了大量努力。只有当矿工故意挖取一个无效Taproot区块，或者禁用硬编码到Bitcoin Core和相关节点软件的安全措施时，Taproot才会出现类似的问题。具体来说，要创建一次链分裂，矿工需要创建或接受一笔从Taproot输出（隔离见证 v1 输出）支出的交易，而不遵循Taproot规则。如果矿工这样做，当比特币节点运营商的经济共识拒绝掉Taproot无效区块时，他们将损失至少 6.25 BTC（大约40万美元）。在没有创建无效区块的情况下，我们无法确定这些节点运营商将做什么（节点可以完全私下运行），但据bitnodes.io/nodes/的数据表明，也许超过 50% 的节点运营商正在运行Bitcoin Core的Taproot执行版本，这可能足以确保任何创建无效Taproot区块的矿工，都会看到其区块会被网络拒绝。虽然不太可能，但从理论上讲，暂时的链分裂还是存在可能的，我们应该可以使用ForkMonitor.info等服务或Bitcoin Core中的getchaintips RPC对其进行监控。如果发生这种情况，轻量级客户端可能会收到错误确认。尽管理论上有可能获得 6 次确认，就像 2015 年的链分裂一样，但这意味着矿工会损失掉近250万美元（相比之下，2015年的损失大约为5万美元）。我们希望，在潜在损失如此大的情况下，矿工们会实际执行Taproot规则。在我们可以想象的几乎任何失败情况下，一个简单但有效的临时响应措施，就是提高你的确认数限制。如果你在接受付款之前通常会等待6次确认，那么你可以将确认数提高到30次，以等到问题得到解决。对于确信全节点运营商的经济共识将执行Taproot规则的用户和服务，更简单的解决方案是仅从Bitcoin Core 0.21.1或更高版本（或兼容的替代节点实现）获取有关的交易确认信息。我们希望Taproot激活能够顺利进行，但也确实鼓励交易运营商及任何在709,632区块附近接受大额交易的人升级节点，或准备在出现任何问题迹象时临时提高确认数。

隐藏在众目睽睽之下：复盘etherscan的零日漏洞 “如果你在etherscan中找到一个0day（零日）漏洞，你会怎么做？我决定构建一个‘弹球机‘。" ——paradigm研究合伙人samczsun注：原文作者是samczsun。我喜欢挑战假设。我喜欢尝试做不可能的事情，找到别人错过的东西，用他们从未见过的事来使他们震惊。去年的时候，我根据一个非常费解的Solidity漏洞为Paradigm CTF 2021 编写了一个挑战。虽然公开披露了一种变体，但我找到的漏洞从未真正被讨论过。结果，几乎所有尝试过挑战它的人，都被它看似不可能的性质所难倒。几周前，我们正在讨论关于Paradigm CTF 2022的计划，当时Georgios在推特上发布了一条难题推文，我认为在启动电话会议的同一天发布一个挑战会非常酷。然而，这不可能只是一次老掉牙的挑战。我想从这个世界得到一些东西，一些没有人会看到的东西，一些超越人们想象极限的东西。我想编写第一个利用0day（零日）漏洞的以太坊 CTF 挑战。如何制造0day（零日）漏洞作为安全研究人员，为了优化我们的时间，我们会做出一些基本假设。一是我们正在阅读的源代码确实产生了我们正在分析的合约。当然，只有当我们从可信的地方读取源代码时，这种假设才成立，比如说Etherscan。因此，如果我能找到一种方法让Etherscan错误地验证某些东西，我就能够围绕它设计出一个真正迂回的谜题。为了找出如何利用Etherscan的合约验证系统，我必须验证一些合约。我在Ropsten测试网部署了一些合约来折腾并尝试验证它们。很快，我就看到了下面的界面。我选择了正确的设置并进入下一页。在这里，我被要求提供我的合约源代码。我输入了源代码并单击了验证按钮，果然，我的源代码现在附在了我的合约上。既然我知道了事情是如何运作的，我就可以开始戏弄验证过程了。我尝试的第一件事是部署一个新的合约，将foo更改为bar，并用原始源代码验证该合约。毫不奇怪的是，Etherscan拒绝验证我的合约。然而，当我手动比较两个字节码输出时，我注意到一些奇怪的事情。合约字节码应该是十六进制的，但显然有一些并非是十六进制的。我知道Solidity会将合约元数据附加到部署的字节码中，但我从未真正考虑过它是如何影响合约验证的。显然，Etherscan 正在扫描元数据的字节码，然后用一个标记替换它，“这个区域中的任何东西都可以不同，我们仍然会认为它是相同的字节码。”对于潜在的0day（零日）漏洞，这似乎是一个很有希望的线索。如果我可以欺骗 Etherscan 将非元数据解释为元数据，那么我将能够在标记为 的区域中调整我部署的字节码，同时仍然让它验证为合法的字节码。我能想到的在创建事务中包含一些任意字节码的最简单方法，是将它们编码为构造函数参数。Solidity 通过将 ABI 编码形式直接附加到创建交易数据上来对构造函数参数进行编码。然而，Etherscan太聪明了，它将构造函数参数排除在任何类型的元数据嗅探之外。你可以看到构造函数参数是斜体的，以表明它们与代码本身是分开的。这意味着我需要以某种方式欺骗 Solidity 编译器，使其发出我控制的字节序列，以便使其类似于嵌入的元数据。然而，这似乎是一个很难去解决的问题，因为如果没有一些严重的编译器争论，我几乎无法控制Solidity选择使用的操作码或字节，之后源代码看起来会非常可疑。我考虑了一会儿这个问题，直到我意识到：导致Solidity发出（几乎）任意字节实际上是非常容易的。以下代码将导致 Solidity 发出 32 个字节的 0xAA。bytes32 value = 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;受到鼓舞，我很快写了一个小合约，它将推送一系列常量，以便 Solidity 会发出与嵌入的元数据完全相似的字节码。令我高兴的是，Etherscan 在我的合约中间标记了IPFS 哈希的存在。我快速复制了预期的字节码，并用一些随机字节替换了 IPFS 哈希，然后部署了生成的合约。果然，Etherscan 像往常一样考虑了不同的字节业务，并允许我的合约得到验证。有了这个合约，源代码建议在调用 example() 时应该返回一个简单的字节对象。 但是，如果你真的尝试调用它，就会发生这种情况。$ seth call 0x3cd2138cabfb03c8ed9687561a0ef5c9a153923f 'example()'seth-rpc: ,"latest"]}seth-rpc: error: code -32000seth-rpc: error: message stack underflow (5 <=> 16)我在 Etherscan 中成功发现了一个0day（零日）漏洞，现在我可以验证行为与源代码建议完全不同的合约。而现在，我只需要围绕它设计一个解密游戏。一个错误的开始显然，这个解密游戏将围绕这样一个想法，即 Etherscan 上看到的源代码并不意味着合约的实际行为方式。我还想确保玩家不能简单地直接重放交易，因此解决方案必须是每个地址唯一的。最好的方法显然是要求签名。但是在什么情况下会要求玩家签署一些数据呢？我的第一个设计是一个具有单一公开函数的简单puzzle。玩家将使用一些输入调用该函数，对数据进行签名以证明他们提出了解决方案，如果输入通过了所有各种检查，那么他们将被标记为solver。然而，当我在接下来的几个小时内充实这个设计时，我很快就对事情的结果感到不满意了，它开始变得非常笨重和不优雅，我无法忍受在一个设计如此糟糕的puzzle上毁掉如此棒的0day（零日）漏洞想法。不得不承认，我无法在周五前完成这件事，于是我决定睡一觉。Pinball弹球难题周末我继续尝试迭代我的初始设计，但没有取得更多的进展。就好像我现在的方法碰壁了，尽管我不想承认，但我知道如果我想要我满意的东西，我可能不得不重新开始。最终，我发现自己从第一原理重新审视了这个问题。我想要的是一个解密游戏，玩家必须在其中完成各种知识检查。但是，我没有要求完成知识检查本身就是获胜的条件，相反，这可能是允许玩家选择的众多路径之一。也许玩家可以在整个puzzle中累积分数，利用这个漏洞可以获得某种奖励。赢的条件只是最高的分数，因此间接鼓励使用漏洞。我回想起我去年设计的一个挑战，Lockbox‌，它迫使玩家构建一个单一的数据块，以满足六个不同合约的要求。合约会对相同的字节应用不同的约束，迫使玩家在构建有效载荷的方式上变得聪明。我意识到我想在这里做一些类似的事情，我会要求玩家提交一个单一的数据blob，我会根据满足特定要求的某些数据部分来奖励分数。正是在这一点上，我意识到我基本上是在描述 pinboooll‌，这是我在 DEFCON CTF 2020 决赛期间面临的一个挑战。pinboooll 的噱头是当你执行二进制文件时，执行会在控制流图上反弹，就像一个球在弹球机中反弹一样。通过正确构造输入，你将能够找到特定的代码部分并获得分数。当然，也有一个漏洞，但坦率地说，我已经忘记了它是什么，我也不打算再去寻找它。除此之外，我已经有了自己想要利用的漏洞。由于我在处理的是一个运行当中的零日漏洞，我决定要尽快解决这个难题。最后，我花了几个小时让自己重新认识pinboooll的工作原理，并花了几天时间将其重新实现。这就解决了puzzle的支架问题，现在我只需要集成这个漏洞。武装化一个零日漏洞我让 Solidity 输出正确字节的方法一直是只加载几个常量，并让 Solidity 发出相应的 PUSH 指令。然而，这样的任意常数可能是一个巨大的危险信号，我想要一些能更好地融入其中的东西。 我还必须加载一行中的所有常量，这在实际代码中很难解释。因为我真的只需要硬编码两个神奇的字节序列（0xa264...1220 和 0x6473...0033），所以我决定看看是否可以在它们之间夹入代码，而不是第三个常量。在已部署的合约中，我只需要用一些其他指令替换夹在中间的代码。address a = 0xa264...1220;uint x = 1 + 1 + 1 + ... + 1;address b = 0x6473...0033;经过一些实验，我发现这是可能的，但前提是启用了优化器。否则，Solidity 会发出过多的值清理代码。 这是可以接受的，所以我继续改进代码本身。我只能在两个地址内修改代码，但是在最后看到一个悬空的地址会很奇怪，所以我决定在条件语句中使用它们。我还必须证明第二个条件的必要性，所以最后我投了一点分数奖励。我做了第一次有条件的检查，检查tx.origin是否匹配了硬编码的值，以给人们一个最初的印象，即没有必要进一步追求这个代码路径。if (tx.origin != 0x13378bd7CacfCAb2909Fa2646970667358221220) return true;state.rand = 0x40;state.location = 0x60;if (msg.sender != 0x64736F6c6343A0FB380033c82951b4126BD95042) return true;state.baseScore += 1500;现在源代码都准备好了，我必须编写实际的后门。我的后门需要验证玩家是否正确触发了漏洞利用，如果他们没有正确触发，则不给出任何提示就失败，如果他们成功触发，则奖励他们。我想确保漏洞不会被轻易重放，所以我决定只要求玩家签署自己的地址，并在交易中提交签名。为了增加乐趣，我决定要求签名位于交易数据中的偏移量0x44处，球通常会从这里开始。这将需要玩家了解 ABI 编码的工作原理，并手动将球数据重新定位到其他地方。但是，在这里我遇到了一个大问题：根本不可能将所有这些逻辑都放入 31 字节的手写汇编中。幸运的是，经过一番考虑，我意识到我还有另外 31 个字节可以使用。毕竟，真正嵌入的元数据包含了另一个 Etherscan 也会忽略的 IPFS 哈希。在打了一些代码高尔夫之后，我抵达了一个可以工作的后门。在第一个 IPFS 哈希中，我会立即弹出刚刚推送的地址，然后跳转到第二个 IPFS 哈希。在那里，我会哈希调用方，并部分设置memory/堆栈以调用 ecrecover。然后我会跳回第一个 IPFS 哈希，在那里我完成设置堆栈并执行调用。最后，我将分数乘数设置为等于 (msg.sender == ecrecover()) * 0x40 + 1，这意味着不需要额外的分支。在把后门编码成一定大小后，我在推特上发布了我的Rinkeby地址，以便从水龙头处获取一些测试网ETH，然后向任何观看这条推文的人暗示可能会发生一些事情。接着，我部署了合约并对其进行了验证。现在剩下要做的，就是等待有缘人发现隐藏在视线中的后门。注：截至发稿时，来自Rocket Pool的软件开发者Kane Wallmann已经解出了这个谜题，具体过程在这里：https://medium.com/@kanewallmann_71759/an-untrustworthy-pinball-machine-d9dcd07882c此外，Etherscan开发者Caleb Lau也已经修复了该漏洞。

一文了解LayerZero如何将IBC带入以太坊EVM世界 注：原文作者是LayerZero Labs 首席技术官 Ryan Zarick以及总工程师Isaac Zhang。今天，庞大的Cosmos 生态系统已通过Cosmos的区块链间通信协议（IBC）连接了起来，最近，Terra 等 Tendermint 链启用了IBC，将它们连接到了Cosmos Hub、Osmosis以及许多其他Cosmos生态链。所谓IBC，它定义了一组标准，定义了一个通用的消息传输层，其中包括数据结构、抽象和语义，一旦由参与链实施，这将允许它们之间安全地进行通信。在传输层之上，IBC 还定义了一个应用层，其中包含了一组标准，例如用于可互换代币的ICS-20，它定义了应如何解释消息。然而，由于通过IBC当前的传输层去连接以太坊和其他基于EVM的区块链的成本很高，因此限制了IBC的扩展。而LayerZero 是一种全链互操作性协议，它能够向任何链上的任何合约发送消息。该消息是一个字节有效载荷，允许用户应用程序完全控制其结构和解释。简单来说：LayerZero 是一个消息传输层，用于智能合约在区块链之间进行通信。LayerZero 如何替换IBC的传输层首先，IBC的传输层管理轻客户端如何存储和验证数据（ICS-2、ICS-23）、执行连接握手（ICS-3）以及建立消息通道（ICS-4）。它是一个完整的轻客户端实现，需要明确的链上完整区块头（header）同步才能成功握手。任何消息传递都由 ICS-18 指定的中继器执行。然而，在大多数基于 EVM 的链中运行完整的轻客户端成本太高了，因此限制了IBC的传输层使用。LayerZero 通过预言机（Oracle）按需流式传输区块头来放松链上完整区块头同步假设，这是通过更高效的链外实体达到所需完整区块头同步状态的隐式方式。提交的header将与中继提交的交易凭证进行交叉验证。LayerZero合约将不同链的tx证明抽象为库。例如，以太坊和Tendermint使用不同的序列化格式（RLP vs go wire）、签名方案（secp256ka vs ed25519）和数据结构（Patricia Trie vs IAVL+树）。在分解预言机（Oracle）和中继器（Relayer）之间的职责时，LayerZero 利用已建立的预言机（例如 Chainlink 和 Band）的安全属性，并通过开放的中继器系统提供额外的安全层。只有当预言机（Oracle）和中继器（Relayer）串通时，系统才会崩溃，因为从统计上看，在不知道特定区块头的情况下，不可能发送针对区块头进行验证的交易证明，反之亦然。IBC传输层的另一个主要问题是，它只允许具有确定最终性的区块链之间进行直接通信。更高IBC抽象层的安全性和应用程序的保证取决于这种最终性。为了让 IBC 与PoW工作量证明系统(具有概率最终性)一起工作，需要一个强加确定性阈值的适配器zone （例如，在 sifchain 中定义的“peg zone”）。而LayerZero 本身就解决了上述问题，因为它可以与确定性和概率性的tx无缝协作。此属性允许 LayerZero连接具有不同网络拓扑和共识算法的异构区块链。LayerZero如何与IBC联动今天，许多应用程序正在转向多链架构，LayerZero 可以使这些应用之间无缝通信（A →A，B →B），但如果 A 想与 B 通信怎么办？一种方法是让 A 和 B 团队设计一套商定的规则，来解释两个应用程序之间的消息传递。消息标准将针对 A 和 B 想要执行的特定类型的通信进行高度优化。如果 C 想在几个月后集成，但他们需要修改标准以满足他们的要求怎么办？这就是 Cosmos 的区块链间通信协议 (IBC) 的用武之地。除了作为如何在两条链之间建立通信的标准之外，IBC 还拥有一套强大的标准，例如 ICS-20，它定义了如何格式化消息以进行代币传输。来自A、B和C的团队可以利用这些社区驱动的标准来定义他们的消息传递规则，而不是重新发明轮子。现在我们来看一看：IBC当前的传输层要求每条链之间有成对的轻客户端，但在大多数基于EVM的区块链中，运行一个完整的轻客户端成本过高了，这限制了IBC向具有高吞吐量和廉价交易的区块链的延伸。但是，在所有智能合约链上运行 IBC 的强大消息传递标准不是很好吗？而通过在全链互操作性协议 LayerZero之上引入IBC，通过用LayerZero替换 IBC 的传输层，IBC 现在可以在任何地方蓬勃发展，让应用程序拥有一个社区驱动的全链通信标准。LayerZero 实施了一系列创新，使全链通信更便宜、更快捷。感兴趣的读者可以查看它的超轻节点（Ultra Light Node）设计。感谢 Kyle Samani、Zaki Manian、John Robert Reed、Bryan Pellegrino 和 Isaac Zhang 的审阅。