ethtxhash

Ⅰ 【ETH钱包开发03】web3j转账ETH

在之前的文章中，讲解了创建、导出、导入钱包。
【ETH钱包开发01】创建、导出钱包
【ETH钱包开发02】导入钱包

本文主要讲解以太坊转账相关的一些知识。交易分为ETH转账和ERC-20 Token转账，本篇先讲一下ETH转账。

1、解锁账户发起交易。钱包keyStore文件保存在geth节点上，用户发起交易需要解锁账户，适用于中心化的交易所。

2、钱包文件离线签名发起交易。钱包keyStore文件保存在本地，用户使用密码+keystore的方式做离线交易签名来发起交易，适用于dapp，比如钱包。

本文主要讲一下第二种方式，也就是钱包离线签名转账的方式。

交易流程
1、通过keystore加载转账所需的凭证Credentials
2、创建一笔交易RawTransaction
3、使用Credentials对象对交易签名
4、发起交易

注意以下几点：

1、Credentials
这里，我是通过获取私钥的方式来加载 Credentials

还有另外一种方式，通过密码+钱包文件keystore方式来加载 Credentials

2、nonce

nonce是指发起交易的账户下的交易笔数，每一个账户nonce都是从0开始，当nonce为0的交易处理完之后，才会处理nonce为1的交易，并依次加1的交易才会被处理。

可以通过 eth_gettransactioncount 获取nonce

3、gasPrice和gasLimit
交易手续费由gasPrice 和gasLimit来决定，实际花费的交易手续费是 gasUsed * gasPrice 。所有这两个值你可以自定义，也可以使用系统参数获取当前两个值

关于 gas ，你可以参考我之前的一篇文章。
以太坊（ETH）GAS详解

gasPrice和gasLimit影响的是转账的速度，如果gas过低，矿工会最后才打包你的交易。在app中，通常给定一个默认值，并且允许用户自己选择手续费。

如果不需要自定义的话，还有一种方式来获取。获取以太坊网络最新一笔交易的 gasPrice ,转账的话， gasLimit 一般设置为21000就可以了。

Web3j还提供另外一种简单的方式来转账以太币,这种方式的好处是不需要管理nonce，不需要设置gasPrice和gasLimit，会自动获取最新一笔交易的gasPrice，gasLimit 为21000（转账一般设置成这个值就够用了）。

这个问题，我想是很多朋友所关心的吧。但是到目前为止，我还没有看到有讲解这方面的博客。

之前问过一些朋友，他们说可以通过区块号、区块哈希来判断，也可以通过Receipt日志来判断。但是经过我的一番尝试，只有 BlockHash 是可行的，在web3j中根据 blocknumber 和 transactionReceipt 都会报空指针异常。

原因大致是这样的：在发起一笔交易之后，会返回 txHash ，然后我们可以根据这个 txHash 去查询这笔交易相关的信息。但是刚发起交易的时候，由于手续费问题或者以太网络拥堵问题，会导致你的这笔交易还没有被矿工打包进区块，因此一开始是查不到的，通常需要几十秒甚至更长的时间才能获取到结果。我目前的解决方案是轮询的去刷 BlockHash ，一开始的时候 BlockHash 的值为0x00000000000，等到打包成功的时候就不再是0了。

这里我使用的是rxjava的方式去轮询刷的，5s刷新一次。

正常情况下，几十秒内就可以获取到区块信息了。

区块确认数=当前区块高度-交易被打包时的区块高度。

Ⅱ linux 内核软中断 是在中断状态吗

