Le largage aérien de ZKSync a suscité la controverse en examinant les difficultés de démarrage à froid du projet Web3.

L’auteur original : @Web3 Mario（_mario）

La semaine dernière, le sujet le plus chaud était certainement l’événement de vérification publique de largage aérien de ZKsync. À l’origine, l’auteur apprenait et écrivait quelques expériences d’apprentissage sur le développement de DApp pour TON, mais en voyant cet événement controversé et les discussions communautaires qu’il a suscitées, il a ressenti quelque chose et a donc décidé d’écrire un article pour partager ses sentiments avec tout le monde. En général, le programme de largage aérien de ZKSync adopte une méthode de distribution basée sur la preuve de propriété, mettant davantage l’accent sur les récompenses aux développeurs, aux contributeurs principaux et aux Baleine natifs de Degen de ZKSync, ce qui crée une situation où les Degen natifs de Baleine rient et le studio de toilettage gémit.

Le point central du débat communautaire : l’interaction est-elle essentielle ou bien le volume des fonds est-il essentiel

Pendant une longue période, l’industrie Web3 semble avoir adopté le paradigme consistant à attirer les utilisateurs par le biais d’Airdrops afin de lancer un projet. Cela est particulièrement vrai dans le domaine de Layer 2, où les attentes des développeurs et des utilisateurs vis-à-vis des potentiels Airdrops stimulent la création et la maintenance active de DApps par les développeurs, ainsi que la participation active des utilisateurs en transférant des fonds vers la couche 2 cible et en utilisant les DApps fonctionnant sur cette couche 2, dans le but de créer un écosystème dynamique. Cela est devenu une norme.

Par conséquent, par le passé, les utilisateurs s’attendaient généralement à ce que ZKSync soit à la hauteur de ses deux principaux concurrents, Arbitrum et Optimism, en ce qui concerne les airdrops. Bien sûr, qu’il s’agisse de l’influence de l’industrie, de l’expérience en capital-risque, de l’ampleur de la collecte de fonds, etc., cette conclusion est logique. Cependant, les résultats sont très différents, ce qui a conduit à de nombreux débats au sein de la communauté, car il semble que de nombreux utilisateurs qui ont participé à ZKSync en se basant sur des expériences passées n’ont pas obtenu le nombre attendu de récompenses, ce qui a entraîné de vifs débats au sein de la communauté.

Pour examiner les raisons de ce débat et discuter de leurs implications pour l’avenir, il est naturel de revoir les règles de largage d’Arbitrum et d’Optimism. Tout d’abord, revenons sur l’activité de largage d’Arbitrum, qui remonte à mars 2023. Il a alloué 11,62% de l’approvisionnement total d’Arb aux utilisateurs d’Arbitrum, et en même temps, 1,13% d’Arb aux DAO opérant dans l’écosystème d’Arbitrum. Les règles spécifiques pour les utilisateurs sont basées sur les données instantanées du 6 février 2023.

• Interaction cross-chain vers Arbitrum : Les utilisateurs doivent transférer leur fonds vers Arbitrum One ou Arbitrum Nova.
• Transactions effectuées à différents moments : l’utilisateur a effectué des transactions au cours de deux mois différents, de six mois différents ou de neuf mois différents.
• Fréquence des transactions et interactions : L’utilisateur a effectué plus de 4, 10, 25 ou 100 transactions, ou a interagi avec le nombre correspondant de smart contracts.
• Valeur de transaction: La valeur totale des transactions effectuées par l’utilisateur dépasse 10 000 dollars, 50 000 dollars ou 250 000 dollars.
• Fournir de la liquidité: Les utilisateurs ont déposé des fonds de liquidité de plus de 10 000 $, 50 000 $ ou 250 000 $.
• Événement Arbitrum Nova : L’utilisateur a effectué plus de 3, 5 ou 10 transactions sur Arbitrum Nova.

Chaque règle aura un mode de calcul de points spécifique, avec un maximum de 15 points, ces points sont utilisés pour déterminer la quantité d’Arb que l’utilisateur peut recevoir. Le mode de calcul peut être approximativement linéaire, mais la récompense initiale commence à 3 points, avec un maximum de 10 200 Arb. En ce qui concerne les récompenses pour DAO, le montant exact est déterminé directement en fonction de l’évaluation de l’activité. En fin de compte, 137 DAO ont reçu des airdrops, parmi lesquels Treasure et GMX ont reçu le plus, respectivement 8 millions d’Arb, ce qui représente actuellement un revenu substantiel.

