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

文章转载来源： 马里奥看Web3

作者：@Web3Mario（https://x.com/web3_mario）

摘要：上周最火热的议题肯定是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中留言讨论。一起头脑风暴一些有趣的方案。

X Links: https://x.com/web3_mario