先说说环境
1.硬件:DELL R410
2.网卡:板载1000M BCM5709
2.OS: RHEL 5.5 x86_64
3.KERNEL: 2.6.18-194.el5
所出现的问题
1.网卡毫无征兆的down掉，而且没有任何log信息
2.当流量增大时，不到理论上限的1/3时机器出现网络延迟严重，伴随大量的丢包
3.机器的cpu软中断不均衡，只有1个cpu处理软中断，并且该cpu的软中断周期性的达到100%
4.内外网网卡做nat丢包数据量不一致，差别很大，不在同一个数量级
想必第一个问题，大部分使用bcm网卡，rhel 5.3以后得机器都会遇到这种情况，网上的资料比较的多，我也不多啰嗦了，直接升级网卡驱动就可以解决了。第二，三，四其实是同一个问题都是由于网卡中断过多，cpu处理不过来(准确的说，cpu分配不均衡，导致只有一个cpu处理，处理不过来)，引起丢包，那么为什么两个网卡丢包的数量级不一样呢，下面从原理上进行解释，既然是做nat多出口，那么就有大量的路由信息，是一个网络应用，当一个数据包请求nat时，数据包先被网卡驱动的数据接收，网卡收到数据时，触发中断。在中断执行例程中，把skb挂入输入队列，并触发软中断。稍后的某个时刻，当软中断执行时，再从该队列中把skb取下来，投递给上层协议。
如果在这个过程当中cpu没有及时处理完这个队列导致网卡的buffer满了，网卡将直接丢弃该数据包。这里牵涉到2个队列，一个是tx，一个是rx，它的队列的大小默认都是255，可以通过ethtool -g eth0(你指定的网卡)，为了防止丢包，当时我通过ethtool -G eth0 rx xxx 把它调大了，但是调大以后，还是杯水车薪啊，通过ethtool -S eth0 |grep rx_fw_discards,发现数值还是不停的在增长，也就是说还在不停的丢包，cpu处理不过来，这时候找到网上有人在利用lvs时也遇到这个问题，cpu软中断分配不均衡，只有一个cpu处理软中断的问题，网上的资料五花八门，有建议使用修改设备中断方式。即通过修改设置中断/proc/irq/${网卡中断号}/smp_affinit这时候，我也修改过，没有什么实质的效果，
从官方的bug报告，https://bugzilla.redhat.com/show_bug.cgi?id=520888，其中提到rhel5.6已经修复了这个bug，这其中也提到目前我们的版本可以升级内核到kernel-2.6.18-194.3.1.el5可以解决这个问题。
红帽子官方修复报告中的说明如下：http://rhn.redhat.com/errata/RHSA-2010-0398.html，我们升级了这个内核算是解决单核处理软中断的问题，升级后各个cpu已经能够平均的分配这个软中断，也不丢包了，那么为什么cpu处理不过来这个软中断呢，数据量并不是特别的大啊，上层应用接到这个数据包后，通过路由协议，找到某个出口给nat出去，找nat出口是需要查找路由表，查询路由表是一件很耗时的工作，而每一个不同源地址，不同目的地址的数据包都得重新查找一次路由表，导致cpu处理不过来，为了提高路由查询的效率。Linux内核引用了路由缓存，用于减少对路由表的查询。Linux的路由缓存是被设计来与协议无关的独立子系统，查看路由缓存可以通过命令route -Cn,由于路由缓存当中是采用hash算法进行才找，它的查找速度非常之快，既然是cache就有超时这一概念。系统默认为10分钟，可以通过这个文件进行查看和修改/proc/sys/net/ipv4/route/secret_interval。而当路由缓存当中未找到或者已经超时的路由信息才开始查找路由表，查询到的结果保存在路由缓存中。如果路由表越大，那么查询的时间就越长，一个新的连接进来后或者是老连接cache超时后，占用大量的cpu查询时间，导致cpu周期性的软中断出现100%，而两个网卡丢包的情况来看不均衡也是因为用户的数据包是经过其中一个网卡进来后查询路由表耗时过长，cpu处理不过来，导致那块网卡的队列满了，丢包严重。当然在路由表变动不大的情况下可以加大cache的时间，修改上述内容后，从我监测的情况来看，扛流量能力得到了大大的提升。

Ⅲ 如何使用 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 ，感兴趣的同学可以去试试。

Ⅳ tx链怎么发币

1、首先打开以太坊官网下载一个钱包，下载完成后解压到本地打开这个文件度条是正在同步区块链。
2、其次同步完区块链数据后，点击LAUNCH APPLICPTION打开钱包创建一个ETH账户往里面充0.05个ETH就可以了。
3、然后创建一个合约然后在下图红圈圈起来的地方把原有的代码删除掉显示新创建的货币，确认完毕，再进入CONTRACTS（合约）页面，将看到刚才创建的代币进入SEND（发送）页面。
4、最后在右上角的红色方框中输入收款者的账户地址。在AMOUT中填写发送的数量，在右边的红色方框中选择要发送的货币。

Ⅳ ETH转账的2种方式的对比

web3j支持使用以太坊钱包文件（推荐）和以太网客户端管理命令来发起一笔交易。当你创建了一个拥有以太币的账户后，你可以通过以下两种交易机制，和以太坊网络（私网/公网）交易：

