区块链相关介绍
区块链概念:区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain),是比特币的一个重要概念,它本质上是一个去中心化的数据库,同时作为比特币的底层技术,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了一批次比特币网络交易的信息,用于验证其信息的有效性(防伪)和生成下一个区块。
1、区块结构简介
区块是一种被包含在公开账簿(区块链)里的聚合了交易信息的容器数据结构。它由一个包含元数据的区块头和紧跟其后的构成区块主体的一长串交易组成,即区块头和区块体,区块体中主要存储交易信息(明文),区块头用于连接区块,并形成一条链(区块链)。区块主要结构表如下:
区块主要结构表
1.1 区块头
区块头由三组区块元数据组成。首先是一组引用父区块哈希值的数据,这组元数据用于将该区块与区块链中前一区块相连接。第二组元数据,即难度、时间戳和nonce,与挖矿竞争相关。第三组元数据是Merkle树根(一种用来有效地总结区块中所有交易的数据结构)。区块头组成结构表如下:
区块头组成结构表
区块头之间的连接大约像下图所示:
比特币区块头结构图
1.2 Merkle Tree
Merkle Tree,是区块链中十分重要的一个结构,其保证了区块链交易的完整性、防篡改、历史留痕可追溯。尤其是在确保交易的完整性方面,大大减少了数据的传输量和计算的复杂度。Merkle Tree的所有节点都是Hash值。
Merkle Tree是一种哈希二叉树、具有树的所有特点,Merkle Tree的叶子节点存储具体的交易,非叶子节点根据下面的所有节点值,按照逐层HASH的方式求得,结构如下图所示:
Merkle Tree结构图
1.3区块链的防篡改
交易的篡改,会导致整个区块的哈希变化,一旦任何某个区块数据产生变动,后续所有区块的数据指纹(哈希值)都会变动,所有人都能发现数据被篡改,并丢弃且不认可这种无效数据。这就保证了区块链数据的不可篡改。
下面举例简单说明区块链的不可篡改性:
上图是区块链中的一个区块,里面存放了一批已经完成的交易信息,为了方便处理,区块的交易信息组织成 Merkle 树的形式,区块的块头存储了前一区块的哈希值。
假设叶子节点上的交易 3 发生篡改,那么交易 3 对应的哈希值就会变动,变动就会逐级向上传递,直到相应的父节点,最终导致区块的的根哈希发生变化,进而会导致整个区块的哈希发生变化。
由于交易 3 的篡改,导致交易 3 对应的整个区块的哈希发生变动,进而会引起下一个区块上记录的上一个区块的哈希无法对上,但是区块后面的后面的区块也要篡改,导致如果要篡改交易数据,就要篡改整条区块链的内容,基本是不可能的,这保证了区块链的不可篡改的特性。
而对区块链上交易的验证则可以通过Merkle树(默克尔树),通过计算交易所在叶子节点的Merkle树根值,并与区块头中的Merkle树根值比较,即可完成交易的验证。
2、区块链项目开发
在项目中使用区块链的基本条件:
基于数据库;需要多个“写操作者”;存在信任缺失的情况;需要去中心化(或者去中介化、或脱媒);交易之间的交互;制定交易规则的需要;需要选择交易仲裁者;锚定现实资产;
区块链开发流程如下图所示:
区块链开发流程图
2.1总体思路
首先要确定区块链的类型,是公证型区块链还是价值型?
公证型区块链:是指仅限一些关键数据自证、披露、防篡改等功能的区块链,通常是在价值型区块链中附带的功能,也可以单独扩展,用于公示公开等。
价值型区块链:是指可以进行资产所有权转移的一种记账账本。
在价值型区块链上,我们需要确定目标区块链的总体定位:
到底是一个普适的价值传输区块链,还是特定场景下的区块链?
如果是特定场景下的区块链,通常推荐超级账本作为技术原型,如果是比较通用的价值区块链,推荐以太坊的思路。
2.2 业务场景的构建与初步分析
首先要明确的观点是,区块链不是万能的。很多场景其实是不需要区块链技术也能解决的。
1. 需求痛点分析
一般需求痛点在满足以下条件的时候,可以考虑使用区块链:
(1)存在一个不信任的P2P网络环境
(2)节点之间是对等节点,不存在一个绝对仲裁者。
(3)节点之间的行为是博弈行为。
(4)P2P网络可能包含输入和输出,当包含输入和输出时,区块链不再封闭。
(5)对于某个节点一般有以下几种行为(包括但不限于):
1)不信任其他节点;
2)保证自己的收益最大化;
3)自私获取但不贡献资源。
4)针对以上情景的业务建模,需要针对具体的业务逻辑结合博弈论推导
出满足自己需求的方案即可。
2. 非区块链技术能否解决
具体场景需要具体分析。
2.3业务场景建模
具体场景需要具体分析。
2.4开发路径
以太坊或Hyperledger fabric。
2.交互接口设计
在交互接口设计上,推荐使用目前业界通用的Json-RPC接口,扩展性和友好性兼备。
一般将接口分为两类:开放接口和账户接口。开放接口是指区块链本身的描述信息,是不需要认证的。而账户接口是需要账户认证的。
3. 基础账本设计
包含以下几个问题:
(1)原型区块链是否已经满足需求?
(2)如果针对以太坊,基本上是不需要改动基础账本的,只需构建智能合约即可。
(3)如何以比特币体系为基础,则可能有较大的改动。
(4)不满足需求如何改动基础账本?这个其实要视账户模型而定,如果使用UTXO模式时,改动重点在如何嵌入模板交易体。如果使用Balance模式,那么则没有这个问题。
5. 业务扩展层设计
包含以下几个问题:
(1)扩展层是外接区块链还是内置到区块链?
(2)如果包含数据输入,是否需要脱敏?脱敏后如何上链?
3、区块链开发相关平台技术简介
3.1以太坊
以太坊,是一个分布式的计算机,有许多的节点,其中的每一个节点,都会执行字节码(即智能合约),然后把结果存在区块链上。由于整个网络是分布式的,且应用就是一个个的状态组成,存储了状态就有了服务;所以它就能永不停机,没有一个中心化的结点(没有任何一个节点说了算,去中心化的),任何第三方不能干预。
以太坊是一个图灵完备的区块链一站式开发平台,采用多种编程语言实现协议,采用Go语言写的客户端作为默认客户端(即与以太坊网络交互的方法, 支持其他多种语言的客户端)。
基于以太坊平台之上的应用是智能合约,这是以太坊的核心。每个智能合约有一个唯一的以太币地址,当用户向合约的地址里发送一笔交易后,该合约就被激活,然后根据交易中的额外信息,合约会运行自身的代码,最后返回一个结果。以太坊社区把基于智能合约的应用称为去中心化的应用程序(Decentralized App),相对于冷冰冰的智能合约代码,DApp拥有一个友好的界面和外加一些额外的东西,配合上图灵完备的语言,可以让用户基于合约搭建各种千变万化的DApp应用,实际上,在以太坊APP展区,已经有大大小小280个的DApp应用在展示。
3.2 web3j类库
web3j是一个轻量级、高度模块化、响应式、类型安全的Java和Android类库提供丰富API,用于处理以太坊智能合约及与以太坊网络上的客户端(节点)进行集成。可以通过它进行以太坊区块链的开发,而无需为你的应用平台编写集成代码。
web3j的特点
基于HTTP和IPC的以太坊JSON-RPC客户端API的完整实现。
对于以太坊钱包的支持。
自动生成Java智能合约封装包,以创建、部署、交易和调用来自本机Java代码的智能合约(支持solidity和Truffle定义格式)。
用于过滤器工作的响应式函数API。
以太坊名称服务(ENS)支持。
支持Parity的(personal模块)[https://github.com/paritytech/parity/wiki/JSONRPC-personal-module]和Geth的personal客户端API。
支持Infura,所以你不必自己运行一个以太坊客户端。
综合集成测试并展示了以上几种场景。
命令行工具。
Android兼容。
通过web3j-quorum支持JP摩根的Quorum。
参考文档:
[1]深度长文:区块链加密机制(https://www.jianshu.com/p/743d6514f253)
[2]比特币背后的密码学原理(https://www.jianshu.com/p/225ff9439132)
[3]区块链为什么能防篡改?(https://baijiahao.baidu.com/s?id=1653985667745220211&wfr=spider&for=pc)
[4]白话区块链入门011 | 区块链是什么?为什么能防伪、防篡改?(https://www.jianshu.com/p/4a4d13be011a)
[5]区块链之加密原理总结(https://www.jianshu.com/p/abfc4f442325)
[6]web3j官网中文版(http://blog.hubwiz.com/2018/07/10/web3j-index/)
[7]区块链应用开发入门(https://blog.csdn.net/elwingao/article/details/52412315?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task)
[8]如何使用区块链技术进行项目开发(https://blog.csdn.net/omnispace/article/details/80142595)
[9]在项目中使用区块链的八个基本条件(https://www.sohu.com/a/126936735_470097)
[10]区块链技术入门 | 区块链开发技术栈(https://blog.csdn.net/rcvisual/article/details/89632677)