geek-web3 (极客 Web3)

A16z 重仓项目：EigenLayer 经济安全的价值分析

geek-web3 — Thu, 21 Mar 2024 17:35:44 -1200

我记得在研究计量经济学中的主成分和因子时，有那么一些罕见的个人启示时刻，可以在实际效益巨大的背景下欣赏到数学结构的优雅。在主成分分析（PCA）中，数据集的协方差矩阵（包含了关于变量间相互关系的大部分信息）被压缩成抽象的、重新组合的成分，这些成分按照它们携带的关于数据集本身的信息量进行排序。结果发现，少数重新组合的成分携带了大部分数据集中的信息。这些成分是协方差矩阵的特征向量，其对应的特征值是一种度量，表示可以通过该成分提取数据集变异性的量。这种线性变换工作得如此美妙，以至于我们花费大部分时间不是在计算，而是在给识别出的主成分命名。

在 EigenLayer 再质押（或是双重质押）

正如我们团队经常做的那样，我们要把没用噪音屏蔽了，从大量的数据或信息中提取出有价值的部分。通常，一个包含在另一个中。——Block unicorn 注释：主成分分析（PCA）的过程。在这个过程中，数据集的协方差矩阵（包含了关于变量间相互关系的大部分信息）被压缩成结构性的、重新组合的成分）。

但是对于 EigenLayer 来说，噪声是什么？EigenLayer 如何定义自己？根据其白皮书，EigenLayer 是一个再质押的聚合体——这确实是加密市场中一个非常简单而强大的特性。但是，再质押聚合体究竟意味着什么？在追求简化的过程中，我请求技术专家原谅我的不准确之处。

简而言之，EigenLayer 使以太坊验证者能够将他们的信标链提款凭证指向 EigenLayer 智能合约，从而选择加入在 EigenLayer 上构建的新模块。本质上，在 EigenLayer 上构建的模块可以利用目前在以太坊主网上提供的安全质押，来获取资金支持。引入额外的临时惩罚条件（因为节点出现宕机或是作恶需要受到惩罚）。因此，以太坊验证者（验证节点）可以通过以某种形式借出质押资本以供其他用途使用，从而获得额外的收入流，而另一方面，构建在 EigenLayer 上的安全模块可以利用现有的以太坊验证者池（stETH 等质押凭证）。自然，这些额外的模块必须为以太坊验证者提供适当的激励，以提供这种增加的安全保障，这就是所谓的再质押过程。

大家都知道的是，该团队强调了有效解锁质押的 ETH 池的能力，并突出了明显的优势——我们在下面重新阐述了白皮书的观点，并暂时按照其面值理解：

对于在以太坊上构建的那些模块，不需要额外的安全层，也不需要另一种数字资产（代币）作为安全抵押。
对于不再与专用模块（但只间接与以太坊）交互的用户，可以减少费用溢出。
对于质押者，可以减少资本（机会）成本——这是与需要锁定资本以（购买和）锁定特定安全代币相关的成本。Block unicorn 注释：对于那些质押者来说，他们可以减少因为需要锁定资本以购买和锁定特定安全代币（stETH）而产生的资本成本。这里的"资本（机会）成本"是指，为了购买和锁定特定的安全代币，质押者需要将他们的资本锁定在这个过程中，这意味着他们无法使用这部分资本进行其他可能带来收益的投资，这就是所谓的机会成本。通过 EigenLayer，质押者可以将他们的质押资本用于其他用途，从而减少这部分机会成本。
对于 DApp，可以降低（安全）创业成本——考虑到质押代币中的初始风险资本可能会大幅降低。

白皮书中强调的四个主要优势中有三个是财务性，而不是技术性。这些优势主要涉及到确保去中心化应用用户的最小可行安全性所关联的结构性成本。鉴于这些声明的财务基调，我认为从公司（或实际上是协议）财务的角度来看待它们会很有益处。

从公司或协议财务的角度来看，这些优势可以帮助降低运营成本，提高资本效率，从而提高公司的财务表现。例如，减少了需要锁定资本以购买和锁定特定安全代币的资本（机会）成本，可以使公司更有效地利用其资本，从而提高资本回报率。

此外，降低了（安全）创业成本对于 DApp 来说，意味着他们可以以更低的初始投资启动和运营他们的应用，这可能会吸引更多的创业者进入这个领域，从而推动整个生态系统的发展。

总的来说，这些财务优势不仅可以提高公司的财务表现，还可以推动整个加密货币和区块链生态系统的发展。

从公司（或协议）财务视角看待安全性

区块链通过提供一个可用的公共计算层，显著降低了构建、启动和维护/开发应用的成本。如果我们忽略这些成本，并简单地将计算层视为公共物品，我们可以概念化地认为，项目需要财务资源来创建和控制一个通称为安全性的资产。通常，DApp 中的安全性是通过要求外部方投资于特定协议的代币来实现，这些代币必须被置于风险之中，以保证激励的一致性。为了吸引这些投资者，代币会提供一定的收益，并在最好的情况下，对协议经济有一些剩余的索赔权。

在协议金融术语中，可以公平地说，协议通过使用代理权益工具来筹集他们的安全性资金，这些工具可以是纯粹的或者优先的类型，具体取决于它们所附加的金融机制的类型。从协议金融的角度来看，在市场运作比较有效的情况下，股权融资实际上是公司融资的最高成本来源；如果有一位风险投资者愿意投资你的创业公司，并且即使项目失败，他也不会向你追讨已经投入的资金，你可以放心，一个好的投资者在对这样一家公司的估值中，已经嵌入了他或她预期在某种形式的权益现金流中获得的 30-50% 的内部回报率（或 IRR）。这对团队来说是一种极其摊薄的融资形式，即使成功的概率相对较高。

在代币领域，稀释不仅通过交换现金融资而放弃公司所有权发生，而且还通过经常高度稀释的激励来吸引安全提供者（和经常是用户）贡献的资本（在加密市场很少使用股权融资方式）。当通过上面的超简单流程图看时，代币激励进一步减少了最佳情况未来估值的所有权，因此进一步压低了今天的预期估值。坦率地说——在我个人的观点中，如果我们今天看私人估值，我们可以推断那些更多的是对公开市场定价错误的赌注。

降低机会成本 → EigenLayer 的观点是，类似股权的工具是一种非常昂贵的融资形式，而某种形式的其他类型工具的再抵押是为单个协议的原子安全提供资金的更有效的方式，从财务角度来看，这绝对没有错。

优雅地说，如果我们把以太坊看作是一种拥有自己的规则和执行机制的主权经济系统，投资者（或公民）直接用$ETH 而不是美元来评估风险，那么允许这些投资者为安全性质押$ETH 的过程就类似于让贷款人通过一种波动性较低的混合形式的债务来融资公司的资产。这种类型的债务，即使在物理上可能的最低级别，也比特定项目的股权成本低。其效果将是降低项目的资本成本，并降低创新的门槛。

EigenLayer 对信任执行（即安全性）的描述非常优雅。研究团队确定了开发者可用的三种信任来源：

经济性：风险资本的相对多少，反映了投资者对项目的信心水平。
于去中心化：从拥有足够分散的独立和隔离的运营商网络推断出来。
与包容性相关：以太坊验证者因为有权提议区块和运行共识软件，因此他们的特权地位会产生一种信任感。

在这里，考虑到我所做研究的性质（以及我的有限能力）以及这一现象的深远意义，我们集中在基于经济的信任。质押激励对齐在交易领域并不新颖，提供了透明和可观察的一致性，并且能够对不当行为进行及时纠正。然而，这种方法在资本使用上存在固有的低效率，因为它需要将大量资源锁定在非生产性的方式中以确保信任，这是我们上面探讨过的话题，也是 EigenLayer 想要缓解的问题。

经济安全和市场效率不足

EigenLayer 非常强调通过再质押$ETH 来显著降低经济安全成本的能力，以替代本地类股权工具。从协议金融的角度来看，我是否同意这种说法？我的回答是，这取决于询问者是谁。

对于以$ETH 计价的投资者而言，使用$ETH 而不是类似股权工具可以节省很多成本，这在很大程度上是有道理的。但对于以美元计价的投资者来说，这就不那么重要了。对于那些用美元思考、评估和定价的投资者来说，用$ETH 替代本地质押代币在降低风险和获得额外收益方面效果并不明显。幸运或不幸的是，99.99% 的投资者和建设者在这个领域都是以美元思考、评估和定价的。

什么时候（When）会有新的代币（token）发行或上线？现实点说，无论它们是否是实际上的证券，具有某种形式的治理功能、实用性、经济性或稀缺性声明的项目特定代币，都被投资者视为项目成功或知名度的代理。即使没有任何剩余的财务或控制权声明，市场情绪也存在这种观点。在像加密货币这样规模较小的行业中，代币往往更多地与叙述或预期的流动性变化联系在一起，而不是现金流。无论我们如何看待，很明显并且可以证明的是，在加密货币中，用于代表股权的市场远未达到有效率，并且高于理性可辨认的代币价格意味着项目的资本成本低于理性预期的水平。通常来说，低成本的资本体现在风险投资轮次中的较低稀释率，或者较其他行业更高的估值。可以说，由于资本市场整体存在的市场效率低下，对于项目创建者来说，使用本地代币的资本成本要比使用$ETH 更低（Block unicorn 注释：大部分项目都会发行自己的代币，使用自己代币可以有更低的成本，重新自定义资本分配，可以更好的配合项目持续的发展）。

双重质押允许 → EigenLayer 的团队不是在与外界隔绝的状态下工作，而是积极地了解和参与周围的环境和趋势，这一点从白皮书的最后一部分，即关于多代币仲裁的部分可以看出。在后来被称为双重质押的机制中，可验证安全性（AVS）可以指定多个仲裁，一个基于质押的$ETH，另一个基于本地代币。虽然 EigenLayer 将项目定义更精准的共识系统作为双重质押的关键目标，但我们不能忽视这种机制确实是为了满足推出本地代币的愿望，以为投资者和团队提供适当的退出流动性窗口。具有讽刺意味的是，采用这种方法可能会无意中加剧本地代币的混乱，导致重大的不良选择，并增加建设者的固有资本成本——这些建设者在很大程度上通过（预）销售代币来筹集资金。

在他们的白皮书中，EigenLayer 团队进一步描述了一个用于有效分配$ETH 资源的市场，从而进一步降低资金成本，并提高合并安全性，尽管我仍不太清楚这种好处是如何实现。白皮书描述了协议如何通过为独立质押者、LST（流动性质押代币）持有者或 LP 代币持有者提供与 EigenLayer 智能合约交互的适当途径，来最大化再质押的灵活性——这就是所谓的超流体质押者（拥有超高流动性和收益）。虽然这些是包装以太坊原生收益并增强其互操作性的各种方法，但每种方法都有其自身的财务和技术风险，我们暂且搁置这些差异，因为它们与对 EigenLayer 协议本身的分析并不直接相关。

正在质押的 ETH

根据最新数据（3 月 11 日），在 EigenLayer 合约中存放了价值约 120 亿美元的质押$ETH（或约 310 万$ETH），其中约 130 万$ETH 是本地质押的，其余以 LST 的形式存在，其中 Lido 的份额最大。自协议推出以来，总锁定价值（TVL）已大幅增长，使 EigenLayer 成为基于 DefiLlama 数据排名第二大的以太坊 DeFi 协议，仅次于 Lido。Lido 的$stETH 和 Lido 的再质押的$stETH 之间的重复计算的讽刺之处没有逃过我的注意。

在该平台上再质押的过程取决于再质押的类型。LSD（Liquid Staking Token，流动性质押凭证）可以通过与前端交互轻松再质押，目前 LSD 的存款已经达到上限。本地再质押略微复杂一些，涉及创建一个 EigenPod 合约，以及定义一组验证者提取凭据。我们不打算（也无法）提供 EigenLayer 的技术概述，而打算专注于该设置的财务和激励影响。

根据这个出色的 Dune 仪表板显示，总$ETH 供应量约为 120 百万美元，目前约有 26% 质押，其中约有 2.5% 再质押到 EigenLayer 上的约 116,000 个存款钱包。这是一个很大的数字。需求端（可验证安全性和从再质押池中受益的 Rollup）正在增长，但这绝对只是一个开始。

EigenLayer 积分

那么为什么$ETH 的质押者要参与到汇集再质押社区中呢？在 2020 年至 2022 年的牛市巅峰时期，答案是代币。但今天，答案是积分，这是一个很大的区别。

积分是存储并在链下验证的忠诚度措施，理论上提供未来参与空投或数字代币分发的权利。换句话说，它们是数字资产的一种松散衍生品，为持有者提供一定程度的安慰，即它们将获得数字资产，最有可能以空投的形式，在更远的未来具有一定的财务价值。如果代币是项目中权益利益的（通常是更糟糕的）代理，那么积分就是这种代理的代理，具有更少的确定性和权利。

EigenLayer 的用户根据他们的再质押时间和金额获得积分——每小时的$ETH 再质押单位。例如，质押了 1 个$stETH 持续 10 天会产生 240 个再质押积分，目前已发行了约 20 亿个再质押积分。

一位存款人 i 在时间 t 为一定数量的代币 j 参与度的度量，以 $ETH 的名义单位来衡量

虽然无法保证积分会通过未来的空投转换为代币，但用户预计 EigenLayer 的代币生成事件（TGE）将在 2024 年第二季度至第三季度的某个时候发生。

其他协议也很快开始在 EigenLayer 积分暴露的基础上创建聚合结构。例如，在 Etherfi 上，用户可以获得$eETH，一种本地再质押的流动质押代币。是的，您读对了，这是再质押数字资产的衍生品的衍生品。用户将能够将质押奖励与再质押奖励以及忠诚度积分转换为再质押积分。Swell、Kelp、StakeWise 提供类似的功能，这个潮流已经出现了。

让我进行一下总结，因为有很多因素在起作用——哦天哪，我可能会错过牛市最好的时期：牛市获得到的协议积分，承诺提供未来（假设的）代币空投的曝光，以积累流动性并提供给另一个协议（EigenLayer），以换取另一种类型的积分，承诺提供未来（假设的）代币空投的曝光，以启动一个旨在避免首先创建项目代币的再质押池。如果您对 Curve 战争有所回忆，那么您并不孤单。

资金从哪里来？我们并不是一个专注于技术或交易话题的研究场所，而是专注于价值分析，旨在加深我们对经济设计的理解，希望能够帮助我们改进这些设计。任何价值分析师都应该从问钱从哪里来，预期经济回报与资金流之间的关系开始。在一个纯粹的系统中，完全使用$ETH 作为 AVS（可验证安全性）的经济安全工具，经济价值主要体现在（i）$ETH 的发行（质押收益）和（ii）资产升值上，通过较低的供应和/或更高的需求来实现。作为参考，目前（感谢超声波人群）以太坊提供约 10 亿美元的利润，或者在当前价格下约 500 倍市盈率，如果我们排除任何隐含的货币溢价，这是一个不可思议的价值。然而，我们不必估算$ETH 的隐含回报来评估将价值存放在 EigenLayer 中是否定价合理——多重质押使得$ETH 质押者不会放弃这些回报。

市场对存放在 EigenLayer 中的价值定价为多少，以及为什么？KelpDAO 通过$KEP 代币以 1 比 1 的比例将 EigenLayer 积分进行了代币化，这有助于我们（分析师）进行分析。在撰写本文时，这些代币的交易价格约为每个 0.133 美元，这意味着再质押一单位的$ETH 一年可获得 8,760 个积分或 1,165 美元的收益，或者以当前（较高）$ETH 价格获得 30% 的额外收益，什么可以证明这 30% 的增益是合理的？

