【DNT精英論壇回顧】基於.Net Core構建aelf區塊鏈雲計算平臺

2019年7月28日，DNT精英論壇（暨.NET北京俱樂部）第1期在北京中關村國際創客中心舉行。論壇由資深.NET專家和社區活躍用戶發起，以「分享、成長、合做、雙贏」爲原則，旨在打造一個領先的技術分享平臺和成長交流生態。

aelf技術VP戎朋做爲受邀嘉賓參加主題爲「見證.NET，風口上的成功案例」的論壇。並分別就aelf的設計理念，以及如何結合.NET Core和相關技術進行實現，同時將對.NET Core和區塊鏈技術將來結合進行深度思考。 當前區塊鏈的痛點是什麼？如何解決？怎樣破局？帶着這些問題，咱們回顧一下，aelf技術副總裁戎朋在這次論壇上所提出的一些解決方案。

做爲去中心化雲計算的區塊鏈平臺，aelf旨在解決區塊鏈的商業落地應用問題，爲了推動區塊鏈價值的實現，aelf找出了區塊鏈目前亟待解決的如下三個主要問題。

資源隔離問題

在一個旨在實現商業落地應用的區塊鏈平臺上，會存在成百上千個Dapp，如何讓這些Dapp各自實現自身的功能屬性，互不影響，資源隔離是目前比較具備前瞻性的解決設計。

性能問題

每個Dapp的用戶增加是沒法預見的，如何在大規模臨時訪問等大流量忽然增加的狀況下，保持性能不受影響，是須要區塊鏈系統具備很強可伸縮處理能力的。

治理問題

區塊鏈是一個開放的去中心化平臺。一旦啓動，就至關於得到了本身的生命。如何構建一套生態體系，均衡區塊鏈內部利益相關方的需求，使整個區塊鏈生態系統朝着有益的方向演進？

基於以上三個行業痛點，aelf提出了對應的解決方案。

DPoS共識協議

DPoS解決了區塊鏈的治理問題。首先經過DPoS共識協議，全部利益相關方投票決定產生區塊的節點，其次是產生區塊的順序，最後是對於所產生區塊的驗證問題。

主鏈+多側鏈，一鏈一場景

主鏈+多側鏈解決了資源隔離的問題，每個Dapp均可以運行在本身的區塊鏈（即aelf側鏈）上，每條鏈均可以自主設置商業場景，並且側鏈之間是物理資源隔離的。

並行執行

akka.net 基於.NET Core實現集羣並行，基於.NET TPL實現的本機並行。

模塊化

aelf深度應用了Dapp的設計理念，因此模塊化特徵很是明顯，好比aelf使用GRPC實現了網絡層的模塊化，只要用戶使用合適的接口，便可實現預約的功能。同理，只要有合適的接口，DPoS共識也能夠轉化爲POW。

基於集羣

aelf的構件運行在集羣上，結合模塊化的設計，aelf內部各模塊的處理能力均可以伸縮與優化。

針對這些解決方案，戎朋在論壇上向嘉賓介紹了一些具體的實現細節

【DPOS機制】

DPOS共識機制決定了出塊節點、出塊順序以及驗證區塊等問題。戎朋重點分享了出塊順序的架構設計。

aelf構建了一個依靠外界輸入的隨機系統，每一個記帳幾點會產生一個in值和out值，每一輪的出塊順序依賴於上一輪in值的輸入和本輪的in值，進而決定出塊順序。驗證區塊主要是對於記帳節點所產生區塊的時間和是否合法進行驗證。緊接着，戎朋就aelf和以太坊的架構進行了對比，以太坊的Network、Miner、Worker、DB等全部的模塊都在一個kubernetes裏執行的，而aelf的DB cluster和執行交易的Worker cluster都是基於集羣執行的，因此具備很高的伸縮性。

【並行執行】

aelf的並行執行設計分爲兩個層次，首先是鏈級別的，也能夠稱爲是設計師的並行，開發者能夠根據本身的應用場景進行劃分，對於不一樣的場景去構建不一樣的Dapp，以分散在不一樣的側鏈上，從而實現並行執行。另一層就是鏈內的並行，也能夠稱之爲run time的並行，這種並行是將衝突的交易放在同一組別中，而後組別之間進行並行執行。

緊接着，戎朋講到：咱們能夠把區塊鏈想象成一個經過合法交易促發的狀態轉移機。那麼，這裏面有兩個角色。一個用來儲存狀態的數據庫，一個定義狀態轉移邏輯的智能合約。

在合約的字段裏，有可能有兩種類型的字段。一種是普通字段，另一種是Map類型的字段，其中字段自己是一個鍵值對的集合。由於區塊鏈的狀態數據是在數據庫裏面以鍵值對的形式儲存的，而合約裏面使用的數據形式是合約類的字段。因此咱們須要一種機制來將合約的字段翻譯爲數據庫數據的key。咱們定義了一個被稱爲data provider來負責這個翻譯工做。每個合約實例咱們會分配一個root data provider，這種root data provider會負責整個合約全部字段的翻譯。

