Categories
程式開發

一文說清“鏈上”和“鏈下”


什麼是“上鍊”?什麼數據和邏輯應該“上鍊”?文件能不能上鍊?鏈上能不能批量查數據? “鏈下”又是什麼?

“鏈上”、“鏈下”諸多問題,一文說清。

什麼是“鏈上”和“鏈下”

一文說清“鏈上”和“鏈下” 1

區塊“鏈”的鏈,包含“數據鏈”“節點鏈”。數據鏈指用鍊式結構組織區塊數據,構成數據校驗和追溯的鏈條;“節點鏈”指多個節點通過網絡連接在一起,互相共享信息,其中的共識節點則聯合執行共識算法,產生並確認區塊。

交易“上鍊”的簡要過程如下:

  • 記賬者們收錄交易,按鍊式數據結構打包成“區塊”。
  • 共識算法驅動大家驗證新區塊裡的交易,確保計算出一致的結果。
  • 數據被廣播到所有節點,穩妥存儲下來,每個節點都會存儲一個完整的數據副本。

交易一旦“上鍊”,則意味著得到完整執行,達成了“分佈式事務性”。簡單地說,就像一段話經過集體核准後在公告板上公示於眾,一字不錯不少,永久可見且無法塗改。

“上鍊”意味著“共識”和“存儲”,兩者缺一不可。交易不經過共識,則不能保證一致性和正確性,無法被鏈上所有參與者接受;共識後的數據不被多方存儲,意味著數據有可能丟失或被單方篡改,更談不上冗餘可用。

除此之外,如果僅僅是調用接口查詢一下,沒有改變任何鏈上數據,也不需要進行共識確認,則不算“上鍊”。

或者,某個業務服務本身和區塊鏈並不直接相關,或其業務流程無需參與共識,所生成的數據也不寫入節點存儲,那麼這個業務服務稱為“鏈下服務”,無論它是否和區塊鏈節點共同部署在一台服務器,甚至和節點進程編譯在一起。

當這個業務服務調用區塊鏈的接口發送交易,且交易完成“共識”和“存儲”後,才稱為“上鍊”;如果這個交易沒有按預期被打包處理,那麼可以叫“上鍊失敗”。

事實上,幾乎所有的區塊鏈系統,尤其是和實體經濟、現實世界結合的區塊鏈應用,都需要鏈上鍊下協同,用“混合架構“來實現,系統本身就包含豐富的技術生態。

*注1:交易(transaction)是區塊鏈裡的通用術語,泛指發往區塊鏈,會改動鏈上數據和狀態的一段指令和數據。

*注2:本節描述的是簡要的模型,在多層鏈、分片模型裡,流程會更加複雜,事務劃分更細,但“共識”和“存儲”才叫上鍊的基本原則不變。

交易之輕和“上鍊”之重

目前區塊鏈底層平台逐步趨於成熟,性能和成本已經不是什麼大問題,只是以下幾個開銷是因“分佈式多方協作”而先天存在的:

  • 共識開銷:主流共識算法裡,PoW(工作量證明,也就是挖礦)消耗電力;PoS(權益證明)要抵押資產獲得記賬權;PBFT(聯盟鏈常用的拜占庭容錯算法)記賬者要完成多次往返投票,流程步驟繁雜。
  • 計算開銷:除了加解密、協議解析等計算之外,在支持智能合約的區塊鏈上,為了驗證合約的執行結果,所有節點都會無差別地執行合約代碼,牽一發而動全身。
  • 網絡開銷:與節點數呈指數級比例,節點越多,網絡傳播次數越多,帶寬和流量開銷越大,如果數據包過大,就更雪上加霜。
  • 存儲開銷:和節點數成正比,所有的鏈上數據,都會寫入所有節點的硬盤,在一個有100個節點的鏈上,就變成了100份副本,如果有1000個節點,那就是1000份。

也許有人會說:“這就是‘信任’的成本,值得的!”我同意。只是理想無法脫離現實,畢竟硬件資源總是有限的。