由于以太坊上质押增加而导致的额外销毁
以太坊作为共识层的额外需求
对 DApp 和 AVS 的用户体验提升，从而带来了（1）和（2）的效果
对 EigenLayer 未来代币的再质押进行一定程度的经济捕捉
市场动态（我打算忽略）

有趣的是，即使我们将（1）、（2）和（3）视为现实，EigenLayer 更像是一个具有正向外部性的公共产品，而不是其他什么。（4）几乎不足以证明以当前价格下$ETH 的 30% 回报溢价。最可能的是（5）——赌注于“总锁定价值上升，代币将会上涨”的启发式方法。虽然 EigenLayer 确实可能通过规范协议安全的设计和执行实践来代表一项重大创新，供项目利用，我真诚地相信它具有这种潜力，但从价值观的角度来看，这些数据并不完全匹配。a16z 最近宣布向该公司投资 1 亿美元，有趣的是，该公告提到了对公共利益的贡献；对于 a16z 来说，在更广泛的层面上，投资于改善以太坊生态系统是经济上合理的，因为他们在这方面的投资更加广泛。因此，应该全面看待 EigenLayer 的投资，而不是孤立地看待。

风险和讽刺

上面进行的名义回报分析显然是肤浅的，没有进行风险调整，并排除了再质押者面临的额外智能合约风险、AVS（可验证安全性）层面的惩罚风险以及由于整合再质押而导致的$ETH 共识层的动荡可能带来的负回报影响。再质押确实是一个危险的因素，它增加了不透明性和系统性风险。我建议那些有睡眠问题的人阅读一下金融稳定理事会 2017 年的一份关于这个话题的报告。

那么为什么 EigenLayer 不自己采取这个方法呢？为什么不简单地开发有用的、标准化的质押框架，而不是通过它旨在部分淘汰的同样代币的金融化来推广它的采用？因为这是加密货币，伙计们，人们需要支付账单，愿牛市原谅我们所有人。

文章作者：LUCA PROSPERI 文章编译：Block unicorn

DePIN 科普文：IoTeX、DePHY 和 peaq 等基础设施是怎么运转的

geek-web3 — Mon, 18 Mar 2024 14:54:39 -1200

导语：尽管DePIN赛道在当下十分火热，但 DePIN 相关的物联网设备要大规模接入到区块链，仍存在技术上的障碍。一般而言，若要将物联网硬件接入到区块链中，要经历以下三个关键阶段：

硬件设备的可信任运行；
收集验证并提供数据；
将数据分发到不同应用。

这三个阶段中存在不同的攻击场景与反制手段，需要引入各种机制设计。本文从项目工作流程与协议设计的角度，回顾分析了物联网设备从可信任产生数据，验证存储数据，通过计算产生证明，和向区块链 rollup 数据的整个流程。如果你是 DePIN 赛道的创业者，希望本文可以在方法论和技术设计上对你的项目发展有所帮助。

下文中，我们以空气质量检测的场景为例，结合 IoTeX、DePHY、peaq 这三个 DePIN 基础设施进行分析，向大家阐明 DePIN 基础设施是如何工作的。此类基础设施平台可以对接物联网设备与区块链/Web3 设施，帮助项目方快速启动 DePIN 应用类项目。

硬件设备的可信任运行

硬件设备的可信任，包括设备身份的信任与程序执行可验证无篡改的信任。

DePIN 的基础工作模式

在大多数 DePIN 项目的激励方案里，硬件设备的运行者会对外提供服务，以此为筹码向激励系统索要奖励，比如在 Helium 中，网络热点设备通过提供信号覆盖，来获取 HNT 奖励。但在从系统中获取激励前，DePIN 设备需要先出示证据，证明自己的确按要求付出了一定“努力”。

这类用于证明自己在现实世界中提供了某类服务、进行了某些活动的证明，被称为物理工作证明 (Proof of Physical Work, PoPW)。在 DePIN 项目的协议设计中，物理工作证明占有举足轻重的地位，相应的也存在各种攻击场景与对应的反制手段。

DePIN 项目要依托于区块链完成激励分发与代币分配。类似于传统公链中的公私钥体系，DePIN 设备的身份核验流程中，也需要使用公私钥，私钥用于生成和签署“物理工作证明”，公钥则被外界用于验证上述证明，或作为硬件设备的身份标签 (Device ID)。

除此之外，直接用设备的链上地址接收代币激励并不方便，因此 DePIN 项目方往往在链上部署一个智能合约，合约中记录着不同设备持有人的链上账户地址，类似于数据库中一对一或多对一的关系。这种方式下，链下物理设备应当收到的代币奖励，可以直接打到设备持有人的链上账户里。

女巫攻击

绝大多数提供激励机制的平台，都会遇到“女巫攻击”，就是说有人可能操控大量的账号或设备，或是生成不同的身份证明，伪装成多个人，拿多份奖励。以我们前面提到的空气质量检测为例，提供此服务的设备越多，系统分发出去的奖励也越多。有人可以通过技术手段，快速生成多份空气检测数据以及对应的设备签名，制造大量的物理工作证明来获利，这会使 DePIN 项目的代币陷入高通胀，所以要制止此类作弊行为。

所谓的反女巫，如果不采用 KYC 等破坏隐私性的方法，最常见的措施就是 POW 和 POS，在比特币协议中，矿工要付出大量的算力资源，才能获得挖矿奖励，POS 公链则直接让网络参与者质押大量的资产。

在 DePIN 领域中，反女巫可以归结为“抬高物理工作证明的生成成本”，由于物理工作证明的生成，依赖于有效的设备身份信息（私钥），所以只要抬高身份信息的获得成本，就可以防止某些低成本生成大量工作证明的作弊行为。

针对上述目标，一种相对有效的方案是，让 DePIN 设备生产商垄断身份信息的生成权限，对设备进行定制化处理，为每部设备录入唯一的身份标签。这就好比，由公安局统一记录全体公民的身份信息，只有在公安局数据库里可查的人，才有资格领取政府补贴。

在生产环节，DePIN 设备厂商会使用程序在足够长的时间里生成根密钥，然后随机选择根密钥使用 eFuse 技术写入到芯片中。这里要科普下，eFuse（可编程电子熔断器）是在集成电路中存储信息的电子技术，录入的信息通常无法被篡改或擦除，具有较强的安全保障。

在这种生产流程下，设备持有者和生产商都无法获知设备的私钥，以及根密钥。硬件设备可以在 TEE 的隔离环境中，从根密钥导出并使用工作密钥，包含签署信息用的私钥，和交由外界验证设备身份的公钥。TEE 环境外的人或程序都无法感知到密钥的细节。

上述模式下，如果你想获取代币激励，必须要从专属厂商那里购买设备。女巫攻击者若想绕开设备厂商，低成本生成大量的工作证明，就需要破解厂商的安全系统，将自己生成密钥的公钥注册到网络许可设备中去，女巫攻击者很难低成本发起攻击，除非设备生产厂商监守自盗。

而一旦人们发现设备厂商有作恶的可疑迹象，可以通过社会共识的方式对 DePIN 设备生产厂商进行曝光，这往往会使得 DePIN 项目本身连带遭殃。但多数情况下，设备厂商作为 DePIN 网络协议的核心受益方，大多没有作恶动机，因为让网络协议井然有序运转的话，卖矿机赚的钱会比 DePIN 挖矿赚的钱多，所以他们更多会倾向于不作恶。

如果硬件设备不是由中心化生产商统一供应的，那么当任意一台设备接入 DePIN 网络时，系统要先确认该设备具有协议要求的特性。比如，系统会检查这些新加入的设备，有没有专属的硬件模块，没有此类模块的设备往往无法通过认证。而要让设备拥有上述硬件模块，要花费一定的资金，这就抬高了女巫攻击的成本，进而达到反女巫的目的。在这种情况下，还是正常运行设备而非制造女巫攻击更为明智和稳妥。

数据篡改攻击

让我们脑洞一下，如果某台设备收集到的空气质量检测数据，其波动性越强，系统就认为数据更有价值，并为此提供更多奖励，那么任何设备都有充足的动机伪造数据，让其故意表现出高波动性。即便是由中心化厂商做身份认证的设备，也可以在数据计算过程中“夹带私货”，对收集到的原始数据进行改写。

该如何保证 DePIN 设备是诚实可信的，没有对收集到的数据进行肆意修改呢？这需要用到可信固件 (Trusted Firmware) 技术，其中较为出名的是 TEE(Trusted Execution Environment), 还有 SPE(Secure Processing Environment).。这些硬件层面的技术，可以保障数据在设备上按照事先验证过的程序来执行，计算过程中没有“夹带私货”。

这里简单介绍下，TEE(可信执行环境) 通常是在处理器或处理器核心中实现的，用于保护敏感数据，执行敏感操作。TEE 提供了一个受信任的执行环境，其中的代码和数据能够受到硬件级别的安全保障，以防止恶意软件、恶意攻击或未经授权的访问。比如，Leger, Keystone 这些硬件钱包都有使用到 TEE 技术。

大多数现代芯片都支持 TEE，尤其是针对移动设备、物联网设备和云服务的芯片。通常情况下，高性能处理器、安全芯片、智能手机 SoC（系统级芯片）和云服务器芯片都会集成 TEE 技术，因为这些硬件涉及的应用场景，往往对安全性有较高的追求。

但是，不是所有的硬件都支持可信任固件，一些较低端的微控制器、传感器芯片和定制的嵌入式芯片可能缺乏对 TEE 的支持。对于这些低成本芯片，可以通过探针攻击等手段去获取芯片内留存的身份信息，进而伪造设备身份和行为。比如，攻击获取到芯片上保存的私钥数据，然后使用私钥对篡改或伪造的数据进行签名，伪装成设备自身运行生成的数据。

但探针攻击依赖于专门设备和精确的操作、数据分析流程，攻击成本过高，远高于从市场上直接获取这类低成本芯片的成本。相比于通过探针攻击等手段破解伪造低端设备的身份信息来获利，攻击者会更愿意直接购买更多台低成本的设备。

数据源攻击场景

前面提到的 TEE 可以保证硬件设备如实的生成数据结果，只能证明数据在输入到设备内部后，没有被恶意的处理，但无法确保数据在进行计算处理前，其输入源头可信，这其实类似于预言机协议面对的难题。

比如，某台空气质量检测仪，被放置在了排废气的工厂附近，但有人在夜里用密闭的玻璃罐把空气质量检测仪罩起来，那么这台空气检测仪获取的数据必定不真实。但上述攻击场景往往无利可图，攻击者大多数时候没必要这么做，因为是费力不讨好。对于 DePIN 网络协议而言，只要设备满足诚实可信的计算过程，付出了满足激励协议所要求的工作量，理论上就该获得奖励。

方案介绍

IoTeX

IoTeX 提供了 W3bStream 开发工具，将物联网设备接入到区块链和 Web3 当中。在 W3bStream 物联网端的 SDK 中，包含了通信和消息传递、身份和凭证服务以及密码学服务等基本组件。

W3bStream 的 IoT SDK 对加密功能的开发非常完善，包含多种加密算法的实现，比如 PSA Crypto API, Cryptographic primitives, Cryptographic services, HAL, Tooling, Root of Trust 等模块。

有了这些模块，可以在各种硬件设备上，用安全或欠安全的方式去对设备产生的数据进行签名，并通过网络传递到后续数据层供验证。

DePHY

DePHY 在物联网端提供了 DID(Device ID) 认证服务。DID 由生产商铸造，每一个设备都有且仅有一个对应的 DID。DID 的元数据可以自定义，可以包含设备序列号、型号、保修信息等等。

对于支持 TEE 的硬件设备，最开始由生产商生成密钥对，使用 eFuse 将密钥写入芯片中，而 DePHY 的 DID 服务，可以帮助生产商根据设备公钥来生成 DID. 而生产商生成的私钥除了被写入到物联网设备，就只有生产商持有。

由于可信任固件可以实现安全可靠的消息签名与硬件端私钥保密，如果人们发现网络中存在作弊生成设备私钥的行为，基本就可以认为是设备生产商在作恶，就可以溯源到对应的生产商身上，实现信任溯源。

DePHY 的用户在买入设备后，可以获取设备的激活信息，再调用链上的激活合约，将硬件设备的 DID 与自己的链上地址关联绑定，进而接入到 DePHY 网络协议中。物联网设备经过 DID 设置流程后，就可以实现用户与设备之间的数据双向流动。

当用户通过链上账户向设备发送控制指令时，流程如下：

确认用户拥有访问控制权限。由于设备的访问控制权限以 metadata 的形式写在 DID 上，可以通过检查 DID 来确认权限；
允许用户和设备开通私密通道建立联接来支持用户控制设备。DePHY relayer 除了 NoStr relay 外，还包含 peer-to-peer 的网络节点，可以支持点对点通道，由网络里的其他节点帮忙中继流量。可以支持用户在链下实时控制设备。

在物联网设备向区块链发送数据时，后续数据层会从 DID 上读取设备的许可状态，只有通过注册被许可的设备才能上传数据。比如被生产商注册过的设备。

这个 DID 服务另一项有意思的功能在于提供了物联网设备的功能特性 (trait) 认证。这项认证可以识别出物联网硬件设备是否具有某些特定功能，达到足以参与特定区块链网络的激励活动的资格。比如一台 WiFi 发射器，通过识别到具有 LoRaWAN 的功能 (trait)，可以认为具有提供无线网络连接的作用，也就可以参与到 Helium 网络中。类似的，还有 GPS trait, TEE trait 等。

在拓展服务方面，DePHY 的 DID 还支持参与质押，链接可编程钱包等，方便参与链上活动。

peaq

peaq 的方案比较奇特，它的方案分为三个等级，分别是源自设备的认证、模式识别校验、基于预言机的认证。

源自设备的认证：peaq 同样提供了生成密钥对，在设备上使用私钥签署信息，将设备地址 peaq ID 绑定用户地址等功能函数。但是，在他们的开源代码中却找不到可信固件的功能实现。peaq 简单的使用私钥对设备信息进行签名的认证方式，并不能保证设备的诚信运行和数据未经篡改。peaq 更像是一个乐观 Rollup，默认设备不会作恶，然后在后续阶段去验证数据的可信状况。
模式识别校验：第二个方案是结合机器学习、模式识别。通过学习之前的数据得到模型，当新的数据输入时，与先前的模型做比较，判别是否可信。但统计模型其实只能识别出异常数据，并不能判断物联网设备是否诚实运行。比如，城市 A 中的某台空气质量检测仪放置在了地下室，收集产生的数据与其他空气质量检测仪都不一样，但并不代表数据伪造，设备仍在诚实运行。另一方面，只要收益足够大，黑客们也愿意使用 GAN 等方法，生成机器学习难以鉴别的数据，尤其是判别模型公开共享的情况下。
基于预言机的认证。第三个方案是他们会挑选一些更受信任的数据源作为预言机，与其它 DePIN 设备收集上来的数据进行比较验证。比如，项目方在城市 A 部署了一台精确的空气质量检测仪，其他空气质量检测仪收集的数据如果偏差太大，就被认为不可信。

这种方式一方面给区块链引入并依赖权威，另一方面，也可能因为预言机数据源的采样偏差，而使得整个网络数据采样都出现偏差。

就目前的资料来看，peaq 的基础设施，在物联网端无法保证设备和数据的可信任。（注：笔者查阅了 peaq 的官网、开发文档、Github 仓库，以及一份仅有的 2018 年白皮书草稿。即使向开发团队发送邮件，也未能在发稿前得到更多补充说明资料）

数据的产生与发布（DA）

