摘要:Dfinity 的ICP儘管在應用生態和標準制定上還仍需建設,但目前已經是一個成熟的專注於Serverless 功能的區塊鍊網絡。它能幫助DApp 開發者更快地搭建更高性能的應用。 Dfinity 概覽Dfinity 基金會Dfinity 是一個非營利性組織,致力於將互聯網重塑為能承載具有…
Dfinity 的ICP儘管在應用生態和標準制定上還仍需建設,但目前已經是一個成熟的專注於Serverless 功能的區塊鍊網絡。它能幫助DApp 開發者更快地搭建更高性能的應用。
Dfinity 概覽
Dfinity 基金會
Dfinity 是一個非營利性組織,致力於將互聯網重塑為能承載具有超高能力並具有安全性的計算機。 Dfinity 所主導的互聯網計算機「ICP」採取WASM 等新技術與新架構,具有防篡改、速度快、規模可達全球數十億用戶的特點,同時支持軟件的自主構建,有望扭轉科技巨頭壟斷互聯網的現狀。
互聯網計算機「ICP」
ICP 是Dfinity 基金會主導的Layer1 區塊鏈項目,致力於構建一個公開區塊鍊網絡。 ICP 為智能合約提供了一個無限制的運行環境,智能合約能夠以近乎正常中心化網絡的速度運行。借助ICP ,可以構建任何應用和服務,例如DeFi ,例如鍊上運行的社交媒體網站,同時也可以擴展傳統意義上的DApp。
-
GitHub
-
技術文檔
-
社區資源
ICP 的特點
重點特點:部署方便、去中心化、容災備份
ICP 擴展了普通互聯網的功能,使其可以託管後端軟件,將整個ICP 網絡轉變為全球計算平台。
使用ICP ,開發人員可以通過直接在ICP 網絡上快捷地部署代碼來創建應用和服務,而無需進行繁瑣的服務器計算機部署和商業雲服務購買。
簡而言之也就是說,ICP 把軟件開發方面的部署、架構問題、拓展問題都解決好了,應用開發人員要做的僅僅就是寫代碼就好。
1. 定位
-
對標Serverless
-
ICP 並沒有特別標榜自己是類似以太坊的公鏈,而是說自己是互聯網計算機。 ICP 的定位就類似區塊鏈版的中心化雲平台(如亞馬遜的AWS ,微軟的Azure ,或者幾乎純做Serverless 的Heroku (母公司為Salesforce ))上的Serverless (無服務)。
-
Serverless 直譯就是“不用擔心服務器”,顧名思義就是當開發者部署一個應用時,不用擔心服務器配置問題,而是類似直接把代碼上傳上去就可以完成部署。 Serverless 除了不用擔心服務器、交付速度快以外還有幾個特點,一是自動彈性,比如在雙十一的時候,淘寶需要大幅增加服務器數量,如果採用Serverless ,就無需去手動調整服務器,雲平台會自動拓展應用的資源;二是按實際使用資源計費,傳統服務器是按月或年進行租用,Serverless 是按照調用的次數來計費,ICP 也如此,因此性價比較高,不會產生閒置服務器浪費資源的情況。
-
Serverless 的最大優點和賣點就是開發方便快捷,整體性價比高。雲平台現在所做的就是不斷支持更多的編程語言(比如支持Nodejs ,不僅吸引Nodejs 的開發者使用Serverless 服務,也逐漸讓Nodejs 的生態也更加繁榮),簡化軟件開發人員使用Serverless 的步驟。而ICP 的生態相對於傳統雲平台Serverless 的生態,就顯得有些不那麼繁榮。 Serverless 原生支持幾乎所有的熱門編程語言,而ICP 採用的是WASM (後文會深入分析WASM ) 以及一門自研的編程語言。對於這門自研的編程語言,雖然功能十分豐富,但是它的生態必然是不如Java 、Nodejs 這類語言的。而WASM 生態也是非常新的一個東西,目前落地還尚早,在WASM 的主戰場瀏覽器,API 也還沒定稿。所以是現階段需要一些發展時間,未來各個生態繁榮後大有可為。
-
Serverless 是未來的趨勢,據AWS 的調查,百分之40 的組織都在使用Serverless。據阿里巴巴所說,Serverless 給阿里的人力成本降低了48%,未來對Serverless 的需求會越來越大。在Serverless 這條大賽道上,ICP 的對手有AWS 、微軟Azure 等巨頭。但是現在Serverless 還處於各家混戰的情況,沒有統一的標準,因此ICP 還是有機會通過高性能和高安全性搶占市場份額的。
-
對比雲平台
-
實際上,ICP 所說的“雲平台太過於中心化”未必是完全正確的。對於單個雲平台來說,中心化是必然的;但是目前有很多開源項目比如Terraform (https://github.com/hashicorp/terraform) 或者Serverless Framework 等各種庫與插件,可以做到部分地串聯雲平台,做到統一運維和部署,通過同時使用多個雲平台,可以部分解決雲平台過於中心化的問題。但是當選擇使用特定的一個雲平台的服務後,確實會造成轉換平台困難的問題。 ICP 同樣存在這樣的問題,並且可能因為生態封閉而更加嚴重。 ICP 所強調的去中心化實際上依然是區塊鏈的特性中的共識以及節點做到的去中心化。
-
對比以太坊
-
回到開發的流程,在ICP 上開發實質上和在以太坊上開發沒有特別大的區別,甚至可以說更加困難(文檔、社區支持相對少)。作為一個新的開發者,開發者需要更多的理由才能說服自己去選擇ICP。既然以太坊上的受眾更大,開發也能找到更多幫助,那開發、發佈到ICP 乃至其他公鏈的優勢是否真的更大呢?這是每個“以太坊殺手”公鏈應該思考的問題。但是ICP 很機智地選擇避免正面和以太坊競爭,而是偏向於對標雲平台上的Serverless。
2. 編程語言
1.WASM:
ICP 所推薦的Motoko 能編譯為WebAssembly (WASM)。 ICP 的運行過程中利用了WASM 容器來存儲數據並執行代碼。 WASM 是一種用於基於堆棧的虛擬機的二進制指令格式。它支持在Web 上部署客戶端和服務器應用程序。 WASM 容器就類似以太坊的EVM,相對EVM,WASM 更加強調執行效率和性能。在以太坊2.0 當中,以太坊也有計劃從EVM 移植到WASM。
WASM 的優點就是性能強、安全性(在內存安全的沙盒裡運行、會執行瀏覽器的安全策略)、生態拓展(可以直接嵌入到Web,但是瀏覽器暫時沒完全支持)。
2.元子:
Dfinity 自研的編程語言,類似以太坊自研的Solidity。 Motoko 擁有很多對於應用的特定優化(後文會進行深入分析)。
https://github.com/dfinity/motoko
3.防銹:
ICP 提供SDK 的語言,適合在WASM 容器中運行。
4.其他的語言由於沒有SDK 以及官方開發文檔,可能還是需要Motoko 或Rust 作為膠水來實現與ICP 直接交互的部分,因此開發基本還是只能選擇Motoko 或者Rust。
3. 生態
從生態和開發者體驗上來說,Dfinity 提供的示例程序源碼、技術文檔、開發工具(VSCode 插件、NPM 庫、DFX 腳手架)都很全面。
共識協議
特點
PoS 提速並解決計算冗餘、隨機數信標保證去中心化、staking 保證安全性、週期性最終確認保證輕量。
共識過程
不同於以太坊的DApp 只是適時調用合約,ICP 設想的軟件是完全依靠智能合約來驅動服務的。綜上來講,ICP 需要非常高的計算性能、減少計算冗餘,因此ICP 但同時還得在保證區塊鍊網絡去中心化的情況下的足夠安全,因此這對它的共識算法提出了苛刻的要求。
-
開始前的節點準備:
-
節點創建私鑰公鑰,建立匿名的永久身份。
-
節點加入網絡需要抵押固定的token 作為staking。
-
節點隨機的與其他節點組成閥值組(完全隨機,一個節點可存在於多個閥值組)
-
閥值組中,運行分佈式密鑰協議(DKG),每個節點獲取該組的「驗證簽名」密鑰(不同於個人密鑰,有一組的私鑰數學拆分而來)。
-
系統還是根據DKG 產生閥值組的共同公鑰,並對閥值組進行註冊。
-
準備就緒,開始等待參與共識。
-
共識過程:
-
選擇本輪委員會組*注1 *注 4
-
提案委員會打包出塊
-
公證委員會持續接收並驗證區塊
-
隨機數信標收集簽名;等待閥值,產出公證與隨機數*注 2
-
R+1 step0 同步正確區塊,R+1 輪開始,回到step1 *注 3
-*注 1
重點:非交互式。 DFINITY,首先由隨機數公開的選出了400 個客戶端一組的出塊組,來打包交易並出塊。每一個客戶端都會出塊,還有一組同時隨機數選出的驗證者,他們會接受區塊,同時運行一個根據隨機數判斷區塊權重的協議,驗證者只簽名權重最高的節點,期間大家不會交互,不會進行拜占庭共識互相發送簽名數據,主要是固定區塊時間裡不斷尋找權重最高的區塊即可。在一個區塊接受到了超過50% 個驗證者的簽名後(是單獨簽名的,不是一起聯合簽名的),系統會自動聚合區塊上的簽名,並確認區塊為唯一,一但客戶端觀察到聚合的簽名,就會進入下一輪共識。可以看到,整個過程都沒有進行拜占庭協議,只是遵序三個原則:
-
客戶端遵序最高權限的原則對區塊簽名,權重越高的鏈越會被確認
-
系統遵循50% 以上簽名產出隨機數信標的原則
-
大家遵序一看到新的隨機數信標馬上進入下一輪共識的原則
三個原則剔除了多餘的無效區塊,獲得了唯一的區塊,從而近似的達成了一致性共識(說近似是因為可能有同時存在兩個被公證區塊)。整個通訊過程幾乎為零,在廣播gossip 協議的網絡中,一個有400 個節點的組網,只需轉發大約20KB 的通信數據,即可產生閾值簽名。而一個小組的分佈式簽名密鑰的生成,是在小組創建時就分配好的,不需要在共識階段產生,一次生成多次使用。類比一下非常相似但由兩輪拜占庭共識交互的Algorand。 Algo 的隨機數抽籤過程是隱秘式的,也就是說節點只知道自己被選擇與否,它卻不知道全網中有多少節點被選中。因此Alogo 共識前必須遍歷一編全部網絡,進行一次拜占庭才能知道全部的被選取的驗證組,因此這裡的延遲時間與帶寬使用就很高了。再加上前面講的超大驗證組(2000 人到4000 人)的拜占庭通訊輪次與簽名數據的問題,Algo 共識下帶寬使用非常爆炸,這種人是沒這個能力參與的。
-
*注2重點:性能和安全性都很高的隨機數算法。 Dfinity 所用的隨機數算法是VRF。 VRF 涉及很多數學演算,我們可以將其視為一個黑箱子,一段是輸入,一段是輸出。輸入是一組客戶端的簽名,輸出是一個準確的隨機數。只有在獲取了足夠多的客戶端簽名,黑箱子才能輸出隨機數,再此之前,沒有任何一個客戶端能知道或預測它的輸出。 「足夠多」簽名的閥值為50%,因此這個VRF 的過程也叫做「閥值簽名」。這個VRF 具備三個特點:
-
可驗證:一但輸出了隨機數,大家都可以拿著客戶端的簽名對其進行驗證。 VRF 的V 就體現在這裡。
-
唯一確定性:一但有超過50% 的客戶端發送了簽名,黑箱子接受到後會獲得唯一的一個確定的隨機數。這裡是因為使用的私鑰簽名算法具有唯一性,也就是統一密鑰對統一數據的多次簽名的結果都不相同,只有一個可以合法的驗證。
-
非交互:在產生隨機數的過程中,雖然黑箱子需要收集大家的簽名,但是客戶端之間不需要進行交流,更沒法干擾到隨機數的從產生。
在已知的密碼學算法裡,只有BLS 算法能做到以上三點,而BLS 算法的提出者之一「L」Lynn 正是DFINITY 的高級工程師。其他的隨機數方案,要么驗證起來難度極高(連續哈希),要么無法保證唯一性,要么就是沒有閥值的設計,必須進行交互,存在「最後一個參與者」就能間接影響隨機數偏差的情況(以太坊的RANDAO 與VDF)。當然這個VRF 還是一點問題,選取的一組共識者中如果有超過50% 被攻擊者掌握,那麼他可以間接的干擾到隨機數的生成,當然來預測隨機數還是基本不可能的,沒法直接控制。攻擊者還可以不發送簽名,讓隨機數生成過程停止,從而讓整個系統宕機。 (這個其實沒有任何共識協議能頂得住)
-
*注3重點:超快的最終確認。 DFINITY 的共識是按輪次進行的,每一輪共識的開始與結束的標誌,都是觀察到隨機數信標產生新的隨機數,而這個隨機數是系統聚合簽名產生公證的同時更新的。因此這DFINITY 的區塊高度必須與輪次一致,每一輪中生產的區塊,必須是引用了上一輪的公證簽名,不然視為非法。同時公正組只會簽名本輪產生的區塊,不會對之前輪次的區塊簽名。總結為兩個強制:
-
只有本輪發布的區塊才能被公證;
-
只有引用上一輪被公證的本輪區塊才是合法的;
這保證了出塊與公證兩個過程,都沒法被惡意扣留,因此攻擊者沒辦法偷偷來準備一條比主鏈更長的影子鏈,來做雙花攻擊,因為從影子鏈的第一個區塊起就不合法了。因為存在上述「驗證者組單獨簽名,系統聚合簽名產生公證」的公證過程,因此每一輪後基本可以做出唯一性的確認。但也有會出現兩個或以上區塊同時通過公證的情況,因此一輪結束後還不能做到最終確認,這時就需要在下一輪中繼續判斷。此時等待出塊過程完成,因為出塊者可能選擇在上一輪同時被公證的區塊後面繼續生產,所以同時存在幾條分叉。驗證者會計算權重來判斷唯一區塊,權重高的一條鏈就作為唯一確認鏈,然後驗證者才會對他進行簽名。因此當本輪出現了新隨機數時,也就意味著分叉已經被剪除,而上一輪的區塊,包括其中的交易,都獲得了最終的確認。快速確認不僅提高了性能,剪除了分叉,降低了系統的冗餘度,並且可以讓客戶端不用存儲全部要歷史區塊數據,任何一個新加入的區塊,只要從最近的確認區塊開始即可。
-
*注4重點:彈性拓展性能。優秀的隨機數給DFINITY 的網絡帶來近乎無限的擴展可能性,因為整個隨機數的產出,包括出塊與公證,都是由固定數目的委員會組來執行的,客戶端新節點的加入不會影響到運行的速度。 DFINITY 隨機產生多個閥值組的,因此多組間並行運行,從而實現分片,是相當輕鬆的。以太坊2.0 的分片方式也非常近似。但是Dfinity 的存儲和網絡拓展性也是需要拓展的,這方面上節點與節點、存儲之間的傳輸也是有損耗的,帶寬未必受得了,如果這個方面無法擴展,僅僅是做到分片的話可能只是表面的優化。
計算與存儲
應用架構
從底層開始:P2P 層(收集分發數據) → 共識層(整理消息,驗證後寫入區塊) → 消息路由層(傳輸信息到目的地) → 應用執行層(通過WASM 安全沙盒環境進行計算)
開發階段,Dfinity 的開發者工具都會把各個層級抽像出來,複製給開發者一個本地版來方便開發。
應用運行機制
代碼編譯為WASM 模塊,部署到ICP 的Canister 容器(容器中包括了程序本身、狀態、用戶交互記錄) 中。
https://zhuanlan.zhihu.com/p/372441370
罐
類似以太坊中的智能合約,除了運行環境是WASM 的沙盒以外本質上沒有其他大區別。正如之前提到的,一個很重要的特點就是ICP 作為一個類似Serverless 的服務提供商,上面的應用相比以太坊應用是需要具有更高的實時性的,比如ICP 版抖音,因此Canister 需要做更多的交互,同時也要保證不宕機、不擁擠卡頓。
存儲
ICP 的應用狀態是存儲在內存裡的,通過共識階段來進行管理和確認修改。
在Dfinity 的博客上有個經常被提及的詞就是正交持久性(orthogonal persistence)。它所指的依然是Serverless 的特點,開發者不用擔心數據丟失,不用擔心數據存在哪裡。這就說明ICP 和中心化的雲平台是類似的,也有容災備份等操作。
我們可以看一份Dfinity 提供的節點服務器硬件要求。
我們可以看到節點服務器要求16 條32GB 的內存和3.2TB 的SSD。相比與以太坊驗證節點4GB 內存和290GB SSD(https://nimbus.guide/hardware.html) 的配置要求來說算是比較誇張了。當然對於存儲來說,更誇張的是Filecoin,需要1TB 內存和16TB SSD 的配置 (https://zhuanlan.zhihu.com/p/337597732)。
ICP 的計算和狀態存儲基本都是跑在內存上的(類似比如中心化雲平台SAP 的HANA),硬盤可能只是起到一個鏡像存儲的作用,因此對內存的要求比較高。這就類似遊戲服務器和網頁服務器的關係,遊戲服務器(類似ICP 上以及傳統中心化應用)需要處理應用無數多的狀態(聊天、裝備、傷害、血量等);網頁服務器(類似以太坊上的應用)相比之下就比較無狀態,可能更多的是每次去數據庫讀取不同的數據就可以。和Filecoin 相比,ICP 並不是專注於存儲,而是Serverless,存儲的數據可能就是常規的應用數據、應用狀態以及應用代碼本身,所以也不需要那麼誇張的存儲要求。
鏈上應用實現方法
鏈上應用的項目結構非常類似以太坊。
-
前端:Web 端React 或Vue 等框架,手機端React Native 或Flutter
-
後端:Motoko(Dfinity 開發的編程語言) 或其他任何能打包編譯成WASM 的語言(比如Rust)
-
數據結構: Canister(Dfinity 為此開發了類似JSON 的接口描述語言Candid)
1. Cancan (類似抖音的短視頻平台)
源碼網址:https://github.com/dfinity/cancan
Cancan 類似ICP 平台上的抖音。 Cancan 的前端是用了Web 端React 框架,後端是用了Dfinity 自研的Motoko 語言。 Motoko 的部分還用到了Motoko Package Manager Vessel 這樣的高級功能。除此之外也用到了系統的一些API,包含了測試和持續集成,而且註釋也寫得非常詳細。 Cancan 可以說是在很少的代碼量裡實現了一個非常標準化的ICP 全棧應用,值得ICP 開發者學習。
整個應用的狀態都是使用了Canister 容器和ICP 來取代服務器、CDN、數據庫等。
-
前端:React 框架的資源都是在一個單獨的Canister 裡 (https://github.com/dfinity/cancan/tree/main/src/utils/canister)。
-
後端與數據庫:視頻數據和點贊等數據全部都在Canister 定義了類型 (https://github.com/dfinity/cancan/blob/main/backend/State.mo)。同時要應對百萬用戶級別的訪問,Cancan 用了一個Motoko 裡的高級數據類型:分佈式哈希表。由於是類似Serverless 的架構,Cancan 不用像傳統前後端交互一樣運作,而是類似能直接在數據庫上進行get 和post 方法(類似谷歌的Firebase)。
總之,從Cancan 的例子來看,當學會了Motoko 並且熟練掌握這門語言以後,在ICP 上的開發會無比高效而且完全不用擔心最惱人的部署等問題。
2. Portal (直播平台)
項目網址:https://ja7sy-daaaa-aaaai-qaguq-cai.raw.ic0.app
Portal 是一個比較新的ICP 上的邊看邊賺,邊播邊賺的直播平台,目前正在Alpha test。 Portal 的源碼暫時找不到,但是可以看出來前端用的是React 框架。經過和開發人員的交流,可以知道Portal 的關鍵的用戶或代幣數據都是在ICP 上,視頻的流媒體等數據的存儲和分發是用的Livepeer 協議。
-
前端:React 框架,目前來看客戶端比較簡陋。
-
數據庫:沒那麼複雜的數據都在ICP 上,而最難處理的流媒體視頻等數據不在ICP 上,而是用的Livepeer。 ICP 上的數據部分不再贅述。 Livepeer 自稱是一個基於以太坊的視頻直播平台,本質上是一個分佈式節點的視頻流媒體解決方案提供商,只是經濟系統基於以太坊。 Portal 使用Livepeer,就類似冷存儲使用Filecoin 平台,並不能體現出技術上特別大的創新。
總而言之,Portal 作為一個直播平台,最關鍵和難處理的視頻分發以及存儲都是選擇用的Livepeer,和ICP 沒有關係。 Portal 與ICP 的關係僅僅是部分簡單的數據使用ICP 存儲以及修改。這實際上就是Portal 抱ICP 的大腿,在宣傳其生態的同時,也能給自己打上這麼一個ICP 平台第一直播網站的標籤。
ICP 到底強在哪裡?
用戶角度
抽象的來說,ICP 已經足夠“快”了,以至於用戶都無法感知到它在後端是區塊鏈。可以說ICP 和其他雲平台在使用上是感受不出區別的。在傳統區塊鏈,比如以太坊上部署智能合約的應用會讓用戶體驗非常差,由於要各種確認交易支付手續費,以及網絡確認的緩慢。但是在ICP 上,由於其POS + 隨機數的共識協議,TPS 高,同時有數據結構的各種優化,可以支撐起流暢的用戶體驗。因此才有各種應用的ICP 版,比如LinkedUp、Distrikt。
開發者角度
-
讀取數據:目前普遍是在250ms 以下。這個速度基本上是人按下鼠標並放開的時間長短,人基本體驗不出來。
-
寫入數據: 因為需要達成共識,所以比讀取需要更多時間。目前通常是2-5 秒。與BTC 或ETH 相比,這要快了無數數量級。與中心化雲平台相比,這可能看起來很慢,但實際上這個速度是還可以接受的。
-
目前Canister 是單線程的,之後Canister 如果升級成多線程,那讀取和寫入的速度也能大幅度提升。從開發應用的角度而言,這個速度不算快,但是對於做一個普通的WebApp 絕對夠用了。
區塊鏈角度
ICP 的架構設計,類似雲平台,有更多的節點意味著節點與用戶之間的物理距離可能更短,網絡會更快,可以做到“更多節點= 更多子網= 更大的網絡容量= 應用更高的性能”。具體的技術實現可以參考這篇詳細的博客:https://medium.com/dfinity/a-technical-overview-of-the-internet-computer-f57c62abc20f。
ICP 的缺點
Canister 優化
目前,Canister 能給其他Canister 發更新請求。如果有A、B、C 三個Canister,A 要通過B 去和C 交互,那麼就需要A 發更新請求給B → B 發更新請求給C → C 接收請求。但是問題就是這樣的響應時間大概需要4 秒,對用戶體驗來說很慢。如果是跨不同子網的話就可能更慢。如果要是有10 個Canister 需要交互的話,那一個請求需要20 秒就是很恐怖的。在ICP 裡有查詢請求,性能是很快的,一次只需要200 微秒,但是跨Canister 的鍊式請求沒有原生支持。所以為了避免未來跨應用間請求的性能問題, ICP 需要更新,提供原生的高性能API。
還有一點就是目前Canister 的執行是單線程的,雖然Canister 中可以“打包”執行一些指令,但是如果支持多線程的話,也會大大改善性能。但是這些更新和生態中的其他部分息息相關,比如ICP 所支持的Rust SDK 也和Rust 這門語言自己的生態發展息息相關,所以技術上或許需要多方努力才能改進完成。
自定義域名
目前在ICP 上部署的APP 的域名都是Canister 的id 在加上ic0.app,比如 https://ja7sy-daaaa-aaaai-qaguq-cai.raw.ic0.app。雖然開發者可以自行通過購買其他的域名來重定向到Canister 的長域名,但是在使用過程中,那麼長的域名還是會對用戶體驗有很大的影響。同時Dfinity 論壇裡的開發者以及他的客戶也對這個問題很有意見,認為是開發過程中的巨大阻礙。這或許是很小的一點缺陷,但是也能展現出Dfinity 還需要努力完善這些細節。除此之外,在與Dfinity 的開發者交流之後得知,在ICP 上創建賬戶會有兩個賬號,這對於區塊鏈應用使用者來說是很反直覺的,所以應用開發者通常會單獨再創建一個賬號。這也是Dfinity 在用戶體驗上能提高的地方。
沒有殺手級應用
https://github.com/dfinity/awesome-dfinity
從Dfinity 的官方生態Repo 中可以看出Dfinity 的生態還是不那麼繁榮的,沒有一個耳熟能詳的殺手級應用。雖然ICP 的技術很強,但是就是沒有爆款產品出現在這個平台上,這樣可能就會形成惡性循環,導致生態越來越差。生態的不完善實際上也和一些標準還未推進有關係,比如下一點提到的代幣標準。
代幣標準
ICP 目前是沒有同質化代幣以及非同質化代幣標準的,這是一件很可怕的事情。作為一個區塊鏈的公鏈,鏈上應用最吸引人的就是其代幣的經濟系統,而ICP 卻還沒有標準化的提案。對一個開發者來說,沒有標準化的提案就意味著開發者的應用可能會在未來,因為不滿足標準化而被生態所拋棄。所以這也導致了大多開發者還在觀望,可能寧願在波場做一個應用,擁抱波場生態,也不願意在ICP 做。
總結
Dfinity 的ICP 是一個高性能,有著雲平台Serverless 定位的區塊鍊網絡。通過優秀的共識算法與架構設計,以及經過各種優化後打磨出的自研編程語言,ICP 能保證網絡上應用的安全性和高性能。儘管在應用生態和標準制定上,ICP 還略有仍需建設,但目前ICP 已經是一個成熟的專注於Serverless 功能的區塊鍊網絡,能幫助DApp 開發者更快地搭建更高性能的應用。
免責聲明:Foresight Ventures 所有文章均不能作為投資建議或推薦,投資有風險,請評估個人風險承受能力後,審慎做出投資決策。
聯繫郵箱:[fv@foresightventures.com]
相關資料與引用
-
https://medium.com/dfinity/a-technical-overview-of-the-internet-computer-f57c62abc20f
-
https://forum.dfinity.org/t/how-does-the-storage-mechanism-in-dfinity-works/2733
-
https://forum.dfinity.org/t/few-general-noob-questions-about-the-internet-computer/1938/3
-
https://www.reddit.com/r/dfinity/comments/mum43f/how_fast_is_dfinity_exatcly/
-
https://forum.dfinity.org/t/custom-domains-for-ic0-app-community-looking/6162/18
-
https://forum.dfinity.org/t/inter-canister-query-calls-community-thinkation/6754
-
https://academy.ivanontech.com/blog/breaking-down-eth-2-0-ewasm-and-evm-explained