# WEB3.0？剑指目前的所有公链！开始讲讲全球首款移动端公有链bfchain到底长啥样？

By [bfchain](https://paragraph.com/@bfchain) · 2022-01-20

---

                           **要成为web3.0的底层，首先要解决的是分布式存储的问题** 
    

在bfchain中，我们重新设计了区块链数据的存储方式，我们叫它⸺Relational Object Storage（关系对象存储）。数据存储能力是区块链落地的基础，由于区块链的特殊性，无法预设和要求参与节点提供大容量高吞吐的数据存储设备，所以相比传统中心化 IT 建设在设计时就需要增加如下方面的考虑：

1.  存储容量
    

传统 IT 建设可以要求提供大容量磁盘阵列提高容量，或分离业务与历史数据以降低存储压力与系统性能压力，但区块链网络中无法通过上述两种方法完成。

2.  吞吐性能
    

传统 IT 建设中可以要求节点采用高转速、SSD 等更快速的存储设备，或采用 Raid1 阵列磁盘并增加磁盘数，或分散吞吐压力到多节点，或预加载数据到内存等方式即可有效提高吞吐性能，但到了区块链场景行不通，因为绝大多数参与节点都没有这些设备和条件。

3)RSD 移动存储机制

传统 IT 建设中，系统架构是按中心化服务器设计，为了兼顾终端成本问题，终端都不参与业务逻辑计算，同时终端也不会存储业务数据，所以终端几乎没有移动存储的需求，少量存储也是不参与业务逻辑运算的用户文件与个人数据信息，在区块链场景中，每一个参与节点既是终端又是服务端，传统的存储设计方式无法应用在区块链场景中。 因为现实的难题，绝大多数区块链在存储设计上依然沿用传统的 IT 建设思想，数据集中存储在参与节点上，终端参与者（如移动钱包）通过其它参与节点进行中转。

A.传统存储思想的问题：

a) 伪去中心

因为终端无法直接访问区块链，实际的数据请求和业务过程由其他节点完成，数据的可信度由参与节点是否作弊来保证，这样有违区块链去中心化的初衷。

b) 伪节点

终端如果不能接入区块链网络，或接入了区块链网络而数据不全，将不能有效参与网络的治理（传统共识机制下），虽然看上去是一个节点，在一定程度上也可以通过桥接手段完成间接通信，但依然算不上一个合格的参与节点。

c) 无法参与共识

当终端网络与数据有一个缺失时，将导致终端失去参与共识的基础，不能参与共识往往代表着不能参与区块的建立，而这意味着伴随区块建立的奖励将无缘获得，对于贡献相同参与度的此类终端来说，某种意义上有失公平。

B.专属于 BFChain 的 RSD 机制

为了未来 BFChain 生态的发展，鼓励更多的角色与终端接入 BFChain 网络，并获取公平的奖励， 我们在设计上就需要兼顾不同终端所面临的接入问题，并提供有效可靠的解决方案。为此我们首次提出了 The R-Node（实时节点）、The S-Node（服务节点）与 The D-Wallet（分布式钱包）的概念，分别实现对高性能网络节点以及分布式服务节点提供支持，为了在实现这些概念的基础上还能保证他们之间也可以参与共识机制，我们对区块链的数据存储机制进行了重新设计。首先为了解决移动终端计算能力有限情况下的计算问题，我们引入了移动设备常用的微型关系型数据库 SQLite，这里主要使用它在没有太多计算资源与存储资源情况下的完整事务运算能力，为我们实现 The D-Wallet 提供了基础。其次为了解决数据检索效率问题，我们引入了目前使用很普遍的 NoSQL 数据库MongoDB，主要使用它在链式数据很长情况下的快速检索能力，由于它存储体积不小并且不适用于移动端，我们将其改造并与 SQLite 进行了融合，让节点既可参与共识又可以保持轻巧的体积，为我们实现公平奖励提供了基础。

在 RSD 机制中，两种数据库各有分工，改造后的 MongoDB 主要用于存储区块哈希树，为共识机制执行过程中对分叉问题的处理提供快速识别的能力；对于需要参与共识的移动终端，需要在本地存储部分区块数据，并通过这部分数据参与到共识机制中，为了尽可能的减少终端存储的数据量，我们建立了关键检查点，终端只需要存储检查点后的区块数据即可，这部分数据存储在 SQLite 中（为了进一步降低终端体积以及运行资源要求，我们后期将进一步对存储机制进行升级，打造更轻量级的存储实体）。对于关键检查点的确立我们采用和区块一致的共识机制进行完成。多维分片存储，任意单一设备都将无法在未来的新数字时代为全社会提供服务，所以采用多设备提供服务是必然。BFChain 生物链林数据存储时不仅采用多磁盘，还采用了全量多节点共同存储的“多维分片扩容”专利存储技术，数据既可以海量存储，又可以在应用层中保持逻辑上的单一性。扩容技术使存储性能得到质的提升，为未来全面的商业应用打下了坚实的基础。

                                  **要成为web3.0的底层，其次要解决的是通信的问题**
    

为实现移动终端直接参与共识机制，我们在通信领域进行了重新设计。我们重新设计了区 块 链 P2P 网 络，我 们 叫 它⸺Full LinkDuplex Communication（全链路双工通信）。区块链网络是建立整个 BFChain 的基础，传统区块链网络基本上都采用 Socket 的方式。

1)Socket 具有的特点

A.组件库丰富，很久远之前的编程语言都 支 持，如 上 世 纪 六 七 十 年 代 的cobol、c++。

B.逻辑简单开发简便，只需要关心传输内容，而不用关心底层通信逻辑。

C.不同区域性网络不能直接互通，需要额外的组件支持，例如 GRPC。

2)Socket 的问题

A.网络连接的自主控制能力较弱，意味着数据实时性，传输的效率很难控制。

B.基于 Socket 的应用不能直接与浏览器通信，意味着以 Webkit 一类为核心的应用均不能直接访问区块链网络。

C.对于服务到端的主动通信能力较弱，很难建立有效的实时推送机制。

3.  更高标准的 BFChain 生物链林网络为了未来 BFChain 生态的发展，我们需要在设计上就允许任何终端类型都可以更方便地接入 BFChain，而当下绝大多数区块链网络在提供对外服务时依然需要一个中心化的服务器（第三方钱包）， 于是我们 对 BFChain 提 出 了 更 高 的 设 计 要求⸺NAAS（Node As A Service 节点即服务），因为这个没有现成的 P2P 网络支持，所以我们对 P2P 网络进行了重新设计
    

4)WebSocket 机制的引入 对于实时性要求高的场景我们引入了 WebSocket 的机制，这个在“微信”一类应用中常用的协议被我们引入到区块链网络的设计中，它除了继承 Socket 的优点，还能有效提高数据的通信能力和广播效率，并顺带解决了服务到端的主动通信能力，为我们提供高可靠高性能的BFChain 提供了基础

5.  HTTP 协议与 WebSocket 协议的结合 除此之外，我们还引入了互联网使用最广泛的协议“HTTP 协议”（后期我们还将逐步升级到 HTTPS），其与 WebSocket 协议有机结合了起来，让 BFChain 的网络能力不仅能在节点之间提供高效互通， 还能为跨区域网络、跨终端类型提供有效互通，为 NAAS 提供支持，并为我们开发真正意义上的分布式应用 DAPP 提供了基础。

---

*Originally published on [bfchain](https://paragraph.com/@bfchain/web3-0-bfchain)*