DePIN 工作流程中第二个阶段主要是收集、验证物联网设备传递过来的数据，保存起来向后续阶段提供数据，要确保数据能完整无误、可被还原的发送给特定接收方，这被称为数据可用性层 (DA 层)。

物联网设备往往通过 HTTP, MQTT 等协议，将数据和签名认证等信息广播出去。而 DePIN 基础设施的数据层在接收到设备端的信息时，需要验证数据的可信度，把通过验证的数据汇集存储起来。

这里介绍下，MQTT(MQ Telemetry Transport) 是一种轻量级的、开放的、基于发布/订阅模式的消息传输协议，旨在用于连接受限的设备，如传感器和嵌入式系统，在低带宽和不稳定网络环境下进行通信，非常适合物联网 (IoT) 应用程序。

在验证物联网设备消息的环节，会包含设备可信执行的认证和消息的认证。

设备可信执行的认证可以结合 TEE。TEE 通过将数据收集代码隔离在设备的受保护区域中，确保了数据的安全收集。

另一种方式是零知识证明，这种方法使得设备能够证明其数据收集的准确性，同时又不泄露底层数据的细节。这种方案因设备而异，对于性能强大的设备，可以在本地生成 ZKP，对于受限制的设备，则可以进行远程生成。

在认证了设备的信任之后，使用 DID 去验证消息签名，就可以确定消息是由该设备产生。

方案介绍

IoTeX

在 W3bStream 中，分为可信任数据收集、验证，数据清洗，数据存储这三个部分。

可信数据的收集、验证使用了 TEE 和零知识证明的方法。
数据清洗是指将来自不同类型设备上传的数据格式统一化、标准化，便于存储和处理。
数据存储环节，允许不同应用项目通过配置存储适配器来选择不同的存储系统。

在当前的 W3bStream 实现中，不同的物联网设备可以直接把数据发送给 W3bStream 的服务终端，也可以先把数据通过服务器收集后，再发送给 W3bStream 的服务器终端。

在接收到传入的数据时，W3bStream 会像一个中心分发调度器那样，将传入的数据分发给不同的程序去处理，而 W3bStream 生态内的 DePIN 项目，会在 W3bStream 上申请注册，并定义事件触发逻辑 (Event Strategy) 和处理程序 (Applet)

每部物联网设备都会有设备账号 (device account), 归属于一个而且也只能有一个 W3bStream 上的项目。因此，当物联网设备的消息传递到 W3bStream 服务端口时，可以先根据注册绑定信息，重定向到某个项目，并验证数据的可信。

至于前面提到的事件触发逻辑，可以定义从 HTTP API 终端、MQTT 话题接收到的数据信息，以及检测到区块链上的事件记录，检测到区块链高度等可以被触发的事件 (Event triggers) 类型，并且绑定对应的处理程序去处理。

处理程序 (Applet) 中定义了一个或多个执行函数，被编译成了 WASM 格式。数据的清洗和格式整理就可以通过 Applet 去执行。处理之后的数据被存放到由项目定义的 key-value 数据库中。

DePHY

DePHY 项目采用了更为去中心化的方式来处理和提供数据，他们称之为 DePHY 消息网络 (DePHY Message network)

DePHY 消息网络由无许可的 DePHY 中继节点 (relayer) 组成。物联网设备可以通过任意一个 DePHY 中继节点的 RPC 端口将数据传入，传入的数据会先调用中间件，结合 DID 去验证数据可信任。

通过信任验证的数据需要在不同的中继节点之间同步，形成共识。DePHY 消息网络采用了 NoStr 协议来实现。NoStr 原本的用途是用于构建去中心化的社交媒体，还记得之前有人用 NoStr 代替 Twitter 而大火么，用在 DePIN 数据的同步中居然也巧妙的合适。

在 DePHY 网络中，每台物联网设备存储的数据片段，都可以被组织成一棵 Merkle 树，节点间会彼此同步这棵 Merkle 树的 root，以及整棵树的 tree 哈希。当某个 Relayer 得到上述 Merkle Root 和 Tree 哈希后，可以快速定位还缺少哪些数据，方便从其他 Relayer 中获取补齐。这种方法能异常高效地达成共识确认 (Finalize)。

DePHY 消息网络的节点运行是 Permissionless 的，任何人都可以质押资产并运行 DePHY 网络节点。节点越多，网络的安全性越高，可访问性就越强。DePHY 节点可以通过 zk 条件付款 (Zero-Knowledge Contingent Payments) 的方式，获得奖励。也就是说，有数据索引需求的应用，在向 DePHY 中继节点请求数据时，根据可否检索到数据的 ZK 证明，来决定向中继节点支付多少费用。

同时，任何人都可以接入 DePHY 网络来监听、读取数据。项目方运营的节点可以设置过滤规则，只储存与自己项目相关的 DePIN 设备数据。由于沉淀了原始数据，DePHY 消息网络可以作为后续其他任务的数据可用层。

DePHY 协议会要求中继节点在运行时至少把接收到的数据在本地存储一段时间，再把冷数据要转存到 Arweave 这种永久性的存储平台上。如果全部数据都当作热数据去处理，最终会抬高节点的存储成本，进而提高全节点运行门槛，使得普通人难以运行全节点。

通过冷热数据分类处理的设计，DePHY 能大大降低消息网络中全节点的运行成本，更能应对海量的物联网数据。

peaq

前面的两种方案都是把数据的收集存储放在链下去执行，然后 Rollup 到区块链上去。这是因为物联网应用产生的数据量本身极大，同时又有通信延时的要求。如果在区块链上去直接去执行 DePIN 交易，数据处理能力有限而且存储成本很高。

单是等待节点共识就带来不可忍耐的延时问题。peaq 却另辟蹊径，自己搭建了一条公链，直接承载和执行这些计算和交易。它是基于 Substrate 开发的，当主网实际上线后，承载的 DePIN 设备增多，将会因为 peaq 的性能瓶颈，最终无法承载那么大量的计算和交易请求。

由于 peaq 没有可信任固件的功能，基本无法有效验证数据的可信。在数据存储方面，peaq 直接在开发文档中介绍了如何给基于 substrate 的区块链接入 IPFS 分布式存储。

将数据分发到不同应用

DePIN 工作流程中的第三阶段，是根据区块链应用的需求，将数据可用层的数据抽取出来，通过执行运算或零知识证明，把执行结果高效地同步到区块链上。

方案介绍

IoTeX

W3bStream 把这一阶段称为数据证明聚合 (Data Proof Aggregation)。这部分网络由许多聚合器节点 (Aggregator Nodes) 组成一个计算资源池 (computing resource pool), 给所有的 DePIN 项目共享调用。

每个聚合器节点会在区块链上记录自己的工作状态，是忙碌还是空闲。当有 DePIN 项目的计算需求过来时，根据链上的状态监控 (monitor) 选择空闲的聚合器节点去处理。

被选中的聚合器节点，会先从存储层检索需要的数据；然后根据 DePIN 项目的需求对这些数据做运算，并且生成运算结果的证明；最后把证明结果发送到区块链上给智能合约去验证。完成工作流程之后，聚合器节点重新回到空闲状态。

而聚合器节点在生成证明时，会用到分层聚合电路 (layered aggregation circuit)。分层聚合电路包含四个部分：

数据压缩电路：类似于 Merkle 树，验证所有收集的数据都来自特定的 Merkle 树根。
签名批验证电路：批量验证来自设备的数据的有效性，每个数据都与一个签名相关联。
DePIN 计算电路：证明 DePIN 设备按照特定计算逻辑正确执行了一些指令，例如在医疗健康项目中验证步数，或者在太阳能发电厂中验证产生的能量。
证明聚合电路：将所有证明聚合成一个单一的证明，以供 Layer1 智能合约最终验证。

数据证明聚合对于确保 DePIN 项目中计算的完整性和可验证性至关重要，为验证链下计算和数据处理提供了可靠和高效的方法。

IoTeX 的收益环节也主要在这一阶段，用户可以通过质押 IOTX 代币，运行聚合器节点。越多聚合器的参与，也就能带来更多的运算处理能力，形成算力充足的计算层。

DePHY

在数据分发层面，DePHY 提供了协处理器来监听 DePHY 消息网络的 finalized 消息，进行状态迁移 (State change) 后，将数据打包压缩并提交到区块链。

状态迁移是用于处理消息的类智能合约的函数，由不同 DePIN 项目方定制，还包括 zkVM 或 TEE 的计算打包数据处理方案。这部分由 DePHY 团队向 DePIN 项目方提供项目脚手架 (Scaffold) 来开发和部署，具有很高的自由度。

除了 DePHY 提供的 co-processor, DePIN 项目方也可以根据项目脚手架将 DA 层的数据接入到其他基础设施的计算层，实现上链。

综合分析

尽管 DePIN 赛道火热，但物联网设备要大规模接入到区块链，仍存在技术上的障碍。本文从技术实现的角度，回顾分析了物联网设备从可信任产生数据，验证存储数据，通过计算产生证明和向区块链 rollup 数据的整个流程，从而支持将物联网设备集成到 Web3 应用中。如果你是 DePIN 赛道的创业者，也希望本文可以在方法论和技术设计上能对项目发展有所帮助。

在选择分析的三个 DePIN 基础设施中，peaq 依然像六年前网上的评论一样，is just hype. DePHY 和 IoTeX 都选择了链下收集物联网设备数据，然后 rollup 到链上的工作模式，能够在低时延、保证设备数据可信的条件下，将物联网设备数据接入到区块链。

DePHY 和 IoTeX 又各有侧重，DePHY 的 DID 包含了硬件功能 trait 的验证，双向数据传输等特点，DePHY 消息网络更注重于去中心化的数据可用层，更多是作为低耦合的功能模块与 DePIN 项目结合；IoTeX 的开发完整度很高，有完整的开发工作流程，更侧重于给不同事件绑定处理程序，偏向计算层。DePIN 项目方可以根据实际需求，选择不同的技术方案去组合。

如果读者在 DePIN 方向有创业项目，也可以通过 telegram 与笔者讨论交流。 Tele: @pika042

解读 Starknet 智能合约模型与原生 AA：特立独行的技术巨匠

geek-web3 — Sun, 10 Mar 2024 20:03:38 -1200

摘要：·Starknet 最主要的几大技术特性，包括利于 ZK 证明生成的 Cairo 语言、原生级别的 AA、业务逻辑与状态存储相独立的智能合约模型。

Cairo 是一种通用的 ZK 语言，既可以在 Starknet 上实现智能合约，也可以用于开发偏传统的应用，其编译流程中引入 Sierra 作为中间语言，使得 Cairo 可以频繁迭代，但又不必变更最底层的字节码，只需要把变化传导至中间语言身上；在 Cairo 的标准库内，还纳入了账户抽象所需要的许多基本数据结构。
Starknet 智能合约将业务逻辑与状态数据分开来存储，不同于 EVM 链，Cairo 合约部署包含“编译、声明、部署”三阶段，业务逻辑被声明在 Contract class 中，包含状态数据的 Contract 实例可以与 class 建立关联，并调用后者所包含的代码；

Starknet 的上述智能合约模型利于代码复用、合约状态复用、存储分层、检测垃圾合约，也利于存储租赁制和交易并行化的实现。虽然后两者目前暂未落地，但 Cairo 智能合约的架构，还是为其创造了“必要条件”。
Starknet 链上只有智能合约账户，没有 EOA 账户，从一开始就支持原生级别的 AA 账户抽象。其 AA 方案一定程度吸收了 ERC-4337 的思路，允许用户选择高度定制化的交易处理方案。为了防止潜在的攻击场景，Starknet 做出了诸多反制措施，为 AA 生态做出了重要的探索。

前言

继 Starknet 发行代币之后，STRK 逐渐成为以太坊观察者眼中不可或缺的要素之一。这个向来以“特立独行”“不重视用户体验”而闻名的以太坊 Layer2 明星，就像一个与世无争的隐士，在 EVM 兼容大行其道的 Layer2 生态里默默的开辟自己的一亩三分地。

由于太过忽视用户，甚至公开在 Discord 开设“电子乞丐”频道，Starknet 一度遭到撸毛党的抨击，在遭喷“不近人情”的同时，技术上的深厚造诣瞬间变得“一文不值”，似乎只有 UX 和造富效应才是一切。《金阁寺》中那句“不被人理解成了我唯一的自豪”，简直就是 Starknet 的自我写照。

但抛开这些江湖琐事，单纯从代码极客们的“技术品味”出发，作为 ZK Rollup 先驱之一的 Starknet 和 StarkEx，几乎就是 Cairo 爱好者眼中的瑰宝，在某些全链游戏开发者心中，Starknet 和 Cairo 简直就是 web3 的一切，无论是 Solidity 还是 Move 都无法与之相提并论。现如今横亘在“技术极客”和“用户”之间的最大代沟，其实更多归因于人们对 Starknet 的认知欠缺。

抱着对区块链技术的兴趣与探索欲，以及对 Starknet 的价值发现，本文作者从 Starknet 的智能合约模型与原生 AA 出发，为大家简单梳理其技术方案与机制设计，在为更多人展示 Starknet 技术特性的同时，也希望让人们了解这个“不被人所理解的独行侠”。

Cairo 语言极简科普

下文中我们将重点讨论 Starknet 的智能合约模型与原生账户抽象，说明 Starknet 是如何实现原生 AA 的。读完此文，大家也可以理解为什么 Starknet 中不同钱包的助记词不能混用。

但在介绍原生账户抽象前，让我们先了解下 Starknet 独创的 Cairo 语言。在 Cairo 的发展历程中，出现了名为 Cairo0 的早期版本，以及后来的的现代版。Cairo 的现代版本整体语法类似于 Rust，实际上是一门通用的 ZK 语言，除了可以在 Starknet 上编写智能合约，也可以用于通用应用的开发。

比如我们可以用 Cairo 语言开发 ZK 身份验证系统，这段程序可以在自己搭建的服务器上运行，不必依赖于 StarkNet 网络。可以说，任何需要可验证计算属性的程序都可以用 Cairo 语言来实现。而 Cairo 可能是目前最利于生成 ZK 证明的编程语言。

从编译流程来看，Cairo 使用了基于中间语言的编译方法，如下图所示。图中的 Sierra 是 Cairo 语言编译过程中的一道中间形态 (IR)，而 Sierra 会再被编译为更底层的二进制代码形式，名为 CASM，在 Starknet 节点设备上直接运行。

引入 Sierra 作为中间形态，便于 Cairo 语言增加新特性，许多时候只要在 Sierra 这道中间语言上做手脚，不必直接变更底层的 CASM 代码，这就省去了很多麻烦事，Starknet 的节点客户端就不必频繁更新。这样就可以在不变更 StarkNet 底层逻辑的情况下，实现 Cairo 语言的频繁迭代。而在 Cairo 的标准库内，还纳入了账户抽象所需要的许多基本数据结构。

Cairo 的其他创新，包括一种被称为 Cairo Native 的理论方案，该方案计划把 Cairo 编译为能适配不同硬件设备的底层机器代码，Starknet 节点在运行智能合约时，将不必依赖于 CairoVM 虚拟机，这样可以大幅度提升代码执行速度【目前还处于理论阶段，未落地】。

Starknet 智能合约模型：代码逻辑与状态存储的剥离

与 EVM 兼容链不同，Starknet 在智能合约系统的设计上，有着突破性的创新，这些创新很大程度是为原生 AA 以及未来上线的并行交易功能准备的。在这里，我们要知道，以太坊等传统公链上，智能合约的部署往往遵循“编译后部署”的方式，以 ETH 智能合约举例：

开发者在本地编写好智能合约后，通过编辑器将 Solidity 程序编译为 EVM 的字节码，这样就可以被 EVM 直接理解并处理；
开发者发起一笔部署智能合约的交易请求，把编译好的 EVM 字节码部署到以太坊链上。

