待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此简书文集记录我的学习笔记。
课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。
第八课分为三部分：
- 以太坊Web应用架构
- AirCoin WebUI 设计概要
- AirCoin WebUI 实际开发演示
这篇文章是第八课第一部分的学习笔记：以太坊Web应用架构。
这节课主要讲解了前节课所述空气币（AirCoin）的Web应用架构。
1、以太坊Web应用组件
在以太坊去中心化应用的前端技术中，主要使用了两个组件，一个是 web3，一个是 TruffleContract，这两个都是基于 JavaScript 的。
Web应用组件
1.1 web3js
web3js 是以太仿官方的JavaScript接口，Go-Ethereum 官方客户端支持。它不但可以使用在 Http 中，还可以使用在 RPC 中，也可以使用在 Go-Ethereum 的控制台中，应用非常广泛。它现在有两个版本，0.2x 和 1.0 版本，其中 1.0 版本还在开发中，后面的例子中使用的是 0.2 版本。
一般来讲，作为 JS 的类库，可以支持同步和异步两种模式，这节课的例子中也会用到两种模式。
web3js 大约有几十种接口，主要使用的有上图中的四种。更多内容可以参见这里：《 js-api 》
1.2 Truffle-Contract
Truffle-Contract 是 Consensys Tuffle 框架的一部分，支持 nodejs 调用和浏览器调用两种形式。这节课的例子中是通过后者来调用。
它是基于 web3js Contract 部分接口的封装。原因是在 web3js Contract 中要使用对应合约的 ABI 来实例化，而 Truffle 本身是个框架，有编译功能，有部署功能，所能提供的信息要远比 ABI 丰富，对这些信息进行更高级的封装，则就是 Truffle-Contract 。Truffle-Contract 的目标是更容易的操作以太坊智能合约。
通过 nodejs 和浏览器创建合约对象的方法如图。其中 JSON 文件包含 ABI、网络ID、地址等信息。JSON 文件要满足 truffle-contract-schema 格式。
生成合约对象后，通常还要再生成对应的实例，大概有三四种方法，最常用的方法是 deployed() 。生成合约实例之后，可以使用这个实例向对应的合约发起相关的调用，在后面的例子中会有演示。
JSON 文件从哪来？它其实是 Truffle 编译时生成的文件，部署时，也会更新它。所以，这个 JSON 文件不止包含静态信息，也包含动态，如部署信息。因为部署信息只有在部署时才会有，所以 Truffle 对 JSON 文件进行了两次操作，一次是创建时，一次是更新时。更详细的信息见：《 truffle-contract 》
2、以太坊Web应用架构
以太坊Web应用架构
以太坊Web应用架构主要有两种，图示左边的一种相对较简单，适用于服务器端逻辑简单的情况。随后的例子用的是这种。图示右边的一种是服务器端逻辑复杂的情况。
第一种。web 前端通过调用 Trufflecontract，通过调用 web3js，来和FullNode 进行交互，这个全节点可以是 Geth，也可以是测试工具 Ganashi 。后面的例子中使用的是 Ganashi 。如果是 Geth 的话，还需要与主网联通。这种架构没有服务器端，逻辑全部依靠智能合约。如果逻辑复杂，代价就昂贵，响应速度还受制于主网的吞吐量。
第二种。如果服务器端的逻辑较复杂，而大部分的内容不需要放到区块链上，就需要第二种架构。这种架构和传统的 C/S 架构还不相同，Client 和 Server 还不是直接通信。以电商购物说明一下。
卖家向主网注册一个事件“买家向我打钱了”，当买家打钱时就会触发这个事件。同样，买家也向主网注册一个事件“卖家向我发货了”，当卖家发货时就会触发这个事件。
之后，买家向区块链发起一笔交易向卖家付款，同时获得收据，同时这个收据也会到卖家，因为触发了事件“买家向我打钱了”。卖家此时就会发货，收据返回到卖家和买家，因为买家的事件“卖家向我发货了”被触发。客户端更新界面。
这种架构中，只有很小的部分放到了区块链上，主要是涉及交易的部分。这里只是举例说明。这种架构的好处是可以节省费用。
小结：这小节主要介绍了以太坊Web应用组件和两种应用架构。
不足之处，请批评指正。
网友评论