想像一下,如果每個交易都是一個複雜科學計算任務,那麼每個節點CPU和內存會跑滿;如果每個交易都包含一個大大的圖片或視頻,那麼全網的帶寬,以及各節點存儲很快被塞爆;如果大家都敞開來濫用“鏈上”資源,“公地悲劇”就不可避免。

調用API發個交易是很容易的,而鏈上的開銷就像房間裡的大象,難以視而不見。作為開發者,需要正視“交易之輕和鏈上之重”,積極“上鍊”的同時減少不必要的開銷,找到平衡之道。

*注1:常規聯盟鏈節點參考配置:8核/16G內存/10m外網帶寬/4T硬盤,不考慮“礦機”和其他特種配置。土豪隨意,俗話說“錢能解決的問題都不是問題,問題是…”
*注2:本節暫未討論“局部/分片共識”,也不探討“平行擴容”的情況,默認假定全網參與共識和存儲。

讓“鏈上”歸鏈上,“鏈下”歸鏈下

開銷只是成本問題,而本質上,應該讓區塊鏈幹自己最該干的事情。鏈上聚焦多方協作,盡快達成共識,營造或傳遞信任,將好鋼用到刀刃上;那些非全局性的、無需多方共識的、數據量大的、計算繁雜的…通通放到鏈下實現,一個好漢三個幫。

如何進行切割?在業務層面,識別多方協作事務和數據共享中“最大公約數”,抓住要點痛點,四兩撥千斤;在技術上,合理設計多層架構,揚長避短、因地制宜地運用多種技術,避免拿著錘子看什麼都是釘子、一招打天下的思維。

為避免過於抽象,下面給出幾個例子。

*注:每個例子其實都有大量的細節,考慮篇幅,這裡做概要介紹,聚焦鏈上鍊下的區別和有機結合

文件能不能上鍊?

一文說清“鏈上”和“鏈下” 2

這是個非常高頻的問題,經常被問到。這裡的文件一般指圖像、視頻、PDF等,也可以泛指大體量的數據集,上鍊可信分享的目的,是使接受者可以驗證文件的完整性、正確性。

常見的場景裡,文件共享一般是局部的、點對點的,而不是廣播給所有人,讓區塊鏈無差別地保存海量數據,會不堪重負。所以,合理的做法是計算文件的數字指紋(MD5或HASH),並與其他一些可選信息一起上鍊,如作者、持有人簽名、訪問地址等,單個上鍊信息並不多。

文件本身則保存在私有的文件服務器、雲文件存儲、或者IPFS系統裡,這些專業方案更適合維護海量文件和大尺寸文件,容量更高、成本更低。注意,如果文件的安全級別到了“一個字節都不能洩露給無關人等”的程度,那麼應慎用IPFS這種分佈式存儲的方案,優選私有存儲方式。

需要分享文件給指定的朋友時,可以走專用傳輸通道點對點的發送文件,或者授權朋友到指定的URL下載,可以和區塊鏈的P2P網絡隔離,不佔用區塊鏈帶寬。朋友獲得文件後,計算文件的MD5、HASH,和鏈上對應的信息進行比對,驗證數字簽名,確保收到了正確且完整的文件。

這種方案,文件在鏈上“確權”、“錨定”和“尋址”,明文在鏈下傳輸並與鏈上互驗,無論是成本、效率、還是隱私安全都取得了平衡。

怎麼批量查詢和分析數據?

一文說清“鏈上”和“鏈下” 3

對區塊鏈上的數據進行分析是自然的需求,比如“某個賬戶參與哪些業務流程、完成了多少筆交易、成功率如何”,“某個記賬節點在一段時間內參與了多少次區塊記賬、是否及時、有否作弊”,這些邏輯會牽涉到時間範圍、區塊高度、交易收發雙方、合約地址、事件日誌、狀態數據等維度。

目前區塊鏈底層平台一般是採用“Key-Value”的存儲結構,其優勢是讀寫效率極高,但難以支持複雜查詢。

其次,複雜查詢邏輯一般是在區塊生成後進行,時效性略低,且並不需要進行多方共識,有一定的“離線”性。