對於普通字段，能夠直接獲得一個最終惟一的Key，可是對於map類型的字段是辦不到的。因此對於map字段的翻譯咱們獲得的不是最終的key，而是一個sub data provider，這個sub data provider會負責在運行時將實際使用的這個map裏的data key翻譯爲數據庫的key。被翻譯出的結果，咱們稱爲path。對於一個普通字段的path，一個標準形式包含合約地址，data provider名，以及字段名。而sub data provider，咱們能夠認爲翻譯後的sub data provider名是root data provider名加上map字段名。完整的path被用來惟一肯定交易所使用的資源，普通字段的path能夠經過靜態分析合約代碼獲得。

基於此，戎朋介紹了key內部的處理流程，首先要進行資源的定義，定義那些衝突的資源，把衝突的資源進行分組，而後進行組與組之間的並行執行，對於因爲用戶手動失誤而產生的衝突資源，最後進行鍼對性的階段性測試。爲了說明這個流程，戎朋用了幾個例子進行說明。

戎朋：這是一個最簡單的token合約。它有幾個普通字段，用來記錄stringstate和mappedstate的一些信息，這些字段都是0xabcd相似的合約地址，表明這一些key值，定義了一系列的path，這些資源的總和就被稱爲是資源的集合，咱們能夠從下面的示例交易中看出最終產生的path。咱們看tx 1，從aaaa用戶轉帳給bbbb用戶的交易，這裏就涉及到的兩個資源，/0xabcd/Balances/a和/0xabcd/Balances/b，tx 2是一樣的道理。

在aelf系統裏，須要實現一個標準，即acs2.proto ,在aelf系統中有不少相似的標準，要想實現資源的定義和合約的並行，那就須要實現Resource Info 這個函數，在這個例子中，須要根據合約的方法，定義這些衝突的資源，這樣在合約執行的時候，會獲取到這些衝突的資源，而後進行分組。接下來這個例子將很好地說明這個分組的方法。

這邊有四個交易，第一個是從aaaa用戶到bbbb用戶的轉帳100個token，第二個是從cccc用戶到dddd用戶的轉帳300個token，第三個是跨合約的調用，從一個合約的aaaa到另一個合約的aaaa，第四個是從cccc用戶到aaaa用戶的轉帳100個token,很明顯，若是沒有第四個交易，兩個合約的資源是沒有交叉可能性的，因此說，若是沒有第四個交易，第一個交易和第二個交易是能夠並行執行的，可是由於第四個交易的存在，整個系統就不能進行並行執行，由於資源衝突會對系統產生根本性的影響。 對於衝突資源的處理，aelf給出了這樣的解決方案：當執行完畢監測到衝突的資源時，會把產生衝突的交易進行簡單的丟棄，而後就會對這些合約進行標識，防止其執行，直到這些資源可以被正確的標識，這就是一個簡單解決衝突的過程。

【側鏈】

戎朋：雖然咱們用並行執行的思路加速了交易執行速度，但若是在一條鏈上存在多個DAPP，仍然會出現資源爭用的問題，所以咱們引入了資源隔離的概念，即側鏈結構。

aelf的側鏈包含兩種結構，一種是內部側鏈，基於aelf經過聯合挖礦的形式建立的側鏈，另一種是外部側鏈，像比特幣和以太坊這樣的異構鏈經過識別器加入aelf，進行交互。緊接着，戎朋介紹了側鏈的索引過程和跨鏈通信機制。戎朋介紹道：跨鏈通信須要完成兩個步驟的程序，首先要驗證交易的存在性，其次驗證交易的時序性，在完成這樣的程序之後，就能夠進行跨鏈轉帳等一些具體的應用程序。而跨鏈索引有如下幾個步驟，由父鏈索引自子鏈的區塊頭部數據，側鏈同時索引主鏈的區塊頭部數據，從而進行數據的交互，最後進行跨鏈的驗證。

【集羣】

戎朋：上面咱們提到的並行執行和側鏈，都是基於集羣，aelf的每個節點都是基於集羣運行。

咱們經過使用Kubernetes實現對集羣的管理，集羣裏面最大的管理單元是鏈，有主鏈和側鏈；而Pod是Kubernetes中的最小的管理單位，一個鏈中有多組不通的Pod角色組成，有Akka Manager Pods、Worker Pods、DB Pods等。aelf基於集羣的並行執行是經過Akka框架實現的，交易經過多個Worker Pod組成並行執行的集羣，而每個Worker Pod由多個actor組成，actor是Akka中最小的計算單元，咱們的交易就是最終分配給這些actor完成執行的 。不只並行執行經過集羣管理，經過聯合挖礦的側鏈也屬於集羣的範疇，這裏展現的是一個主鏈+2個側鏈的結構，主鏈和側鏈之間經過Merge Mining（聯合挖礦）的形式實現相互索引。

最後，戎朋分享了關於aelf將來的深度思考。第一，即將發佈的. NET 3.0 ，具備Assembly unload的特徵，相比於2.0，在aelf系統裏，將會比較方便的解決合約unload問題，第二，gRPC和ASP.NET Core 的深度結合，在aelf的技術棧中，gRPC做爲底層通信，將會大大促進aelf接口的性能改進，增長便捷性。第三，aelf使用了大量的DDD (Domain-Driven Design)模型，促使aelf的模塊化程度很高，讓企業級用戶可以簡單便捷定製本身的區塊鏈，最後一點就是網絡延遲的問題，由於aelf是分佈式的區塊鏈系統，因此會有一個難以免的網絡延遲，大概是300ms--500ms,因此在作模塊化功能的時候，須要考慮延遲的存在，這樣對於系統的穩定性有必定程度的提高。