ZKSync 空投惹争议来看 Web3 项目冷启动的困境

作者：@Web3Mario

摘要：上周最火热的议题肯定是 ZKsync 的公开空投查验的事件了，本来笔者正在学习并书写一些关于 TON 的 DApp 开发的学习经验，但是看到这个颇具争议的事件，以及引发的社区的广泛讨论，颇有一些感受，因此撰文一篇，希望与大家分享。总的来说，ZKSync 的空投方案采用了一个基于财产证明的分配方式，更聚焦于对开发者，核心贡献者和 ZKSync 原生 Degen 巨鲸的奖励，这就造成了一个局面原生 Degen 巨鲸在笑，撸毛工作室在叫。

社区争论的焦点：交互是关键还是资金量是关键

很长一段时间，Web3 行业似乎已经形成了通过 Airdrop 吸引用户使用产品，从而实现项目冷启动的范式。在 Layer2 赛道中更是如此，通过引导开发者和用户对潜在空投的预期，刺激开发者积极构建并维护 DApp，同时刺激用户在发展早期将资金桥接到目标 Layer2，并积极参与目标 Layer2 上面运行的 DApp，从而起到活跃生态的目的，这已经成为了一种制式。

因此在过去，用户普遍对于 ZKSync 的空投预期是对标它的两个直接竞品，Arbitrum 和 Optimism。当然无论从行业影响力，VC 背景，募资规模等角度来思考，这个结论都是合乎逻辑的，然而结果却大相径庭，这就导致了很多复用过去经验来参与 ZKSync 的用户似乎并没有得到期望内的奖励数量，从而导致了社区陷入到了广泛的争论中。

为了探究这个争论背后的原因并探讨一些对未来的借鉴意义，自然是需要回顾一下之前的 Arbitrum 和 Optimism 的空投规则的设置。首先回顾一下 Arbitrum 的空投活动，这要追溯到 2023 年 3 月，其为 Aribitrum 用户分配了占总供应量 11.62% 的 Arb 空投，同时为 Arbitrum 生态中运行的 DAO 分配了 1.13% 的 Arb 空投。空投活动的设置基于 2023 年 2 月 6 日的快照数据，针对用户具体的规则如下：

• 跨链到 Arbitrum: 用户需要将资金转入 Arbitrum One 或 Arbitrum Nova。

• 不同时间段内的交易: 用户在两个不同的月份、六个不同的月份或九个不同的月份进行过交易。

• 交易频次和互动: 用户进行了超过 4 笔、10 笔、25 笔或 100 笔交易，或与相应数量的智能合约进行了互动。

• 交易价值: 用户进行的交易总价值超过 10,000 美元、50,000 美元或 250,000 美元。

• 提供流动性: 用户已存入超过 10,000 美元、50,000 美元或 250,000 美元的流动资金

• Arbitrum Nova 活动: 用户在 Arbitrum Nova 上进行了超过 3 笔、5 笔或 10 笔交易。

每个细则会有具体的分值计算方式，分值上限为 15 分，这个分值用于确定用户可以领取的 Arb 数量，计算方式可以近似为线性关系，但是起始奖励从 3 分开始，封顶奖励 10200 个 Arb。而针对 DAO 的奖励，则直接按照活跃度评估的方式来确定具体金额，从结果上看最终 137 个 DAO 获得了空投，其中 Treasure 和 GMX 获得的最多，分别为 800 万个 Arb，按照当前的实质，这实在是一笔丰厚的收益。

接下来回顾一下 Optimism，与 Arbitrum 不同，Optimism 的空投共分多轮次进行，总共分配奖励数量占总供应量的 19%，其最早的第一轮空投活动要追溯到 2022 年 6 月，总共有 5% 的奖励被分发给了 26 万个地址，截止到目前已经进行了四轮空投，其每轮空投的具体规则如下：

• 第一轮：按交易次数划分了普通用户与活跃用户，分别对应交易 1 次的地址与交易大于 4 次的地址，以及 Ethereum DAO 的参与者，Ethereum 多签钱包使用者，Gitcoin 捐赠者和跨链桥使用者。每种身份对应一个定值奖励，后三种奖励可叠加。

• 第二轮：总交易 gas fee 大于 6.1 美金或参与委托治理的币龄超过 2000 的用户可以瓜分 11,742,277 个 $OP；

• 第三轮：参与委托治理的币龄超过 18000 的用户可以瓜分 19,411,313 个 $OP；

• 第四轮：针对 NFT 的创建者分配了 10,343,757 个 $OP；

从上述回顾我们不难发现，其具体的活动设置中都会以交互次数作为一个重要的参考指标，交互越频繁的用户通常可获得的奖励越多。然而这个潜规则似乎被 ZKSync 摒弃了，在 ZKSync 的空投设计中，ZKsync 用户的资格和分配分为四个连续步骤来选取并计算，具体规则大致如下：

• 资格筛选：每个在 ZKsync Era 和 ZKsync Lite 上进行过交易的地址都会根据资格标准进行检查。其设置了 7 个考察标准用于筛选符合资格的用户，例如与非代币合约交互超过 10 个且非代币合约必须至少有 30 天活跃时间，在 ZKsync Era 至少发送 5 笔交易等。