Ensuite, jetons un coup d’œil à Optimism. Contrairement à Arbitrum, les largages d’Optimism se déroulent en plusieurs étapes, représentant au total 19 % de l’approvisionnement total. La première série de largages remonte à juin 2022, avec 5 % des récompenses distribuées à 260 000 adresses. Jusqu’à présent, quatre séries de largages ont eu lieu, avec les règles spécifiques suivantes pour chaque série :

• Première ronde : les utilisateurs ordinaires et les utilisateurs actifs sont divisés en fonction du nombre de transactions, correspondant respectivement aux adresses effectuant 1 transaction et aux adresses effectuant plus de 4 transactions, ainsi qu’aux participants de Ethereum DAO, aux utilisateurs de portefeuilles à signatures multiples Ethereum, aux donateurs de Gitcoin et aux utilisateurs de ponts cross-chain. Chaque identité correspond à une récompense à valeur fixe, les trois dernières récompenses étant cumulables.
• Deuxième tour: Les utilisateurs dont les frais de gaz total sont supérieurs à 6,1 dollars américains ou dont l’âge de la monnaie engagée dans la gouvernance dépasse 2000 peuvent se partager 11 742 277 $OP;
• Troisième tour : les utilisateurs dont l’ancienneté de délégation dépasse 18000 peuvent partager 19, 411, 313 $OP ;
• Quatrième tour : 10, 343, 757 $OP ont été attribués aux créateurs de NFT ;

En examinant la revue ci-dessus, nous pouvons constater que le nombre d’interactions est souvent utilisé comme indicateur de référence important dans la configuration des activités spécifiques, les utilisateurs ayant des interactions plus fréquentes étant généralement récompensés par des récompenses plus importantes. Cependant, cette règle tacite semble avoir été abandonnée par ZKSync. Dans la conception de largage aérien de ZKSync, l’éligibilité et l’allocation des utilisateurs de ZKSync sont sélectionnées et calculées en quatre étapes consécutives, les règles spécifiques étant les suivantes :

• Sélection des qualifications : Chaque adresse qui a effectué des transactions sur ZKsync Era et ZKsync Lite sera vérifiée selon les critères de qualification. Il y a 7 critères d’évaluation pour sélectionner les utilisateurs éligibles, par exemple, interagir avec des contrats non token plus de 10 fois et les contrats non token doivent avoir une activité active d’au moins 30 jours, envoyer au moins 5 transactions sur ZKsync Era, etc.
• Multiplicateur : Une adresse répondant à des critères spécifiques peut obtenir un multiplicateur dans la distribution. Ces critères sont généralement la détention de certaines altcoins à haut risque ou de NFT natifs de ZKSync.
• Détection de Sybil: ZKSync effectuera également une détection d’attaques de Sybil pour filtrer la plupart des robots, selon deux critères: la source de la première transaction en ETH après la création d’une adresse EOA, et les interactions entre cette adresse EOA et les adresses de dépôt sur CEX. En fait, cela exploite les caractéristiques de la vérification KYC sur CEX.

En examinant les règles spécifiques, il est facile de voir que le calcul des récompenses ne concerne pas le nombre d’interactions, mais se concentre plutôt sur le montant des fonds dans un compte individuel et la volonté de configurer des actifs à risque. Par conséquent, après l’annonce des résultats, de nombreux utilisateurs de ZKSync qui ont l’habitude de faire de nombreuses interactions pour maximiser leurs gains ont été surpris et cela a été à l’origine de la controverse. En effet, ces utilisateurs ont tendance à répartir leurs gros capitaux sur plusieurs adresses afin d’augmenter le nombre d’adresses potentielles pour les airdrops. Ces groupes d’adresses peuvent compter plusieurs centaines, voire des milliers d’adresses, et utilisent de petits montants pour participer à certains protocoles. Ils utilisent ensuite des scripts automatisés ou effectuent manuellement des interactions fréquentes afin d’optimiser leurs gains potentiels en prévoyant certains comportements incitatifs. Cependant, la configuration des airdrops sur ZKSync rend cette stratégie inefficace, car les frais de transaction engagés par ces adresses qui effectuent des interactions fréquentes peuvent même dépasser les récompenses potentielles, ce qui a naturellement entraîné l’insatisfaction de ce groupe d’utilisateurs.

De plus, il n’est pas difficile de trouver de nombreux chasseurs de largages aériens KOL dans X, cette partie de la population publie principalement du contenu sur la façon de faciliter l’obtention de largages aériens de la part des projets, et a généralement une large base de fans et un fort pouvoir de mobilisation. Par conséquent, en mettant la pression sur ZKSync officiellement via les médias sociaux, ils espèrent changer la situation actuelle. Cependant, du point de vue de l’officiel, il semble être assez ferme et n’a pas modifié les règles sous pression, d’où la situation actuelle. Les accusations et les contre-arguments sur certains comportements malveillants suscités pendant le débat sont particulièrement intéressants dans cette guerre médiatique.