这里主要讲一下 线下签名交易（Offline transaction signing） 。线下签名交易允许你使用web3j提供的钱包账户发起交易，你完全控制自己的私钥，交易发送到网络上的其它节点并广播。

线下签名交易使用 RawTransaction 对象来完成，一共有如下几步：

1、通过私钥或密码+钱包文件（keystore）来加载转账凭证Credentials
2、获取发起转账账户的nonce 值，也就是第几笔交易
3、创建 RawTransaction交易 对象
4、签名 RawTransaction 对象，也就是对交易做签名
5、发送交易（ RawTransaction 对象）给节点处理。
6、获取交易哈希值TxHash

以太坊实战-再谈nonce使用陷阱： https://blog.csdn.net/wo541075754/article/details/79054937

此外，还有一种简单的转账方式

这种方式，不需要自己管理nonce。

这2种方式都是离线交易，先组装交易，然后发送到链上。

参考：
https://docs.web3j.io/getting_started.html#transactions
https://www.jianshu.com/p/6650d2a3aea9

Ⅵ 对区块链游戏是什么有价值吗

区块链游戏是什么？

目前对于区块链游戏的定义很多，比较公认的一个定义是的把核心数据写入区块链、基于链上数据作为随机数来源。比如之前的游戏中的货币是由游戏运营商决定，但是由于区块链的去中心化特点，货币之间的交易都是透明，并且交易数据都是同步到每一个玩家身上，那么这样一来，货币总量不变的情况下， 游戏获得货币会更具价值。

区块链能给游戏带来什么价值？

游戏资产的所有权和流通性

在区块链上，玩家可以拥有游戏内的资产，而这些资产则有更广泛意义上的流通性。传统游戏中的积分、道具、武器、角色往往全部归开发商所有，也因此中心化的开发商有更大的权力对这些资产进行大刀阔斧的改动，甚至随意处置。游戏内的这些资产往往也只能局限于这一个游戏内部进行流通，出了游戏之外，似乎毫无复用的价值，也从技术层面很难被再次赋予应用场景。

在区块链逻辑下，一旦游戏内的资产上链，这些积分、道具、武器、角色完全可以归属到玩家的区块链地址下面，玩家对于这个地址以及其下面的资产拥有所有权。那么我们可以设想若干个应用场景：

1.资产随时随地交易：大量的游戏是不具备道具交易功能的，当然这么设计很多时候的初衷是为了避免游戏内经济机制的混乱、延长用户游戏时间、增加开发商的收入。假设以上并不是开发者所担心的问题，那么“道具上链+移动钱包”可以实现两个用户随时随地在线上线下交易。你跟好友在吃饭时聊到最近的一个PC端游戏，打开手机钱包，看看彼此有什么样的武器装备，完成一笔交易的体验就像一次微信扫码支付一样简单，晚上回到家，打开PC登录游戏，交易完成的道具早已躺在了你的装备栏里。

2.游戏资产复用：资产上链后因为挂在每一个玩家的地址下，对于开发商来说可以轻松的复用其他游戏的资产进行二次改造或者实现跨游戏复用。SpiderStore有一个游戏叫CryptoCuddles，基于加密猫的猫咪战斗游戏，玩家用自己的以太坊地址登录，游戏就会自动获取到该地址下所有的加密猫咪，角色来自于加密猫，只有战斗逻辑来自于CryptoCuddles本身。

3.新的用户获取方式：传统游戏下，新的游戏往往需要重新获取用户，或者用老游戏给新游戏导流。区块链可以打破这种方式，降低获客成本，比如上述的CryptoCuddles，所有加密猫的用户都是潜在可以直接转换过来的游戏玩家。如果直接复用资产涉及到IP问题，开发商也可以这样设计，只要在加密猫拥有猫咪的用户，可以直接在这个游戏中直接获取一定的奖励，可以是角色、宝箱、道具等等，验证方式只需要用地址登录读取一下链上数据即可。

这样一来，一款新游戏上线完全可以借用现有爆款游戏的用户引流，这个玩法其实不就是分叉币发糖果、新代币空投的套路么？利用ETH或者EOS这类持币人数最大的币种，给持币人1：1空投自己的代币，从而非常低成本获取用户。

SpiderStore目前拥有2000多个游戏DApp下，累计几十万个玩过以太坊游戏的用户信息，如果新的一款游戏需要推广，最简单的就是给这些地址空投游戏资产，这可比传统的广告投放精准多。

