什麼是“上鍊”？什麼資料和邏輯應該“上鍊”？檔案能不能上鍊？鏈上能不能批次查資料？“鏈下”又是什麼？
“鏈上”、“鏈下”諸多問題，一文說清。
什麼是“鏈上”和“鏈下”
區塊“鏈”的鏈，包含“資料鏈”和“節點鏈”。資料鏈指用鏈式結構組織區塊資料，構成資料校驗和追溯的鏈條；“節點鏈”指多個節點透過網路連線在一起，互相共享資訊，其中的共識節點則聯合執行共識演算法，產生並確認區塊。
交易“上鍊”的簡要過程如下：
記賬者們收錄交易，按鏈式資料結構打包成“區塊”。
共識演算法驅動大家驗證新區塊裡的交易，確保計算出一致的結果。
資料被廣播到所有節點，穩妥儲存下來，每個節點都會儲存一個完整的資料副本。
交易一旦“上鍊”，則意味著得到完整執行，達成了“分散式事務性”。簡單地說，就像一段話經過集體核准後在公告板上公示於眾，一字不錯不少，永久可見且無法塗改。
“上鍊”意味著“共識”和“儲存”，兩者缺一不可。交易不經過共識，則不能保證一致性和正確性，無法被鏈上所有參與者接受；共識後的資料不被多方儲存，意味著資料有可能丟失或被單方篡改，更談不上冗餘可用。
除此之外，如果僅僅是呼叫介面查詢一下，沒有改變任何鏈上資料，也不需要進行共識確認，則不算“上鍊”。
或者，某個業務服務本身和區塊鏈並不直接相關，或其業務流程無需參與共識，所生成的資料也不寫入節點儲存，那麼這個業務服務稱為“鏈下服務”，無論它是否和區塊鏈節點共同部署在一臺伺服器，甚至和節點程序編譯在一起。
當這個業務服務呼叫區塊鏈的介面傳送交易，且交易完成“共識”和“儲存”後，才稱為“上鍊”；如果這個交易沒有按預期被打包處理，那麼可以叫“上鍊失敗”。
事實上，幾乎所有的區塊鏈系統，尤其是和實體經濟、現實世界結合的區塊鏈應用，都需要鏈上鍊下協同，用“混合架構“來實現，系統本身就包含豐富的技術生態。
*注1：交易（transaction）是區塊鏈裡的通用術語，泛指發往區塊鏈，會改動鏈上資料和狀態的一段指令和資料
*注2：本節描述的是簡要的模型，在多層鏈、分片模型裡，流程會更加複雜，事務劃分更細，但“共識”和“儲存”才叫上鍊的基本原則不變
交易之輕和“上鍊”之重
目前區塊鏈底層平臺逐步趨於成熟，效能和成本已經不是什麼大問題，只是以下幾個開銷是因“分散式多方協作”而先天存在的：
共識開銷：主流共識演算法裡，PoW（工作量證明，也就是挖礦）消耗電力；PoS（權益證明）要抵押資產獲得記賬權；PBFT（聯盟鏈常用的拜占庭容錯演算法）記賬者要完成多次往返投票，流程步驟繁雜。
計算開銷：除了加解密、協議解析等計算之外，在支援智慧合約的區塊鏈上，為了驗證合約的執行結果，所有節點都會無差別地執行合約程式碼，牽一髮而動全身。
網路開銷：與節點數呈指數級比例，節點越多，網路傳播次數越多，頻寬和流量開銷越大，如果資料包過大，就更雪上加霜。
儲存開銷：和節點數成正比，所有的鏈上資料，都會寫入所有節點的硬碟，在一個有100個節點的鏈上，就變成了100份副本，如果有1000個節點，那就是1000份。
也許有人會說：“這就是‘信任’的成本，值得的！”我同意。只是理想無法脫離現實，畢竟硬體資源總是有限的。
想象一下，如果每個交易都是一個複雜科學計算任務，那麼每個節點CPU和記憶體會跑滿；如果每個交易都包含一個大大的圖片或影片，那麼全網的頻寬，以及各節點儲存很快被塞爆；如果大家都敞開來濫用“鏈上”資源，“公地悲劇”就不可避免。
呼叫API發個交易是很容易的，而鏈上的開銷就像房間裡的大象，難以視而不見。作為開發者，需要正視“交易之輕和鏈上之重”，積極“上鍊”的同時減少不必要的開銷，找到平衡之道。
*注1：常規聯盟鏈節點參考配置：8核/16G記憶體/10m外網頻寬/4T硬碟，不考慮“礦機”和其他特種配置。土豪隨意，俗話說“錢能解決的問題都不是問題，問題是...”
*注2：本節暫未討論“區域性/分片共識”，也不探討“平行擴容”的情況，預設假定全網參與共識和儲存
讓“鏈上”歸鏈上，“鏈下”歸鏈下
開銷只是成本問題，而本質上，應該讓區塊鏈幹自己最該乾的事情。鏈上聚焦多方協作，儘快達成共識，營造或傳遞信任，將好鋼用到刀刃上；那些非全域性性的、無需多方共識的、資料量大的、計算繁雜的...通通放到鏈下實現，一個好漢三個幫。
如何進行切割？在業務層面，識別多方協作事務和資料共享中“最大公約數”，抓住要點痛點，四兩撥千斤；在技術上，合理設計多層架構，揚長避短、因地制宜地運用多種技術，避免拿著錘子看什麼都是釘子、一招打天下的思維。
為避免過於抽象，下面給出幾個例子。
*注：每個例子其實都有大量的細節，考慮篇幅，這裡做概要介紹，聚焦鏈上鍊下的區別和有機結合
檔案能不能上鍊？
這是個非常高頻的問題，經常被問到。這裡的檔案一般指影象、影片、PDF等，也可以泛指大體量的資料集，上鍊可信分享的目的，是使接受者可以驗證檔案的完整性、正確性。
常見的場景裡，檔案共享一般是區域性的、點對點的，而不是廣播給所有人，讓區塊鏈無差別地儲存海量資料，會不堪重負。所以，合理的做法是計算檔案的數字指紋（MD5或HASH），並與其他一些可選資訊一起上鍊，如作者、持有人簽名、訪問地址等，單個上鍊資訊並不多。
檔案本身則儲存在私有的檔案伺服器、雲檔案儲存、或者IPFS系統裡，這些專業方案更適合維護海量檔案和大尺寸檔案，容量更高、成本更低。注意，如果檔案的安全級別到了“一個位元組都不能洩露給無關人等”的程度，那麼應慎用IPFS這種分散式儲存的方案，優選私有儲存方式。
需要分享檔案給指定的朋友時，可以走專用傳輸通道點對點的傳送檔案，或者授權朋友到指定的URL下載，可以和區塊鏈的P2P網路隔離，不佔用區塊鏈頻寬。朋友獲得檔案後，計算檔案的MD5、HASH，和鏈上對應的資訊進行比對，驗證數字簽名，確保收到了正確且完整的檔案。
這種方案，檔案在鏈上“確權”、“錨定”和“定址”，明文在鏈下傳輸並與鏈上互驗，無論是成本、效率、還是隱私安全都取得了平衡。
怎麼批次查詢和分析資料？
對區塊鏈上的資料進行分析是自然的需求，比如“某個賬戶參與哪些業務流程、完成了多少筆交易、成功率如何”，“某個記賬節點在一段時間內參與了多少次區塊記賬、是否及時、有否作弊”，這些邏輯會牽涉到時間範圍、區塊高度、交易收發雙方、合約地址、事件日誌、狀態資料等維度。
目前區塊鏈底層平臺一般是採用“Key-Value”的儲存結構，其優勢是讀寫效率極高，但難以支援複雜查詢。
其次，複雜查詢邏輯一般是在區塊生成後進行，時效性略低，且並不需要進行多方共識，有一定的“離線”性。
最後，資料一旦“上鍊”，就不會改變，且只增不減，資料本身有明顯特徵（如區塊高度、互相關聯的HASH值、數字簽名等）可以檢驗資料的完整性和正確性，在鏈上還是鏈下處理並無區別，任何擁有完整資料的節點都能支援獨立的複雜查詢。
於是，我們可以將資料完整地從鏈上匯出，包括從創世塊開始到最新的所有區塊、所有交易流水和回執、所有交易產生的事件、狀態資料等，通通寫入鏈外的關係型資料庫（如MySQL）或大資料平臺，構建鏈上資料的“映象”，然後可以採用這些引擎強大的索引模型、關聯分析、建模訓練、並行任務能力，靈活全面地對資料進行查詢分析。
區塊鏈瀏覽器、運營管理平臺、監控平臺、監管審計等系統，都會採用這種策略，鏈上出塊，鏈下及時ETL入庫，進行本地化地分析處理後，如需要和鏈上進行互動，再透過介面傳送交易上鍊即可。
複雜邏輯和計算
和複雜查詢略有不同，複雜邏輯指交易流程中關係複雜、流程繁雜的部分。
如上所述，鏈上的智慧合約會在所有節點上執行，如果智慧合約寫得過於複雜，或者包含其實不需要全網共識的多餘邏輯，全網就會承擔不必要的開銷。極端的例子是，合約裡寫了個超級大的資料遍歷邏輯（甚至是死迴圈），那麼全網所有節點都會陷入這個遍歷中，吭哧吭哧跑半天，甚至被拖死。
除了用類似GAS機制來控制邏輯的長度外，在允許的GAS範圍內，我們推薦智慧合約的設計儘量精簡，單個合約介面裡包含的程式碼在百行以上就算是比較複雜的了，可以考慮是否將一部分拆解出去。
拆解的邊界因不同業務而異，頗為考驗對業務的熟悉程度。開發者要對業務進行庖丁解牛式地分層分模組解耦，僅將業務流程中牽涉多方協作、需要共識、共享和公示的部分放到鏈上，使得合約只包含“必須”“鐵定”要在鏈上執行的邏輯，合約邏輯“小而美”。
一般來說，多方見證的線上協同、公共賬本管理、一定要分享給全體的關鍵資料（或資料的HASH）都是可以放到鏈上的，但相關的一些前置或後續的檢驗、核算、對賬等邏輯可以適當拆解到鏈下。
一些和密集計算有關的邏輯，宜儘量將其在鏈下實現，如複雜的加解密演算法，可以設計成鏈下生成證明鏈上快速驗證的邏輯；如果業務流程中牽涉對各種資料的遍歷、排序和統計，則在鏈下建立索引，鏈上僅進行Key-Value的精準讀寫。
其實，現在但凡看到合約裡有用到mapping或array，我都會強迫症地想想能不能把這部分放鏈下服務去，個人比較欣賞“胖鏈下”和“瘦鏈上”的設計取向。
強調一下，精簡鏈上合約邏輯，並不全是因為合約引擎的效率問題，合約引擎已經越來越快了。核心原因還是在發揮區塊鏈最大功效的同時，避免“公地悲劇”。開發者拿出計算和儲存成本最小的合約，有著“如無必要勿增實體”的奧卡姆剃刀式美感，更是對鏈上所有參與者表達尊重和負責任的態度。
即時訊息：快速協商和響應
受佇列排程、共識演算法、網路廣播等因素約束，“上鍊”的過程多少都會有一點延時。採用工作量證明共識的鏈，時延在十幾秒到10分鐘，採用DPOS、PBFT的共識，時延可縮短到秒級，此外，如果遇到網路波動、交易擁擠等特殊情況，時延表現會有抖動。
總的來說，對照毫秒或百毫秒級響應的瞬時互動，“上鍊”會顯得些許“遲鈍”。比如去超市買瓶水，支付後肯定不能站在那裡等十幾秒到十分鐘，鏈出塊確認後才走吧（略尷尬）。
對類似場景，宜結合鏈上預存和鏈外支付，在鏈下的點對點通道實現高頻、快速、低延時的交易，鏈下確保收妥和響應，最後將雙方的賬戶餘額、交易憑據彙總到鏈上，在鏈上完成妥善記賬。著名的“閃電網路”就類似這種模式。
另外，有些商業場景會先進行多輪的訂單撮合、競價拍賣或討價還價。一般來說，這些操作是發生在區域性的交易對手方之間，未必需要全網共識，所以也可以透過鏈下通道完成，最後將雙方的訂單（包含雙方磋商結果、數字簽名等資訊）傳送到鏈上，完成交易事務即可。
舉個下快棋的例子，棋手的每一步棋並不需要實時上鍊，雙方只管啪啪地下，裁判和觀眾只管圍觀，在棋局結束時，比如總共下了一百手，那麼將這一百手的記錄彙總起來，連同輸贏結果上鍊，以便記錄戰績分配獎金。如果要覆盤棋局詳情（如影片），可以參考上文提及的鏈下檔案儲存模式，用專用的伺服器或分散式儲存實現。
針對類似需求，在FISCO BCOS底層平臺中，提供了AMOP（鏈上信使協議），利用已經搭建起來的區塊鏈網路，在全網範圍實現點對點、實時、安全的通訊。基於AMOP，可以支援即時訊息、快速協商、事件通知、交換秘密、構建私有交易等，推薦。
*注：【AMOP】詳情可參考：
https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/manual/amop_protocol.html
鏈下資訊如何可信上鍊？
先看一個典型問題：“智慧合約執行中要使用鏈外資訊，怎麼辦？”
比如，鏈上有個世界盃決賽競猜遊戲，但世界盃不可能在鏈上踢吧；或者需要參考今天的天氣，天氣顯然不是鏈上原生資訊，應該從氣象局獲取；在跨境業務中，可能用到法定匯率，而匯率一定是來自權威機構的，不能在鏈上憑空生成。
這時候就要用到“預言機(Oracle)”，由一個或多個鏈下可信機構將球賽、天氣、匯率等資訊寫到鏈上的公共合約，其他合約統一使用這份經過共識確認的可信資訊，不會出現歧義。考慮到安全和效率，預言機（Oracle）會有多種具體做法，實現起來相當有趣。
更進一步的靈魂拷問是：“如何保證上鍊的資料是真實的？”坦率地說，區塊鏈並不能從根本上保證鏈下資料的可信性，只能保證資訊一旦上鍊，就是全網一致且難以篡改的。而區塊鏈跟實體經濟結合時，勢必要面對“如何可信上鍊”這個問題。
如資產相關應用，除了進行人員管理之外，還要“四流合一”，即“資訊流、商流、物流、資金流”互相匹配和交叉印證，會使業務流程更加可信。這些“流”常常發生在鏈下現實世界，要把控它們，可能會用到物聯網（感測器、攝像頭等）、人工智慧（模式識別、聯邦學習等）、大資料分析、可信機構背書等多種技術和方式，這已經遠遠超出了區塊鏈的範圍。
所以，本節的命題其實是：區塊鏈如何和數字世界裡的技術廣泛結合，更好地發揮自身多方協作、營造信任的作用。
隨著數字世界的發展、尤其“新基建”的強力推動，我們相信廣泛的數字化能在保護隱私的前提下，降低資訊採集和校驗的成本，採集的資料會越來越豐富。
如在使用、轉移、回收實體物資時，及時採集監測，甚至是多方、多路、多維度立體化的採集監控，並上鏈進行共識、公示、錨定，鏈上鍊下交叉驗證，這樣就可以逐漸逼近“物理世界可信上鍊”的效果，邏輯會更嚴密，更具有公信力，資料和價值流通會更可靠，協作的摩擦更低。
"鏈上"還是“鏈下"治理？
“治理”即制定行業聯盟和業務運作規則，確保規則的執行，處理異常事件，獎勵和懲戒參與者等。
以理想化的標準，似乎應該實現鏈上治理，透過程式碼決策、制定和執行規則，出錯時系統具有“自修復”的“超能力"。實際上，完備的鏈上治理過於複雜，實現起來很有挑戰性，尤其在需要達成現實世界法律法規的執行力時，純鏈上的治理往往力不從心。
再多想一步：如完全依賴程式碼，萬一程式碼本身有BUG、或者要“改需求”呢？鏈下的決策者、開發者如何發現和介入？
所以，“Code is Law”還是個理想化的目標，鏈下治理不可或缺。
聯盟鏈參與者們組成管理委員會，在現實世界裡進行民主集中制的討論和決策，共同制定規則，採用多籤、工作流的方式一起發起治理動作，呼叫區塊連結口上鍊。
在鏈上，包括區塊鏈底層平臺和智慧合約在內，都會內建一系列的決策和控制點，如支援多方投票決策，具備從業務層穿透到底層的准入和許可權控制能力，可修改業務和節點的引數，能應對異常情況的重置賬戶，對錯賬進行衝正調賬等等。
治理動作和結果經過共識確認，在鏈上全網生效，公開透明，接受廣泛監督，彰顯其合理性和公正性。必要時還可以引入監管方和司法仲裁。
反過來，聯盟鏈上的資料，具備身份可知、難以篡改、無法否認且可全程追溯等特點，可為鏈下治理決策提供完備的資料基礎，也便於為鏈下實際執行提供可信的憑據。所以，鏈上和鏈下有機結合，有助於設計完備、可控、可持續的治理機制。
如何做到“上” “下”自如
或許有人會說：“這鏈上鍊下什麼的太複雜了，我就想用區塊鏈！”
我認為這個說法很對。說到底，使用者就想要一條趁手的“鏈”。作為開發者，我們要打造靈活的、外掛化的系統架構，實現各種能力，什麼資料匯出、檔案儲存和傳輸、密集計算、資料採集和非同步上鍊、治理監管、一鍵部署......按需取捨後，打包起來開箱即用，實際上提供了“基於區塊鏈的一系列能力”。
最終呈現的“鏈”，除了節點之外，還有區塊鏈瀏覽器、管理臺、監控和審計系統、業務模板、APP/小程式等一系列互動入口，使用者只需動動滑鼠，點點頁面，調調介面，一站式體驗到一個完整的區塊鏈應用。使用者會覺得：“這就是區塊鏈”，無需再分“鏈上”和“鏈下”，渾然一體。
說到這裡，推薦一個我認為非常棒的設計：分散式身份標識（DID）。
DID是一套涵蓋了分散式身份管理、可信資料交換的規範。權威機構為使用者完成KYC，頒發憑據。使用者將身份標識的摘要公佈到鏈上，而將自己隱私資料存在鏈下（這一點非常重要）。
使用時，使用者採用“明確授權”和“選擇性披露”的策略，僅需出示少量的資訊或加密證明，與鏈上資料進行對照校驗，即可證明使用者憑據和資料可信性，達成了“資料多跑路，使用者少跑腿”、保護了使用者隱私的可喜效果。
這種設計很好地將鏈上鍊下結合起來，邏輯閉環自洽，並不因為資料存在鏈下，就削弱了鏈上的功效，反而使得鏈的授信模型更為重要。
DID規範定義了語義清晰、層次分明的資料結構，以及通用的互動協議。開源專案WeIdentity完整地實現了DID協議，並提供豐富的周邊支撐工具和服務，值得參考。
*注：【WeIdentity】詳情可見：
https://fintech.webank.com/weidentity
結 語
鏈漫漫其修遠兮，吾將“上下”而求索。在未來，“可信的”區塊鏈將越來越多地和人們日常生活、實體經濟聯動，步入尋常百姓家。作為從業者，保持開放的心態，積極而創新地將區塊鏈與更多技術結合，無論運作於鏈上還是鏈下，只要能解決問題、創造價值，就是一條好鏈。
