什么是“上鏈”致扯？什么數(shù)據(jù)和邏輯應該“上鏈”肤寝？文件能不能上鏈？鏈上能不能批量查數(shù)據(jù)抖僵？“鏈下”又是什么鲤看？
交易“上鏈”的簡要過程如下：
1，記賬者們收錄交易耍群，按鏈式數(shù)據(jù)結(jié)構打包成“區(qū)塊”义桂。
2，共識算法驅(qū)動大家驗證新區(qū)塊里的交易蹈垢，確保計算出一致的結(jié)果慷吊。
3，數(shù)據(jù)被廣播到所有節(jié)點耘婚，穩(wěn)妥存儲下來罢浇，每個節(jié)點都會存儲一個完整的數(shù)據(jù)副本陆赋。
交易一旦“上鏈”沐祷，則意味著得到完整執(zhí)行，達成了“分布式事務性”攒岛。簡單地說赖临，就像一段話經(jīng)過集體核準后在公告板上公示于眾，一字不錯不少灾锯，永久可見且無法涂改兢榨。
區(qū)塊需要進行區(qū)塊鏈共識，狀態(tài)數(shù)據(jù)是通過執(zhí)行區(qū)塊中的交易生成的顺饮，這兩類數(shù)據(jù)都直接或間接跟區(qū)塊鏈共識有關系吵聪，可以將其稱為“鏈上數(shù)據(jù)”。
“上鏈”意味著“共識”和“存儲”兼雄，兩者缺一不可吟逝。交易不經(jīng)過共識，則不能保證一致性和正確性赦肋，無法被鏈上所有參與者接受块攒；共識后的數(shù)據(jù)不被多方存儲励稳，意味著數(shù)據(jù)有可能丟失或被單方篡改，更談不上冗余可用囱井。
除此之外驹尼，如果僅僅是調(diào)用接口查詢一下，沒有改變?nèi)魏捂溕蠑?shù)據(jù)庞呕，也不需要進行共識確認新翎，則不算“上鏈”。
-
Fabric聯(lián)盟鏈的上鏈后可不可刪除住练？
也不能料祠，但是它有專門delstate接口，但是這個接口不是真的刪除了鏈上數(shù)據(jù)澎羞，只是隱藏鏈上的數(shù)據(jù)髓绽，你查詢將不能正常查到。而且區(qū)塊鏈世界狀態(tài)可以進行妆绞，出的塊都是空塊顺呕。
- 文件能不能上鏈西乖？
這是個非常高頻的問題澎怒，經(jīng)常被問到部逮。這里的文件一般指圖像迅诬、視頻罐呼、PDF等盐碱，這種非結(jié)構化的數(shù)據(jù)姊氓，也可以泛指大體量的數(shù)據(jù)集葛家，上鏈可信分享的目的技羔，是使接受者可以驗證文件的完整性僵闯、正確性。
結(jié)構化數(shù)據(jù)能如果數(shù)據(jù)特別大藤滥，更新頻率特別高鳖粟，能不能鏈下保存，鏈上通過哈希關聯(lián)拙绊？
結(jié)構化數(shù)據(jù)一定是非結(jié)構化數(shù)據(jù)經(jīng)過處理后向图，保存到數(shù)據(jù)庫進行了結(jié)構化處理。比如文檔數(shù)據(jù)标沪，通過數(shù)據(jù)庫處理后變成結(jié)構化表格數(shù)據(jù)榄攀。可以將處理后的表數(shù)據(jù)金句，整體打包進行內(nèi)容hash檩赢，這個內(nèi)容hash值可以存放到區(qū)塊里面，區(qū)塊根據(jù)hash索引到元數(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é)點在一段時間內(nèi)參與了多少次區(qū)塊記賬蛔六、是否及時、有否作弊”废亭，這些邏輯會牽涉到時間范圍国章、區(qū)塊高度、交易收發(fā)雙方豆村、合約地址液兽、事件日志、狀態(tài)數(shù)據(jù)等維度掌动。
目前區(qū)塊鏈底層平臺一般是采用“Key-Value”的存儲結(jié)構抵碟，其優(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ā)送交易上鏈即可势篡。
一般來說翩肌，多方見證的線上協(xié)同、公共賬本管理禁悠、一定要分享給全體的關鍵數(shù)據(jù)（或數(shù)據(jù)的HASH）都是可以放到鏈上的念祭，但相關的一些前置或后續(xù)的檢驗、核算碍侦、對賬等邏輯可以適當拆解到鏈下粱坤。
“鏈下”又是什么？
某個業(yè)務服務本身和區(qū)塊鏈并不直接相關瓷产，或其業(yè)務流程無需參與共識站玄，所生成的數(shù)據(jù)也不寫入節(jié)點存儲，那么這個業(yè)務服務稱為“鏈下服務”濒旦，無論它是否和區(qū)塊鏈節(jié)點共同部署在一臺服務器株旷，甚至和節(jié)點進程編譯在一起。數(shù)據(jù)上鏈數(shù)據(jù)庫之分：
獨立式數(shù)據(jù)庫尔邓，如 MySQL晾剖、Oracle 是通常理解的數(shù)據(jù)庫，獨立式數(shù)據(jù)庫作為獨立的進程運行铃拇，需要單獨部署和啟停钞瀑。獨立式數(shù)據(jù)庫可以與區(qū)塊鏈節(jié)點部署在同一臺服務器，或者部署在不同的服務器慷荔，還支持分布式、集群化的部署。無論何種部署方式显晶，獨立式數(shù)據(jù)庫都是區(qū)塊鏈節(jié)點的存儲組件贷岸，隸屬于區(qū)塊鏈節(jié)點，與區(qū)塊鏈網(wǎng)絡無關磷雇。嵌入式數(shù)據(jù)庫如 LevelDB偿警、RocksDB，它們以動態(tài)依賴庫或靜態(tài)依賴庫的方式唯笙，與區(qū)塊鏈節(jié)點整合在同一個進程中螟蒸，同時啟停，用戶不會明顯感受到它們的存在崩掘。
