什么是“上链”？什么数据和逻辑应该“上链”？文件能不能上链？链上能不能批量查数据？“链下”又是什么？
交易“上链”的简要过程如下：
1，记账者们收录交易，按链式数据结构打包成“区块”。
2，共识算法驱动大家验证新区块里的交易，确保计算出一致的结果。
3，数据被广播到所有节点，稳妥存储下来，每个节点都会存储一个完整的数据副本。
交易一旦“上链”，则意味着得到完整执行，达成了“分布式事务性”。简单地说，就像一段话经过集体核准后在公告板上公示于众，一字不错不少，永久可见且无法涂改。
区块需要进行区块链共识，状态数据是通过执行区块中的交易生成的，这两类数据都直接或间接跟区块链共识有关系，可以将其称为“链上数据”。
“上链”意味着“共识”和“存储”，两者缺一不可。交易不经过共识，则不能保证一致性和正确性，无法被链上所有参与者接受；共识后的数据不被多方存储，意味着数据有可能丢失或被单方篡改，更谈不上冗余可用。
除此之外，如果仅仅是调用接口查询一下，没有改变任何链上数据，也不需要进行共识确认，则不算“上链”。
-
Fabric联盟链的上链后可不可删除？
也不能，但是它有专门delstate接口，但是这个接口不是真的删除了链上数据，只是隐藏链上的数据，你查询将不能正常查到。而且区块链世界状态可以进行，出的块都是空块。
image.png
- 文件能不能上链？
image
这是个非常高频的问题，经常被问到。这里的文件一般指图像、视频、PDF等，这种非结构化的数据，也可以泛指大体量的数据集，上链可信分享的目的，是使接受者可以验证文件的完整性、正确性。
结构化数据能如果数据特别大，更新频率特别高，能不能链下保存，链上通过哈希关联？
结构化数据一定是非结构化数据经过处理后，保存到数据库进行了结构化处理。比如文档数据，通过数据库处理后变成结构化表格数据。可以将处理后的表数据，整体打包进行内容hash，这个内容hash值可以存放到区块里面，区块根据hash索引到元数据。
常见的场景里，文件共享一般是局部的、点对点的，而不是广播给所有人，让区块链无差别地保存海量数据，会不堪重负。所以，合理的做法是计算文件的数字指纹（MD5或HASH），并与其他一些可选信息一起上链，如作者、持有人签名、访问地址等，单个上链信息并不多。
文件本身则保存在私有的文件服务器、云文件存储、或者IPFS系统里，这些专业方案更适合维护海量文件和大尺寸文件，容量更高、成本更低。注意，如果文件的安全级别到了“一个字节都不能泄露给无关人等”的程度，那么应慎用IPFS这种分布式存储的方案，优选私有存储方式。
需要分享文件给指定的朋友时，可以走专用传输通道点对点的发送文件，或者授权朋友到指定的URL下载，可以和区块链的P2P网络隔离，不占用区块链带宽。朋友获得文件后，计算文件的MD5、HASH，和链上对应的信息进行比对，验证数字签名，确保收到了正确且完整的文件。
这种方案，文件在链上“确权”、“锚定”和“寻址”，明文在链下传输并与链上互验，无论是成本、效率、还是隐私安全都取得了平衡。
- 怎么批量查询和分析数据？
image
对区块链上的数据进行分析是自然的需求，比如“某个账户参与哪些业务流程、完成了多少笔交易、成功率如何”，“某个记账节点在一段时间内参与了多少次区块记账、是否及时、有否作弊”，这些逻辑会牵涉到时间范围、区块高度、交易收发双方、合约地址、事件日志、状态数据等维度。
目前区块链底层平台一般是采用“Key-Value”的存储结构，其优势是读写效率极高，但难以支持复杂查询。
其次，复杂查询逻辑一般是在区块生成后进行，时效性略低，且并不需要进行多方共识，有一定的“离线”性。
最后，数据一旦“上链”，就不会改变，且只增不减，数据本身有明显特征（如区块高度、互相关联的HASH值、数字签名等）可以检验数据的完整性和正确性，在链上还是链下处理并无区别，任何拥有完整数据的节点都能支持独立的复杂查询。
于是，我们可以将数据完整地从链上导出，包括从创世块开始到最新的所有区块、所有交易流水和回执、所有交易产生的事件、状态数据等，通通写入链外的关系型数据库（如MySQL）或大数据平台，构建链上数据的“镜像”，然后可以采用这些引擎强大的索引模型、关联分析、建模训练、并行任务能力，灵活全面地对数据进行查询分析。
区块链浏览器、运营管理平台、监控平台、监管审计等系统，都会采用这种策略，链上出块，链下及时ETL入库，进行本地化地分析处理后，如需要和链上进行交互，再通过接口发送交易上链即可。
一般来说，多方见证的线上协同、公共账本管理、一定要分享给全体的关键数据（或数据的HASH）都是可以放到链上的，但相关的一些前置或后续的检验、核算、对账等逻辑可以适当拆解到链下。
-
“链下”又是什么？
某个业务服务本身和区块链并不直接相关，或其业务流程无需参与共识，所生成的数据也不写入节点存储，那么这个业务服务称为“链下服务”，无论它是否和区块链节点共同部署在一台服务器，甚至和节点进程编译在一起。 -
数据上链数据库之分：
独立式数据库，如 MySQL、Oracle 是通常理解的数据库，独立式数据库作为独立的进程运行，需要单独部署和启停。独立式数据库可以与区块链节点部署在同一台服务器，或者部署在不同的服务器，还支持分布式、集群化的部署。无论何种部署方式，独立式数据库都是区块链节点的存储组件，隶属于区块链节点，与区块链网络无关。嵌入式数据库如 LevelDB、RocksDB，它们以动态依赖库或静态依赖库的方式，与区块链节点整合在同一个进程中，同时启停，用户不会明显感受到它们的存在。
网友评论