À en juger par les résultats, les demandes des deux parties semblent compréhensibles, mais la question de qui a raison ou tort dépend du point de vue. Cependant, je pense qu’il y a des choses qui méritent d’être réfléchies, comme qui sont les utilisateurs de valeur clé du projet Web3 à ce jour, ou quel type d’utilisateurs devraient être incités pendant la phase de démarrage à froid.

Les interactions lourdes entraînent des problèmes d’Attaque de Sybil, tandis que la preuve de propriété entraîne des problèmes de monopole

Les récompenses basées sur Airdrop pour les participants early bird se sont avérées être un moyen efficace de démarrer à froid des projets Web3, et un bon mécanisme Airdrop peut aider le projet à attirer efficacement les utilisateurs de semences au stade précoce, et en même temps compléter l’éducation des utilisateurs en stimulant les utilisateurs à utiliser les comportements clés du protocole et à augmenter l’adhérence du produit. C’est aussi la raison fondamentale pour laquelle, pendant une longue période, les paramètres Airdrop de la plupart des projets Web3 se sont concentrés sur les incitations au comportement interactif, mais cela présente un inconvénient, c’est-à-dire qu’il fait goutte le seuil d’obtention des récompenses, ce qui facilite les activités pour rencontrer l’attaque de Sybil. Lorsqu’un grand nombre de robots compte affluent, bien que cela fasse apparaître le protocole comme une fausse prospérité à short terme, ces « utilisateurs » vivent généralement dans l’eau short long et l’herbe, incapables de donner une impulsion au développement futur du projet, et la plupart d’entre eux seront encaissés pour augmenter le taux de rotation du capital et améliorer les revenus après avoir reçu la récompense, ce qui dilue le nombre de récompenses pour les utilisateurs qui ont vraiment de la valeur, ce qui vaut vraiment la perte.

Alors, pourquoi ce mécanisme fonctionnait-il bien au début ? C’est naturellement parce qu’à l’époque, il y avait moins d’équipes professionnelles similaires, la plupart des utilisateurs n’avaient pas encore développé d’habitudes de pensée envers ce type de mécanisme d’incitation, les comportements d’interaction étaient encore assez purs et appartenaient à de vrais utilisateurs, ce qui permettait une distribution plus efficace des incitations à ces utilisateurs, et l’effet de création de richesse qui en découlait aidait également les projets à réaliser les avantages mentionnés ci-dessus. Cependant, avec l’impact de l’effet de gain d’argent qui a suivi, il est évident que cette méthode ne peut plus attirer efficacement de vrais utilisateurs. Mon sentiment personnel est que l’utilité des largages principalement axés sur l’interaction en tant qu’objet d’incitation a atteint son apogée lors du largage Arbitrum.

C’est également la raison fondamentale pour laquelle ZKSync souhaite abandonner l’utilisation du nombre d’interactions comme critère d’identification des utilisateurs de valeur en se basant sur la taille relative des actifs. Cependant, ce mode de preuve de propriété n’est pas sans problèmes. Bien qu’il puisse identifier et exclure efficacement le risque d’attaque de Sybil, il entraîne de nouveaux problèmes tels que l’inégalité de la distribution des richesses causée par le monopole.

Nous savons qu’une des valeurs fondamentales du projet Web3 est le modèle d’autonomie distribuée de bas en haut. Cela signifie que le soutien des utilisateurs de base (de petits utilisateurs réels) est le socle du développement d’un projet. C’est grâce à ces utilisateurs de base que des Baleines peuvent éventuellement affluer et former un modèle de développement plus durable, car l’avantage financier est toujours présent dans la plupart des scénarios. Seulement avec un grand nombre d’utilisateurs de base, les Baleines peuvent réaliser des profits suffisamment importants. Par conséquent, le système de répartition des preuves de propriété peut entraîner une nette augmentation des profits des Baleines parmi les premiers utilisateurs lors du démarrage, ce qui rend difficile de motiver efficacement les utilisateurs de base et, par conséquent, de former une communauté cohésive.

En fin de compte, pour les projets Web3, lors de la conception du mécanisme de démarrage à froid, il est important de prendre en compte attentivement le profil de l’utilisateur de valeur pour votre propre produit, et de concevoir un mécanisme correspondant en fonction de l’environnement actuel. Cela permet de stimuler efficacement les utilisateurs de valeur mentionnés ci-dessus tout en évitant autant que possible les attaques de Sybil. Par conséquent, la conception de votre propre mécanisme de démarrage à froid est un sujet très précieux, et je vous invite également à laisser un message dans ma plateforme X pour en discuter. Ensemble, nous pouvons faire naître des idées intéressantes.