Ⅶ 为什么ETH挖矿需要用这么大的显存

1、挖矿主要是使用高端3G显存以上显卡来挖矿。显卡通常搭载有4GB以上的物理显存，在大吞吐量计算时有很大的作用。
2、其中显卡决定挖矿的速度，主板、电源在很大程度上决定了矿机运行的稳定程度。

Ⅷ 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

Ⅸ 011：Ethash算法|《ETH原理与智能合约开发》笔记

待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此文集记录我的学习笔记。

课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。
第四课分为三部分：

这篇文章是第四课第一部分的学习笔记：Ethash算法。

这节课介绍的是以太坊非常核心的挖矿算法。

在介绍Ethash算法之前，先讲一些背景知识。其实区块链技术主要是解决一个共识的问题，而共识是一个层次很丰富的概念，这里把范畴缩小，只讨论区块链中的共识。

什么是共识？

在区块链中，共识是指哪个节点有记账权。网络中有多个节点，理论上都有记账权，首先面临的问题就是，到底谁来记帐。另一个问题，交易一定是有顺序的，即谁在前，前在后。这样可以解决双花问题。区块链中的共识机制就是解决这两个问题，谁记帐和交易的顺序。

什么是工作量证明算法

为了决定众多节点中谁来记帐，可以有多种方案。其中，工作量证明就让节点去算一个哈希值，满足难度目标值的胜出。这个过程只能通过枚举计算，谁算的快，谁获胜的概率大。收益跟节点的工作量有关，这就是工作量证明算法。

为什么要引入工作量证明算法？

Hash Cash 由Adam Back 在1997年发表，中本聪首次在比特币中应用来解决共识问题。

它最初用来解决垃圾邮件问题。

其主要设计思想是通过暴力搜索，找到一种Block头部组合（通过调整nonce）使得嵌套的SHA256单向散列值输出小于一个特定的值（Target）。

这个算法是计算密集型算法，一开始从CPU挖矿，转而为GPU，转而为FPGA，转而为ASIC，从而使得算力变得非常集中。

算力集中就会带来一个问题，若有一个矿池的算力达到51%，则它就会有作恶的风险。这是比特币等使用工作量证明算法的系统的弊端。而以太坊则吸取了这个教训，进行了一些改进，诞生了Ethash算法。

Ethash算法吸取了比特币的教训，专门设计了非常不利用计算的模型，它采用了I/O密集的模型，I/O慢，计算再快也没用。这样，对专用集成电路则不是那么有效。

该算法对GPU友好。一是考虑如果只支持CPU，担心易被木马攻击；二是现在的显存都很大。

轻型客户端的算法不适于挖矿，易于验证；快速启动

算法中，主要依赖于Keccake256 。

数据源除了传统的Block头部，还引入了随机数阵列DAG（有向非循环图）（Vitalik提出）

种子值很小。根据种子值生成缓存值，缓存层的初始值为16M，每个世代增加128K。

在缓存层之下是矿工使用的数据值，数据层的初始值是1G，每个世代增加8M。整个数据层的大小是128Bytes的素数倍。

框架主要分为两个部分，一是DAG的生成，二是用Hashimoto来计算最终的结果。

DAG分为三个层次，种子层，缓存层，数据层。三个层次是逐渐增大的。

种子层很小，依赖上个世代的种子层。

缓存层的第一个数据是根据种子层生成的，后面的根据前面的一个来生成，它是一个串行化的过程。其初始大小是16M，每个世代增加128K。每个元素64字节。

数据层就是要用到的数据，其初始大小1G，现在约2个G，每个元素128字节。数据层的元素依赖缓存层的256个元素。

整个流程是内存密集型。

首先是头部信息和随机数结合在一起，做一个Keccak运算，获得初始的单向散列值Mix[0]，128字节。然后，通过另外一个函数，映射到DAG上，获取一个值，再与Mix[0]混合得到Mix[1]，如此循环64次，得到Mix[64]，128字节。

接下来经过后处理过程，得到 mix final 值，32字节。（这个值在前面两个小节《 009：GHOST协议 》、《 010：搭建测试网络 》都出现过）

再经过计算，得出结果。把它和目标值相比较，小于则挖矿成功。

难度值大，目标值小，就越难（前面需要的 0 越多）。

这个过程也是挖矿难，验证容易。

为防止矿机，mix function函数也有更新过。

难度公式见课件截图。