最後,數據一旦“上鍊”,就不會改變,且只增不減,數據本身有明顯特徵(如區塊高度、互相關聯的HASH值、數字簽名等)可以檢驗數據的完整性和正確性,在鏈上還是鏈下處理並無區別,任何擁有完整數據的節點都能支持獨立的複雜查詢。

於是,我們可以將數據完整地從鏈上導出,包括從創世塊開始到最新的所有區塊、所有交易流水和回執、所有交易產生的事件、狀態數據等,通通寫入鏈外的關係型數據庫(如MySQL)或大數據平台,構建鏈上數據的“鏡像”,然後可以採用這些引擎強大的索引模型、關聯分析、建模訓練、並行任務能力,靈活全面地對數據進行查詢分析。

區塊鏈瀏覽器、運營管理平台、監控平台、監管審計等系統,都會採用這種策略,鏈上出塊,鏈下及時ETL入庫,進行本地化地分析處理後,如需要和鏈上進行交互,再通過接口發送交易上鍊即可。

複雜邏輯和計算

一文說清“鏈上”和“鏈下” 4

和復雜查詢略有不同,複雜邏輯指交易流程中關係複雜、流程繁雜的部分。

如上所述,鏈上的智能合約會在所有節點上運行,如果智能合約寫得過於復雜,或者包含其實不需要全網共識的多餘邏輯,全網就會承擔不必要的開銷。極端的例子是,合約裡寫了個超級大的數據遍歷邏輯(甚至是死循環),那麼全網所有節點都會陷入這個遍歷中,吭哧吭哧跑半天,甚至被拖死。

除了用類似GAS機制來控制邏輯的長度外,在允許的GAS範圍內,我們推薦智能合約的設計盡量精簡,單個合約接口裡包含的代碼在百行以上就算是比較複雜的了,可以考慮是否將一部分拆解出去。

拆解的邊界因不同業務而異,頗為考驗對業務的熟悉程度。開發者要對業務進行庖丁解牛式地分層分模塊解耦,僅將業務流程中牽涉多方協作、需要共識、共享和公示的部分放到鏈上,使得合約只包含“必須”“鐵定”要在鏈上運行的邏輯,合約邏輯“小而美”。

一般來說,多方見證的線上協同、公共賬本管理、一定要分享給全體的關鍵數據(或數據的HASH)都是可以放到鏈上的,但相關的一些前置或後續的檢驗、核算、對賬等邏輯可以適當拆解到鏈下。

一些和密集計算有關的邏輯,宜盡量將其在鏈下實現,如復雜的加解密算法,可以設計成鏈下生成證明鏈上快速驗證的邏輯;如果業務流程中牽涉對各種數據的遍歷、排序和統計,則在鏈下建立索引,鏈上僅進行Key-Value的精準讀寫。

其實,現在但凡看到合約裡有用到mapping或array,我都會強迫症地想想能不能把這部分放鏈下服務去,個人比較欣賞“胖鏈下”和“瘦鏈上”的設計取向。

強調一下,精簡鏈上合約邏輯,並不全是因為合約引擎的效率問題,合約引擎已經越來越快了。核心原因還是在發揮區塊鏈最大功效的同時,避免“公地悲劇”。開發者拿出計算和存儲成本最小的合約,有著“如無必要勿增實體”的奧卡姆剃刀式美感,更是對鏈上所有參與者表達尊重和負責任的態度。

即時消息:快速協商和響應

一文說清“鏈上”和“鏈下” 5

受隊列調度、共識算法、網絡廣播等因素約束,“上鍊”的過程多少都會有一點延時。採用工作量證明共識的鏈,時延在十幾秒到10分鐘,採用DPOS、PBFT的共識,時延可縮短到秒級,此外,如果遇到網絡波動、交易擁擠等特殊情況,時延表現會有抖動。

總的來說,對照毫秒或百毫秒級響應的瞬時交互,“上鍊”會顯得些許“遲鈍”。比如去超市買瓶水,支付後肯定不能站在那裡等十幾秒到十分鐘,鏈出塊確認後才走吧(略尷尬)。

