- 第 1 章 区块链
- 第 2 章 以太坊
- 第 3 章 以太坊私链入门
- 第 4 章 以太坊网络
- 第 5 章 geth v1.8.16 命令详解
- 第 6 章 Wallet
- 第 7 章 Token
- 第 8 章 智能合约语言 Solidity v0.5.0
- 第 9 章 Truffle v4.1.8 开发框架
- 第 10 章 web3.js - 1.0.0
- 第 11 章 web3j v3.4.0 - Jave Client
- 11.2. 启动以太坊
- 11.3. Maven pom.xml 文件
- 11.4. Java 与 Solidity 数据类型映射关系
- 11.5. 常量
- 11.6. 连接到服务器获取版本号
- 11.7. 获得以太坊状态信息
- 11.8. 单位转换
- 11.9. 账号管理
- 11.10. Credentials
- 11.11. 交易
- 11.12. 钱包
- 11.13. 智能合约
- 11.14. ERC20合约
- 11.15. Infura
- 11.16. 助记词
- 11.17. 过滤器 (Filter)
- 11.18. Subscription
- 11.19. 解锁账号
- 11.20. IBAN (International Bank Account Number)
- 11.21. Springboot with Ethereum (web3j)
- 第 12 章 web3.py - A python interface for interacting with the Ethereum blockchain and ecosystem.
- 第 14 章 Ethereum Developer APIs
- 第 15 章 infura
- 第 16 章 以太坊案例
- 第 17 章 FAQ
- 17.3. Error: authentication needed: password or unlock
- 17.4. 新增节点后不生效
- 17.5. Unhandled rejection Error: Returned error: The method personal_unlockAccount does not exist/is not available
- 17.6. Error: exceeds block gas limit
- 17.7. Migrations.sol:11:3: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(…) { … }" instead.
- 17.8. Exception in thread "main" rx.exceptions.OnErrorNotImplementedException: Invalid response received: okhttp3.internal.http.RealResponseBody@6c25e6c4
- 17.9. 旧版本 Remix(browser-solidity) 本地安装
- 第 18 章 Hyperledger Fabric v2.0.0
- 第 19 章 Hyperledger Fabric 运维
- 第 20 章 Chaincode 链码(智能合约)
- 第 21 章 Hyperledger Fabric Client SDK for Node.js
- 第 22 章 fabric-sdk-java
- 第 24 章 已知 Hyperledger 落地案例
- 第 25 章 Fabric Command
- 第 26 章 Fabric FAQ
- 第 27 章 IPFS(InterPlanetary File System,星际文件系统)
- 第 28 章 IPFS 命令
- 第 29 章 IPFS WebUI
- 第 30 章 IPFS 集群配置
- 第 31 章 IPFS API
- 第 32 章 IPFS Faq
- 第 33 章 EOS
- 第 34 章 EOS 安装
- 第 35 章 CLEOS
- 第 36 章 智能合约开发
- 第 37 章 EOS Dapp 开发
- 第 38 章 FAQ
- 第 39 章 BaaS (Blockchain as a Service) 平台
- 第 40 章 BitCoin
- 第 41 章 其他区块链相关
- 附录 1. 附录
1.12. 区块链落地面临的问题
1.12. 区块链落地面临的问题
1.12.1. 性能问题
区块链目前的底层只适合做,低频高价值的业务。
区块链的读取性能通常是没有问题的,但是区块链的写入实际上无论你用多少个服务器节点都不能提升,因为写入区块需要做共识算法,这步操作,会在所有节点上进行,同时还需要加密运算,这些操作都是 CPU 密集型操作。所以写入操作是存在瓶颈的。
解决这个问题,我想出了几种方案:
性能解决方案
通过消息队列技术异步写入,将需要写入的区块放入队列,异步完成上链操作。
并行写入,我们可以建设多个区块链平台。多个平台同时服务于业务。
为了达到去中心化并行写入,我们将在客户端通过算法,匹配服务器。而不是在两个平台前面增加负载均衡。因为这样又回到了中心化系统。
1.12.2. 颗粒度问题
朔源的颗粒度问题,例如“红酒”的溯源,我们是将单位溯源做到箱呢?还是打,或是瓶呢?
我们用“四象限法则”分析
高价值 o | | o | 低频率 --------------+------------- 高频率 操作频率 | o | o | 低价值 物品价值
通过观察上面图,我们可以看到可以有四种情况,低频低价值,低频高价值,高频高价值,高频低价值
我认为对于低频高价值和高频高价值的业务,尽量做到最小颗粒度。
而对于低频低价值和高频低价值的业务,可以颗粒度更粗。
1.12.3. 区块链不能替代传统数据
回归技术本质,我认为区块链技术本身是一种追求分布一致性的数据库。
我们学过数据库的,都知道CAP理论。CAP理论是指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。大多数区块链,放弃了一些可用性,偏向了一致性和分区容错。
区块链并非能解决所有问题,虽然他也算是一种数据库,它能解决问题十分有限,它的数据管理和查询能力还打不到 NoSQL 的水平,更别提 SQL 的复杂应用。所以在实际的应用中,区块链不能替代数据,只能互补。
所以在项目实施前,仔细想想自己需求,真的需要区块链吗?还是需要区块链上的一些特性?例如数据不可撰改。如果仅仅是需要区块链的某一个特性。我们可以针对这个需求,思考一下能否使用传统数据库解决。
1.12.4. 链上,链下数据一致性问题
既然区块链替代不了传统数据库,那么必然要在项目中同时使用两种技术。这样问题来了,会有两份数据,一份存储在链下,即传统数据库,另外一部分数据上链,这样就有两份重复的数据,那么怎样保证他们的一致性呢?
非链上的原生资产在上链过程中,有一个重要的问题:原生资产的真实性问题,即链上资产、链下资产如何保持一致性问题。
区块链和比特币网络不同,比特币是在链上产生的,它与区块链密布可分,是一体的,所以它的数据安全性是自闭环的。而我们的链下数据并不是在区块链中产生的,将链下数据与区块链对接上链
我们需要考虑几个问题
怎样能保证数据的真实和一致性呢?
当出现不一致的时候以哪个为准呢?
当需要读取数据时,是走连上,还是链下呢?
什么数据上链,什么数据不上链?
下面回答上面提出的问题
两端都将数据做一次hash,可以快速对比是否数据一致
我认为以连上数据为准较好,因为数据库数据更容易被撰改。
前台走上链,后台走数据库,前台是为用户提供服务的,所以要走连上数据,后台是管理的,可以直接走数据库,然后保证数据库与区块链数据一致。
共享数据上链,私有数据不上链,想象一下在盟链系统中,需要共享给其他成员数据,之前采用 Api接口,有了区块链更好的解决了资源共享问题。
例如下图我们将共享数据上链,在联盟中共享。私有数据(不能公开的数据)放到自己本地数据库,或者私链中。
盟链系统 +----------+ +----------+ +----------+ | 你 | | 我 | | 他 | +----------+ +----------+ +----------+ | | | V V V +------------------------------------+ | Block Chain | +------------------------------------+
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论