應用鏈:應用匯總的最終目的地

路易士:

在這次獨家採訪中,Bnews介紹了Octopus Network的創始人Louis,他是機制設計和加密貨幣市場的資深研究員,BTC早期投資者。 本次訪談聚焦應用鏈、多鏈、八達通2.0、DePIN等熱點話題。

1.您認為應用鏈如何確保安全?

Appchain的安全性一直是痛點。 誠然,自己做PoS可以保證安全,但這是一種傳統的思維方式,實踐證明,獨立的PoS是最昂貴的。 為了維護鏈的基本安全,可能需要每年額外發行5%-10%的代幣。 這將給Appchain帶來非常大的成本壓力,這體現在Token在市場上的持續拋售壓力上。

如果使用共用安全機制,每年只需要多發行1%-2%的代幣來保證鏈的安全性,獲得的安全級別可能遠高於獨立PoS。 為什麼效率提高了五倍? 為什麼沒有許多應用程式鏈開始使用共用安全性? 我認為這是思維方式的轉變,大多數應用程式開發團隊對共用安全性仍然不夠瞭解。 還有一些團隊認為,如果代幣沒有質押,就沒有價值。 但是,在未來,市場會給出一個選擇,即作為應用鏈代幣,它應該具有應用價值,並且能夠從應用層經濟系統中獲取價值。 如果令牌僅用於保持鏈的安全,而不使用應用程式,則它是無用的令牌。

現在應用鏈共用安全有多種選擇,包括最早的 Polkadot 老虎機拍賣、Cosmos 的複製安全和八達通的租賃安全。 在我看來,租賃安全是最靈活和可訪問的,鏈可以在沒有整個生態系統支持的情況下啟動,安全級別僅取決於提供的代幣獎勵數量。 起初可能只有十幾個驗證者提供數百萬美元的安全性,但隨著使用量的增長,代幣價格的增長,激勵水準自然增加,安全性也是如此。 **

除了共用安全之外,還有另一種思維方式,就是將Appchain作為Rollup運行,錨定公鏈L1的安全性,其中最重要的是乙太坊。 這是一個複雜的問題,但總的來說,匯總技術的採用遠不如應用鏈成熟,它們最終可能會落在同一個地方。 **

2.對於Infra來說,Appchain是否能夠在一定程度上連接整個區塊鏈?

在基礎設施領域,應用鏈和公有鏈之間的平衡一直是人們關注的話題。 應用鏈不能替代公鏈,公有鏈也不能完全取代應用鏈。 因為在計算系統中,多功能性和效率總是需要平衡的。

系統越通用,針對特定需求進行優化的難度就越大,相反,針對特定需求優化設計,自然會局限於這個場景,失去一定程度的通用性,這是一個基本的矛盾。 因此,對於一個應用來說,一開始就可以選擇公鏈。 在一定程度上,會出現公鏈有時無法滿足的特定需求,例如費用或用戶體驗等,因為公鏈不可能針對特定應用進行更改。 此時,應用可以選擇從公鏈遷移到應用鏈,通過控制自己的第 1 層來實現深度優化。 一個典型的例子是 DYDX,其 V4 版本使用 Cosmos 作為應用鏈。

應用鏈也有其自身的挑戰。 比如安全需要從零開始維護,需要跨鏈,否則就成孤島。 經過多鏈網路技術和跨鏈技術的發展,我們相信已經有良好的基礎設施能力來支撐應用鏈的不斷發展。 所以我預計未來會有大量的應用鏈,他們會探索很多應用領域和Web3應用領域。 這些應用鏈將通過安全強大的跨鏈協定相互連接成一個統一的網路,這是Cosmos在2015年提出的區塊鏈互聯網願景。 **

3.您如何看待未來多鏈互聯和多匯總互聯的爭議?

我先澄清一個問題,Rollup是一個區塊鏈,但目前Rollup並沒有通過去中心化的共識產生區塊。 如果你依賴集中式排序器,你就失去了區塊鏈的一些基本特徵,比如拜占庭式的容錯活潑和抗審查性。 因此,為了實現去中心化匯總,需要許多節點來充當排序器,這些節點應該是無需許可的,最有可能使用 PoS 網路。 另一方面,為了獲得更高的安全性,PoS Appchain可以將區塊發佈到DA層,並將交易摘要提交給進行結算的公鏈。

想一想,雖然一個是應用匯總,一個是應用鏈,但有什麼本質區別嗎? 這就是所謂的通向同一目的的不同路徑,核心原因是在模組化區塊鏈的世界里,Web3基礎設施面臨著同樣的問題,最好的可用技術是一樣的。 **

4.對於市場基於ETH2.0提出的一些想法可能會沖淡ETH共識,你怎麼看?

我非常關注V God發佈的博客和推文,並參與了一些討論。 你為什麼叫他神V?因為他很有遠見。 他會為未來幾年的重要問題做基礎工作,明確一些基本概念,進行深入討論,這些都是長期問題。

V 上帝建議不要使社區共識ETH超負荷。 說白了,代碼就是法律,智慧合約代碼解決了應用層的所有問題,處理了自己的規則,不需要社會共識來解決糾紛,尤其是不會將糾紛擴大到整個ETH社區。 **