對類似場景,宜結合鏈上預存和鏈外支付,在鏈下的點對點通道實現高頻、快速、低延時的交易,鏈下確保收妥和響應,最後將雙方的賬戶餘額、交易憑據匯總到鏈上,在鏈上完成妥善記賬。著名的“閃電網絡”就類似這種模式。

另外,有些商業場景會先進行多輪的訂單撮合、競價拍賣或討價還價。一般來說,這些操作是發生在局部的交易對手方之間,未必需要全網共識,所以也可以通過鏈下通道完成,最後將雙方的訂單(包含雙方磋商結果、數字簽名等信息)發送到鏈上,完成交易事務即可。

舉個下快棋的例子,棋手的每一步棋並不需要實時上鍊,雙方只管啪啪地下,裁判和觀眾只管圍觀,在棋局結束時,比如總共下了一百手,那麼將這一百手的記錄匯總起來,連同輸贏結果上鍊,以便記錄戰績分配獎金。如果要復盤棋局詳情(如視頻),可以參考上文提及的鏈下文件存儲模式,用專用的服務器或分佈式存儲實現。

針對類似需求,在FISCO BCOS底層平台中,提供了AMOP(鏈上信使協議),利用已經搭建起來的區塊鍊網絡,在全網範圍實現點對點、實時、安全的通信。基於AMOP,可以支持即時消息、快速協商、事件通知、交換秘密、構建私有交易等,推薦。

*注:【AMOP】詳情可參考:
https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/manual/amop_protocol.html

鏈下信息如何可信上鍊?

一文說清“鏈上”和“鏈下” 6

先看一個典型問題:“智能合約運行中要使用鏈外信息,怎麼辦?”

比如,鏈上有個世界杯決賽競猜遊戲,但世界杯不可能在鏈上踢吧;或者需要參考今天的天氣,天氣顯然不是鏈上原生信息,應該從氣象局獲取;在跨境業務中,可能用到法定匯率,而匯率一定是來自權威機構的,不能在鏈上憑空生成。

這時候就要用到“預言機(Oracle)”,由一個或多個鏈下可信機構將球賽、天氣、匯率等信息寫到鏈上的公共合約,其他合約統一使用這份經過共識確認的可信信息,不會出現歧義。考慮到安全和效率,預言機(Oracle)會有多種具體做法,實現起來相當有趣。

一文說清“鏈上”和“鏈下” 7

更進一步的靈魂拷問是:“如何保證上鍊的數據是真實的?”坦率地說,區塊鏈並不能從根本上保證鏈下數據的可信性,只能保證信息一旦上鍊,就是全網一致且難以篡改的。而區塊鏈跟實體經濟結合時,勢必要面對“如何可信上鍊”這個問題。

如資產相關應用,除了進行人員管理之外,還要“四流合一”,即“信息流、商流、物流、資金流”互相匹配和交叉印證,會使業務流程更加可信。這些“流”常常發生在鏈下現實世界,要把控它們,可能會用到物聯網(傳感器、攝像頭等)、人工智能(模式識別、聯邦學習等)、大數據分析、可信機構背書等多種技術和方式,這已經遠遠超出了區塊鏈的範圍。

所以,本節的命題其實是:區塊鏈如何和數字世界裡的技術廣泛結合,更好地發揮自身多方協作、營造信任的作用。

隨著數字世界的發展、尤其“新基建”的強力推動,我們相信廣泛的數字化能在保護隱私的前提下,降低信息採集和校驗的成本,採集的數據會越來越豐富。

如在使用、轉移、回收實體物資時,及時採集監測,甚至是多方、多路、多維度立體化的採集監控,並上鍊進行共識、公示、錨定,鏈上鍊下交叉驗證,這樣就可以逐漸逼近“物理世界可信上鍊”的效果,邏輯會更嚴密,更具有公信力,數據和價值流通會更可靠,協作的摩擦更低。

“鏈上”還是“鏈下”治理?

一文說清“鏈上”和“鏈下” 8

“治理”即制定行業聯盟和業務運作規則,確保規則的執行,處理異常事件,獎勵和懲戒參與者等。

以理想化的標準,似乎應該實現鏈上治理,通過代碼決策、制定和執行規則,出錯時系統具有“自修復”的“超能力”。實際上,完備的鏈上治理過於復雜,實現起來很有挑戰性,尤其在需要達成現實世界法律法規的執行力時,純鏈上的治理往往力不從心。

再多想一步:如完全依賴代碼,萬一代碼本身有BUG、或者要“改需求”呢?鏈下的決策者、開發者如何發現和介入?

所以,“Code is Law”還是個理想化的目標,鏈下治理不可或缺。

聯盟鏈參與者們組成管理委員會,在現實世界裡進行民主集中製的討論和決策,共同製定規則,採用多簽、工作流的方式一起發起治理動作,調用區塊鏈接口上鍊。

在鏈上,包括區塊鏈底層平台和智能合約在內,都會內置一系列的決策和控制點,如支持多方投票決策,具備從業務層穿透到底層的准入和權限控制能力,可修改業務和節點的參數,能應對異常情況的重置賬戶,對錯賬進行沖正調賬等等。

治理動作和結果經過共識確認,在鏈上全網生效,公開透明,接受廣泛監督,彰顯其合理性和公正性。必要時還可以引入監管方和司法仲裁。

反過來,聯盟鏈上的數據,具備身份可知、難以篡改、無法否認且可全程追溯等特點,可為鏈下治理決策提供完備的數據基礎,也便於為鏈下實際執行提供可信的憑據。所以,鏈上和鏈下有機結合,有助於設計完備、可控、可持續的治理機制。

如何做到“上” “下”自如

或許有人會說:“這鏈上鍊下什麼的太複雜了,我就想用區塊鏈!”

我認為這個說法很對。說到底,用戶就想要一條趁手的“鏈”。作為開發者,我們要打造靈活的、插件化的系統架構,實現各種能力,什麼數據導出、文件存儲和傳輸、密集計算、數據採集和異步上鍊、治理監管、一鍵部署…按需取捨後,打包起來開箱即用,實際上提供了“基於區塊鏈的一系列能力”。

最終呈現的“鏈”,除了節點之外,還有區塊鏈瀏覽器、管理台、監控和審計系統、業務模板、APP/小程序等一系列交互入口,用戶只需動動鼠標,點點頁面,調調接口,一站式體驗到一個完整的區塊鏈應用。用戶會覺得:“這就是區塊鏈”,無需再分“鏈上”和“鏈下”,渾然一體。

說到這裡,推荐一個我認為非常棒的設計:分佈式身份標識(DID)。

DID是一套涵蓋了分佈式身份管理、可信數據交換的規範。權威機構為用戶完成KYC,頒發憑據。用戶將身份標識的摘要公佈到鏈上,而將自己隱私數據存在鏈下(這一點非常重要)。

使用時,用戶採用“明確授權”和“選擇性披露”的策略,僅需出示少量的信息或加密證明,與鏈上數據進行對照校驗,即可證明用戶憑據和數據可信性,達成了“數據多跑路,用戶少跑腿”、保護了用戶隱私的可喜效果。

這種設計很好地將鏈上鍊下結合起來,邏輯閉環自洽,並不因為數據存在鏈下,就削弱了鏈上的功效,反而使得鏈的授信模型更為重要。

DID規範定義了語義清晰、層次分明的數據結構,以及通用的交互協議。開源項目WeIdentity完整地實現了DID協議,並提供豐富的周邊支撐工具和服務,值得參考。

*注:【WeIdentity】詳情可見:
https://fintech.webank.com/weidentity

結 語

鏈漫漫其修遠兮,吾將“上下”而求索。在未來,“可信的”區塊鏈將越來越多地和人們日常生活、實體經濟聯動,步入尋常百姓家。作為從業者,保持開放的心態,積極而創新地將區塊鏈與更多技術結合,無論運作於鏈上還是鏈下,只要能解決問題、創造價值,就是一條好鏈。

關於作者

張開翔,FISCO BCOS 首席架構師。