讀懂Dfinity：去中心化云計算平臺+高性能區塊鏈網路

撰文：msfew@Foresight Ventures

Dfinity 概覽

Dfinity 基金會

Dfinity 是一個非營利性組織，致力于將互聯網重塑為能承載具有超高能力并具有安全性的計算機。Dfinity 所主導的互聯網計算機「ICP」采取 WASM 等新技術與新架構，具有防篡改、速度快、規模可達全球數十億用戶的特點，同時支持軟體的自主構建，有望扭轉科技巨頭壟斷互聯網的現狀，

互聯網計算機「ICP」

ICP 是 Dfinity 基金會主導的 Layer1 區塊鏈項目，致力于構建一個公開區塊鏈網路。ICP 為智能合約提供了一個無限制的運行環境，智能合約能夠以近乎正常中心化網路的速度運行。借助 ICP ，可以構建任何應用和服務，例如 DeFi ，例如鏈上運行的社交媒體網站，同時也可以擴展傳統意義上的 DApp。

GitHub
https://github.com/dfinity/ic
技術文檔
https://sdk.dfinity.org/docs/introduction/welcome.html
社區資源
https://github.com/dfinity/awesome-dfinity

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.Motoko：

Dfinity 自研的編程語言，類似以太坊自研的 Solidity，Motoko 擁有很多對于應用的特定優化（后文會進行深入分析），

https://github.com/dfinity/motoko

3.Rust：

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

Canister

類似以太坊中的智能合約，除了運行環境是 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 的缺點

https://dfinity.org/roadmap/

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 所有文章均不能作為投資建議或推薦，投資有風險，請評估個人風險承受能力后，審慎做出投資決策，

聯系信箱：[[email protected]]

相關資料與引用

https://medium.com/dfinity/a-technical-overview-of-the-internet-computer-f57c62abc20f
https://www.chainnews.com/articles/465260109330.htm
https://forum.dfinity.org/t/how-does-the-storage-mechanism-in-dfinity-works/2733
https://medium.com/dfinity/software-canisters-an-evolution-of-smart-contracts-internet-computer-f1f92f1bfffb
https://support.internetcomputer.org/hc/en-us/articles/4402245887764-What-are-the-Hardware-Requirements-to-be-a-Node-Provider-
https://forum.dfinity.org/t/few-general-noob-questions-about-the-internet-computer/1938/3
https://www.chainnews.com/zh-hant/articles/626831391302.htm
https://www.zhihu.com/question/275674226
https://medium.com/dfinity/cancan-the-internet-computers-decentralized-tiktok-is-now-open-source-5eed04547aa1
https://www.reddit.com/r/dfinity/comments/mum43f/how_fast_is_dfinity_exatcly/
https://forum.dfinity.org/t/custom-domains-for-ic0-app-community-consideration/6162/18
https://forum.dfinity.org/t/inter-canister-query-calls-community-consideration/6754
https://academy.ivanontech.com/blog/breaking-down-eth-2-0-ewasm-and-evm-explained