Starknet 的智能合约虽然也遵循“先编译后部署”的思路，智能合约以 CairoVM 支持的 CASM 字节码形式部署在链上，但在智能合约的调用方式与状态存储模式上，Starknet 与 EVM 兼容链有着巨大差异。

准确的说，以太坊智能合约=业务逻辑 + 状态信息，比如 USDT 的合约中不光实现了 Transfer、Approval 等常用的函数功能，还存放着所有 USDT 持有者的资产状态，代码和状态被耦合在了一起，这带来了诸多麻烦，首先不利于 DAPP 合约升级与状态迁移，也不利于交易的并行处理，是一种沉重的技术包袱。

对此，Starknet 对状态的存储方式进行了改良，在其智能合约实现方案中，DAPP 的业务逻辑与资产状态完全解耦，分别存放在不同地方，这样做的好处很明显，首先可以让系统更快速的分辨出，是否存在重复或多余的代码部署。这里的原理是这样：

以太坊的智能合约=业务逻辑 + 状态数据，假如有几个合约的业务逻辑部分完全一致，但状态数据不同，则这几个合约的 hash 也不同，此时系统难以分辨出这些合约是否冗余，是否有“垃圾合约”存在。

而在 Starknet 的方案中，代码部分和状态数据直接分开，系统根据代码部分的 hash，更容易分辨出是否有相同的代码被多次部署，因为他们的 hash 是相同的。这样便于制止重复的代码部署行为，节约 Starknet 节点的存储空间。

在 Starknet 的智能合约系统中，合约的部署与使用，分为“编译、声明、部署”三个阶段。资产发行者如果要部署 Cairo 合约，第一步要在自己的设备本地，把写好的 Cairo 代码，编译为 Sierra 以及底层字节码 CASM 形式。

然后，合约部署者要发布声明“declare”交易，把合约的 CASM 字节码和 Sierra 中间代码部署到链上，名为Contract Class。

之后，如果你要要采用该资产合约里定义的函数功能，可以通过 DAPP 前端发起“deploy"交易，部署一个和 Contract Class 相关联的Contract 实例，这个实例里面会存放资产状态。之后，用户可以调用 Contract Class 里的函数功能，变更 Contract 实例的状态。

其实，但凡了解面向对象编程的人，都应该能很容易的理解 Starknet 这里的 Class 和 Instance 各自代表啥。开发者声明的 Contract Class，只包含智能合约的业务逻辑，是一段谁都可以调用的函数功能，但没有实际的资产状态，也就没有直接实现“资产实体”，只有“灵魂”没有“肉体”。

而当用户部署具体的 Contract 实例后，资产就完成了“实体化”。如果你要对资产“实体”的状态进行变更，比如把自己的 token 转移给别人，可以直接调用 Contract Class 里写好的函数功能。上述过程就和传统面向对象编程语言里的“实例化”有些类似（但不完全一致）。

智能合约被分离为 Class 和实例后，业务逻辑与状态数据解耦合，为 Starknet 带来了以下特性：

1.利于存储分层和“存储租赁制”的实现

所谓的存储分层，就是开发者可以按照自己的需求，将数据放在自定义的位置，比如 Starknet 链下。StarkNet 准备兼容 Celestia 等 DA 层，DAPP 开发者可以将数据存放在这些第三方 DA 层里。比如一个游戏可以将最重要的资产数据存放在 Starknet 主网上，而将其他数据存储在 Celestia 等链下 DA 层。这种按照安全需求定制化选择 DA 层的方案，被 Starknet 命名为"Volition"。

而所谓的存储租赁制，是指每个人应当持续的为自己占用的存储空间付费。你占用的链上空间有多少，理论上就该持续的支付租金。

在以太坊智能合约模型中，合约的所有权不明确，难以分辨出一个 ERC-20 合约应该由部署者还是资产持有者支付“租金”，迟迟没有上线存储租赁功能，只在合约部署时向部署者收取一笔费用，这种存储费用模型并不合理。

而在 Starknet 和 Sui 以及 CKB、Solana 的智能合约模型下，智能合约的所有权划分更明确，便于收取存储资金【目前 Starknet 没有直接上线存储租赁制，但未来会实现】

2.实现真正的代码复用，减少垃圾合约的部署

我们可以声明一个通用的代币合约作为 class 存储到链上，然后所有人都可以调用这个 class 里的函数，来部署属于自己的代币实例。而且合约也可以直接调用 class 内的代码，这就实现了类似于 Solidity 中的 Library 函数库的效果。

同时，Starknet 的这种智能合约模型，有助于分辨“垃圾合约”。前面对此有所解释。在支持代码复用与垃圾合约检测后，Starknet 可以大幅度减少上链的数据量，尽可能减轻节点的存储压力。

3.真正的合约“状态”复用

区块链上的合约升级主要涉及到业务逻辑的变更，在 Starknet 的场景下，智能合约的业务逻辑与资产状态天生就是分离的，合约实例变更了关联的合约类型 class，就可以完成业务逻辑升级，不需要把资产状态迁移到新去处，这种合约升级形式比以太坊的更彻底、更原生。而以太坊合约要变更业务逻辑，往往就要把业务逻辑“外包”给代理合约，通过变更依赖的代理合约，来实现主合约业务逻辑的变更，但这种方式不够简洁，也“不原生”。

在某些场景下，如果旧的以太坊合约被整个弃用，里面的资产状态就无法直接迁移到新去处，非常麻烦；而 Cairo 合约就不需要把状态迁移走，可以直接“复用”旧的状态。

4.利于交易并行化处理

要尽可能提升不同交易指令的可并行度，必要一环是把不同人的资产状态分散开存储，这在比特币、CKB 和 Sui 身上可见一斑。而上述目标的先决条件，就是把智能合约的业务逻辑和资产状态数据剥离开。虽然 Starknet 还没有针对交易并行进行深度的技术实现，但未来将把并行交易作为一个重要目标。

Starknet 的原生 AA 与账户合约部署

其实，所谓的账户抽象与 AA，是以太坊社区发明出来的独特概念，在许多新公链中，并没有 EOA 账户和智能合约账户的分野，从一开始就避开了以太坊式账户体系的坑。比如在以太坊的设定下，EOA 账户控制者必须在链上有 ETH 才可以发起交易，没有办法直接选用多样性的身份验证方式，要添加一些定制化的支付逻辑也极为麻烦。甚至有人认为，以太坊的这种账户设计简直就是反人类的。

如果我们去观察 Starknet 或 zkSyncEra 等主打“原生 AA”的链，可以观察到明显的不同：首先，Starknet 和 zkSyncEra 统一了账户类型，链上只有智能合约账户，从一开始就没有 EOA 账户这种东西（zkSync Era 会在用户新创建的账户上，默认部署一套合约代码，模拟出以太坊 EOA 账户的特征，这样就便于兼容 Metamask）。

而 Starknet 没有考虑直接兼容 Metamask 等以太坊周边设施，用户在初次使用 Starknet 钱包时，会自动部署专用的合约账户，说白了就是部署前面提到的合约实例，这个合约实例会和钱包项目方事先部署的合约 class 相关联，可以直接调用 class 里面写好的一些功能。

下面我们将谈及一个有意思的话题：在领取 STRK 空投时，很多人发现 Argent 与 Braavos 钱包彼此不能兼容，将 Argent 的助记词导入 Braavos 后，无法导出对应的账户，这其实是因为 Argent 和 Braavos 采用了不同的账户生成计算方式，导致相同助记词生成的账户地址不同。

具体而言，在 Starknet 中，新部署的合约地址可以通过确定性的算法得出，具体使用以下公式：

上述公式中的 pedersen()，是一种易于在 ZK 系统中使用的哈希算法，生成账户的过程，其实就是给 pedersen 函数输入几个特殊参数，产生相应的 hash，这个 hash 就是生成的账户地址。

上面的图片中显示了 Starknet 生成“新的合约地址”时用到的几个参数，deployer_address 代表“合约部署者”的地址，这个参数可以为空，即便你事先没有 Starknet 合约账户，也可以部署新的合约。

salt 为计算合约地址的盐值，简单来说，就是一个随机数，该变量实际上是为了避免合约地址重复引入的。class_hash 就是前面介绍过的，合约实例对应的 class 的哈希值。而 constructor_calldata_hash，代表合约初始化参数的哈希。

基于上述公式，用户可以在合约部署至链上之前，就预先算出生成的合约地址。Starknet 允许用户在事先没有 Starknet 账户的情况下，直接部署合约，流程如下：

用户先确定自己要部署的合约实例，要关联哪个合约 class，把该 class 的 hash 作为初始化参数之一，并算出 salt，得知自己生成的合约地址；
用户知道自己将会把合约部署在哪后，先向该地址转入一定量的 ETH，作为合约部署费用。一般来说，这部分 ETH 要通过跨链桥从 L1 跨到 Starknet 网络；
用户发起合约部署的交易请求。

其实，所有的 Starknet 账户都是通过上述流程部署的，但大部分钱包屏蔽了这里面的细节，用户根本感知不到里面的过程，就好像自己转入 ETH 后合约账户就部署完了。

上述方案带来了一些兼容性问题，因为不同的钱包在生成账户地址时，生成的结果并不一致，只有满足以下条件的钱包才可以混用:

钱包使用的私钥派生公钥与签名算法相同；
钱包的 salt 计算流程相同；
钱包的智能合约 class 在实现细节上没有根本性不同；

在之前谈到的案例中，Argent 与 Braavos 都使用了 ECDSA 签名算法，但双方的 salt 计算方法不同，相同的助记词在两款钱包中生成的账户地址会不一致。

