首頁  >  文章  >  ZKSync 空投惹爭議來看 Web3 計畫冷啟動的困境

ZKSync 空投惹爭議來看 Web3 計畫冷啟動的困境

WBOY
WBOY原創
2024-06-18 20:55:48266瀏覽

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

作者:@Web3Mariohttps://x.com/web3_mario

上週最火熱的議題肯定是ZKsync的公開空投查驗的事件了,本來筆者正在學習並書寫一些關於TONDApp開發的學習經驗,但是看到這個的學習經驗,但是引發的爭議的廣泛討論,頗有一些感受,因此撰文一篇,希望與大家分享。總的來說,ZKSync的空投方案採用了一個基於財產證明的分配方式,更聚焦於對開發者,核心貢獻者和ZKSync原生DegenZKSync原生Degen這就造成了一個局面原生Degen巨鯨在笑,擼毛工作室在叫。

社群爭論的焦點:互動是關鍵還是資金量是關鍵

很長一段時間,Web3產業似乎已經形成了透過專案的產品冷啟動的範式。在Layer2賽道中更是如此,透過引導開發者和用戶對潛在空投的預期,刺激開發者積極構建並維護DApp,同時刺激用戶在發展早期將資金橋接到目標 Layer2,並積極參與目標Layer2上面運行的DApp,從而起到活躍生態的目的,這已經成為了一種制式。

因此在過去,用戶普遍對於ZKSync的空投預期是對標它的兩個直接競品,ArbitrumOptimism。當然無論從產業影響力,VC背景,募資規模等角度來思考,這個結論都是合乎邏輯的,然而結果卻大相徑庭,這就導致了很多復用過去經驗來參與ZKSync 的用戶似乎並沒有得到期望內的獎勵數量,從而導致了社區陷入了廣泛的爭論中。

為了探究這個爭論背後的原因並探討一些對未來的借鑒意義,自然是需要回顧一下之前的ArbitrumOptimism的空投規則的設定。首先回顧一下Arbitrum的空投活動,這要追溯到20233月,其為使用者供應 Arb空投,同時為Arbitrum生態中運行的DAO分配了13%..空投活動的設定是基於202326日的快照數據,針對用戶具體的規則如下:

  • 跨鏈到Arbitrum: 用戶需要將資金轉入Arbitrum OneArbitrum Nova
  • Arbitrum Nova
  • 不同時間內的交易: 用戶在兩個不同的月份、六個不同的月份或九個不同的月份進行過交易。 交易頻次和互動: 用戶進行了超過4筆、10筆、25筆或
  • 100筆交易,或與相應數量的智能合約進行了互動。 交易價值: 用戶進行的交易總價值超過10,000美元、50,000
  • 提供流動性: 用戶已存入超過10,000美元、50,000 rum Nova活動: 用戶在
  • Arbitrum Nova
  • 上進行了超過3筆、5筆或10筆交易。

每個細則會有具體的分數計算方式,分數上限為15分,這個分數用來決定使用者可以領取的Arb,計算方式可以近似為數量線性關係,但起始獎勵從3分開始,封頂獎勵10200Arb。而針對DAO的獎勵,則直接按照活躍度評估的方式來確定具體金額,從結果上看最終137DAO GMX獲得的最多,分別為800萬個Arb,按照當前的實質,這實在是一筆豐厚的收益。

接下來回顧Optimism,與Arbitrum不同,Optimism的空投其最早的第一輪空投活動要追溯到20226月,總共有5%的獎勵被分發給了該地址已經進行了四輪空投,其每輪空投的具體規則如下:

  • 第一輪:按交易次數劃分了普通用戶與活躍用戶,分別對應交易1次的地址與交易大於4次的地址,以及參與者,Ethereum多簽錢包使用者,Gitcoin捐贈者和跨鏈橋使用者。每種身分對應一個定值獎勵,後三種獎勵可疊加。
  • 第二輪:總交易gas fee大於6.1美金或參與委託治理的幣齡$OP 第三輪:參與委託治理的幣齡超過18000的用戶可以瓜分
  • 19,411,313
  • $OP第四輪:針對NFT的創建者分配了
  • 10,343,757
  • $OP$OP
  • $OP

🎜🎜🎜指標,互動越頻繁的用戶通常可獲得的獎勵越多。然而這個潛規則似乎被ZKSync摒棄了,在ZKSync的空投設計中,ZKsync 用戶的資格和分配如下:

  • 資格篩選:每個在 ZKsync Era ZKsync Lite ZKsync Lite ZKsync Lite ZKsync Lite ZKsync Lite 其設定了7個考察標準用於篩選符合資格的用戶,例如與非代幣合約互動超過🎜🎜10🎜🎜個且非代幣合約必須至少有🎜🎜30🎜個且非代幣合約必須至少有🎜🎜30🎜在🎜🎜ZKsync Era🎜🎜至少發送🎜🎜5🎜🎜筆交易等。
  • 分配:在計算某個符合上述標準的地址具體的獎勵數量時,基於一個價值縮放公式來確認,該公式根據發送到 🜎而這些加密資產在錢包中保留的時間計算出一個時間加權平均值,並以此來調整每個地址的分配,同時參與DApp協議的資金將獲得2倍的加成,這意味著你向ZKSync轉移了大資金,保持了很長一段時間,並積極使用這些資金參與一些有風險的產品,例如向DEX提供流動性,將獲得更多的獎勵。 乘數:
  • 符合特定標準的位址可以在分配中獲得乘數。這些標準通常是持有一些高風險的ZKSync原生的山寨幣或NFT
  • Sybil檢測:最後ZKSync也會做女巫攻擊檢測,以確保大部分的機器人被過濾掉,其標準從兩個方面也會做女巫攻擊檢測,以確保大部分的機器人被過濾掉,其標準從兩個方面。 地址建立後的首筆ETH來源,以及該EOA地址與CEX存款地址的交互情況。其實這也是利用了CEX KYC的特色。
