ETH 中继接口

ETH中继能提供的功能

1. 接受其他服务端脸上的相关服务请求，中继处理请求业务，将处理后的响应返回给用户。如查询余额等
2. 发起交易的功能，包括ETH转账和ERC20转账
3. 用户的钱包创建
4. 对链上区块相关事件的监听，目前可以实现的监听事件包括但不限于如下：
	a. ERC20 Token的授权Approve事件
	b. Token转账Transfer的结果事件
	c. WETH Token置换ETH事件
	d. 新区块生成事件
	e. 遍历一个区块事件
	f. 区块分查事件

区块遍历

在中继开发中，事件的监听是开发难度最高的。
事件监听的技术原理主要是通过获取一个区块内部的交易信息并解析交易信息内的“EventLog”(日志事件)来达到目的。
目前ETH提供web.js库，该库中有区块事件监听函数，但并不完美，有以下不足：

1. 如果客户端的进程被杀死，监听动作就会被丢失
2. 如果对上一次最后遍历成功的区块号进行存储，重新启动的时候将会造成时间段内新生成的区块的数据丢失
3. 完整的监听流程比较消耗客户端的设备资源，影响用户体验

为什么要监听？
中心化Exchange就要做这样的事情，比如充值或者提现，都需要对链上的数据进行监控，要链上转账成功后，再修改中心化服务端的数据库，如果不监控，就提现而言，如果链上交易失败，但是用户在中心化的数值减少了，就会有问题。

在ETH机制中，链上的授权，交易，合约发布等事件都是一条条的交易信息，可以把每一笔交易信息提取出来，进行划分处理，就可以实现不同的功能和业务。

RPC接口(Remote Process Call，远程过程调用)

RPC接口在基于通讯协议方面有多种实现方法，但是主要是如下两种：

1. 同“RESTful API”一样，基于应用层HTTP/HTTPS协议实现
2. 基于传输层的TCP协议实现，也被称为Socket(嵌套字)的实现

两种方式的区别在于请求和响应的位置，一个是在应用层，一个是在传输层。
RPC接口和“RESTful API”接口，在HTTP/HTTPS协议实现，在速度方面几乎没有差别，
但是基于传输层的TCP协议实现的RPC接口，除了数据传输流的层级上比"RESTful"接口少而整体比它快外，传输时的整体数据报层面还少了HTTP/HTTPS的头部数据量及组装的时间损耗。也即是说，当RPC接口基于传输层的TCP协议实现时，RPC接口不仅请求和响应的速度比“RESTful”接口快，而且数据量也相对要少。

常见的RPC框架有以下几种：

1. JSON-RPC
2. XML-RPC
3. Protobuf-RPC
4. SOAP-RPC

简言之：RPC协议，就是规范了一种客户端和实现了RPC接口的服务端交互的数据格式。

RPC接口实现的大致流程：

1. 服务调用方案按照规范好了的编码方式把某个RPC接口的函数和参数进行序列化编码
2. 发送到服务的提供方，即服务器端
3. 服务器端再通过反序列化后把对应的参数提取出来
4. 然后通过调用相关函数
5. 最后把结果返回给服务端的调用方

相伴ETH RPC接口的重要三个参数

在了解ETH RPC接口之前，先了解3个参数，因为这3个参数会出现在每一个接口中。

• genesis，代表的是最早的，早期的源码版本中等同于 earliest
• pending，代表的是等待或者挂起状态中的
• latest，代表的是最新完成的

ETH RPC接口

1.eth_blockNumber

该接口可以根据传参(genesis,pending,latest)获取 3 种类型的区块高度

1. genesis, 代表的是创世区块，因为可以指定最早的区块号，所以创世区块不一定是0
2. pending，代表的是当前正在被minter开采的区块，代表正在打包交易的区块，一个区块在打包完一定的交易后才会完整上链
3. latest，当前链上最新生成的区块的高度

2.eth_getBlockByNumber