• 分配：在计算某个符合上述标准的地址具体的奖励数量时，基于一个价值缩放公式来确认，该公式根据发送到 ZKsync Era 的金额以及这些加密资产在钱包中保留的时间计算出一个时间加权平均值，并以此来调整每个地址的分配，同时参与 DApp 协议的资金将获得 2 倍的加成，这就意味着你向 ZKSync 转移了大资金，保持了很长一段时间，并积极使用这些资金参与一些有风险的产品，例如向 DEX 提供流动性，将获得更多的奖励。

• 乘数：符合特定标准的地址可以在分配中获得乘数。这些标准通常是持有一些高风险的 ZKSync 原生的山寨币或 NFT。

• Sybil 检测：最后 ZKSync 也会做女巫攻击检测，以保证大部分的机器人被过滤掉，其检测标准从两个方面进行，某 EOA 地址创建后的首笔 ETH 来源，以及该 EOA 地址与 CEX 存款地址的交互情况。其实这也是利用了 CEX KYC 的特点。

从具体规则我们不难发现，在奖励的计算中并不涉及到交互次数这个纬度，更聚焦在单个账户的资金量与配置风险资产的意愿度。因此当结果公布之后，让很多秉持着过去经验在 ZKSync 上大量交互的撸毛党或工作室大跌眼镜，这也是引爆整个争议的源头。因为该部分用户为了增加获得潜在空投的地址数量，通常会选择将大资金尽可能的分散到地址群中，这些地址群通常为几百甚至上千个，并使用小资金参与某协议，通过预判一些可能的激励行为，通过自动化脚本或手工的方式频繁的刷交互，做任务的方式提高潜在的收益。而 ZKSync 的空投设置让这个策略失效，很多频繁交互的地址所付出的手续费甚至都比获得的奖励还高，这自然引起了该部分人群的不满。

而且我们在 X 中不难发现大量的空投猎人 KOL，该部分人群以教大家如何方便获得项目方空投为主题发布内容，通常有着广泛的粉丝群体，具有较强的号召性，因此通过社交媒体给 ZKSync 官方施压，从而期望改变这个局面。然而从官方的态度来看，似乎也很强硬，并没有因承压而修改规则，所以才有了现在的局面。争论的过程中所引发的对于一些可能的作恶行为的指摘与辩解更是这场舆情大战的看点。

从结果来看，两边的诉求似乎都可以理解，个中对错只能看从什么角度去论述了，但我认为有些东西是值得思考的，那就是时至今日，Web3 项目冷启动阶段的核心价值用户究竟是谁，或者说什么样的用户才是冷启动阶段应该去激励的用户。

重交互带来女巫攻击问题，财产证明则带来垄断问题

对早鸟参与者基于 Airdrop 奖励，已经被证明是一个行之有效的 Web3 项目冷启动的手段，好的空投机制设置能够帮助项目在早期高效的吸引种子用户，同时通过刺激用户对协议关键行为的使用而完成用户教化，增加产品的粘性。这也是很长一段时间内，大部分 Web3 项目的空投设置着重于对交互行为进行激励的根本原因，然而这样做带来了一个弊端，就是降低了获得奖励的门槛，容易使得活动遭遇女巫攻击。因为交互行为是容易被自动化和批量化，这就给了很多专业团队批量操作的空间，当大量的机器人账户涌入后，虽然会让协议出现短暂的虚假繁荣，然而这些“用户”通常是逐水草而居，无法为项目未来的发展提供动力，在获得奖励后大部分也会套现用于增加资金周转率从而提升收益，这种激励机制反倒稀释了项目方对于那些真正价值用户的奖励数量，实在得不偿失。

那么为什么这种机制在早期效果不错呢，这自然是由于彼时类似的专业团队并没有那么多，大部分用户还没有对这种激励机制形成思维惯式，交互行为还是比较纯粹的，属于真实用户，这就让激励能够较为高效的分配给这些用户，由此产生的财富效应也帮助项目方实现上述好处，然而随着于此而来的赚钱效应的影响，这种方式显然已经无法有效的吸引真实用户。我的一个切身的感受，以交互为主要激励对象的空投活动的效用到 Arbitrum 空投时基本上已经到了顶点。

这也是 ZKSync 想要围绕资产相对规模而舍弃使用交互数来作为价值用户识别的依据的根本原因。然而这种财产证明方式也未必没有问题。虽然能够较为有效的识别并排除女巫攻击的风险，但与之而来的新问题就是垄断所引发的财富分配不均。

我们知道 Web3 项目的一个核心价值观是自下而上的分布式自治模型。这就意味着基层用户（小资金量的真实用户）的支持才是一个项目发展的基本盘。也正是有了基层用户，一些巨鲸用户才可能涌入，并形成一个较为可持续的发展形态，毕竟资金优势在大部分的场景上还是具备的，只有基层用户足够多，巨鲸用户收益才足够大。那么财产证明的分配制度会导致在冷启动之初，其早鸟用户中巨鲸用户的收益就已经较为明显，这就很难对基层用户形成有效激励，自然就无法形成一个有凝聚力的社区。

归根到底，对于 Web3 项目来说，在设计冷启动机制时还是要仔细斟酌对自己产品来说价值用户画像，并根据当前所处的环境，设计对应的机制，有效的激励上述价值用户的同时尽量规避女巫攻击才是重中之重。因此如何设计自己的冷启动机制，这是一个非常有价值的话题，也欢迎大家来我的 X 中留言讨论。一起头脑风暴一些有趣的方案。