㈠ JSON-RPC轻量级远程调用协议介绍及使用
json-rpc是基于json的跨语言远程调用协议。比xml-rpc、webservice等基于文本的协议数据传输格小；相对hessian、java-rpc等二进制协议便于调试、实现、扩展，是很优秀的一种远程调用协议。眼下主流语言都已有json-rpc的实现框架，java语言中较好的json-rpc实现框架有jsonrpc4j、jpoxy、json-rpc。三者之中jsonrpc4j既可独立使用。又可与spring无缝集合，比较适合于基于spring的项目开发。
json-rpc协议很easy，发起远程调用时向服务端数据传输格式例如以下：
{ "method": "sayHello", "params": ["Hello JSON-RPC"], "id": 1}
参数说明：
method： 调用的方法名
params： 方法传入的参数。若无参数则传入 []
id ： 调用标识符。用于标示一次远程调用过程
server其收到调用请求，处理方法调用，将方法效用结果效应给调用方；返回数据格式：
参数说明:
result: 方法返回值。若无返回值。则返回null。
若调用错误，返回null。
error ：调用时错误，无错误返回null。
id : 调用标识符，与调用方传入的标识符一致。
以上就是json-rpc协议规范，很easy，小巧。便于各种语言实现。
2.1、server端Java调用演示样例
jsonrpc4jserver端java演示样例：
2.2、Javaclient调用演示样例
jsonrpc4j的Javaclient调用演示样例：
2.3、JavaScriptclient调用演示样例
基于jsonrpcjs的JavaScriptclient调用演示样例：
2.4、直接GET请求进行调用
无需不论什么client。仅仅需手工拼接参数进行远程调用，请求URL例如以下：
参数说明:
method : 方法名
params ：调用参数。json的数组格式[], 将参数需先进行url编码，再进行base64编码
id : 调用标识符，随意值。
json-rpc是一种很轻量级的跨语言远程调用协议。实现及使用简单。
仅需几十行代码，就可以实现一个远程调用的client。方便语言扩展client的实现。
server端有php、java、python、ruby、.net等语言实现，是很不错的及轻量级的远程调用协议。
㈡ DApp开发入门
本文仅介绍以太坊系列的DApp开发，其他链原理差不太多。
MetaMask安装完成并运行后，可以在Chrome控制台打印 MetaMask注入的window.ethereum对象
关于ethereum对象，我们只需要关心 ethereum.request 就足够了，MetaMask 使用 ethereum.request(args) 方法 来包装 RPC API。这些 API 基于所有以太坊客户端公开的接口。 简单来说钱包交互的大部分操作都是由 request() 方法实现，通过传入不同的方法名来区分。
⚠️ 即使ethereum对象中提供了chainId，isMetaMask，selectAddress属性，我们也不能完全相信这些属性，他们是不稳定或不标准，不建议使用。我们可以通过上面说的request方法，拿到可靠的数据 。
钱包通过method方法名，进行对应的实现 以获取钱包地址为例
调用 ethereum.request({ method: "eth_requestAccounts" }) ，钱包实现了该方法，那么就可以拿到钱包的地址了。
MetaMask注入的 window.ethereum 就是一个Provider，一个RPC节点也是一个Provider，通过Provider，我们有了访问区块链的能力。 在连接到钱包的情况下，通常使用钱包的Provider就可以了， ethers.providers.Web3Provider(ethereum)
如果只需要查询一些区块链数据，可以使用EtherscanProvider 和 InfuraProvider 连接公开的 第三方节点服务提供商 。JsonRpcProvider 和 IpcProvider 允许连接到我们控制或可以访问的以太坊节点。
获取当前账户余额
获取最新区块号
其他RPC操作，可以通过 JSON-RPC 查看。
通过 ethers.js 可以连接ERC20的合约，合约编译后会生成ABI，合约部署后，会生成合约地址，开发者通过 ABI和合约地址 ，对合约发送消息。
合约中的方法大致分为两种： 视图方法(免费)，非视图方法(消耗Gas) ，可以通过ABI查看方法类型。
⚠️ ERC20需要多加关注的是 Approve() 方法以及 transfer() 和 transferFrom() 的区别 ，授权过的代币，被授权的那一方，可以通过调用 transferFrom() 方法,转走你授权数量内的代币，所以授权是一个很危险的操作，假设你授权了一个不良的合约，那你会面临授权的token被转走的风险，即使你没有泄露私钥助记词。
便利三方库： web3-react use-wallet
文档： doc.metamask.io ethers
㈢ 技术基础--JSON-RPC2.0
最近刚加入区块链学习的热潮，从一些基本技术开始学起。本文翻译自 JSON-RPC 2.0 Specification . 其实协议很简单，本不需要翻译，主要是为了记录这个学习过程，以及加深理解。
JSON是一种轻量级的数据交换格式。它可以地标数字，字符串，有序数组，以及键值对。
而JSON-RPC是一种无状态的，轻量级的远程程序调用协议。不只一种数据结构及其处理规则可以符合这种定义。数据通过socket, http, 或其他环境传输，并不能确定其将在本进程内使用。它使用JSON来座位数据格式。
设计也很简单。
关键词“MUST”, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"的解释可以在RFC2119中找到。
由于采用了JSON协议，其可传输的数据类型也和JSON相同。JSON可以表示四种基本类型， Strings, Numbers, Booleans, Null，还有两种结构类型：Objects， Arrays。当我们提到“基本类型”的时候，是指四种基本的JSON类型，而“结构类型”则指代以上两种JSON结构类型。当提到JSON类型时，总会把第一个字母大写，比如Object, Array, String, Number, Boolean, Null. True和False也是如此。
JSON-RPC 2.0定义的请求对象和响应对象和现有的JSON-RPC 1.0客户端/服务器有兼容问题。这两个版本其实很好区分，2.0定义了一个叫"jsonrpc"的成员，其值时2.0，而1.0版本没有。2.0的实现往往要兼容1.0的对象，即使我们在开发点对点以外或者明显不是1.0的业务的时候亦是如此。
RPC调用是指发送一个请求对象到远程服务器上。请求对象包括以下成员：
jsonrpc: 用来声明JSON-RPC协议的版本，固定为“2.0”
method：需要调用的方法。方法名以单词rpc开头，后面跟上期限字符，这个字段在rpc交互的方法及其扩展上被存储起来，并且不能用于其他意义。
params: 结构化的值，用于存储方法响应需要用到的参数，且不能被省略。
id：客户端分配的一个标识符，可以包含字符串，数字或者为空。如果没有id，就会被当成是广播通知。这个值一般不能为Null，且为数字时不能有小数。如果请求中含有这个字段，服务器在响应时，必须原样返回该字段，用来关联以下两个对象的不同环境：
当请求参数中不发送id成员时，该请求会被当作通知处理。对于通知，客户端不关心响应对象，因为服务端也没必要返回响应对象，确切的说，服务端不准答复一个通知请求，即便这个请求是批处理请求中的一个。
根据这个定义，通知请求并不会被确认，因为客户端不会收到响应对象，更进一步说，通知请求的客户端无法感知到错误，比如参数错误/网络错误等。
RPC调用的参数必须是结构化的值(对象或者数组)，对象通过名字遍历，而数组通过位置可遍历。
数组参数的遍历顺序必须与服务端顺序一致。
对象参数的成员值必须与服务端期望的一致，且在大小写上精确匹配。一旦有成员缺失，会导致错误产生。
当RPC请求出错时，服务器响应的Response对象中，必须包含error，且包含以下成员：
code: Number类型，表示出错类型
message: String类型 简介的一句话来描述错误
data: 可以是基本类型，也可以是结构类型，来表示错误的额外信息，且可以缺省。具体取值由服务器自定义，比如错误详情，访问限制等等。
-32768到-32000之间的错误码是系统保留错误码，协议预定义方便未来使用。错误码的定义和XML-RPC类似：
-32700: 解析错误，无效的JSON结构，服务器在解析JSON时出错
-32600: 请求无效，Request对象不是一个合法的JSON请求
-32601: 未知的方法，服务器未定义该method，或者该方法不可用
-32602: 参数错误
-32603: 网络错误
-32000--32099: 服务器错误，服务器其他错误的保留错误码
上述区间以外的错误码可在应用开发时使用。
同时发送多个Request对象时， 客户端可以把请求都放到一个数组里一起发送。
服务端收到Request对象数组并处理完成后，应当以数组的形式返回，且数组中包含了响应的请求的Response对象。每一个请求对应一个响应，如果请求是通知的话，则不包含该Response对象。服务端在批处理请求任务时，可以按任何顺序或者并行化处理。
服务端对请求进行批处理时者不是至少长度为1的合法请求对象数组时，服务器响应的对象必须是一个单的Response对象。如果没有Response数组中不包含Response对象，那也不能返回空数组，而应该什么都不返回。
--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}
--> {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2}<-- {"jsonrpc": "2.0", "result": -19, "id": 2}
--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3}<-- {"jsonrpc": "2.0", "result": 19, "id": 3}--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4}<-- {"jsonrpc": "2.0", "result": 19, "id": 4}
--> {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5]}
--> {"jsonrpc": "2.0", "method": "foobar"}
--> {"jsonrpc": "2.0", "method": "foobar", "id": "1"}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "1"}
--> {"jsonrpc": "2.0", "method": "foobar, "params": "bar", "baz]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}
--> {"jsonrpc": "2.0", "method": 1, "params": "bar"}
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}
--> [ {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"}, {"jsonrpc": "2.0", "method"]<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}
--> []<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}
--> [1]
<-- [ {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}]
--> [1,2,3]
<-- [ {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}, {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}, {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}]
--> [
{"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
{"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
{"foo": "boo"},
{"jsonrpc": "2.0", "method": "foo.get", "params": {"name": "myself"}, "id": "5"},
{"jsonrpc": "2.0", "method": "get_data", "id": "9"}
]
<-- [
{"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "result": 19, "id": "2"},
{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "5"},
{"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
]
--> [
{"jsonrpc": "2.0", "method": "notify_sum", "params": [1,2,4]},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]}
]
<-- //Nothing is returned for all notification batches
使用rpc开头的方法名是系统扩展方法，且不能用于其他场合。每一个系统扩展都在相关声明中定义。系统扩展是可选的。
1）如何撰写一个规范，或者说一个规范由哪些部分组成，本规范是一个很好的模版
2）如何做前后兼容。jsonrpc的兼容方式很简单，在请求头部扩展一个jsonrpc的版本号即可。如果是良好的设计，在1.0的时候就应该加上此字段。
3）严谨性。比如，我们不能简单的使用Null作为id参数来表示通知，服务端解析id失败也返回Null的id，无法区分这两种情形。
4）批处理。一个好的设计必然要考虑多任务的批处理，在设计批处理时，需要考虑数据的解析，服务器可能不按序处理，以及可能并发处理，需要考虑不同的请求在不同的时许下处理可能产生的影响
5）举例。和测试用例的设计有点类似，尽可能覆盖全面
JSON-RPC 2.0 Specification
㈣ 以太坊event log查询与解析
从 ethereum json-rpc文档 的文档中找到一个同时指定多个事件以 OR 或者 AND 查询的方法.以下是查询 Approval 或 Transfer 事件的方法：
topics 字段中指定查询条件的语法参考上面链接。
通过 getTransactionReceipt 在ropsten测试网上查询到交易号为 的交易详情
这个交易从 "from": "" 发送到合约地址 "to": "" .这个合约为ERC20代币合约.从 topics 的第一个元素可以看出合约中产生了 Transfer 事件(topics第一个元素一定是事件的keccak哈希). topics 的第二个字段是转出代币的地址，第三个字段是接收者地址.ERC20代币 Transfer 事件的签名为
我们注意到 Transfer 事件的第一个和第二个参数被标记为 indexed , 因此他们的值被放在 topics array 中. 由于tokens参数没有标记为 indexed , 所以他的值被放在 data 字段. 如果事件中有多个字段未标记为 indexed ， 那么他们的值都会被记录在 data 字段中。
㈤ 以太坊如何使用web3.js或者rpc接口获取交易数据交易时间与确认数
如果要查询主网上的交易记录，可以使用etherscan。但是，如果是你自己搭建的私链，应该如何查询交易记录呢？
答案是你需要自己监听链上的日志，存到数据库里，然后在这个数据库中查询。例如：
varaddr=""
varfilter=web3.eth.filter({fromBlock:0,toBlock:'latest',address:addr});
filter.get(function(err,transactions){
transactions.forEach(function(tx){
vartxInfo=web3.eth.getTransaction(tx.transactionHash);
//这时可以将交易信息txInfo存入数据库
});
});
web3.eth.filter()用来监听链上的日志，web3.eth.getTransaction()用来提取指定交易的信息，一旦获得交易信息，就可以存入数据库供查询用了。
推荐一个实战入门，你可以看看：以太坊教程
㈥ Php如何调用以太坊接口
curl方法，file_get_contents,
㈦ Infura API 获取以太坊当前配置链 ID - 区块链数据开发实战
简介：Infura 是以太坊和 IPFS 的 API 服务提供商。Infura 一开始只是为 ConsenSys 内部项目提供稳定可靠的 RPC 访问，后来随着以太坊生态发展，他们意识到自己可以起到更大作用，于是开始面向开发者提供公共 API 服务。本文整理使用 Infura API 获取以太坊当前配置链 ID 的实现。
Infura 是以太坊和 IPFS 的 API 服务提供商。Infura 一开始只是为 ConsenSys 内部项目提供稳定可靠的 RPC 访问，后来随着以太坊生态发展，他们意识到自己可以起到更大作用，于是开始面向开发者提供公共 API 服务。
本文整理使用 Infura API 获取以太坊当前配置链 ID 的实现。
Infura API 官方文档： https://infura.io/docs
使用 API 需要申请 Project ID ，ID 是免费申请的，申请流程为“注册 - 登录 - 创建新项目”，不需要审核，几分钟就能搞定。
Infura API 标准请求端口格式：
本例中我们使用基于 HTTP 的以太坊主网 JSON-RPC 端口：
Infura API 获取以太坊当前配置链 ID：
Curl 示例：
Node.js 示例：
返回的 JSON 示例：
返回当前链 ID 的大整数。
Infura API 服务思维导图：
我们有一个区块链知识星球，做区块链前沿资料的归纳整理以方便大家检索查询使用，也是国内顶尖区块链技术社区，欢迎感兴趣的朋友加入。如果你对上面内容有疑问，也可以加入知识星球提问我：