我们再回到账户抽象的话题上。Starknet 和 zkSync Era 把交易处理流程中涉及的一系列流程，如身份验证 (验证数字签名）、Gas 费支付等核心逻辑，全部挪到“链底层”之外去实现。用户可以在自己的账户中，自定义上述逻辑的实现细节。

比如你可以在自己的 Starknet 智能合约账户里，部署专用的数字签名验证函数，当 Starknet 节点收到了你发起的交易后，会调用你在链上账户中自定义的一系列交易处理逻辑。这样显然要更灵活。

而在以太坊的设计中，身份验证（数字签名）等逻辑是写死在节点客户端代码里的，不能原生支持账户功能的自定义。

（Starknet 架构师指明的原生 AA 方案示意图，交易验证和 gas 费资格验证都被转移到链上合约去处理，链的底层虚拟机可以调用用户自定义或指定的这些函数）

按照 zkSyncEra 和 Starknet 官方人员的说法，这套账户功能模块化的思路，借鉴了 EIP-4337。但不同的是，zkSync 和 Starknet 从一开始就把账户类型合并了，统一了交易类型，并且用统一入口接收处理所有交易，而以太坊因为存在历史包袱，且基金会希望尽可能避免硬分叉等粗暴的迭代方案，所以支持了 EIP-4337 这种“曲线救国”的方案，但这样的效果是，EOA 账户和 4337 方案各自采用独立的交易处理流程，显得别扭而且臃肿，不像原生 AA 那么灵便。

但目前 Starknet 的原生账户抽象还没有达到完全的成熟，从实践进度来看，Starknet 的 AA 账户实现了签名验证算法的自定义，但对于手续费支付的自定义，目前 Starknet 实际上仅支持 ETH 和 STRK 缴纳 gas 费，并且还没有支持第三方代缴 gas。所以 Starknet 在原生 AA 上的进度，可以说是“理论方案基本成熟，实践方案还在推进”。

由于 Starknet 内只有智能合约账户，所以其交易的全流程都考虑了账户智能合约的影响。首先，一笔交易被 Starknet 节点的内存池 (Mempool) 接收后，要进行校验，验证步骤包括：

交易的数字签名是否正确，此时会调用交易发起者账户中，自定义的验签函数；
交易发起人的账户余额能否支付得起 gas 费；

这里要注意，使用账户智能合约中自定义的签名验证函数，就意味着存在攻击场景。因为内存池在对新来的交易进行签名验证时，并不收取 gas 费（如果直接收取 gas 费，会带来更严重的攻击场景）。恶意用户可以先在自己的账户合约中自定义超级复杂的验签函数，再发起大量交易，让这些交易被验签时，都去调用自定义的复杂验签函数，这样可以直接耗尽节点的计算资源。

为了避免此情况的发生，StarkNet 对交易进行了以下限制：

单一用户在单位时间内，可发起的交易笔数有上限；
Starknet 账户合约中自定义的签名验证函数，存在复杂度上的限制，过于复杂的验签函数不会被执行。Starknet 限制了验签函数的 gas 消耗上限，如果验签函数消耗的 gas 量过高，则直接拒绝此交易。同时，也不允许账户合约内的验签函数调用其他合约。

Starknet 交易的流程图如下：

值得注意的是，为了进一步加速交易校验流程，Starknet 节点客户端中直接实现了 Braavos 和 Argent 钱包的签名验证算法，节点发现交易生成自这两大主流 Starknet 钱包时，会调用客户端里自带的 Braavos/Argent 签名算法，通过这种类似于缓存的思想，Starknet 可以缩短交易验证时间。

交易数据再通过排序器的验证后（排序器的验证步骤比内存池验证会深入很多），排序器会将来自内存池的交易打包处理，并递交给 ZK 证明生成者。进入此环节的交易即使失败，也会被收取 gas。

但如果读者了解 Starknet 的历史，会发现早期的 Starknet 对执行失败的交易不收取手续费，最常见的交易失败情况是，用户仅有 1ETH 的资金，但是对外转出 10ETH，这种交易显然有逻辑错误，最终必然失败，但在具体执行前谁也不知道结果是啥。

但 StarkNet 在过去不会对这种失败交易收取手续费。这种无成本的错误交易会浪费 Starknet 节点的计算资源，会衍生出 ddos 攻击场景。表面上看，对错误交易收取手续费似乎很好实现，实际上却相当复杂。Starknet 推出新版的 Cairo1 语言，很大程度就是为了解决失败交易的 gas 收取问题。

我们都知道，ZK Proof 是一种有效性证明，而执行失败的交易，其结果是无效的，无法在链上留下输出结果。尝试用有效性证明，来证明某笔指令执行无效，不能产生输出结果，听起来就相当奇怪，实际上也不可行。所以过去的 Starknet 在生成证明时，直接把不能产生输出结果的失败交易都刨除了出去。

Starknet 团队后来采用了更聪明的解决方案，构建了一门新的合约语言 Cairo1，使得“所有交易指令都能产生输出结果并 onchain”。乍一看，所有交易都能产生输出，就意味着从不出现逻辑错误，而大多数时候交易失败，是因为遇到一些 bug，导致指令执行中断了。

让交易永不中断并成功产生输出，很难实现，但实际上有一种很简单的替代方案，就是在交易遇到逻辑错误导致中断时，也让他产生输出结果，只不过这时候会返回一个 False 值，使大家知道这笔交易的执行不顺利。

但要注意，返回 False 值，也就返回了输出结果，也就是说，Cairo1 里面，不管指令有没有遇到逻辑错误，有没有临时中断，都能够产生输出结果并 onchain。这个输出结果可以是正确的，也可以是 False 报错信息。

例如假如存在以下代码段

#[external]

fn transfer(to: ContractAddress, amount: u256) -> bool {
  let from = get_caller_address();

  _balances::Write(from, _balances::Read(from) - amount);
  ...
}

此处的 _balances::read(from) - amount 可能因为向下溢出而报错，这个时候就会导致相应的交易指令中断并停止执行，不会在链上留下交易结果；而如果将其改写为以下形式，在交易失败时仍然返回一个输出结果，留存在链上，单纯从观感上来看，这就好像所有的交易都能顺利的在链上留下交易输出，统一收取手续费就显得特别合理。

#[external]
fn transfer(to: ContractAddress, amount: u256) -> bool {
  let from = get_caller_address();

  _balances::Write(from, _balances::read(from) - amount);
}

StarknetAA 合约概述

考虑到本文有部分读者可能存在编程背景，所以此处简单展示了一下 Starknet 中的账户抽象合约的接口：

上述接口中的 validate_declare，用于用户发起的 declare 交易的验证
而validate则用于一般交易的验证，主要验证用户的签名是否正确
而execute则用于交易的执行

我们可以看到 Starknet 合约账户默认支持 multicall 即多重调用。多重调用可以实现一些很有趣的功能，比如在进行某些 DeFi 交互时打包以下三笔交易：

第一笔交易将代币授权给 DeFi 合约
第二笔交易触发 DeFi 合约逻辑
第三笔交易清空对 DeFi 合约的授权

当然，由于多重调用是具有原子性的，所以存在一些更加复杂的用法，比如执行某些套利交易。

总结

Starknet 最主要的几大技术特性，包括利于 ZK 证明生成的 Cairo 语言、原生级别的 AA、业务逻辑与状态存储相独立的智能合约模型。
Cairo 是一种通用的 ZK 语言，既可以在 Starknet 上实现智能合约，也可以用于开发偏传统的应用，其编译流程中引入 Sierra 作为中间语言，使得 Cairo 可以频繁迭代，但又不必变更最底层的字节码，只需要把变化传导至中间语言身上；在 Cairo 的标准库内，还纳入了账户抽象所需要的许多基本数据结构。
Starknet 智能合约将业务逻辑与状态数据分开来存储，不同于 EVM 链，Cairo 合约部署包含“编译、声明、部署”三阶段，业务逻辑被声明在 Contract class 中，包含状态数据的 Contract 实例可以与 class 建立关联，并调用后者包含的代码；
Starknet 的上述智能合约模型利于代码复用、合约状态复用、存储分层、检测垃圾合约，也利于存储租赁制和交易并行化的实现。虽然后两者目前暂未落地，但 Cairo 智能合约的架构，还是为其创造了“必要条件”。
Starknet 链上只有智能合约账户，没有 EOA 账户，从一开始就支持原生级别的 AA 账户抽象。其 AA 方案一定程度吸收了 ERC-4337 的思路，允许用户选择高度定制化的交易处理方案。为了防止潜在的攻击场景，Starknet 做出了诸多反制措施，为 AA 生态做出了重要的探索。

关于 Runes 协议及“公开铭刻"发行机制的拓展讨论

geek-web3 — Wed, 06 Mar 2024 17:54:09 -1200

2024 年 3 月 2 日，Runes 生态基础设施项目 Rune alpha 的创始人，在 Github 的公开议题中，与 Runes 协议创始人 Casey 展开了讨论，双方对如何拓展 Runes 协议的「公开铭刻」机制进行了探讨。话题包括：

要不要放宽「公开铭刻」不可预留的要求？
指出了采用「公开铭刻」发行方式的 Runes 符文不存在管理权的观点
提出了一套基于铭文 NFT 和符文 FT 互相配合的发行机制设想

出于对比特币衍生资产协议的浓厚兴趣，本文作者结合上述 Runes 的一些最新话题，写作了此篇文章，就 Runes 与 Ordinals 协议的过往，以及类似的资产发行方式进行开发性的探索，相信能够对大家了解比特币生态带来帮助。

什么是 Runes 协议

所谓的 Runes 协议，是在比特币网络上发行同质化代币的协议，由 Ordinals 创始人 Casey 在发布 Ordinals 方案后，又重新构建的同质化代币方案，基于比特币 UTXO 的特性而构建，整体的设计思路非常简洁。

值得一提的是，Runes 协议计划在比特币 2024 年减半时（区块高度 840000），也即是今年四月下旬上线主网。现在 Runes 协议仍然处于优化和版本迭代的过程中。

在简要科普 Runes 的原理前，让我们先快速了解下来龙去脉，以及所谓的【公开铭刻】到底代表什么。

Runes 的提出者 Casey 在一开始并没有要做同质化代币协议的 idea，早在 2022 年 12 月时，Casey 就发布了 Ordinals 协议，意图是将 NFT 数据永久上链 Bitcoin，简单说就是将 NFT 元数据像铭文一样，记录在比特币交易的见证数据 witness 中（witness 主要包含数字签名信息），这样就能够将任意形式的内容（如文本、图像等）铭刻在指定的聪上。

随后，历史的齿轮开始转动，2023 年 3 月 8 日，匿名开发者@domodata基于 Ordinals 这个典型的 NFT 发行协议，迂回的搞出一套发行同质化代币的 BRC-20 标准，就是以铭文的方式，对那些需要上传到比特币链上的衍生资产数据，规定出统一的格式和属性（Token 名称、总供应量、单次最大铸造量等），再通过索引器去解析并追踪这些信息，展示出 BRC-20 代币相关的钱包账户和资产数额。

关键来了，BRC-20 的发行，要依赖于 Ordinals 这种比特币铭文 NFT 协议，所以在初始的发行机制上变得和 NFT 铸造过程类似，天然具备「先到先得」的特性，谁先 Mint 谁就拥有，完全不同于以太坊 ERC-20 资产发行时“项目方先部署资产合约，定义资产分配机制，官方想怎么控盘都可以”。

这种Fair Launch的特性，使得大多数人有了公平参与同质化代币初始发行的机会，项目方无预留无锁仓，每个人都可以在资产最初发行的第一时间参与。很快，BRC20 就带来了比特币链上衍生资产的发行热潮，甚至直接启动了这轮牛市。由此可知，我们今天重点讨论的「公开铭刻」的发行方式，对于 Runes 协议而言非常重要。

但 BRC-20 也带来了很多问题：BRC-20 资产的每一次操作，都要在比特币链上发起特定的交易，随着 BRC-20 资产的火爆，比特币 UTXO 数据集也快速膨胀，这使得 BTC 核心开发者对 BRC-20 产生公开质疑。

Ordinals 创始人 Casey 不仅反对 BRC-20，更是对基于 Ordinals 之上发行的 FT 资产不予认可，但是 BRC-20 的火爆，让他觉得虽然 99% 的代币都是骗局和噱头，但这些东西仍会像赌场一样无法消失。

同时，BRC-20 在比特币链上留下了“过多的痕迹”，为比特币节点带来了数据承载上的负担，但如果有人提出一套，能够在上链数据方面“减负”的资产协议，或许能减缓 BRC-20 带来的问题。

所以Casey 决定为比特币构建一种“更好的同质化代币协议”，随后在 2023 年 9 月 25 日，他发布了 Runes 协议的初步构想。

从技术角度看，Runes 协议基于比特币 UTXO 和附加信息而构建，每一笔交易的触发，都要把链下生成的数字签名信息 on chain，我们可以在签名信息中携带特定格式的消息。Runes 协议通过 OP_RETURN 操作码来标记出“特定消息”，这些特定消息就是与 Runes 资产变更相关的信息。

相比于 BRC-20 协议，Runes 优势很多，其中最重要在于：

交易步骤简化，且不会生成多余的无用 UTXO，能更好的为比特币节点“减轻负担”。此外，BRC-20 的一笔转账交易仅支持一个接收者和一种代币，而 Runes 支持同时向多个接收者转账，且可转账多种 Runes 代币。
资产数据的存储与索引更简洁：BRC-20 的数据以 JSON 格式存储在特定交易的 witness 数据中，且 BRC-20 基于账户模型，资产余额与指定的账户相关联。而 Runes 协议的数据存储在特定交易的 OP_RETURN 字段中，资产的记录方式采用 UTXO 模型，可以直接与比特币链上的 UTXO“同构绑定”。在确认一个人的 Runes 资产状况时，只需验证这个人拥有的、与 Runes 资产相绑定的特殊 UTXO，虽然还是要追溯部分信息完成计算，但无需像 BRC-20 那样扫描比特币链上的完整 UTXO 集合，这种轻量化的方式对数据索引更友好。
与 UTXO 功能拓展层兼容：Runes 基于 UTXO 的设计，使其能够与 CKB、Cardano、Fuel 等基于 UTXO 的功能拓展层更好地兼容。通过类似于 RGB++ 的“UTXO 同构绑定”，上述功能拓展层可以为 Runes 提供智能合约场景。

简要谈完了技术，我们回到本文最开始谈论的发行机制的事情。Casey 为 Runes 符文设计了两套发行方式，即「固定总量」和「公开铭刻」：

固定总量就是发行方直接铭刻所有 Runes 符文，然后再进行分发，相对更中心化。
公开铭刻就是对 Runes 符文的发行方式设定参数，比如指明一个区块高度或时间戳，在符合规则的时间段内，用户 Mint 了多少资产，最后该符文的总量就是多少。

两种发行方式对应的场景与机制完全不同，下文中我们只聊「公开铭刻」。

事实上，Sondotpin从Runes的Issues#124议题中，就开始讨论此话题，并得到了Casey的认可。

而Issues#165具体内容如下： Sondotpin：目前的公开发行，项目方/发行方不能提前预留 Runes 符文，这限制了项目方设计优秀通证经济模型的机会。

Casey：请查看之前的 Issues#124。我正在考虑放宽这个要求，允许发行方在发行时以合理的方式安排符文，甚至超出参数的设定范围。如果这样设计，相关信息会在 Runes 符文的详情页做非常突出的展示。

Sondotpin：是不是可以设计一个多次发行的机制，比如能有两轮「公开铭刻」Runes 符文，然后每一轮发行设定不同的参数？

Casey：我并不倾向于这样的做法，因为 Runes 符文本质上并没有「管理者」。发行的权限不应该掌握在有特别权限的单一实体手上。但是你可以在发行符文的时候添加一个铭文，然后在这个铭文的基础上再发行新的符文，这样就可以实现两次发行的符文都是同一个资产。当然，你也可以采用预挖的方式，然后用其他的分配方式进行发行。

如果未来 CTV 的功能能够顺利启动，就不需要协议支持了，CTV 直接可以预先设定条件模板，达到条件后就可以做符合条件设置的空投和公开发行。

围绕 Casey 和 SonPin 的讨论，个人看法：

1. 在发起项目的早期，预留部分 Token 确有必要

在早期，项目方想要实现业务的自举，需要有一定的 Token 储备去激励核心团队、凝聚社区。如果可以按照本次讨论去实现协议，是对「公开铭刻」的公平和全民参与价值的补充，可以让更多有价值基础项目方通过「公开铭刻」的方式参与到 Runes 生态中。

2. 是否预留、如何预留，是将自证的手段交给发行方

事实上，Casey 曾多次在 Youtube 视频里直言，同质化通证 99.9% 都是骗局，大家也别冠冕堂皇的说自己要改变世界，坦率地承认这是一个充满赌博和投机的行业，以诚相待，对所有人都好。IT’S JUST FOR FUN!

是从issue#124到#165，可以看到Casey对同质化通证的使用场景有了更多认可。「公开铭刻」的方式勿需质疑，在此基础上进行拓展，比如增加预留机制，是将选择的权利、自证的手段交给发行方，也是防止劣币驱逐良币的好方法。

3. 铭文 NFT 和符文 FT 将会有更多的创新空间

Casey 提出的铭文 NFT 和符文 FT 互相配合进行多轮次的发行机制设想，相当有趣。背景知识里我们说到，Ordinals 和 Runes 都是 Casey 设计的协议，应该算是两个平行关系协议，但是在 Github 上都做到 Ord 这个项目里，技术上不少交叉和配合，比如共用了同步区块这类底层逻辑。

当下热点 Runestone 和 Runecoin 等项目，也是铭文和符文互相组合创新。Runecoin 的玩儿法是最主流的铭文预挖矿，持有 Runecoin 发行的 RSIC 铭文，就会持续不断的挖出项目的符文，然后 4 月底 Runes 协议上线再分配 FT。期待未来有更多项目可以推陈出新，带来更新颖的玩儿法。

4.采用「公开铭刻」发行方式的 Runes 符文不存在所有权

Casey 原文中只表达了「Rune 不存在所有权」，但是笔者认为这应该是特指采用「公开铭刻」发行方式的 Runes 符文不存在所有权。SonPin 提出的两轮「公开铭刻」方案，就一定会有一个拥有极高权限的地址的地址来操作，这并不是 Crypto 加密领域希望看到的。

就像项目 Runecoin 在发完 21000 张 RSIC 铭文 NFT 后，很快就将父铭文打到了中本聪地址，相当于没有人能够再次使用，也就是通过技术手段承诺不做增发。这波操作本身就为其带来一大波好评，非常涨路人缘。

PS：什么是父铭文？因为在 BTC 做交互速度慢且 gas 高昂，所以当操作数量比较大的时候，为提高效率，一般会先设置一个父铭文，在父铭文的那一次交易里，直接批量处理多个子铭文，这样可以在交互的时候，节约区块链的存储空间和处理时间。

最后说一下 Casey 提到的 CTV，即「Check Template Verify」。

CTV 是一个比特币提议的协议升级，旨在通过允许用户在创建交易时，指定未来交易的模板，从而增强比特币网络的智能合约和锁定功能。CTV 的激活将使得用户能够创建更复杂的交易类型，例如可信赖的空投和开放式蚀刻，而无需协议的显式支持。

这个 CTV 提案增加了比特币网络的可编程性和灵活性，在这次讨论中提到，简单来说就是可以创建一个使用 UTXO 的解锁条件模板，有机会给 Runes 创造更多玩法。举个例子，通过「Runes 协议+CTV」，可以让 10 个用户联合使用 CTV 技术，共同 Mint 符文，然后预设未来的一些比特币支付交易的承诺之类。

空投史学研究第二弹：撸毛党的未来在哪里

geek-web3 — Wed, 28 Feb 2024 15:44:02 -1200

尽管 2023 年是刺骨寒的熊市，很多项目方还是向用户分发了大规模的空投奖励。熊市中的 FreeMoney 让用户们趋之若鹜，仅以 Coingecko 的数据为例，以空投 Token 的 ATH（alltime 最高点）价格计算，仅过去一年中，Arbitrum 和 Celestia、Blur 等项目方就向用户分发了大约 46.5 亿美元的空投。

如今，距离极客 web3 在 2023 年 9 月的空投科普文章《空投简史与反女巫策略：论撸毛文化的传统与未来》发表，已过了半年，这段时间内 Web3 行业再度发生了变化，空投分发机制也出现了新特点、新趋势。本文将对这段时间发生变化的空投机制进行分析与科普，向大家进一步展示空投策略在未来可能出现的格局与演化。

积分制成为大部分项目的空投参考指标

空投积分制的流行基本离不开 Blur 创始人铁顺的推波助澜。从 Blur 到 Blast，项目方对用户忠诚度的衡量方式，已经从最初的交易量，变为用户的存款数额及存续时间。

如今，积分制深受各大公链生态项目的喜爱，比如 Solana 上的 Magic Eden、Marginfi 和 Kamino，BTC 生态的 Bounce Bit、B²Network，而再质押 ReStaking 概念的兴起，更是把积分制的火热推至顶峰。以挖 Eigenlayer 的积分为核心，Swell、KelpDao、Ether.Fi 等再质押项目展开了积分套娃大战，目前已经出现了 LST、LRT 积分的双挖甚至三挖。

其实，当前主流的积分制可以细分为两类，即交易量为主的积分和存款为主的积分。

以交易量为主的积分模式常见于 NFT 交易市场、衍生品交易所等，这些项目会鼓励用户刷交易量，是空投积分制在过去的玩法。对于用户来说，交易量积分可以用一笔资金多次轮转完成，某种程度上鼓励了单用户多地址，要识别其中的女巫攻击，较为麻烦；

而存款积分制是另一种主流的积分模式。采用该计量方式比较多的项目是借贷平台、公链类项目，以及大热的再质押概念项目。这种模式下的积分，主要靠资金数额和留存时间来决定。

为了最大化对资金/资本的吸引力，此类项目通常不会将吸纳的资金类型限制的较为单一，而是积极吸纳多类型资产的涌入，例如 Merlin Chain 第二期就允许用户质押比特币或部分以太坊资产，以及 BRC-20、Bitamp 和 BRC-420 等铭文资产。

在如今这个 TVL 数据为王的 Web3 世界中，存款积分制简单粗暴地用空投预期吸取资金，但会长时间占用用户的资金，设置为期几个月的提款限制期，让用户付出巨大的机会成本。在如今这个女巫玩家遍地、真实身份难分难辨的时代，存款积分制可以大幅增加女巫攻击的成本，就像 Proof of Stake 一样有奇效。

存款积分制的空投预期，对于 TVL 数据的增长几乎是立竿见影的，成为当前以太坊 Layer2 的破局之道。由于 ZK 系 Layer2 在主网启动时正值熊市，ZkSync、Starknet 的 TVL 表现一直不温不火，Manta、ZKFair 等则竞相效仿 Blast，仅用了较短时间便在 TVL 数据上超越了前述的 ZK 天王，在空投结束一段时间后仍然维持着不错的数据表现。

此外，采用存款积分制的项目一般会使用一些软性的反女巫方法，比如让用户的钱包地址和 Discord、Twitter 等社交账号绑定，但即便如此，还是无法完全制止女巫攻击。

本质上来看，存款积分制只是把撸毛猎人发动女巫攻击的成本大幅度提高。有些项目方则别出心裁的，把用户是否有为其他项目做存款质押，当做一种发放空投的参考数据：比如，Altlayer 分发空投时，把“是否为 Eigenlayer 和 Celestia 的质押者”作为一条有力的限制条件。

Altlayer 空投时采用了分层制，积分分发参考了用户在 Celestia 主网质押的 TIA 金额，进行了明确层级划分，你能获得的空投金额，按照你过去在 Celestia 等网络中质押的存款数额来定，不是看你有多少个账户。但是，单个账户的空投份额还是有限，满足了存款的最低金额后，才能获得奖励，奖励的下限和上限都有明确规定。这本质上是把激励分层化的 POS。

这类空投分发方法虽然抵制了空投猎人，但手握大量资产的大户依然可以将存款分拆为多份（这就好比运行以太坊 Validator 的人，往往会把手上的 ETH 分为多份，每份 32 枚 ETH，满足每个 Validator 的最低质押门槛，然后这个人可以运行多个 Validator）

而资金小的羊毛党为了符合空投的预期条件——每个接收空投的地址至少要在过去达到 XX 金额的存款质押门槛，往往要把多个地址的资金整合到一起，作为一个单一的接受空投的账户。但对于项目方来说有钱即正义，“资产阶级”的女巫是有价值的。

其实“万物皆可积分制”，如今除了上述两种主流的积分计算方式，市场上还出现了如 LineaDeFiVoyageXP、B²Network 的 B²Buzz 和 bsquaredOdyssey、Galxe 上发布的任务等综合积分计算方案，即以用户交易量、资金存续时间为基准，加上签到、社交媒体互动行为、邀请拉人头组队等多重积分考量系统，更全面地捕获用户在其生态上的贡献度。

积分，本质就是空投承诺，类似于一种期权，你在今天付出了一定的成本，未来可以获得 XX 的预期回报。

但跟明码标价 APY 的 DeFi 挖矿不同，积分制引导下的用户，把自己的一切行为参考建立在“项目未发布的代币经济模型、未发布的空投分配方案、无法预测的市场未来状况”等条件下，进行盲挖，挖积分实际上是用户与项目方之间针对信息不对称展开的博弈，考验用户的投研能力。

同时，空投积分本质上是无限通胀的，对于资金小的用户来说，大户们的参与是对空投份额的稀释。当然这一点其实就像以太坊 Validator 的质押一样，手握大量质押资金的人会获得更多的红利（这个规律其实万年不变）。

不论是上述所说的交易量还是资金存续时间，纯粹以资金为计量单位的积分制毫无疑问会让奖励的大头流向大户；一些项目则会加上盲盒、随机积分抽奖的类彩票形式以再分配到小资金用户，以寻求大户和普通用户二者之间的平衡。

但积分制被诟病的是，跟 Web2 平台的许多既有玩法越来越相似，获得积分需要夹带着各种复杂任务，不禁让社区发问，用户究竟是体验生态还是成为项目打工的黑奴。

空投对象愈发注重核心玩家，“阳光普惠”给多链用户

不过，多重标准和筛查的广撒网式空投，能覆盖到尽可能多的用户，让不同群体皆大欢喜，项目方赢得社区的追捧。但随着撸毛工作室的内卷加剧，项目方只能寄希望于层层筛选，以将激励精准发放给真实用户，让 EVM 链上广撒网式的空投逐渐走向消亡。

但类似 Sei、Celestia 和 Dymension 的非 EVM 生态项目打开了广撒网式空投的新思路，对多链基数用户进行“阳光普惠”式的空投，核心分发对象则是链上的高质量玩家。

一般而言，空投项目方对这些高质量用户有多重考量，既会考虑在 EVM 和 Solana 等多链上与自己有合作关系，且资金丰裕的协议平台上的 TOP 级活跃用户，并通过截取部分时间段的用户交互金额、交易频次、Gas 消耗等多维度考量链上用户活跃度，寻找真正的高质量活跃玩家。

另一方面，空投往往被分发给长期质押用户，特别是质押大户，以 Cosmos 生态的 ATOM、TIA 和 INJ 生态相关质押者为代表。严格意义上来说，质押空投不算是新玩法，在上个周期即有 ATOM 质押者获得 Cosmos 系多个优质标的空投，但因为在熊市下持有者的空投收益不能覆盖 ATOM 的价格下挫所带来的损失，这种连锁空投的优点往往被忽视。

得益于模块化区块链叙事的热度，打着“质押得空投”口号的项目接连出现，加之再质押概念的火热，让质押再次成为流行叙事。质押空投叙事下，不同社区蔓延着着严重的 FOMO 情绪，人们基本都在寻找下一个“金铲子”。比如 PythNetwork 在暂无实际 APY 和空投收益发布的前提下，也获得了超过 10 万名用户的质押资金。不过，随着质押地址和质押金额的增长，空投的最低门槛估计会一步步提高。

质押的火热让项目方之间也顺水推舟形成了一套质押套娃体系。当一个项目方 A 向合作方平台 B 上的 Token 质押者发放空投，A 为自己的 Token 也推出质押功能，让质押者认为，在 A 平台质押锁仓，能再度获得其他项目方如 C 和 D 的空投，这种空投预期（实际上是 PUA）能够有效吸收 A 平台空投接收者的资金。

在这种连锁条件下，可以形成 A—B—C—D 的 Stake 无限套娃，人们最终被 Token 质押预期环环套住，人们最终付出的是资金的机会成本，得到的是空投回报。考虑到空投得到的代币，往往不同于二级市场上买来的资产，持仓成本与心理压力要远低于后者，所以这种模式下人们更愿意把资金长期锁定在有质押空投预期的平台。

除了质押 Token 的大户，部分项目方可能会给社区内的蓝筹 NFT 持有者一些空投，例如以太坊主网上的 PudgyPenguins、BoredApeYachtClub、CryptoPunks、Comomos 的 BadKids、Solana 的 MadLads 等 NFT 品牌，这类 NFT 持有者一般都为其社区 OG 用户。

总结就是，虽然阳光普照空投大家齐乐乐，但如今空投核心分发对象是高质量活跃者和质押大户。另外一个层面上来说，多链“阳光普惠”式空投一般是作为非 EVM 链生态，或新生态内的“贫瘠营销策略”，以收获口碑和捕获其他生态的玩家为主要目的。项目方仍然是以帮助生态数据增长，和增加用户链上活跃度及资金留存为目标，将这些空投尽可能交到做出贡献度的用户手中。

未来的空投规则参考条件

除上述观点外，我们发现了一些趋势，这些趋势未来有可能成为空投的参考条件：

1. 官方背景的 NFT 绑定空投份额

官方背景的 NFT 逐渐成为项目空投的新标准，尽管这些“权益类”NFT 并没有实际明牌绑定空投份额，但通过项目方在社交媒体高频提及或间接背书，不知不觉便成为如今项目方空投的潜规则。

在 Altlayer 的 AltlayerOGBadge 和 OhOttie!NFT 系列持有者获得大份额空投后，社区 FOMO 情绪蔓延之下，EigenLayer、zkSync、Berachain 等一些未开展空投的项目方，其官方 NFT 被人们视为接下来必须把握住的重要筹码。

但这些 NFT 是纪念品，还是作为空投凭证，需要用户自己具备较强的预测能力，以及长期以来对项目方态度的考察。同时，这些“权益”NFT 也因为 PUA 炒作，成为项目方在发行 Token 之前的潜在变现渠道，老鼠仓行为不在少数。

2.项目方空投有重视开发者的倾向

Blast 将空投份额对半分给了普通用户和开发者，Celestia 将空投总量的三分之一分配给 GitHub 开发者，Staknet 几乎明牌给予大量开发者空投份额奖励，越来越多的明星项目开始把空投分发重点倾斜给开发者，这使得“为项目贡献代码”或者“伪装为正经开发者”成为一种新的撸毛手法，链上开始出现大量的低质量项目，以期获得生态奖励，这种现象可能在未来愈演愈烈，当然估计也会出现新的反制手段（目测会让 AI 介入）。

3.与专业猎巫机构合作筛选合格用户

仅在近期，Celestia、Manta 就与 TrsutaLabs 合作筛选符合标准的用户，Linea 在真人验证（POH）环节提供 Nomis、GitcoinPassport、Clique 等反女巫项目选择，项目与猎巫机构合作筛选似乎成为新趋势。

专业机构会整合多链数据、用户所参与空投项目的深度，更全面的分析地址的女巫风险，但同时也被批评过度严格或不够智能误杀真实用户，例如目前还存在被打入女巫库地址的恶意转账“投毒”无辜地址无法识别的问题。

撸毛用户另类的“创新与扩散”

1.从 EVM 链向其他链扩散

随着信息的透明和 EVM 链生态的成熟，空投份额在 EVM 链特别是人满为患的以太坊 Layer2 上，僧多肉少已很常见。普通用户比金额比不过，比活跃卷不过，投入产出比的低下，使得羊毛党重新在其他方向寻找机会，把目光放在 Sui、Aptos、Solana 等 TVL 或资本背景不错的链上。

EVM 链用户的溢出效应，表现在近期 Sui、Solana 等公链在用户活跃度和 TVL 数据的不断上涨，在这些生态内寻找 Jupiter 这类 UNI 式的简单交互，即可获得空投机会，这在 BTC 生态内甚至也很常见。

2.从关注大额融资项目到关注小而精

大额融资的项目因为不缺乏现金流，空投分发的周期往往很长，羊毛党的战线也相应被拉长，长期投入却迟迟不见回报，已然成为常态。除此之外，大额融资意味着项目具备稳健性，对用户来说，如果确定性强了，会吸引许多人跑步进场，从而稀释空投份额。

对此，部分羊毛党转变方向，把注意力集中在小而精的项目上，这些项目披露的融资额度往往不大，但也因为参与用户较少，撸毛的性价比较高。因为长期 PUA 社区成员而被戏称为“三傻”的 Starknet、Layerzero 和 ZkSync，活跃数据都出现不同程度的震动下滑趋势。

还有一种撸毛策略，是寻找具有大交易所背景的项目，鉴于空投 Token 的价值取决于上大所的预期，因此很多撸毛行为围绕着与 Binance、OKX、Coinbase 等大所有关系的项目展开，如 Binance Labs Fund、Coinbase Ventures 等交易所旗下 VC 投资的项目，或各大交易所自营公链生态内的项目。另一类捡漏行为，则围绕着顶流 VC 如 Paradigm、a16z 等参与融资但额度较小，看起来偏冷门的项目。

除此之外，一些相对冷门的空投规则，例如 NFP 的持续签到、Arkham 注册，也会让人均空投份额达到爽点，但一次有致富效应的冷门规则出现后，会成为被市场充分共识的规则，想要“抄作业”形成持续的路径依赖或许不太可行。这个市场乃至于世界上，几乎充满了不确定性，过往的历史经验不一定适用于广阔的未来，一切所谓的“规则”“约定俗成”都有可能在不久的将来被改写。

或许每个赛道内的龙头项目们，都试图发明新的空投规则，这些规则或许能出现不同的创新，但万变不离其宗的是，项目方分发奖励的对象，始终离不开“早期＋深度参与＋大资金贡献”的忠实用户。

争论：空投农民与项目方的博弈

最近，Starknet 因在社交媒体上，把关注于空投的用户称为“电子乞丐”，还在官方 Discord 开设“电子乞丐”的频道，招致社区非议。类似的项目方与空投玩家冲突也发生于 Scroll 身上，后来 Scroll 与 Starknet 相关人员亲自下场与社区对线，甚至在社交媒体上拉黑用户，引起了社区震怒。尽管相关当事人后来道歉，但无法彻底消解社区的牢骚。这场公关争议对社区产生了反向营销效果，值得作为一个案例进行分析。

这起舆论事件点破了空投 Farmer 与项目方二者之间微妙的关系。羊毛党和项目方长久以来形成的空投潜规则默契，似乎让二者之间产生了误解。很多用户认为，空投是自己应得的“劳动所得”，在熊市中用户努力活跃耕耘，贡献手续费提供收入，帮助项目打造链上繁荣的假象，应当获得“酬劳”。但这些用户的目的性较强，项目方未必会充分买账。

在羊毛党尚未成群、真实用户居多的早期空投时代（可能在 2021 年及以前），因为不错的用户留存率，项目方并不排斥低净值用户的参与。但正如上文所说，由于大量羊毛党的加入，这种能让项目方 - 用户之间彼此认可的空投方式，正在持续减少。

另外，空投也不应该被当成是项目的终点。一些案例表明，成功的空投计划会激发项目的用户活跃。Jupiter 有年度空投计划，在第一期空投发放后，Jupiter 的 DAU 一度超过 Uniswap；Arbitrum 的 STIP 资助计划和 Optimism Op Grants 都使二者活跃数据长期保持高位。

一些项目方为了锁定资金也会另辟蹊径，先扶持生态项目或开发者，类似明牌不发 Token 的 Base 也通过 friend.tech、Bold 等赚钱效应的应用，吸引大户们在协议上沉淀资金，培养出用户粘性。但即便是 Uniswap 这种优秀的应用，也在发行 Token 前面临 TVL 停滞不前的问题。可以说，空投是生态出现社区贡献乏力、增长疲软甚至倒退时的大招，但绝不应该是最后一招。

结语

社区成员普遍抱怨的是，羊毛党支撑起链上数据，帮助项目在熊市里苟活下去，另一方面，很多项目方对羊毛党抱爱搭不理，但又通过各种暗示，或与第三方合作发起任务，PUA 用户参与链上交互，吸引了大量的撸毛用户，但迟迟不公布空投计划。这种表里不一在社区中往往掀起了负面情绪。

更直接吸引资金的存款空投，是租用用户手上资金的流动性，未来以空投回报用户，对于用户来说，他们也需要考虑到机会成本。

空投标准从交互式到存款式，未来以用户的沉淀资金为主要标准，可能是常态，这反映的是用户和项目方之间的博弈和需求的变化。不过这种项目方和用户的博弈，可能在牛市将近、加密市场大环境转暖之下有所缓和，在熊市项目空投分发的囚徒困境，会因为市场资金的逐渐丰裕而改善。近期还有“再质押协议比用户手上的 ETH 还多”的吐槽。伴随着项目少用户多的格局的改变，项目方的态度可能也会从嫌弃羊毛党变成争抢羊毛党。

项目方的本意不是对抗社区，只是在成千上万个工作室的加入撸毛大军后，需要更谨慎的对待空投分配。如今想要通过空投致富，基本不太现实，这需要极强的投研能力或很好的运气，能够从小众项目发现其未来价值，对于羊毛党来说，大众空投、遍地捡钱的黄金时代已然成为历史，未来的空投叙事将何去何从，一切都要考虑到那具经典的“一个人的成功固然要靠自身的努力，但也要考虑历史的进程”。

技术解读 ZetaChain：一站式多链 DAPP 底层设施

geek-web3 — Wed, 07 Feb 2024 18:37:41 -1200

作者：Howe & Faust，极客 web3

ZetaChain 是一条基于 Cosmos SDK 的 POS 公链，其区块中记录了“外部链”上发起的跨链消息与数据。用户可以在 BTC 等“外部链”上，通过类似 Ordinals 协议的原理，发布特定格式的消息，向 ZetaChain 网络传达自己的“意图”；
ZetaChain 的节点通过共识的方式，确定哪些消息要被处理，以及先后次序，最终通过 TSS 门限签名技术，在目标链上生成数字签名，从该链的公共账户中释放资产，触发后续的交易步骤。
ZetaChain 的节点通过共识的方式，确定哪些消息要被处理，以及先后次序，最终通过 TSS 门限签名技术，在目标链上生成数字签名，从该链的公共账户中释放资产，触发后续的交易步骤。从用户端来看，理论上只需要和 ZetaChain 上的合约交互，而不必与源链 - 目标链之间的桥接合约多次交互，也可以节省手续费成本。
与一些具有“一站式资产托管链”效果的 Intent 项目类似，ZetaChain 本身支持部署资产合约或 Defi 协议，用户可以在不同链上的 DAPP 前端生成特定消息，对 ZetaChain 上的 Defi 合约或资产状态，进行异步调用（支持 BTC 链上账户）；这就好像让 ZetaChain 直接托管了全链统一的资产账户，但要达成这种效果，需要专属的 DAPP 前端来配合。
目前看来，ZetaChain 最主要的功能，是充当跨链、全链互操作的底层设施，既可以解析并处理特定的跨链消息，也可以作为多链 DAPP 的业务逻辑执行平台，主要的商业模式是典型的 B to B to C。

背景

随着区块链行业的不断发展，我们正处于一个多链互联的时代。在这样的时代背景下，不同特性的公链衍生出了差异化的应用场景，为用户创造了多样化的体验，但与此同时，“链间孤岛”问题也显得愈发严重。不同链上的账户往往无法互通，人们的全链资产处于一种割裂而不统一的状态，这增加了使用门槛，也极大程度降低了用户体验。

可以说，异构链之间的割裂与不兼容问题，是阻碍用户转化率增长的主要原因之一。而当今 BTC 生态的火爆，把异构链的互操作问题进一步体现了出来。

正如 Vitalik Buterin 多年前所言：「多链是未来」。虽然多链并存已经成为大势所趋，但在异构链之间建立跨链桥，仍然是一个麻烦事。

为了解决多链互操作问题，LayerZero、Polyhedra、Map Protocol、Bool Network 乃至于 Cosmos 和 Polkadot，都曾提出不同的链间消息传递方案，而近期上线 Token 的 ZetaChain 也是全链基础设施版图中的重要一员。

下文中，我们将简要的对 ZetaChain 的全链解决方案进行技术视角的阐述，说明 ZetaChain 如何作为全链互操作 DAPP 的底层基础设施，实现跨链消息解析与处理。

现有跨链方案的问题

其实，单纯论跨链桥要解决的问题，最简单的场景是资产在不同链上的转移。你从 ETH 往 Polygon 上跨资产，要先往 ETH 链上指定的充值地址转入资产，然后在 Polygon 链上接收等量资金。

但问题在于，Polygon 的节点无法确认 ETH 链上发生了什么，不知道你是否真充值了 xx 金额。如果有人谎称，自己往 ETH 链的指定地址转了 100U，然后在 Polygon 链上发起提款声明，要求释放他的 100U，这就会出现“凭空提款问题”。

跨链桥的关键在于，解决此处的“凭空提款问题”，即确认所有的提款声明都对应着真实的充值行为，本质而言，是设法在 B 链上证明，A 链上的确发生了 N 笔与跨链桥相关的交易。

目前主流的跨链桥都倾向于采用公证人机制，就是设置一批公证人节点，通过多签或者 MPC 签名来“共识”，只要多数公证人认为你的跨链行为可以被批准，你的资产就可以顺利跨走。

也有一些跨链桥采取更安全的哈希锁，或是用链上合约实现其他链的轻节点，通过接收 merkle proof 或 zk proof，来确认跨链行为有效性，但这种跨链桥的成本往往比较高，最终会转嫁到用户手续费上。所以，多数跨链桥还是选择了链下公证人节点走多签的模式。

基于公证人的跨链桥往往面临着巨大风险：易遭黑客攻击，或监守自盗，据 SlowMist Hacked 统计，2022 年跨链桥安全事件共 16 起，损失达 12.1 亿美元，占当年链上攻击事件损失总额的 32%，由此可见跨链桥安全漏洞的危害。

同时，现有的跨链桥方案大多选择 Lock-Mint 模式，即在 A 链上锁定资产，在 B 链上增发相应的映射资产，从而实现资产跨链。但这类方案的充提款处理流程中，需要与映射资产合约进行多次交互，手续费摩擦较大，存在资金损耗问题。此外，不少跨链桥方案只支持 EVM 兼容链间的资产转移，在异构链如 Solana、Bitcoin 的跨链行为往往受制于彼此的技术标准不同，开发难度较大。

综合安全与手续费问题，目前主流的跨链桥方案往往无法取得太好的效果，更无法保证资产的“原生跨链”。而在如今的比特币生态中，越来越多的人渴望实现原生、无缝的跨链交互体验，期待找到一种更优的方案。ZetaChain 对此提出了自己的一套解决方案。

ZetaChain 的功能：全链互操作 DAPP 的底层基础设施

ZetaChain 的自我定位是全链互操作型 DAPP 的基础设施，专门支持各种全链交互类的应用协议，是一种典型的 B To B To C 底层基础设施。它通过 PoS 准入机制，允许任何质押资产的节点进入网络之中，充当公证人。全体 PoS 节点通过 TSS 门限签名技术，参与到跨链消息的验证与处理中，尽可能提升安全性。

同时，ZetaChain 上可以部署智能合约，添加与资产互换相关的业务逻辑，用户可以在任何一条链上发送特定格式的消息，调用 ZetaChain 或其支持的多链上的 Defi 合约，在 BTC 链上就可以间接调用 Polygon 上的 DeFi 功能。这样达到的效果是：在不同的区块链之间进行消息传递，实现互操作。

基于全链互操作场景的 DAPP 可以在 ZetaChain 上部署资产互换的业务逻辑，帮用户自动兑换不同链上的 gas 代币。

比如，你可以通过某些全链 DAPP 的前端，在 BTC 上通过类似 Ordinals 协议的数据发布方式，发出一条特定格式的消息，指明要调用 Solana 上的 XX 合约，这条消息会被 ZetaChain 节点监测到。

之后，ZetaChain 上的 AMM 合约可以自动计算 BTC 和 SOL 的兑换比例，然后在 Solana 链上释放等量的 SOL，完成后续的调用合约等复杂操作，最后再把你应得的资产，转回到你的 BTC 地址或 Solana 地址，这便是所谓的“全链互操作”，你只需要在一条链上发布消息，就可以远程调用多条链上的 DAPP，当然这中间涉及到好几条异步消息的发布与触发过程。

在此，我们可以将 ZetaChain 理解为一个“链中链结算层”，所有的多链交互场景，比如 A 链上发起调用 B 链的某 DAPP，相当于 A 链先和 ZetaChain 进行“结算”，然后 ZetaChain 将预处理的结算结果，同步到 B 链的相应账户，再完成后续的步骤。

整个过程中不存在与映射资产合约的过度交互及手续费摩擦，资产流通经由 ZetaChain 在不同链上的公共账户来完成，这样就不需要像传统跨链应用那样，频繁的在不同链上部署映射资产合约。

目前看来，基于 ZetaChain 的全链应用可以省去不少麻烦事，至少不需要在不同链上费尽心力的设计映射资产合约了，所有关于源链 - 目标链之间资产进入 - 进出的细节，都由 ZetaChain“承包”。换句话说，就是你只需要在 ZetaChain 上部署和跨链交易相关的业务逻辑就可以。

这样便于不同的全链应用在前端支持 Solana、Algorand、Bitcoin 和 DogeCoin 等非 EVM 链，不需要费尽心力的在不同链上实现跨链应用专属合约。

此外，ZetaChain 本身也支持部署资产合约或 AA 账户，不同链上的用户可以发送特定格式的消息来调用，就好像在操作一个全链统一的账户一般，这种设计思路在 Particle Network 的 Particle chain 上也有体现，最终达成的效果是：

用户可以尽量把资产的数据记录，集中在 ZetaChain 或 Particle Chain 一条链上，在必要时，通过“外部链”上的 DAPP 前端发送调用消息，异步调用自己在 ZetaChain 上的资产合约，然后 ZetaChain 会通过外部链上公共账户，转移一定的资产至用户消息指定的地址，或是与用户指定的 Defi 协议进行交互。

当然，这一系列操作需要专门的前端 DAPP 来实现，也就是说，ZetaChain 本身只提供全链底层设施的服务，而在应用端需要有专门的前端入口来生成特殊格式的消息。

ZetaChain 的安全模型：基于 POS 质押的大号公证人节点网络

归根结底，ZetaChain 本质上是一个专为跨链消息处理，而设置的公证人节点网络，它建立在 Cosmos SDK 基础上，由很多台 Validator 验证节点组成，并以 POS 作为准入机制，以此实现节点反女巫和底层安全。

Validator 节点们在 ZetaChain 网络中，作为去中心化的公证人存在，他们会确认其他链上触发了哪些待处理的跨链请求，并通过共识，对这些跨链行为做记录，进行后续步骤。通过 TSS 分布式密钥签名，ZetaChain 可以在其他链上生成交易指令。

可以说，Validator 做的事情，与公证人模式下的跨链桥有部分类似，但通过 POS 质押，公证人节点更去信任，以解决女巫问题。

目前 Zetachain 的验证者节点名单，有很多项目方或机构

Zetachian 的 Validator 客户端中包含 ZetaCore 和 ZetaClient 两个模块。ZetaCore 模块参与 ZetaChain 区块的产生和共识过程，ZetaClient 模块则观察外部链上的事件，并签署出站交易。

这里的出站，可以简单理解成，将 ZetaChain 上的交易日志记录，发送到“外部链”（就是指 ZetaChain 外的其他链），从而在目标链上触发对应行为，发送的内容主要包含用户在消息中声明要调用的合约地址、链 ID、消息内容，其实就类似于 Ethereum 交易中的 Log 部分。

反之，入站则可以理解成，将 ZetaChain 外的外部链上相关消息/交易，如跨链请求、调用 zEVM 上的智能合约等内容，记录到 ZetaChain 上。

这里需要注意，实际运行 ZetaChain 的 Validator 节点时，客户端代码包含验证者、观察者、TSS 签名者三个模块。这三个模块负责的职能有所不同，但同属于 ZetaChain 客户端中。

观察者和 TSS 签名者模块

首先，所有的 ZetaChain 节点都具备“验证者”的模块，与 PoS 公链中 Validator 节点的职能基本一致，要参与出块和共识流程。此外，节点可以按质押的代币（ZETA）比例，投票参与链上提案。ZetaChain 的区块中，则包含了处理的所有跨链记录、全链智能合约交互等行为，相当于日志记录。

而 ZetaChain 客户端中的“观察者”模块，会通过运行其他公链的全节点/轻节点，监测特定格式的跨链交易/消息。观察者模块可以分为两种模式：主动模式和被动模式。

不同的 ZetaChain 节点可以做出选择，将观察者模块切换到两种模式中的一个。观察者模块会持续监控，其他链上是否有 ZetaChain 相关的跨链消息/事件，如果有，ZetaChain 节点的观察者模块会向验证者模块汇报情况。这些观测到的跨链消息，会被提交到 ZetaChain 的区块里，通过共识的方式进行全体确认。

观察者模块有两种模式：主动模式和被动模式。主动模式下，节点会不断扫描 ZetaChain 外的区块链上的交易/事件/状态，运行其他链的 fullnode；而被动模式下，节点不同步其他区块链的完整 block，被动的从其他 ZetaChain 节点处，接收解析后的跨链消息。

不过，被动模式下的节点，虽然不同步完整的外部链区块，但是会同步区块头，并通过 Merkle 证明确定外部链上真的存在这些跨链消息/交易数据。

主动模式的优点是，大多数 ZetaChain 节点都会同步外部链上的数据，此时的抗审查性最强，任何用户要和 ZetaChain 产生交互，只要有节点监测到，你在外部链上发起请求即可。

但主动模式下，运行节点的成本较高，除了要运行 ZetaChain 自身的节点客户端，还要运行外部链的全节点，时刻同步数据并进行扫描。而被动模式下，普通观察者节点的运行成本低得多，只有特定节点去运行外部链的全节点客户端，其他节点只运行外部链的轻客户端，不需要同步外部链的完整区块。

这样一来，被动模式下的费用更便宜，也更容易扩展节点数量，方便对接多条外部链。但被动模式的缺点是，外部链上的数据观察活性，取决于少数节点，抗审查性差。

为了缓解这种情况，ZetaChain 会激励节点运行主动模式的观察者模块。

（主动模式下，节点还需要运行外部链的全节点客户端；被动模式下，只运行外部链的轻客户端，从主动模式的 ZetaChain 节点那里，接收跨链消息+merkle proof，确认消息的有效性）

TSS 签名

所有被 ZetaChain 节点观察到并验证过的跨链消息，最终会在目标链上通过 ZetaChain 的公共账户地址，触发一笔交易行为，进而执行后续的操作。而这个过程中，需要在目标链上为该笔跨链交易生成数字签名。

为了保证安全与去信任，签名的生成由 ZetaChain 所有节点承担，共同存储用于生成签名的密钥片段。这些密钥片段分布在多个签名者之间，只有绝大多数签名者都签名了，才能在外部链上，生成交易的数字签名。任何时候，单个实体或一小部分节点，都无法代表 ZetaChain 在外部链上触发交易/签署消息。

ZetaChain 的跨链模型下，只需要在不同的链上拥有一个公共账户地址，而不必部署复杂的智能合约）

ZetaChain 的多签算法，采用 TSS，全称为 Threshold Signature Scheme 门限签名方案。对于外界来说，我们能看到的交易数字签名，虽然只对应着一个私钥、公钥和地址，但实际上，这个私钥是由很多道片段，在没有中间人的情况下生成的，这些片段分布在所有 ZetaChain 节点设备本地。任何时候，单个实体或少数验证者都无法代表网络整体去拼凑私钥片段并签署消息。

TSS 的密钥生成和签名过程，通过多方计算（MPC）的方式完成，不会泄露任何参与节点的秘密。ZetaChain 的节点可以生成不同链上的交易签名，在兼容各 EVM 链的基础上，为比特币/非智能合约链的账户，添加了远程调用智能合约的功能，直观体验就好比 BTC 用户可以直接调用某些 defi 功能。

这种场景其实格外适合搭载 BTC 生态的多链 Defi 应用，因为 BTC 链上无法实现太复杂的业务逻辑，只能依赖于外部设施远程调用某些 Defi 合约。而 ZetaChain 的这些特性，正适合 BTC 生态内的用户通过异步调用的方式。

zEVM：一站式的全链 DAPP 合约平台

不同于传统跨链方案要在每条链上部署映射资产合约，ZetaChain 可以仅在自家链上部署一次智能合约，即实现多链的跨链功能。在 ZetaChain 中，有一个 EVM 兼容的执行层，称为 zEVM，而跨链智能合约可以直接部署在 zEVM 上。 zEVM 支持以下功能：

任何人可以在外部链上发送特定格式的交易数据，调用 zEVM 上的某个合约；
zEVM 上的合约逻辑，可以控制在外部链上生成的出站交易数据。

这两个附加功能使得 zEVM 支持通用编程，可部署特定的业务逻辑，原子性地对不同链上的状态进行修改。如果一笔跨链操作发生了，ZetaChain 检测到这笔跨链行为的后续步骤，在目标链上没有成功，则可以回滚掉该笔跨链交易在 ZetaChain 合约里修改的数据，就好像什么都没发生。

同时，全链应用 DAPP 无需在不同的链上部署映射资产合约，只需要通过 ZetaChain 链上的合约，就可以一站式的将消息跨链的处理逻辑集中设置，无需频繁的将跨链合约部署到多链网络中。

这样可以大幅度节省全链 DAPP 开发成本。在用户层面，因为不需要频繁的与多链上的映射资产合约产生交互，成本要比那些需要在不同链上部署映射资产合约的主流跨链桥更低。

此外，ZetaChain 上也可以部署专门的 Defi 合约和 ZRC-20 乃至 NFT 资产，对资产状态进行数据同步，或是部署 AA 账户。这使其具备了统一的资产管理（状态记录）平台功能。因为我们不再需要费尽心力的在多链上拥有资产，这种全链统一资产账户的场景，可以在未来赋予更多的想象力。

总结

通过前面的内容，我们或多或少对 ZetaChain 的“全链互操作基础设施”身份有了更多了解。其通过 Validator 客户端中的观察者模块，监测外部链的特定消息/交易，并汇报给验证者模块，最终在 ZetaChain 网络中对消息进行共识。再对消息包含的数据进行解析，用 TSS 生成数字签名，在对应的目标链上触发后续的交易流程，从而实现全链上的交互。

与此同时，基于 ZetaChain 的全链智能合约，使得我们可以与不同区块链进行贴近原生的交互，无需在不同的链上使用映射资产合约，这可以避免调用冗余的合约逻辑，节约了手续费成本。

同时，由于 ZetaChain 本身 EVM 兼容，可以让任何 DAPP 开发者甚至个人用户，部署定制化的跨链消息处理逻辑，理论上可以一站式的部署全链 DAPP 合约，跨链应用开发者不需要在不同的链上频繁部署/更新映射资产合约逻辑，免去了重复造轮子的成本。

参考链接

https://www.ZetaChain.com/whitepaper.pdf
https://www.ZetaChain.com/docs/
https://mp.weixin.qq.com/s/y7zGrzOsVYOQOgNekhT4mw
https://ZetaChain.notion.site/7785df1366f84042a568b51688afe3b4
https://ZetaChain.notion.site/ZetaChain-8a38becc37af4fc59185b0c6d915b326
https://www.theblockbeats.info/news/50498

极简解读 BitVM：如何在 BTC 链上验证欺诈证明（执行 EVM 或其他 VM 的操作码）

geek-web3 — Thu, 01 Feb 2024 19:19:29 -1200

导语：目前，比特币 Layer2 已经成为一股热潮，市面上自我定位为“比特币 Layer2”的项目，据说已有数十家。其中，不少自封为“Rollup”的比特币 Layer2，声称采用了 BitVM 白皮书提出的方案，使得 BitVM 成为比特币生态的显学。

但无奈的是，目前大多数关于 BitVM 的文字资料，都未能通俗的解释其原理。

本文是我们读过了 BitVM 只有 8 页的白皮书后，查阅了与 Taproot、MAST 树、Bitcoin Script 相关的资料后，得出的简单总结。为了便于读者理解，其中一些表达方式与 BitVM 白皮书中阐述的内容不同，我们假定读者对 Layer2 有一些了解，并能够理解“欺诈证明”的简单思想。

先几句话概括 BitVM 的思路：无需 on chain 的数据，先在链下发布并存储，链上只存放 Commitment（承诺）。

发生挑战/欺诈证明时，我们只把需要上链的数据 on chian，证明其与链上的 Commitment 存在关联。之后，BTC 主网再校验这些 on chian 的数据是否有问题，数据生产者（处理交易的节点）是否有作恶行为。这一切都遵循奥卡姆剃刀原则——“若非必要，勿增实体”（能少 on chain，就少 on chain）。

正文：所谓的基于 BitVM 的 BTC 链上欺诈证明验证方案，通俗总结：

1.首先，计算机/处理器，是一个由大量逻辑门电路组合成的输入 - 输出系统。BitVM 的核心思路之一，是用 Bitcoin Script（比特币脚本），模拟出逻辑门电路的输入 - 输出效果。

只要能模拟出逻辑门电路，理论上就可以实现图灵机，完成所有可计算任务。也就是说，只要你人多钱多，就可以召集一帮工程师，帮你用功能简陋的 Bitcoin Script 代码，先模拟出逻辑门电路，再用巨量的逻辑门电路实现 EVM 或是 WASM 的功能。

（此截图来自于一款教学游戏：《图灵完备》，其中最核心的内容，就是用逻辑门电路尤其是与非门，搭建出完整的 CPU 处理器）

有人曾将 BitVM 的思路比作：在《我的世界》里，用红石电路做一个 M1 处理器。或者说，相当于用积木撘出来纽约帝国大厦。

2.那么，为什么非要用 Bitcoin Script 模拟 EVM 或 WASM？这样不是很麻烦吗？这是因为大多数比特币 Layer2 往往选择支持 Solidity 或 Move 等高级语言，而目前可以直接在比特币链上运行的，是 Bitcoin Script这种简陋的、由一堆独特操作码组成的、非图灵完备的编程语言。

（一段 Bitcoin Script 代码示例）

如果比特币 Layer2 打算像 Arbitrum 等以太坊 Layer2 一样，在 Layer1 上验证欺诈证明，极大程度继承 BTC 安全性，需要在 BTC 链上直接验证“某笔有争议的交易”或“某个有争议的操作码”。如此一来，就要把 Layer2 采用的 Solidity 语言 / EVM 对应的操作码，放在比特币链上重新跑一遍。问题归结为：

用 Bitcoin Script 这种比特币 native 的简陋编程语言，实现出 EVM 或其他虚拟机的效果。

所以，从编译原理的角度去理解 BitVM 方案，它是把 EVM / WASM / Javascript 操作码，转译为 Bitcoin Script 的操作码，逻辑门电路作为“EVM 操作码 ——> Bitcoin Script 操作码”两者之间的一种中间形态（IR）。

（BitVM 白皮书里，谈到在比特币链上执行某些“有争议的指令”的大致思路）

Anyway，最终模拟出的效果是，把原本在 EVM / WASM 上才能处理的指令，放到比特币链上直接处理。这个方案虽然可行，但难点在于，如何用大量的逻辑门电路作为中间形态，表达出所有的 EVM / WASM 操作码 op code。而且，用逻辑门电路的组合，直接表达某些极为复杂的交易处理流程，可能产生巨大的工作量。

3.下面说下 BitVM 白皮书中提到的另一个核心，也就是与 Arbitrum 高度相似的“交互式欺诈证明”。

交互式欺诈证明会涉及到一个称为 assert（断言）的词，一般而言，Layer2 的提议者 Proposer（往往由排序器充当），会在 Layer1 上发布 assert 断言，声明某些交易数据、状态转换结果，是有效无误的。

如果有人认为 Proposer 提交的 assert 断言有问题（关联的数据有误），就会发生争议。此时，Proposer 和 Challenger 会回合式的交换信息，并对有争议的数据进行二分法查找，快速定位到某个粒度极细的操作指令，及其关联的数据片段。

对这个有争议的操作指令（OP Code），需要连带其输入参数在 Layer1 上直接执行，并对输出结果作出验证（Layer1 节点会把自己计算得到的输出结果，与 Proposer 之前发布的输出结果进行对比）。在 Arbitrum 里，这被称为“单步欺诈证明”。

（Arbitrum 的交互欺诈证明协议中，会通过二分法检索 Proposer 发布的数据，尽快定位到有争议的那条指令及执行结果，最后发送单步欺诈证明到 Layer1，进行最终验证）

（Arbitrum 的交互式欺诈证明流程图，阐述的比较粗糙）

到了这里，单步欺诈证明的思路很好理解了：绝大多数发生在 Layer2 的交易指令，不需要在 BTC 链上重新验证。但其中某个有争议的数据片段/操作码，在被人挑战时要在 Layer1 重放一遍。

如果检测结论为：Proposer 之前发布的数据有问题，则 Slash 掉 Proposer 质押的资产；如果是 Challenger 有问题，则 Slash 掉 Challenger 质押的资产。如果 Prover 长时间不响应挑战，也可以被 Slash。

Arbitrum 通过以太坊上的合约来实现上述效果，BitVM 则要借助 Bitcoin Script 实现时间锁、多签等功能。

4.简单讲完“交互式欺诈证明”与“单步欺诈证明”后，我们将谈及 MAST 树和 Merkle Proof。

前面谈到，BitVM 方案中，不会将 Layer2 在链下处理的大量交易数据/涉及的巨量逻辑门电路直接 on chain，只在必要时刻将极少数据/逻辑门电路 on chian。

但是，我们需要某种方式，证明这些“原本在链下，现在要 on chain”的数据，不是随手捏造的，这就是密码学中常提到的 Commitment。Merkle Proof 就是 Commitment 的一种。

首先，我们说下 MAST 树。MAST 树全名为 Merkelized Abstract Syntax Trees，是把编译原理里涉及的 AST 树，转化为 Merkle Tree 之后的形态。

那么，AST 树又是什么？它的中文名是“抽象语法树”，简单的讲，就是把一段复杂的指令，通过词法分析，细分为一堆基础的操作单元，然后组织为一棵树状的数据结构。

一个 AST 树的简单案例，这棵 AST 树将 x=2，y=x*3 这样的简单运算，细分为了底层操作码 + 数据）

而 MAST 树，就是把 AST 树 Merkle 化，以支持 Merkle Proof。Merkle 树有一个好处，就是它可以实现高效率的“数据压缩”。比如，你想在必要时，将 Merkle 树上的某段数据发布到 BTC 链上，但又要让外界确信，这个数据片段确实存在于 Merkle 树上，而不是你“随手拈来”的，怎么办？

你只要事先将 Merkle 树的 Root 记录在链上，在未来出示 Merkle Proof，证明某段数据，存在于 Root 对应的 Merkle 树上，就行。

（Merkle Proof/Branch与Root之间的关系）

所以，无需将完整的 MAST 树存放在 BTC 链上，只需要提前披露其 Root 充当 Commitment，在必要时出示数据片段 + Merkle Proof /Branch 即可。这种可以极大程度压缩 on chain 的数据量，且能保证 on chain 数据真的存在于 MAST 树上。而且，仅在 BTC 链上公开小部分数据片段+Merkle Proof，而不是公开所有数据，能起到很好的隐私保护效果。

（MAST 树示例）

BitVM 的方案，尝试把所有的逻辑门电路用比特币脚本表达出来，再组织成一个巨大的 MAST 树，这棵树最底下的叶子 leaf（图中的 Content），就对应着用比特币脚本实现的逻辑门电路。

Layer2 的 Proposer，会频繁的在 BTC 链上发布 MAST 树的 root，每棵 MAST 树，都关联着一笔交易，涉及其所有的输入参数 / 操作码 / 逻辑门电路。某种程度上，这类似于 Arbitrum 的 Proposer 在以太坊链上发布 Rollup Block。

当争议发生时，挑战者在 BTC 链上声明，自己要挑战 Proposer 发布的哪个 Root，然后要求 Proposer 揭示 Root 对应的某段数据。之后，Proposer 出示默克尔证明，反复在链上披露 MAST 树的小部分数据片段，直到和挑战者共同定位到有争议的逻辑门电路。之后就可以执行 Slash。

（图源：https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca）

5.到这里，BitVM 整个方案最重要的部分基本讲完，虽然其中某些细节还是有点晦涩，但相信读者已经可以 get 到 BitVM 的精华与要旨。至于其白皮书里提到的 bit value commitment，是为了防止 Proposer 在被挑战并被迫在链上验证逻辑门电路时，给该逻辑门的输入值“既赋值 0，又赋值 1”，产生二义性混乱。

总结：BitVM 的方案，先用比特币脚本表达逻辑门电路，再用逻辑门电路表达 EVM/其他 VM 的操作码，再用操作码表达任意一条交易指令的处理流程，最后组织成 merkle tree/MAST树。

这样的一棵树，如果表达的交易处理流程很复杂，很容易破 1 亿个 leaf，所以要尽量缩减 Commitment 占用的区块空间，以及欺诈证明波及的范围。

虽然单步欺诈证明，只需要 onchain 极小的一段数据和逻辑门脚本，但完整的 Merkle Tree 要长期存储在链下，以备有人挑战时，可以随时 onchain 树上的数据。

Layer2 每笔发生的交易，都会产生一个大号 Merkle Tree，节点的计算和存储压力可想而知，大多数人可能不愿意去运行节点（但这些历史数据可以被过期淘汰，而 B^2 network 专门引入类似 Filecoin 的 zk 存储证明，激励存储节点长期保存历史数据）

不过，基于欺诈证明的乐观 Rollup，本身也不需要有太多节点，因为其信任模型是 1/N，只要 N 个节点中有 1 个是诚实的，能够在关键时刻发起欺诈证明，Layer2 网络就是安全的。

但是，基于 BitVM 的 Layer2 方案设计中，还存在许多挑战，比如：

1）理论上说，为了进一步压缩数据，不必直接在 Layer1 验证操作码，可以将操作码的处理流程再度压缩为 zk proof，让挑战者对 zk proof 的验证步骤进行挑战。这样可以大幅度压缩 on chain 的数据量。但具体的开发细节会很复杂。

2）Proposer 和 Challenger 要在链下反复产生交互，协议该如何设计，Commitment 和挑战过程，该如何在处理流程上进一步优化，需要消耗很多脑细胞。

参考文献：

BitVM 白皮书 https://bitvm.org/bitvm.pdf
Deep dive into BitVM -Computing paradigm to express Turing-complete Bitcoin contracts - https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca
Merkelized Abstract Syntax Trees https://hashingit.com/elements/research-resources/2014-12-11-merkelized-abstract-syntax-trees.pdf
数据扣留与欺诈证明：Plasma 不支持智能合约的原因https://mp.weixin.qq.com/s/oOPZqIoi2p6sCxBdfUP4eA
前 Arbitrum 技术大使解读 Arbitrum 的组件结构（上） https://mp.weixin.qq.com/s/BgpHI4oXQYYVpB5v6x8cAg

作者：雾月 & Faust，极客web3
顾问：Kevin He, BitVM 中文社区发起人，ex Web3 Tech Head@Huobi