以太坊rpc接口配置
Ⅰ Quorum介绍
Quorum和以太坊的主要区别:
Quorum 的主要组件：
1,用其自己实现的基于投票机制的共识方式 来代替原来的 “Proof of work” 。
2,在原来无限制的P2P传输方式上增加了权限功能。使得P2P传输只能在互相允许的节点间传输。
3, 修改区块校验逻辑使其能支持 private transaction。
4, Transaction 生成时支持 transaction 内容的替换。这个调整是为了能支持联盟中的私有交易。
Constellation 模块的主要职责是支持 private transaction。Constellation 由两部分组成：Transaction Manager 和 Enclave。Transaction Manager 用来管理和传递私有消息，Enclave 用来对私有消息的加解密。
在私有交易中，Transaction Manager 会存储私有交易的内容，并且会将这条私有交易内容与其他相关的 Transaction Manager 进行交互。同时它也会利用 Enclave 来加密或解密其收到的私有交易。
为了能更有效率的处理消息的加密与解密，Quorum 将这个功能单独拉出并命名为 Enclave 模块。Enclave 和 Transaction Manager 是一对一的关系。
在 Quorum 中有两种交易类型，”Public Transaction” 和 “Privat Transaction”。在实际的交易中，这两种类型都采用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基础上添加了一个新的 “privateFor” 字段。同时，针对一个 tx 类型的对象添加了一个新的方法 “IsPrivate”。用 “IsPrivate” 方法来判断 Transaction是 public 还是 private，用 “privateFor” 来记录 事务只有谁能查看。
Public Transaction 的机理和以太坊一致。Transaction中的交易内容能被链上的所有人访问到。
Private Transaction 虽然被叫做 “Private”，但是在全网上也会出现与其相关的交易。只不过交易的明细只有与此交易有关系的成员才能访问到。在全网上看到的交易内容是一段hash值，当你是交易的相关人员时，你就能利用这个hash值，然后通过 Transaction Manager 和 Enclave 来获得这笔交易的正确内容。
Public Transaction的处理流程和以太坊的Transaction流程一致。Transaction 广播全网后，被矿工打包到区块中。节点收到区块并校验区块中的 事务 信息。然后根据 Transaction信息更新本地的区块
Private Transaction也会将 Transaction 广播至全网。但是它的 Transaction payload已经从原来的真实内容替换为一个hash值。这个hash值是由Transaction Manager提供的。
有两个共识机制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都采用了 QuorumChain。
从 2.0 版本开始，Quorum 废弃了 QuorumChain 转而只支持 Raft-based Consensus。
QuorumChain Consensus 是一个基于投票的共识算法。其主要特点有：
相比较以太坊的POW，Raft-based 提供了更快更高效的区块生成方式。相比 QuorumChain，Raft-based 不会产生空的区块，而且在区块的生成上比前者更有效率。
要想了解Raft-based Consensus，必须先了解Raft算法
Raft算法
Raft是一种一致性算法，是为了确保容错性，也就是即使系统中有一两个服务器当机，也不会影响其处理过程。这就意味着只要超过半数的大多数服务器达成一致就可以了，假设有N台服务器，N/2 +1 就超过半数，代表大多数了。
Raft的工作模式：
raft的工作模式是一个Leader和多个Follower模式，即我们通常说的领导者-追随者模式。除了这两种身份，还有Candidate身份。下面是身份的转化示意图
1，leader的选举过程
raft初始状态时所有server都处于Follower状态，并且随机睡眠一段时间，这个时间在0~1000ms之间。最先醒来的server A进入Candidate状态，Candidate状态的server A有权利发起投票，向其它所有server发出投票请求，请求其它server给它投票成为Leader。
2，Leader产生数据并同步给Follower
Leader产生数据，并向其它Follower节点发送数据添加请求。其它Follower收到数据添加请求后，判断该append请求满足接收条件（接收条件在后面安全保证问题3给出），如果满足条件就将其添加到本地，并给Leader发送添加成功的response。Leader在收到大多数Follower添加成功的response后。提交后的log日志就意味着已经被raft系统接受，并能应用到状态机中了。
Leader具有绝对的数据产生权利，其它Follower上存在数据不全或者与Leader数据不一致的情况时，一切都以Leader上的数据为主，最终所有server上的日志都会复制成与Leader一致的状态。
Raft的动态演示： http://thesecretlivesofdata.com/raft/
安全性保证，对于异常情况下Raft如何处理：
1，Leader选举过程中，如果有两个FollowerA和B同时醒来并发出投票请求怎么办？
在一次选举过程中，一个Follower只能投一票，这就保证了FollowerA和B不可能同时得到大多数（一半以上）的投票。如果A或者B中其一幸运地得到了大多数投票，就能顺利地成为Leader，Raft系统正常运行下去。但是A和B可能刚好都得到一半的投票，两者都成为不了Leader。这时A和B继续保持Candidate状态，并且随机睡眠一段时间，等待进入到下一个选举周期。由于所有Follower都是随机选择睡眠时间，所以连续出现多个server竞选的概率很低。
2，Leader挂了后，如何选举出新的Leader？
Leader在正常运行时候，会周期性的向Follower节点发送数据的同步请求，同时也是起到一个心跳作用。Follower节点如果在一段时间之内（一般是2000ms左右）没有收到数据同步请求，则认为Leader已经死了，于是进入到Candidate状态，开始发起投票竞选新的Leader，每个新的Leader产生后就是一个新的任期，每个任期都对应一个唯一的任期号term。这个term是单调递增的，用来唯一标识一个Leader的任期。投票开始时，Candidate将自己的term加1，并在投票请求中带上term；Follower只会接受任期号term比自己大的request_vote请求，并为之投票。 这条规则保证了只有最新的Candidate才有可能成为Leader。
3，Follower的数据的生效时间
Follower在收到一条添加数据请求后，是否立即保存并将其应用到状态机中去？如果不是立即应用，那么由什么来决定该条日志生效的时间？
首先会检查这条数据同步请求的来源信息是否与本地保存的leader信息符合，包括leaderId和任期号term。检查合法后就将日志保存到本地中，并给Leader回复添加log成功，但是不会立即将其应用到本地状态机。Leader收到大部分Follower添加log成功的回复后，就正式将这条日志commit提交。Leader在随后发出的心跳append_entires中会带上已经提交日志索引。Follower收到Leader发出的心跳append_entries后，就可以确认刚才的log已经被commit(提交)了，这个时候Follower才会把日志应用到本地状态机。下表即是append_entries请求的内容，其中leaderCommit即是Leader已经确认提交的最大日志索引。Follower在收到Leader发出的append_entries后即可以通过leaderCommit字段决定哪些日志可以应用到状态机。
4，向raft系统中添加新机器时，由于配置信息不可能在各个系统上同时达到同步状态，总会有某些server先得到新机器的信息，有些server后得到新机器的信息。比如在raft系统中有三个server，在某个时间段中新增加了server4和server5这两台机器。只有server3率先感知到了这两台机器的添加。这个时候如果进行选举，就有可能出现两个Leader选举成功。因为server3认为有3台server给它投了票，它就是Leader，而server1认为只要有2台server给它投票就是Leader了。raft怎么解决这个问题呢？
产生这个问题的根本原因是，raft系统中有一部分机器使用了旧的配置，如server1和server2，有一部分使用新的配置，如server3。解决这个问题的方法是添加一个中间配置(Cold, Cnew)，这个中间配置的内容是旧的配置表Cold和新的配置Cnew。这个时候server3收到添加机器的消息后，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)来做决策。比如说server3在竞选Leader的时候，不仅需要得到Cold中的大部分投票，还要得到Cnew中的大部分投票才能成为Leader。这样就保证了server1和server2在使用Cold配置的情况下，还是只可能产生一个Leader。当所有server都获得了添加机器的消息后，再统一切换到Cnew。raft实现中，将Cold，(Cold,Cnew)以及Cnew都当成一条普通的日志。配置更改信息发送Leader后，由Leader先添加一条 (Cold, Cnew)日志，并同步给其它Follower。当这条日志(Cold, Cnew)提交后，再添加一条Cnew日志同步给其它Follower，通过Cnew日志将所有Follower的配置切换到最新。
Raft算法和以太坊结合
所以为了连接以太坊节点和 Raft 共识，Quorum 采用了网络节点和 Raft 节点一对一的方式来实现 Raft-based 共识
一个Transaction完整流程
1，客户端发起一笔 Transaction并通过 RPC 来呼叫节点。
2，节点通过以太坊的 P2P 协议将节点广播给网络。
3，当前的 Raft leader 对应的以太坊节点收到了 Transaction后将它打包成区块。
区块被 编码后传递给对应的 Raft leader。
leader 收到区块后通过 Raft 算法将区块传递给 follower。这包括如下步骤：
3.1，leader 发送 AppendEntries 指令给 follower。
3.2，follower 收到这个包含区块信息的指令后，返回确认回执给 leader。
3.3，leader 收到不少于指定数量的确认回执后，发送确认 append 的指令给 follower。
3.4，follower 收到确认 append 的指令后将区块信息记录到本地的 Raft log 上。
3.5，Raft 节点将区块传递给对应的 Quorum 节点。Quorum 节点校验区块的合法性，如果合法则记录到本地链上。
参考链接： http://blog.csdn.net/about_blockchain/article/details/78684901
Ⅱ 以太坊如何使用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()用来提取指定交易的信息，一旦获得交易信息，就可以存入数据库供查询用了。
推荐一个实战入门，你可以看看：以太坊教程
Ⅲ 以太坊stratum协议原理
参照比特币的 stratum协议 和 NiceHash的stratum协议规范 编写了一版以太坊版本的stratum协议说明.
stratum协议是目前最常用的矿机和矿池之间的TCP通讯协议。
以太坊是一个去中心化的网络架构，通过安装Mist客户端的节点来转发新交易和新区块。而矿机、矿池也同时形成了另一个网络，我们称之为矿工网络。
矿工网络分成矿机、矿池、钱包等几个主要部分，有时矿池软件与钱包安装在一起，可合称为矿池。
矿机与矿池软件之间的通讯协议是 stratum ，而矿池软件与钱包之间的通讯是 bitcoinrpc 接口。
stratum是 JSON 为数据格式.
矿机启动，首先以 mining.subscribe 方法向矿池连接，用来订阅工作。
矿池以 mining.notify 返回订阅号、ExtraNonce1和ExtraNonce2_size。
Client:
Server:
其中：
是 订阅号 ；
080c是 extranonce ，Extranonce可能最大3字节；
矿机以 mining.authorize 方法，用某个帐号和密码登录到矿池，密码可空，矿池返回 true 登录成功。该方法必须是在初始化连接之后马上进行，否则矿机得不到矿池任务。
Client:
Server:
难度调整由矿池下发给矿机，以 mining.set_difficulty 方法调整难度， params 中是难度值。
Server:
矿机会在下一个任务时采用新难度，矿池有时会马上下发一个新任务并且把清理任务设为true，以便矿机马上以新难度工作。
该命令由矿池定期发给矿机，当矿机以 mining.subscribe 方法登记后，矿池应该马上以 mining.notify 返回该任务。
Server:
任务ID ： bf0488aa ；
seedhash ： 。每一个任务都发送一个seedhash来支持尽可能多的矿池，这可能会很快地在货币之间交换。
headerhash : 。
boolean cleanjobs : true 。如果设为true，那么矿工需要清理任务队列，并立即开始从事新提供的任务，因为所有旧的任务分享都将导致陈旧的分享错误。如果是 false 则等当前任务结束才开始新任务。
矿工使用seedhash识别DAG，然后带着headerhash,extranonce和自己的minernonce寻找低于目标的share(这是由提供的难度而产生的)。
矿机找到合法share时，就以” mining.submit “方法向矿池提交任务。矿池返回true即提交成功，如果失败则error中有具体原因。
Client:
任务ID : bf0488aa
minernonce : 6a909d9bbc0f 。注意minernonce是6个字节，因为提供的extranonce是2个字节。如果矿池提供3字节的extranonce，那么minernonce必须是5字节
Server:
一般的矿机与矿池通讯过程就如下所示：
Ⅳ 如何开发数字货币
谢邀~
为何要开发数字货币?从中央银行的角度来看有6个好处：
第一、提升经济交易活动的便利性和透明度
第二、降低传统纸币发行、流通的高昂成本
第三、更好地支持经济和社会发展
第四、助力普惠金融的全面实现
第五、 减少洗钱、逃漏税等违法犯罪行为
第六、提升央行对货币供给和货币流通的控制力
数字货币开发步骤：
第一步、
首先我们要从git 上下载某套区块链体系的源码,比如选择比特币的主干代码下载好
相关源码。
同时准备好对应的编译环境(C + +的建议在Linux)和安装好对应开发环境和工具。
第二步、
代码都是需要编译的,因此需要准备编译环境和工具,需要下载环境编译工具、配
好系统环境变量, qt环境等文件,编译命令在Itc源代码里的文件里有详细说明。
不过系统和开发环境的搭建、程序编译等过程都比较繁琐,不建议普通用户自己制作。对于开发人员,第一次可能要预计2-3天的安装配置时间。
第三步、
拿比特币开发来说,他是Q的开发环境，下载好源码并配置好环境后,在QtCreator内打开该比特币核心的源码,配置相关文件和编译器,开始尝试编译比特币核心的客户端。
第四步、
改造成自己的数字货币，打开各个源文件,找到对应的地方调整参数即可,如调整
每个区块出币数,总产量,调整难度等等,然后就到最关键的点,就是改名为自己的币名。
想怎么取名就怎么取名,别忘记在资源文件夹里替换掉相关图标。如果一切顺利,经过重新
编译,你的新币就顺利发明了。
对于这个数字货币的开发,还是属于技术比较专业的,因此最好有-个专业的团队协助。
数字货币开发大致需要学习的框架：
1、搭建以太坊私链测试环境以及公链节点环境配置
2、以太坊中以太币的交易、确认原理
3、以太坊中json rpc接口
4、以太币转账与提现原理
5、服务器对接以太坊公链接口，自有服务器存储业务数据，公链存储交易可匿名数据
6、私钥的安全处理
以下是开发的代码示例：
举例下市场上常用的数字货币钱包有：
APP类：kcash、imtokenweb：myEthereumWalletgoogle 浏览器插件：metaMask
其中最常用的就是imToken
区块链交易技术概念：
让我们来看看区块链交易是如何以比特币为例进行处理的。为了将一定数量的比特币发送到另一个钱包，您需要以下信息：将资金发送到您的钱包的地址，您想要发送的加密货币数量
接收者的钱包的ID。
每笔交易都使用唯一的机密私人密钥进行签名。一旦付款由发件人签署，它就变为公开可用。交易仍需要确认，以便收款人可以得到这笔钱为了确认交易，有必要生成一个新的链条块。
这些块是通过进行复杂的数学计算来找到唯一的密钥而生成的。创建一个新块需要10分钟，找到该密钥的人获得一定数量的硬币作为奖励。一旦创建了链的新块，就不可能将其从数据库中删除或以某种方式更改信息。因此，区块链交易是最终且不可逆的。
数字货币的三大核心优点：
第一点、数字货币是公平的货币
数字货币没有特定的发行机构，不是由某一国家发行的，仅仅是依靠特定算法产生的，这就意味着无法通过操纵发行数量来操纵数字货币，因此数字货币是一种自由的、非国家的货币。
我们可以看到现在有许多国家是直接认可了虚拟货币，那么有需求，就需要交易的平台。
我们现在许多想搭建虚拟货币交易平台的投资者，为什么不能去这些地区搭建交易平台呢?搭建虚拟货币交易平台，这不就是一个很好的商机吗?
第二点、数字货币的安全系数更高
纸币的出现虽然方便了我们日常生活中的交易，但是会有被偷盗以及收到的风险。电子货币虽然可以避免这些风险，但是会出现诸如被盗刷、等新的问题。
数字货币则可以避免以上问题。并且将每一笔交易记录在网络上进行广播，是的所有节点都保存全部货币的流通信息，这样任意一个节点在交易之前就可以轻易地发现货币的流通。
第三点、数字货币的交易可以实现匿名交易
由于没有传统银行开户和身份认证的过程，数字货币是纯匿名的。虽然可以根据本地完整的交易记录查询到每个账号的流水信息。
但却无法知道这个账号的主人是谁，同样也没有任何人有能力操纵他人账号上的数字货币，这样很好的保护了使用人的隐私。
如果您也在持有交易数字货币、外汇黄金原油、合约期货：
Ⅳ 以太坊多节点私有链部署
假设两台电脑A和B
要求：
1、两台电脑要在一个网络中，能ping通
2、两个节点使用相同的创世区块文件
3、禁用ipc;同时使用参数--nodiscover
4、networkid要相同，端口号可以不同
1.4 搭建私有链
1.4.1 创建目录和genesis.json文件
创建私有链根目录./testnet
创建数据存储目录./testnet/data0
创建创世区块配置文件./testnet/genesis.json
1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json
1.4.3 启动私有节点
1.4.4 创建账号
personal.newAccount()
1.4.5 查看账号
eth.accounts
1.4.6 查看账号余额
eth.getBalance(eth.accounts[0])
1.4.7 启动&停止挖矿
启动挖矿：
miner.start(1)
其中 start 的参数表示挖矿使用的线程数。第一次启动挖矿会先生成挖矿所需的 DAG 文件，这个过程有点慢，等进度达到 100% 后，就会开始挖矿，此时屏幕会被挖矿信息刷屏。
停止挖矿，在 console 中输入：
miner.stop()
挖到一个区块会奖励5个以太币，挖矿所得的奖励会进入矿工的账户，这个账户叫做 coinbase，默认情况下 coinbase 是本地账户中的第一个账户，可以通过 miner.setEtherbase() 将其他账户设置成 coinbase。
1.4.8 转账
目前，账户 0 已经挖到了 3 个块的奖励，账户 1 的余额还是0：
我们要从账户 0 向账户 1 转账，所以要先解锁账户 0，才能发起交易：
发送交易，账户 0 -> 账户 1：
需要输入密码 123456
此时如果没有挖矿，用 txpool.status 命令可以看到本地交易池中有一个待确认的交易，可以使用 eth.getBlock("pending", true).transactions 查看当前待确认交易。
使用 miner.start() 命令开始挖矿：
miner.start(1);admin.sleepBlocks(1);miner.stop();
新区块挖出后，挖矿结束，查看账户 1 的余额，已经收到了账户 0 的以太币：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')
用同样的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json
启动私有节点一,修改 rpcport 和port
可以通过 admin.addPeer() 方法连接到其他节点，两个节点要要指定相同的 chainID。
假设有两个节点：节点一和节点二，chainID 都是 1024，通过下面的步骤就可以从节点二连接到节点一。
首先要知道节点一的 enode 信息，在节点一的 JavaScript console 中执行下面的命令查看 enode 信息：
admin.nodeInfo.enode
" enode://@[::]:30303 "
然后在节点二的 JavaScript console 中执行 admin.addPeer()，就可以连接到节点一：
addPeer() 的参数就是节点一的 enode 信息，注意要把 enode 中的 [::] 替换成节点一的 IP 地址。连接成功后，节点一就会开始同步节点二的区块，同步完成后，任意一个节点开始挖矿，另一个节点会自动同步区块，向任意一个节点发送交易，另一个节点也会收到该笔交易。
通过 admin.peers 可以查看连接到的其他节点信息，通过 net.peerCount 可以查看已连接到的节点数量。
除了上面的方法，也可以在启动节点的时候指定 --bootnodes 选项连接到其他节点。 bootnode 是一个轻量级的引导节点，方便联盟链的搭建 下一节讲 通过 bootnode 自动找到节点
参考： https://cloud.tencent.com/developer/article/1332424
Ⅵ 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 服务思维导图：
我们有一个区块链知识星球，做区块链前沿资料的归纳整理以方便大家检索查询使用，也是国内顶尖区块链技术社区，欢迎感兴趣的朋友加入。如果你对上面内容有疑问，也可以加入知识星球提问我：
Ⅶ 如何使用 Etherscan 的 API
虽然以太坊提供了 Web3 和 Json Rpc 这 2 种 API，geth 也额外提供了一些 API ，但是对于开发以太坊应用来说还是显得有些不足，比如说获取交易记录的时间，需要先通过交易的 hash 找到该交易对应的区块 id，然后才能找到对应的时间，查询起来相当不方便。
好在 Etherscan 对外提供了一些公共的 API，给我们提供了额外的能力来处理更多的业务场景。
为了方便开发人员更好地使用 ethersacn.io ，网站提供了 一系列 API 供开发人员使用。
API 的使用非常简单，基本上都是 get 方法，通过 http 请求就可以直接调用，在每个 Api 的说明文档都有对应的例子可以查看。
API 主要包含以下模块：账号、智能合约、交易、区块、事件日志、代币及工具等。
账号相关的 API，有获取账号金额，获取交易记录等，该模块提供的 API 最多。
API 示例
https://api.etherscan.io/api?mole)=account&action=balance&address=&tag=latest&apikey=YourApiKeyToken
参数说明
其中 mole、action、apikey 是每个 API 都有的参数，其他的参数则因不同 API 而不同。
返回结果
API 示例
https://api.etherscan.io/api?mole=account&action=balancemulti&address=,,&tag=latest&apikey=YourApiKeyToken
参数说明
（前面有讲过的参数就不讲了，下同）
与单个账号金额 API 相比，参数 address 用 , 号分隔多个账号，最多可支持 20 个账号的金额查询。
返回结果
API 示例
https://api.etherscan.io/api?mole=account&action=txlist&address=&startblock=0&endblock=99999999&page=1&offset=10&sort=asc&apikey=YourApiKeyToken
参数说明
返回结果
API 示例
https://api.etherscan.io/api?mole=account&action=txlistinternal&address=&startblock=0&endblock=2702578&page=1&offset=10&sort=asc&apikey=YourApiKeyToken
参数说明
参数与上一个 API 基本相同，只有 action 是 txlistinternal 这一点不同，这 2 种交易的区别是什么呢？简单的理解就是“正常”的交易是会记录到区块链上的，而“内部”交易是指不会记录到区块链上的记录，比如交易失败的记录。
另外这个 API 还可以通过交易 hash 查看交易的详情。
https://api.etherscan.io/api?mole=account&action=txlistinternal&txhash=&apikey=YourApiKeyToken
返回结果
API 示例
参数说明
返回结果
API 示例
参数说明
返回结果
智能合约相关的 API，其实只有一个获取智能合约接口的 API，但是这个 API 非常有用。
API 示例
参数说明
智能合约的 abi 就是一个 json 对象，通过这个对象我们可以调用其接口方法，后面会写一篇文章介绍如何操作 abi 对象，敬请期待。
返回结果
返回结果内容比较长，这里省略，就是一个 json 对象，感兴趣的可以自行调用该 API 看结果。
账号和智能合约的 API 已经能满足大部分的业务需求了，其他模块的 API 感觉没什么太大的作用，这里就不介绍了，感兴趣的读者可以自行查阅。
这里再说下 API 的使用限制，刚才提到每个 API 都有一个 apikey 参数，如果 API 没加上这个参数的话，每个 API 的请求次数不能超过 5 次每秒。
Etherscan 提供的这些 API 有些是和以太坊提供的 API 有重复的，比如说获取账号金额，获取事件日志记录等，但有一些 API 给我们带来了很大的便利性，比如获取账号交易记录，有了这个 API 就不用使用几个原生 API 进行各种数据拼接了。
另外 Etherscan 的这套 API 在 Rinkeby 测试网络也有一套一模一样的，区别只是前面的 url 不同，Rinkeby 的是： api-rinkeby.etherscan.io ，感兴趣的同学可以去试试。
Ⅷ 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
Ⅸ 一学就会，手把手教你用Go语言调用智能合约
智能合约调用是实现一个 DApp 的关键，一个完整的 DApp 包括前端、后端、智能合约及区块 链系统，智能合约的调用是连接区块链与前后端的关键。
我们先来了解一下智能合约调用的基础原理。智能合约运行在以太坊节点的 EVM 中。因此要 想调用合约必须要访问某个节点。
以后端程序为例，后端服务若想连接节点有两种可能，一种是双 方在同一主机，此时后端连接节点可以采用 本地 IPC(Inter-Process Communication，进 程间通信)机制，也可以采用 RPC(Remote Procere Call，远程过程调用)机制;另 一种情况是双方不在同一台主机，此时只能采用 RPC 机制进行通信。
提到 RPC， 读者应该对 Geth 启动参数有点印象，Geth 启动时可以选择开启 RPC 服务，对应的 默认服务端口是 8545。。
接着，我们来了解一下智能合约运行的过程。
智能合约的运行过程是后端服务连接某节点，将 智能合约的调用(交易)发送给节点，节点在验证了交易的合法性后进行全网广播，被矿工打包到 区块中代表此交易得到确认，至此交易才算完成。
就像数据库一样，每个区块链平台都会提供主流 开发语言的 SDK(Software Development Kit，软件开发工具包)，由于 Geth 本身就是用 Go 语言 编写的，因此若想使用 Go 语言连接节点、发交易，直接在工程内导入 go-ethereum(Geth 源码) 包就可以了，剩下的问题就是流程和 API 的事情了。
总结一下，智能合约被调用的两个关键点是节点和 SDK。
由于 IPC 要求后端与节点必须在同一主机，所以很多时候开发者都会采用 RPC 模式。除了 RPC，以太坊也为开发者提供了 json- rpc 接口，本文就不展开讨论了。
接下来介绍如何使用 Go 语言，借助 go-ethereum 源码库来实现智能合约的调用。这是有固定 步骤的，我们先来说一下总体步骤，以下面的合约为例。
步骤 01:编译合约，获取合约 ABI(Application Binary Interface，应用二进制接口)。 单击【ABI】按钮拷贝合约 ABI 信息，将其粘贴到文件 calldemo.abi 中(可使用 Go 语言IDE 创建该文件，文件名可自定义，后缀最好使用 abi)。
最好能将 calldemo.abi 单独保存在一个目录下，输入“ls”命令只能看到 calldemo.abi 文件，参 考效果如下:
步骤 02:获得合约地址。注意要将合约部署到 Geth 节点。因此 Environment 选择为 Web3 Provider。
在【Environment】选项框中选择“Web3 Provider”，然后单击【Deploy】按钮。
部署后，获得合约地址为:。
步骤 03:利用 abigen 工具(Geth 工具包内的可执行程序)编译智能合约为 Go 代码。abigen 工具的作用是将 abi 文件转换为 Go 代码，命令如下:
其中各参数的含义如下。 (1)abi:是指定传入的 abi 文件。 (2)type:是指定输出文件中的基本结构类型。 (3)pkg:指定输出文件 package 名称。 (4)out:指定输出文件名。 执行后，将在代码目录下看到 funcdemo.go 文件，读者可以打开该文件欣赏一下，注意不要修改它。
步骤 04:创建 main.go，填入如下代码。 注意代码中 HexToAddress 函数内要传入该合约部署后的地址，此地址在步骤 01 中获得。
步骤 04:设置 go mod，以便工程自动识别。
前面有所提及，若要使用 Go 语言调用智能合约，需要下载 go-ethereum 工程，可以使用下面 的指令:
该指令会自动将 go-ethereum 下载到“$GOPATH/src/github.com/ethereum/go-ethereum”，这样还算 不错。不过，Go 语言自 1.11 版本后，增加了 mole 管理工程的模式。只要设置好了 go mod，下载 依赖工程的事情就不必关心了。
接下来设置 mole 生效和 GOPROXY，命令如下:
在项目工程内，执行初始化，calldemo 可以自定义名称。
步骤 05:运行代码。执行代码，将看到下面的效果，以及最终输出的 2020。
上述输出信息中，可以看到 Go 语言会自动下载依赖文件，这就是 go mod 的神奇之处。看到 2020，相信读者也知道运行结果是正确的了。
Ⅹ 以太坊的 ChainId 与 NetworkId
ChainId 是 EIP-155 引入的一个用来区分不同 EVM 链的一个标识。如下图所示，主要作用就是避免一个交易在签名之后被重复在不同的链上提交。最开始主要是为了防止以太坊交易在以太经典网络上重放或者以太经典交易在以太坊网络上重放。在以太坊网络上是从 2675000 这个区块通过 Spurious Dragon 这个硬分叉升级激活。
引入 ChainId 后，带来了哪些影响呢？
NetworkId 主要用来在网络层标识当前的区块链网络。NetworkId 不一致的两个节点无法建立连接。
NetworkId 无法通过配置文件指定，智能通过参数 --networkid 来指定。所以我们启动自己私链节点上需要记得加上这个参数。如果不加这个参数也不指定网络类型，默认 NetworkId 的值和以太坊主网一致。
不是。
这个根据上面的介绍可以很明显的看出，两者并没有非常高的关联度。
网上几乎所有提到搭建以太坊私链的文章，都要强调 NetworkId 需要和 genesis 文件里 ChainId 的值相同。事实上是没必要的。
就像下面这张图展示的这样，很多已经在主网运行的 EVM 链，它们的 ChainId 和 NetworkId 并不相同。比如以太经典，它的 ChainId 是 61，但 NetworkId 和以太坊主网一样都是 1。
之所以很多文章强调 ChainId 和 NetworkId 要保持一致，可能因为在某一段时间内，一些开发工具比如 MetaMask，会把 NetworkId 当作 ChainId 来用。不过现在 MetaMask 已经支持自定义 ChainId，以太坊也添加了 “eth_chainId” 这个 RPC API，相信两者误用的情况会越来越少。