根据上一个区块的难度，来推算下一个。

从公式看出，难度由三部分组成，首先是上一区块的难度，然后是线性部分，最后是非线性部分。

非线性部分也叫难度炸弹，在过了一个特定的时间节点后，难度是指数上升。如此设计，其背后的目的是，在以太坊的项目周期中，在大都会版本后的下一个版本中，要转换共识，由POW变为POW、POS混合型的协议。基金会的意思可能是使得挖矿变得没意思。

难度曲线图显示，2017年10月，难度有一个大的下降，奖励也由5个变为3个。

本节主要介绍了Ethash算法，不足之处，请批评指正。

Ⅹ 以太国际空间谁知道怎么玩。EIS币怎么交易

现在我们大家都很关注关于以太坊方面的问题，那么关于以太币怎么交易?我想我们大家应该会很想了解一些内容，那么下面就让我们小编在这里就来为大家好好的介绍一下很多内容关于以太币怎么交易?以太坊的交易最直观解释：从外部账户发送到区块链上的另一个账户的消息和签名的数据包。

包含如下内容：
发送者的签名
接收的地址
转移的数字货币数量等内容
以太坊上的交易都是需要支付费用，和比特币以比特币来支付一定的交易费用不同，以太坊上固定了这个环节，那么这个间接理解是以太坊的一种安全防范错误，防止了大量的无意义的交易，保证一定的安全性，特别是智能合约的创建、执行、调用都需要消耗费用，那么也保证了整个系统的稳定性，防止了一些链上无意义的恶意行为。
交易手续费
以太坊的核心是EVM，以太坊虚拟机，那么在EVM中执行的字节码都是要支付费用。也就是经常看到的Gas、Gas limit、Gas Price这几个概念。
Gas：字面理解就是汽油，以太坊和日常的汽车一样需要Gas才能运行。Gas是一笔交易过程中计算消耗的基本单位。有一个列表可以直观看到在以太坊中操作的Gas消耗量：
操作Gas消耗具体内容
step1执行周期的默认费用。
stop0终止操作是免费的。
suicide0智能合约账户的内部数据存储空间，当合约账户调用suicide()方法时，该值将被置为null。
sha320加解密
sload20在固定的存储器中去获取
sstore100输入到固定的存储器中
balance20账户余额
create100创建合约
call20初始化一个只读调用
memory1扩充内存额外支付的费用
txdata5交易过程中数据或者编码的每一个字节的消耗
transaction500交易费用
contract creation53000homestead中目前从21000调整到53000
所以有些公司或者个人觉得区块链技术去中介化，不需要中心服务器，这种开发模式是比较便宜的，但是事实上区块链的开发不比之前的那些传统软件开发来的便宜。
Gas Price：字面理解汽油价格，这个就像你去加油站，95#汽油今天是什么价格。一个Gas Price就是单价，那么你的交易费用=Gas*Gas Price，然后以以太币来ether来支出。当然你觉得我不想支付费用，你可以设置Gas Price为0，但是选择权在矿工手中，矿工有权选择收纳交易和收取费用，那么最简单的想想很难让一个矿工去接收一个价格很低的交易吧。另外提一句，以太坊默认的Gas Price是1wei。
Gas Limit：字面理解就是Gas的限制，限制是必要的，没有限制就没有约束。这个Gas Limit是有两个意思的。首先针对单个交易，那么这个表示交易的发起者他愿意支付最多是多少Gas，这个交易发起者在发起交易的时候需要设置好。还有一个是针对区块的Gas Limit，一个单独的区块也有Gas的限制。
假设几个场景来说明Gas的使用：
用户设置Gas Limit，那么在交易过程中，如果你的实际消耗的Gas used
用户设置Gas Limit，那么交易过程中，如果你的实际消耗的Gas used > Gas Limit，那么矿工肯定发现你的Gas不足，这个交易就无法执行完成，这个之后会回滚到执行之前的状态，这个时候矿工会收取Gas Price*Gas Limit。
区块的Gas Limit，区块中有一个Gas上限，收纳的交易会出现不同的用户指定的Gas Limit。那么矿工就会根据区块限制的Gas Limit来选择，“合理”选择打包交易。
具体交易
以太坊上交易可以是简单的以太币的转移，同时也可以是智能合约的代码消息。列个表格看下交易的具体内容：
代码内容
from交易发起者的地址、不能为空，源头都没有不合理。
to交易接收者的地址(这个可以为空，空的时候就表示是一个合约的创建)
value转移的以太币数量
data数据字段。这个字段存在的时候表示的是，交易是一个创建或者是一个调用智能合约的交易
Gas Limit字面理解就是Gas的限制，限制是必要的，没有限制就没有约束。这个Gas Limit是有两个意思的。首先针对单个交易，那么这个表示交易的发起者他愿意支付最多是多少Gas，这个交易发起者在发起交易的时候需要设置好。还有一个是针对区块的Gas Limit，一个单独的区块也有Gas的限制。
Gas Price一个Gas Price就是单价，那么你的交易费用=Gas*Gas Price，然后以以太币来ether来支出。以太坊默认的Gas Price是1wei。
nonce用于区别用户发出交易的标识。
hash交易ID，是由上述的信息生成的一个hash值
r、s、v交易签名的三部分，交易发起者的私钥对hash签名生成。
交易分三种类型
转账：简单明了的以太坊上的以太币的转移，就和比特币类似，A向B转移一定数量的以太币。这种交易包含：交易发起者、接收者、value的数量，其余类似Gas Limit、hash、nonce都会默认生成。所以你会看到一段代码：
web3.eth.sendTransaction({ from: "交易发起者地址", to：“交易接收者地址”, value: 数量});
智能合约创建：创建智能合约就是把智能合约部署到区块链上，那么这个时候to是一个空的字段。data字段则是初始化合约的代码。所以看到代码：
web3.eth.sendTransaction({ from: "交易发起者地址", data: "contract binary code"});
智能合约执行：合约创建部署在区块链上，那么执行就是会加上to字段到要智能合约执行的地址，然后data字段来指定调用的方法和参数的传递，所以看到代码：
web3.eth.sendTransaction({ from: "交易发起者地址", to：“合约执行者地址”, data：“调用的方法和参数的传递”});
以上大致就是交易的类型。
交易的确认
和比特币一样，以太坊的交易需要后续区块确认后，节点同步后、才能确认。简单理解就是多挖出一些区块来，通过验证后这一笔交易才算确认，以太坊时常会出现拥堵的情况，所以有时候需要等待确认。
转账、合约交易流转
首先交易发起者A发起一笔转账交易，那么发送的格式如下：
代码具体内容
from交易发起者的地址
to交易接收者的地址
value转移的以太币数量
GasGas的量
Gas PriceGas的单价
data发送给接收者的消息
nonce交易编号
节点验证：以太坊网络中会有节点收到A发送出来的消息，那么会去检查这个消息格式时候有效，然后计算Gas Limit。这个时候回去验证A的以太坊余额，如果余额不足，那么就返回错误，不予处理。一旦A发送的消息通过了节点的验证，那么节点就会把这个交易放到交易存储池中。并广播到区块链网络。
矿工验证：那么写入区块链必须要矿工打包，矿工在接收到A发出的交易，会和其他交易一块打包，普通转账交易打包即可，那么合约调用的交易则需要在矿工本地的EVM上去执行调用的合约代码，代码执行过程中检查Gas的消耗。一旦Gas消耗完了，那么就回滚，如果Gas足够那么返回多余的Gas。并广播到区块链网络。
其余节点：重复节点验证步骤，然后合约也会在本地EVM上执行验证。通过验证后同步区块链。
首先还是发起者A发起一个创建智能合约的交易请求。格式如下：
代码具体内容
from交易发起者的地址
to0
value转移的以太币数量
GasGas的量
Gas PriceGas的单价
data合约代码
nonce交易编号
节点验证：
以太坊网络中会有节点收到A发送出来的消息，检查交易是否有效，格式是否正确，验证交易签名。计算Gas，确定下发起者的地址，然后查询A账户以太币的余额。如果余额不足，那么就返回错误，不予处理。一旦A发送的消息通过了节点的验证，那么节点就会把这个交易放到交易存储池中。并广播到区块链网络。
矿工验证：
矿工将交易打包，那么会根据交易费用和合约代码，来创建合约账户，在账户的空间中部署合约。这里说下合约地址(智能合约账户的地址是有发起者的地址和交易的随机数作为输入，然后通过加密算法生成)。交易确认后会把智能合约的地址返回给A。且广播到区块链网络。
其余节点：
重复节点验证步骤，验证区块，在节点的内存池中更新A的智能合约交易，同步区块链，且智能合约部署在自己本地的区块链中。