從具體規則我們不難發現,在獎勵的計算中並不涉及到交互次數這個緯度,更聚焦在單一帳戶的資金量與配置風險資產的意願度。因此當結果公佈之後,讓許多秉持過去經驗在

ZKSync上大量交互的擼毛黨或工作室大跌眼鏡,這也是引爆整個爭議的源頭。因為該部分用戶為了增加獲得潛在空投的地址數量,通常會選擇將大資金盡可能的分散到地址群中,這些地址群通常為幾百甚至上千個,並使用小資金參與某協議,通過預判一些可能的激勵行為,透過自動化腳本或手工的方式頻繁的刷交互,做任務的方式提高潛在的收益。而ZKSync的空投設定讓這個策略失效,許多頻繁互動的地址所付出的手續費甚至都比獲得的獎勵還高,這自然引起了該部分人群的不滿。

而且我們在X中不難發現大量的空投獵人KOL,該部分人群以教大家如何方便獲得項目方空投為主題發佈內容,通常有著廣泛的粉絲群體,具有較強的號召性,因此透過社群媒體給ZKSync官方施壓,從而期望改變這個局面。然而從官方的態度來看,似乎也很強硬,並沒有因為承壓而修改規則,所以才有了現在的局面。爭論的過程中所引發的對於一些可能的作惡行為的指摘與辯解更是這場輿情大戰的看點。

從結果來看,兩邊的訴求似乎都可以理解,個中對錯只能看從什麼角度去論述了,但我認為有些東西是值得思考的,那就是時至今日,Web3 專案冷啟動階段的核心價值使用者究竟是誰,或是說什麼樣的使用者才是冷啟動階段該去激勵的使用者。

重交互帶來女巫攻擊問題,財產證明則帶來壟斷問題

對早鳥參與者基於Airdrop專案冷啟動的手段,好的空投機制設定能夠幫助專案在早期高效的吸引種子用戶,同時透過刺激用戶對協議關鍵行為的使用而完成用戶教化,增加產品的黏性。這也是很長一段時間內,大部分Web3專案的空投設定著重於對互動行為進行激勵的根本原因,然而這樣做帶來了一個弊端,就是降低了獲得獎勵的門檻,容易使得活動遭遇女巫攻擊。因為互動行為是容易被自動化和批量化,這就給了很多專業團隊批量操作的空間,當大量的機器人帳戶湧入後,雖然會讓協議出現短暫的虛假繁榮,然而這些「用戶」通常是逐水草而居,無法為項目未來的發展提供動力,在獲得獎勵後大部分也會套現用於增加資金周轉率從而提升收益,這種激勵機制反倒稀釋了項目方對於那些真正價值用戶的獎勵數量,實在得不償失。 那麼為什麼這種機制在早期效果不錯呢,這自然是由於彼時類似的專業團隊並沒有那麼多,大部分用戶還沒有對這種激勵機制形成思維慣式,交互行為還是比較純粹的,屬於真實用戶,這就讓激勵能夠較為高效的分配給這些用戶,由此產生的財富效應也幫助項目方實現上述好處,然而隨著於此而來的賺錢效應的影響,這種方式顯然已經無法有效的吸引真實使用者。我的一個切身的感受,以交互為主要激勵對象的空投活動的效用到

Arbitrum

空投時基本上已經到了頂點。 這也是

ZKSync

想要圍繞資產相對規模而捨棄使用交互數來作為價值用戶識別的依據的根本原因。然而這種財產證明方式也未必沒有問題。雖然能夠較為有效的識別並排除女巫攻擊的風險,但與之而來的新問題就是壟斷所引發的財富分配不均。

我們知道Web3計畫的一個核心價值是自下而上的分散式自主模型。這意味著基層用戶(小資金量的真實用戶)的支持才是一個專案發展的基本盤。也正是有了基層用戶,一些巨鯨用戶才可能湧入,並形成一個較為可持續的發展形態,畢竟資金優勢在大部分的場景上還是具備的,只有基層用戶足夠多,巨鯨用戶收益才夠大。那麼財產證明的分配製度會導致在冷啟動之初,其早鳥用戶中巨鯨用戶的收益就已經較為明顯,這就很難對基層用戶形成有效激勵,自然就無法形成一個有凝聚力的社區。

歸根到底,對於Web3專案來說,在設計冷啟動機制時還是要仔細斟酌對自己產品來說價值用戶畫像,並根據當前所處的環境,設計對應的機制,有效的激勵上述價值用戶的同時盡量規避女巫攻擊才是重中之重。因此如何設計自己的冷啟動機制,這是一個非常有價值的話題,也歡迎大家來我的X中留言討論。一起腦力激盪一些有趣的方案。

以上是ZKSync 空投惹爭議來看 Web3 計畫冷啟動的困境的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn