什么是“上鏈”?什么數(shù)據(jù)和邏輯應該“上鏈”?文件能不能上鏈?鏈上能不能批量查數(shù)據(jù)?“鏈下”又是什么?

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

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

區(qū)塊“鏈”的鏈，包含“數(shù)據(jù)鏈”和“節(jié)點鏈”。數(shù)據(jù)鏈指用鏈式結構組織區(qū)塊數(shù)據(jù)，構成數(shù)據(jù)校驗和追溯的鏈條;“節(jié)點鏈”指多個節(jié)點通過網(wǎng)絡連接在一起，互相共享信息，其中的共識節(jié)點則聯(lián)合執(zhí)行共識算法，產(chǎn)生并確認區(qū)塊。

交易“上鏈”的簡要過程如下：

• 記賬者們收錄交易，按鏈式數(shù)據(jù)結構打包成“區(qū)塊”。
• 共識算法驅動大家驗證新區(qū)塊里的交易，確保計算出一致的結果。
• 數(shù)據(jù)被廣播到所有節(jié)點，穩(wěn)妥存儲下來，每個節(jié)點都會存儲一個完整的數(shù)據(jù)副本。

交易一旦“上鏈”，則意味著得到完整執(zhí)行，達成了“分布式事務性”。簡單地說，就像一段話經(jīng)過集體核準后在公告板上公示于眾，一字不錯不少，永久可見且無法涂改。

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

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

或者，某個業(yè)務服務本身和區(qū)塊鏈并不直接相關，或其業(yè)務流程無需參與共識，所生成的數(shù)據(jù)也不寫入節(jié)點存儲，那么這個業(yè)務服務稱為“鏈下服務”，無論它是否和區(qū)塊鏈節(jié)點共同部署在一臺服務器，甚至和節(jié)點進程編譯在一起。

當這個業(yè)務服務調用區(qū)塊鏈的接口發(fā)送交易，且交易完成“共識”和“存儲”后，才稱為“上鏈”;如果這個交易沒有按預期被打包處理，那么可以叫“上鏈失敗”。

事實上，幾乎所有的區(qū)塊鏈系統(tǒng)，尤其是和實體經(jīng)濟、現(xiàn)實世界結合的區(qū)塊鏈應用，都需要鏈上鏈下協(xié)同，用“混合架構“來實現(xiàn)，系統(tǒng)本身就包含豐富的技術生態(tài)。

• 注 1：交易transaction是區(qū)塊鏈里的通用術語，泛指發(fā)往區(qū)塊鏈，會改動鏈上數(shù)據(jù)和狀態(tài)的一段指令和數(shù)據(jù)
• 注 2：本節(jié)描述的是簡要的模型，在多層鏈、分片模型里，流程會更加復雜，事務劃分更細，但“共識”和“存儲”才叫上鏈的基本原則不變

交易之輕和“上鏈”之重

目前區(qū)塊鏈底層平臺逐步趨于成熟，性能和成本已經(jīng)不是什么大問題，只是以下幾個開銷是因“分布式多方協(xié)作”而先天存在的：

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

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

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

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

• 注 1：常規(guī)聯(lián)盟鏈節(jié)點參考配置：8 核/16G 內存/10M 外網(wǎng)帶寬/4T 硬盤，不考慮“礦機”和其他特種配置。土豪隨意，俗話說“錢能解決的問題都不是問題，問題是...”
• 注 2：本節(jié)暫未討論“局部/分片共識”，也不探討“平行擴容”的情況，默認假定全網(wǎng)參與共識和存儲

讓“鏈上”歸鏈上，“鏈下”歸鏈下

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

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

為避免過于抽象，下面給出幾個例子。

注：每個例子其實都有大量的細節(jié)，考慮篇幅，這里做概要介紹，聚焦鏈上鏈下的區(qū)別和有機結合

文件能不能上鏈?

這是個非常高頻的問題，經(jīng)常被問到。這里的文件一般指圖像、視頻、PDF 等，也可以泛指大體量的數(shù)據(jù)集，上鏈可信分享的目的，是使接受者可以驗證文件的完整性、正確性。

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

文件本身則保存在私有的文件服務器、云文件存儲、或者 IPFS 系統(tǒng)里，這些專業(yè)方案更適合維護海量文件和大尺寸文件，容量更高、成本更低。注意，如果文件的安全級別到了“一個字節(jié)都不能泄露給無關人等”的程度，那么應慎用 IPFS 這種分布式存儲的方案，優(yōu)選私有存儲方式。

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

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

怎么批量查詢和分析數(shù)據(jù)?

對區(qū)塊鏈上的數(shù)據(jù)進行分析是自然的需求，比如“某個賬戶參與哪些業(yè)務流程、完成了多少筆交易、成功率如何”，“某個記賬節(jié)點在一段時間內參與了多少次區(qū)塊記賬、是否及時、有否作弊”，這些邏輯會牽涉到時間范圍、區(qū)塊高度、交易收發(fā)雙方、合約地址、事件日志、狀態(tài)數(shù)據(jù)等維度。

目前區(qū)塊鏈底層平臺一般是采用“鍵值對”的存儲結構，其優(yōu)勢是讀寫效率極高，但難以支持復雜查詢。

其次，復雜查詢邏輯一般是在區(qū)塊生成后進行，時效性略低，且并不需要進行多方共識，有一定的“離線”性。

最后，數(shù)據(jù)一旦“上鏈”，就不會改變，且只增不減，數(shù)據(jù)本身有明顯特征(如區(qū)塊高度、互相關聯(lián)的HASH值、數(shù)字簽名等)可以檢驗數(shù)據(jù)的完整性和正確性，在鏈上還是鏈下處理并無區(qū)別，任何擁有完整數(shù)據(jù)的節(jié)點都能支持獨立的復雜查詢。

于是，我們可以將數(shù)據(jù)完整地從鏈上導出，包括從創(chuàng)世塊開始到最新的所有區(qū)塊、所有交易流水和回執(zhí)、所有交易產(chǎn)生的事件、狀態(tài)數(shù)據(jù)等，通通寫入鏈外的關系型數(shù)據(jù)庫(如 MySQL)或大數(shù)據(jù)平臺，構建鏈上數(shù)據(jù)的“鏡像”，然后可以采用這些引擎強大的索引模型、關聯(lián)分析、建模訓練、并行任務能力，靈活全面地對數(shù)據(jù)進行查詢分析。

區(qū)塊鏈瀏覽器、運營管理平臺、監(jiān)控平臺、監(jiān)管審計等系統(tǒng)，都會采用這種策略，鏈上出塊，鏈下及時 ETL 入庫，進行本地化地分析處理后，如需要和鏈上進行交互，再通過接口發(fā)送交易上鏈即可。

復雜邏輯和計算

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

如上所述，鏈上的智能合約會在所有節(jié)點上運行，如果智能合約寫得過于復雜，或者包含其實不需要全網(wǎng)共識的多余邏輯，全網(wǎng)就會承擔不必要的開銷。極端的例子是，合約里寫了個超級大的數(shù)據(jù)遍歷邏輯(甚至是死循環(huán))，那么全網(wǎng)所有節(jié)點都會陷入這個遍歷中，吭哧吭哧跑半天，甚至被拖死。

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

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

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

一些和密集計算有關的邏輯，宜盡量將其在鏈下實現(xiàn)，如復雜的加解密算法，可以設計成鏈下生成證明鏈上快速驗證的邏輯;如果業(yè)務流程中牽涉對各種數(shù)據(jù)的遍歷、排序和統(tǒng)計，則在鏈下建立索引，鏈上僅進行鍵值對的精準讀寫。

其實，現(xiàn)在但凡看到合約里有用到映射或數(shù)組，我都會強迫癥地想想能不能把這部分放鏈下服務去，個人比較欣賞“胖鏈下”和“瘦鏈上”的設計取向。

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

即時消息：快速協(xié)商和響應

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

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

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

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

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

針對類似需求，在 FISCO BCOS 底層平臺中，提供了 AMOP(鏈上信使協(xié)議)，利用已經(jīng)搭建起來的區(qū)塊鏈網(wǎng)絡，在全網(wǎng)范圍實現(xiàn)點對點、實時、安全的通信。基于AMOP，可以支持即時消息、快速協(xié)商、事件通知、交換秘密、構建私有交易等，推薦。

鏈下信息如何可信上鏈?

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

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

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

更進一步的靈魂拷問是：“如何保證上鏈的數(shù)據(jù)是真實的?”坦率地說，區(qū)塊鏈并不能從根本上保證鏈下數(shù)據(jù)的可信性，只能保證信息一旦上鏈，就是全網(wǎng)一致且難以篡改的。而區(qū)塊鏈跟實體經(jīng)濟結合時，勢必要面對“如何可信上鏈”這個問題。

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

所以，本節(jié)的命題其實是：區(qū)塊鏈如何和數(shù)字世界里的技術廣泛結合，更好地發(fā)揮自身多方協(xié)作、營造信任的作用。

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

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

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

“治理”即制定行業(yè)聯(lián)盟和業(yè)務運作規(guī)則，確保規(guī)則的執(zhí)行，處理異常事件，獎勵和懲戒參與者等。

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

再多想一步：如完全依賴代碼，萬一代碼本身有錯誤、或者要“改需求”呢?鏈下的決策者、開發(fā)者如何發(fā)現(xiàn)和介入?

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

聯(lián)盟鏈參與者們組成管理委員會，在現(xiàn)實世界里進行民主集中制的討論和決策，共同制定規(guī)則，采用多簽、工作流的方式一起發(fā)起治理動作，調用區(qū)塊鏈接口上鏈。

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

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

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

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

或許有人會說：“這鏈上鏈下什么的太復雜了，我就想用區(qū)塊鏈!”

我認為這個說法很對。說到底，用戶就想要一條趁手的“鏈”。作為開發(fā)者，我們要打造靈活的、插件化的系統(tǒng)架構，實現(xiàn)各種能力，什么數(shù)據(jù)導出、文件存儲和傳輸、密集計算、數(shù)據(jù)采集和異步上鏈、治理監(jiān)管、一鍵部署......按需取舍后，打包起來開箱即用，實際上提供了“基于區(qū)塊鏈的一系列能力”。

最終呈現(xiàn)的“鏈”，除了節(jié)點之外，還有區(qū)塊鏈瀏覽器、管理臺、監(jiān)控和審計系統(tǒng)、業(yè)務模板、APP/小程序等一系列交互入口，用戶只需動動鼠標，點點頁面，調調接口，一站式體驗到一個完整的區(qū)塊鏈應用。用戶會覺得：“這就是區(qū)塊鏈”，無需再分“鏈上”和“鏈下”，渾然一體。

說到這里，推薦一個我認為非常棒的設計：分布式身份標識(DID)。

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

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

這種設計很好地將鏈上鏈下結合起來，邏輯閉環(huán)自洽，并不因為數(shù)據(jù)存在鏈下，就削弱了鏈上的功效，反而使得鏈的授信模型更為重要。

DID規(guī)范定義了語義清晰、層次分明的數(shù)據(jù)結構，以及通用的交互協(xié)議。開源項目 WeIdentity 完整地實現(xiàn)了 DID 協(xié)議，并提供豐富的周邊支撐工具和服務，值得參考。

結語

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