Résumé : Le sujet le plus brûlant de la semaine dernière était sans aucun doute l'incident de vérification du largage public de ZKsync. À l'origine, l'auteur étudiait et écrivait une expérience d'apprentissage sur le développement de DApp de TON, mais après avoir vu cet incident controversé et déclenché une discussion approfondie dans la communauté. m'a donné des sentiments, alors j'ai écrit un article dans l'espoir de le partager avec tout le monde. En général, le plan de largage de ZKSync adopte une méthode de distribution basée sur une preuve de propriété et se concentre davantage sur les récompenses pour les développeurs, les principaux contributeurs et les baleines Degen natives de ZKSync. Cela a créé une situation dans laquelle les baleines Degen natives rient, le studio ébouriffant. appelle.
Pendant longtemps, l'industrie du Web3 semble avoir formé un paradigme visant à inciter les utilisateurs à utiliser des produits via Airdrop, réalisant ainsi un démarrage à froid du projet. Cela est particulièrement vrai dans le cadre de la couche 2. En guidant les attentes des développeurs et des utilisateurs concernant les largages potentiels, cela stimule les développeurs à créer et à maintenir activement des DApp, tout en incitant les utilisateurs à transférer les fonds vers la couche 2 cible dans les premiers stades de développement et activement. participer aux projets en cours d'exécution sur la couche 2 cible. DApp, servant ainsi à activer l'écologie, est devenu un standard.
Ainsi, dans le passé, les attentes des utilisateurs concernant le largage de ZKSync étaient généralement basées sur ses deux concurrents directs, Arbitrum et Optimism. Bien sûr, cette conclusion est logique, quel que soit le point de vue de l'influence de l'industrie, de l'expérience en capital-risque, de l'ampleur de la collecte de fonds, etc. Cependant, les résultats sont assez différents, ce qui conduit de nombreux utilisateurs à réutiliser leurs expériences passées pour participer à ZKSync et ne semblent pas le faire. obtenir ce à quoi ils s'attendaient. Le nombre de récompenses au sein du système a donné lieu à un large débat dans la communauté.
Afin d'explorer les raisons de cette controverse et de discuter de certaines implications de référence pour l'avenir, il est naturellement nécessaire de revoir les paramètres précédents des règles de largage d'Arbitrum et d'Optimisme. Tout d’abord, passons en revue l’activité de largage d’Arbitrum, qui remonte à mars 2023. Elle a alloué 11,62 % de l’offre totale de largages Arb aux utilisateurs d’Arbitrum, et a alloué 1,13 % des largages Arb au DAO fonctionnant dans l’écosystème Arbitrum. Le paramétrage de l'activité airdrop est basé sur les données de l'instantané du 6 février 2023. Les règles spécifiques pour les utilisateurs sont les suivantes :
Chaque détail aura une méthode de calcul de score spécifique. La limite supérieure du score est de 15 points. Ce score est utilisé pour déterminer le nombre d'Arbs que l'utilisateur peut recevoir. La méthode de calcul peut être approchée comme une relation linéaire, mais la récompense de départ commence à partir de 3 points. En commençant par une récompense plafond de 10 200 Arb. Quant aux récompenses pour DAO, le montant spécifique est déterminé directement sur la base de la méthode d'évaluation des activités. À partir des résultats, 137 DAO ont finalement reçu des parachutages, dont Treasure et GMX ont reçu le plus, respectivement 8 millions d'Arb. ce qui représente vraiment un énorme profit.
Passons en revue Optimism. Contrairement à Arbitrum, les largages d'Optimism sont effectués en plusieurs tours. Le nombre total de récompenses distribuées représente 19 % de l'offre totale. Sa première série de largages remonte à juin 2022. Un total de 5. % des récompenses ont été distribuées à 260 000 adresses. Jusqu'à présent, quatre séries de largages ont été effectuées. Les règles spécifiques de chaque série de largages aériens sont les suivantes :
D'après l'examen ci-dessus, il n'est pas difficile de constater que le nombre d'interactions sera utilisé comme un indicateur de référence important dans ses paramètres d'activité spécifiques. Les utilisateurs qui interagissent plus fréquemment reçoivent généralement de plus grandes récompenses. Cependant, cette règle tacite semble avoir été abandonnée par ZKSync. Dans la conception du parachutage de ZKSync, la qualification et l'attribution des utilisateurs de ZKsync sont divisées en quatre étapes consécutives pour sélectionner et calculer. Les règles spécifiques sont à peu près les suivantes :
D'après les règles spécifiques, il n'est pas difficile de constater que le nombre d'interactions n'intervient pas dans le calcul des récompenses, mais se concentre plutôt sur le montant des fonds sur un seul compte et la volonté d'allouer des actifs risqués. Par conséquent, lorsque les résultats ont été annoncés, de nombreux fans ou studios qui se sont appuyés sur leurs expériences passées et ont beaucoup interagi sur ZKSync ont été choqués. Cela a également été la source de toute la controverse. Afin d'augmenter le nombre d'adresses qui reçoivent des parachutages potentiels, ce groupe d'utilisateurs choisit généralement de disperser autant que possible des fonds importants dans des groupes d'adresses. Ces groupes d'adresses sont généralement des centaines, voire des milliers, et utilisent de petits fonds pour participer à un certain. accord. Déterminez certains comportements motivants possibles, interagissez fréquemment via des scripts automatisés ou des méthodes manuelles et accomplissez des tâches pour augmenter les avantages potentiels. Le paramètre airdrop de ZKSync rend cette stratégie inefficace. Les frais de traitement payés par de nombreuses adresses interagissant fréquemment sont encore plus élevés que les récompenses reçues, ce qui suscite naturellement le mécontentement de ce groupe de personnes.
Et il n'est pas difficile de trouver un grand nombre de KOL chasseurs de parachutages dans Les médias ont fait pression sur les responsables de ZKSync dans l'espoir de changer cette situation. Cependant, à en juger par l'attitude officielle, il semble qu'ils soient également très durs et n'aient pas modifié les règles sous la pression, ce qui explique la situation actuelle. Les accusations et les justifications de certains comportements potentiellement pervers déclenchées par le débat sont les points forts de cette guerre d’opinion publique.
À en juger par les résultats, les appels des deux côtés semblent compréhensibles. Le bien et le mal ne peuvent être discutés que sous quel angle, mais je pense qu'il y a certaines choses qui méritent d'être réfléchies, c'est-à-dire, à ce jour, le démarrage à froid. étape du projet Web3 Qui sont les utilisateurs des valeurs fondamentales, ou quel type d'utilisateurs doit être motivé pendant la phase de démarrage à froid.
Les récompenses Airdrop pour les participants précoces se sont avérées être une méthode de démarrage à froid efficace pour les projets Web3. Un bon réglage du mécanisme de largage peut aider le projet à attirer des graines. les utilisateurs efficacement dès le début, et complète en même temps la formation des utilisateurs en les incitant à utiliser les comportements clés du protocole, augmentant ainsi l'adhérence du produit. C'est aussi la raison fondamentale pour laquelle, pendant longtemps, les paramètres d'airdrop de la plupart des projets Web3 se sont concentrés sur la motivation des comportements interactifs. Cependant, cela a apporté un inconvénient, à savoir que cela abaisse le seuil d'obtention de récompenses, facilitant ainsi les activités. faire face à des attaques de sorcières. Étant donné que les comportements interactifs sont faciles à automatiser et à regrouper, cela donne à de nombreuses équipes professionnelles une marge de manœuvre pour les opérations par lots lorsqu'un grand nombre de comptes de robots affluent, même si cela entraînera une fausse prospérité à court terme du protocole, ces « utilisateurs ». généralement progressivement, vivre seul ne peut pas donner une impulsion au développement futur du projet. Après avoir reçu les récompenses, la plupart d'entre elles seront encaissées pour augmenter le taux de rotation du capital et ainsi augmenter les bénéfices. Ce mécanisme d'incitation dilue en fait le nombre de récompenses du côté du projet. donne à ces utilisateurs une valeur réelle. Cela ne vaut vraiment pas la perte.
Alors pourquoi ce mécanisme a-t-il bien fonctionné au début ? C'est naturellement parce qu'il n'y avait pas beaucoup d'équipes professionnelles similaires à cette époque. La plupart des utilisateurs n'avaient pas encore pris l'habitude de réfléchir à ce mécanisme d'incitation, et le comportement interactif l'était. encore relativement pur, cela permet aux incitations d'être distribuées plus efficacement à ces utilisateurs, et l'effet de richesse qui en résulte aide également la partie au projet à obtenir les avantages ci-dessus. Cependant, avec l'impact de l'effet lucratif, cette méthode. n’est évidemment plus possible. Attirer efficacement de vrais utilisateurs. L'un de mes sentiments personnels est que l'efficacité des activités de parachutage avec l'interaction comme principale incitation a pratiquement atteint son apogée au moment du largage d'Arbitrum.
C'est également la raison fondamentale pour laquelle ZKSync souhaite abandonner l'utilisation des numéros d'interaction comme base pour identifier les utilisateurs précieux en fonction de la taille relative des actifs. Cependant, cette méthode de certification de propriété n’est pas sans poser de problèmes. Bien que le risque d’attaques de sorcières puisse être identifié et éliminé plus efficacement, un nouveau problème qui en découle est la répartition inégale des richesses provoquée par le monopole.
Nous savons que l'une des valeurs fondamentales du projet Web3 est le modèle d'autonomie distribuée ascendante. Cela signifie que le soutien des utilisateurs de base (utilisateurs réels disposant de petits capitaux) constitue la base du développement d’un projet. C'est précisément avec les utilisateurs de base que certains utilisateurs de baleines peuvent affluer et former une forme de développement plus durable. Après tout, l'avantage financier n'est toujours disponible que s'il y a suffisamment d'utilisateurs de base, les utilisateurs de baleines en bénéficieront. assez gros. Ensuite, le système de distribution des certificats de propriété entraînera des avantages évidents pour les utilisateurs de baleines parmi les utilisateurs précoces au début du démarrage à froid. Cela rend difficile la formation d'incitations efficaces pour les utilisateurs de base et, naturellement, il est impossible de former une cohésion. communauté.
En dernière analyse, pour les projets Web3, lors de la conception du mécanisme de démarrage à froid, vous devez toujours examiner attentivement les profils d'utilisateurs qui sont précieux pour votre produit et concevoir les mécanismes correspondants basés sur l'environnement actuel pour motiver efficacement les personnes mentionnées ci-dessus. utilisateurs précieux. Dans le même temps, la priorité absolue est d’éviter autant que possible les attaques de sorcières. Par conséquent, comment concevoir votre propre mécanisme de démarrage à froid est un sujet très précieux, et tout le monde est invité à laisser un message dans mon X pour en discuter. Réfléchissez ensemble à des options amusantes.
Liens X : https://x.com/web3_mario
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