防止社會共識過載是一種預防措施。 目前,似乎沒有一個依靠社會共識來解決爭端的重大ETH專案。 因為依賴社會共識本質上是糟糕的設計,協定本身應該是自洽的。 上帝V提出的問題和想法非常重要,具有前瞻性。 **

5.你對賽道有什麼樣的想法?

一些 Web3 應用程式更適合在應用程式鏈上運行。 我們一直在研究非 DeFi 應用程式,因為 DeFi 通常依賴於共用流動性,以及與其他協議的組合。 非 DeFi 應用,例如鏈遊戲、創作者經濟以及最近 DePIN 的興起,都是我們關注的問題。 特別是DePIN,我們認為這是一個尚未充分探索的領域。 基本思想是通過協議發行代幣,然後通過眾包構建服務網路,無需許可即可參與。 消費者通過協定使用網路服務,服務商和整個網路受益,從而可以跳過公司的組織形式。 DePIN能否建立,取決於協定能否與分散的服務商協同形成可靠的服務網路,以及通過協定協調協調網路是否比中心化公司更高效。

**DePIN 正在計算存儲、無線通信、能源網路、感測器網路等領域進行探索。 我們希望八達通網路能夠為DePIN的應用鏈做一些具體的服務,比如代幣經濟的設計,或者提供通用模組,説明早期專案更快地構建網路,形成服務能力。 **

6.您認為專案端、市場和VC之間的關係在整個行業代幣中是如何平衡的?

我想談的第一件事是代幣本身的定義及其在 Web3 中的位置,這引起了激烈的爭論。 在我看來,雖然一個加密協議網路可以有多個代幣,但基本上會有一個主要的原生代幣或治理代幣。 本機令牌實際上是加密協議網路的擁有權證書。

擁有權包括權利的兩個主要方面。 一方面,有收益權,即通過加密網路的運營,內置的價值捕獲機制將增加這些代幣的價值。 另一方面,還有治理權,即通過原生代幣或其衍生代幣,社區可以加權確定協議網路的演進方向。 有人可能會說,如果以這種方式定義令牌,則它是一種證券。 就我個人而言,我認為這是不可避免的。 監管需要隨著 Web3 經濟現象的發展而發展。 幾年前,赫斯特皮爾斯的安全港提議為代幣發行人提供豁免期,以適應新的擁有權分配機制。 如果為了適應現有法規而扭曲Web3 Token的經濟實質,恐怕未來的彎路會越來越大。

假設我們同意令牌是加密協定網路擁有權的證明,那麼協議的設計方式必須考慮到網路中存在不同類型的利益相關者,即具有不同角色的參與者,並且通常只有一個角色是長期網路擁有者,擁有者角色。 例如,在雙邊基於市場的Web3網路中,服務提供者應該是擁有者,例如,在去中心化的B2C網路中,商家應該是擁有者,司機應該是去中心化的乘車鏈中的所有者,創造者應該是去中心化的創造者經濟網路中的所有者。 確定擁有者的目的是在協定中向擁有者發行盡可能多的代幣。

除了擁有者之外,網路通常需要其他類型的貢獻者才能發揮作用,例如開發人員,專案擁有者,社區和機構投資者等。 如果有擁有者的概念,我認為其他貢獻者的代幣獎勵應該被視為構建加密協議網路的必要成本。 其他貢獻者的激勵設計背後的想法是如何用最少數量的代幣交換足夠的貢獻,以滿足早期構建和冷啟動的需求。 例如,在應用鏈中安全性是一種成本,應該考慮如何在獲得足夠安全性的同時最小化安全性成本。 如果車主的概念錯了,那麼就會出現大問題,比如某網約車應用鏈使用獨立的PoS,每年向驗證人發放10%的代幣,很有可能驗證人的治理能力會超過司機的治理能力。

總之,如果我們將令牌視為加密協定網路的所有權證明,那麼擁有者角色是在設計協定之前確定的。 將其他貢獻者(包括團隊和投資者)視為供應商。 **

7.現在很多 DePIN 項目的經濟性都參考了 Helium 的雙代幣 Burn-Mint 模型,引入了數據信用或其他信用,目前看起來比較健康,你能談談這個模型的潛在風險嗎?

你提到的BME模型是燒鑄均衡模型,它有兩個主要優點,一是法定貨幣定價降低了交易成本,二是協定收入燒掉和協定成本Mint是分開的,非常清晰方便各種角色評估和參與。

BME模型還存在兩個潛在風險。 首先,Burn依賴於價格預言機,因此面臨預言機攻擊的風險,第二點是關於均衡的。 當代幣價格下降時,服務提供者的收入減少,運營效率低的供應商將首先退出。 然後,效率最高的供應商將收到更多的代幣,從而達到盈虧平衡。 相當於在Token價格下跌時淘汰了效率低下的服務提供者,完成了系統的新陳代謝。 但是,需要注意的是,如果大量服務提供者退出,可能會損害網路的服務能力,並使系統陷入死亡螺旋。 **

**免責聲明:本文僅供參考,不應用作法律、稅務、投資、財務或任何其他建議。 **

查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)