作者：@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日的快照数据，针对用户具体的规则如下：
每个细则会有具体的分值计算方式，分值上限为15分，这个分值用于确定用户可以领取的Arb数量，计算方式可以近似为线性关系，但是起始奖励从3分开始，封顶奖励10200个Arb。而针对DAO的奖励，则直接按照活跃度评估的方式来确定具体金额，从结果上看最终137个DAO获得了空投，其中Treasure和GMX获得的最多，分别为800万个Arb，按照当前的实质，这实在是一笔丰厚的收益。
接下来回顾一下Optimism，与Arbitrum不同，Optimism的空投共分多轮次进行，总共分配奖励数量占总供应量的19%，其最早的第一轮空投活动要追溯到2022年6月，总共有5%的奖励被分发给了26万个地址，截止到目前已经进行了四轮空投，其每轮空投的具体规则如下：
从上述回顾我们不难发现，其具体的活动设置中都会以交互次数作为一个重要的参考指标，交互越频繁的用户通常可获得的奖励越多。然而这个潜规则似乎被ZKSync摒弃了，在ZKSync的空投设计中，ZKsync 用户的资格和分配分为四个连续步骤来选取并计算，具体规则大致如下：
从具体规则我们不难发现，在奖励的计算中并不涉及到交互次数这个纬度，更聚焦在单个账户的资金量与配置风险资产的意愿度。因此当结果公布之后，让很多秉持着过去经验在ZKSync上大量交互的撸毛党或工作室大跌眼镜，这也是引爆整个争议的源头。因为该部分用户为了增加获得潜在空投的地址数量，通常会选择将大资金尽可能的分散到地址群中，这些地址群通常为几百甚至上千个，并使用小资金参与某协议，通过预判一些可能的激励行为，通过自动化脚本或手工的方式频繁的刷交互，做任务的方式提高潜在的收益。而ZKSync的空投设置让这个策略失效，很多频繁交互的地址所付出的手续费甚至都比获得的奖励还高，这自然引起了该部分人群的不满。
而且我们在X中不难发现大量的空投猎人KOL，该部分人群以教大家如何方便获得项目方空投为主题发布内容，通常有着广泛的粉丝群体，具有较强的号召性，因此通过社交媒体给ZKSync官方施压，从而期望改变这个局面。然而从官方的态度来看，似乎也很强硬，并没有因承压而修改规则，所以才有了现在的局面。争论的过程中所引发的对于一些可能的作恶行为的指摘与辩解更是这场舆情大战的看点。
从结果来看，两边的诉求似乎都可以理解，个中对错只能看从什么角度去论述了，但我认为有些东西是值得思考的，那就是时至今日，Web3项目冷启动阶段的核心价值用户究竟是谁，或者说什么样的用户才是冷启动阶段应该去激励的用户。
对早鸟参与者基于Airdrop奖励，已经被证明是一个行之有效的Web3项目冷启动的手段，好的空投机制设置能够帮助项目在早期高效的吸引种子用户，同时通过刺激用户对协议关键行为的使用而完成用户教化，增加产品的粘性。这也是很长一段时间内，大部分Web3项目的空投设置着重于对交互行为进行激励的根本原因，然而这样做带来了一个弊端，就是降低了获得奖励的门槛，容易使得活动遭遇女巫攻击。因为交互行为是容易被自动化和批量化，这就给了很多专业团队批量操作的空间，当大量的机器人账户涌入后，虽然会让协议出现短暂的虚假繁荣，然而这些“用户”通常是逐水草而居，无法为项目未来的发展提供动力，在获得奖励后大部分也会套现用于增加资金周转率从而提升收益，这种激励机制反倒稀释了项目方对于那些真正价值用户的奖励数量，实在得不偿失。
那么为什么这种机制在早期效果不错呢，这自然是由于彼时类似的专业团队并没有那么多，大部分用户还没有对这种激励机制形成思维惯式，交互行为还是比较纯粹的，属于真实用户，这就让激励能够较为高效的分配给这些用户，由此产生的财富效应也帮助项目方实现上述好处，然而随着于此而来的赚钱效应的影响，这种方式显然已经无法有效的吸引真实用户。我的一个切身的感受，以交互为主要激励对象的空投活动的效用到Arbitrum空投时基本上已经到了顶点。
这也是ZKSync想要围绕资产相对规模而舍弃使用交互数来作为价值用户识别的依据的根本原因。然而这种财产证明方式也未必没有问题。虽然能够较为有效的识别并排除女巫攻击的风险，但与之而来的新问题就是垄断所引发的财富分配不均。
我们知道Web3项目的一个核心价值观是自下而上的分布式自治模型。这就意味着基层用户（小资金量的真实用户）的支持才是一个项目发展的基本盘。也正是有了基层用户，一些巨鲸用户才可能涌入，并形成一个较为可持续的发展形态，毕竟资金优势在大部分的场景上还是具备的，只有基层用户足够多，巨鲸用户收益才足够大。那么财产证明的分配制度会导致在冷启动之初，其早鸟用户中巨鲸用户的收益就已经较为明显，这就很难对基层用户形成有效激励，自然就无法形成一个有凝聚力的社区。
归根到底，对于Web3项目来说，在设计冷启动机制时还是要仔细斟酌对自己产品来说价值用户画像，并根据当前所处的环境，设计对应的机制，有效的激励上述价值用户的同时尽量规避女巫攻击才是重中之重。因此如何设计自己的冷启动机制，这是一个非常有价值的话题，也欢迎大家来我的X中留言讨论。一起头脑风暴一些有趣的方案。
以上是ZKSync 空投惹争议来看 Web3 项目冷启动的困境的详细内容。更多信息请关注PHP中文网其他相关文章！
