ethgetblock
转自： https://zhuanlan.hu.com/p/23558268
getblocktemplate协议诞生于2012年中叶，此时矿池已经出现。矿池采用getblocktemplate协议与节点客户端交互，采用stratum协议与矿工交互，这是最典型的矿池搭建模式。
与getwork相比，getblocktemplate协议最大的不同点是：getblocktemplate协议让矿工自行构造区块。如此一来，节点和挖矿完全分离。对于getwork来说，区块链是黑暗的，getwork对区块链一无所知，他只知道修改data字段的4个字节。对于getblocktemplate来说，整个区块链是透明的，getblocktemplate掌握区块链上与挖矿有关的所有信息，包括待确认交易池，getblocktemplate可以自己选择包含进区块的交易。
挖矿有两种方式，一种叫SOLO挖矿，另一种是去矿池挖矿。前文所述的在节点客户端直接启动CPU挖矿，以及依靠getwork+cgminer驱动显卡直接连接节点客户端挖矿，都是SOLO挖矿，SOLO好比自己独资买彩票，不轻易中奖，中奖则收益全部归自己所有。去矿池挖矿好比合买彩票，大家一起出钱，能买一堆彩票，中奖后按出资比率分配收益。理论上，矿机可以借助getblocktemplate协议链接节点客户端SOLO挖矿，但其实早已没有矿工会那么做，在写这篇文章时，比特币全网算力1600P+，而当前最先进的矿机算力10T左右，如此算来，单台矿机SOLO挖到一个块的概率不到16万分之一，矿工（人）投入真金白银购买矿机、交付电费，不会做风险那么高的投资，显然投入矿池抱团挖矿以降低风险，获得稳定收益更加适合。因此矿池的出现是必然，也不可消除，无论是否破坏系统的去中心化原则。
矿池的核心工作是给矿工分配任务，统计工作量并分发收益。矿池将区块难度分成很多难度更小的任务下发给矿工计算，矿工完成一个任务后将工作量提交给矿池，叫提交一个share。假如全网区块难度要求Hash运算结果的前70个比特位都是0，那么矿池给矿工分配的任务可能只要求前30位是0（根据矿工算力调节），矿工完成指定难度任务后上交share，矿池再检测在满足前30位为0的基础上，看看是否碰巧前70位都是0。
矿池会根据每个矿工的算力情况分配不同难度的任务，矿池是如何判断矿工算力大小以分配合适的任务难度呢？调节思路和比特币区块难度一样，矿池需要借助矿工的share率，矿池希望给每个矿工分配的任务都足够让矿工运算一定时间，比如说1秒，如果矿工在一秒之内完成了几次任务，说明矿池当前给到的难度低了，需要调高，反之。如此下来，经过一段时间调节，矿池能给矿工分配合理难度，并计算出矿工的算力。
矿池通过getblocktemplate协议与网络节点交互，以获得区块链的最新信息，通过stratum协议与矿工交互。此外，为了让之前用getwork协议挖矿的软件也可以连接到矿池挖矿，矿池一般也支持getwork协议，通过阶层挖矿代理机制实现（Stratum mining proxy）。须知在矿池刚出现时，显卡挖矿还是主力，getwork用起来非常方便，另外早期的FPGA矿机有些是用getwork实现的，stratum与矿池采用TCP方式通信，数据使用JSON封装格式。
先来说一下getblocktemplate遗留下来的几个问题：
矿工驱动：在getblocktemplate协议里，依然是由矿工主动通过HTTP方式调用RPC接口向节点申请挖矿数据，这就意味着，网络最新区块的变动无法及时告知矿工，造成算力损失。
数据负载：如上所述，如今正常的一次getblocktemplate调用节点都会反馈回1.5M左右的数据，其中主要数据是交易列表，矿工与矿池需频繁交互数据，显然不能每次分配工作都要给矿工附带那么多信息。再者巨大的内存需求将大大影响矿机性能，增加成本。
Stratum协议彻底解决了以上问题。
Stratum协议采用主动分配任务的方式，也就是说，矿池任何时候都可以给矿工指派新任务，对于矿工来说，如果收到矿池指派的新任务，应立即无条件转向新任务；矿工也可以主动跟矿池申请新任务。
现在最核心的问题是如何让矿工获得更大的搜索空间，如果参照getwork协议，仅仅给矿工可以改变nNonce和nTime字段，则交互的数据量很少，但这点搜索空间肯定是不够的。想增加搜索空间，只能在hashMerkleroot下功夫，如果让矿工自己构造coinbase，那么搜索空间的问题将迎刃而解，但代价是必要要把区块包含的所有交易都交给矿工，矿工才能构造交易列表的Merkleroot，这对于矿工来说压力更大，对于矿池带宽要求也更高。
Stratum协议巧妙解决了这个问题，成功实现既可以给矿工增加足够的搜索空间，又只需要交互很少的数据量，这也是Stratum协议最具创新的地方。
再来回顾一下区块头的6个字段80字节，这个很关键，nVersion，nBits，hashPrevBlock这3个字段是固定的，nNonce，nTime这两个字段是矿工现在就可以改变的。增加搜索空间只能从hashMerkleroot下手，这个绕不过去。Stratum协议让矿工自己构造coinbase交易，coinbase的scriptSig字段有很多字节可以让矿工自由填充，而coinbase的改动意味着hashMerkleroot的改变。从coinbase构造hashMerkleroot无需全部交易，
如上图所示，假如区块将包含13笔交易，矿池先对这13笔交易进行处理，最后只要把图中的4个黑点（Hash值）交付给矿工，同时将构造coinbase需要的信息交付给矿工，矿工就可以自己构造hashMerkleroot（图中的绿点都是矿工自行计算获得，两两合并Hash时，规定下一个黑点代表的hash值总是放在右边）
。按照这种方式，假如区块包含N笔交易，矿池可以浓缩成log2(N)个hash值交付给矿工，这大大降低了矿池和矿工交互的数据量。
Stratum协议严格规定了矿工和矿池交互的接口数据结构和交互逻辑，具体如下：
1. 矿工订阅任务
启动挖矿机器，使用mining.subscribe方法链接矿池
返回数据很重要，矿工需本地记录，在整个挖矿过程中都用到，其中：
Extranonce1，和 Extranonce2对于挖矿很重要，增加的搜索空间就在这里，现在，我们至少有了8个字节的搜索空间，即nNonce的4个字节，以及 Extranonce2的4个字节。
2. 矿池授权
在矿池注册一个账号 ，添加矿工，矿池允许每个账号任意添加矿工数，并取不同名字以区分。矿工使用mining.authorize方法申请授权，只有被矿池授权的矿工才能收到矿池指派任务。
3. 矿池分配任务
以上每个字段信息都是必不可少，其中：
有了以上信息，再加上之前拿到的Extranonce1 和Extranonce2_size，就可以挖矿了。
4. 挖矿
1) 构造coinbase交易
用到的信息包括Coinb1, Extranonce1, Extranonce2_size 以及Coinb2，构造很简单：
为啥可以这样，因为矿池帮矿工做了很多工作，矿池已经构建了coinbase交易，系列化后在指定位置分割成coinb1和coinb2，coinb1和coinb2包含指定信息，比如coinb1包含区块高度，coinb2包含了矿工的收益地址和收益额等信息，但是这些信息对于矿工来说无关紧要，矿工挖矿的地方只是Extranonce2 的4个字节。另外Extranonce1是矿池写入区块的指定信息，一般来说，每个矿池会写入自己矿池的信息，比如矿池名字或者域名，我们就是根据这个信息统计每个矿池在全网的算力比重。
2) 构建Merkleroot
利用coinbase和merkle_branch，按照上图方式构造hashMerkleroot字段。
3) 构建区块头
填充余下的5个字段，现在，矿池可以在nNonce和Extranonce2 里搜索进行挖矿，如果嫌搜索空间还不够，只要增加Extranonce2_size为多几个字节就可轻而易举解决。
5. 矿工提交工作量
当矿工找到一个符合难度的shares时，提交给矿池，提交的信息量很少，都是必不可少的字段：
矿池拿到以上5个字段后，首先根据任务号ID找出之前分配任务前存储的信息（主要是构建的coinbase交易以及包含的交易列表等），然后重构区块，再验证shares难度，对于符合难度要求的shares，再检测是否符合全网难度。
6. 矿池给矿工调节难度
矿池记录每个矿工的难度，并根据shares率不断调节以指定合适难度。矿池可以随时通过mining.set_difficulty方法给矿工发消息另其改变难度。
如上，Stratum协议核心理念基本解析清楚，在getblocktemplate协议和Stratum协议的配合下，矿池终于可以大声的对矿工说，让算力来的更猛烈些吧。
2. eth是什么意思
eth的意思是以太坊。
eth是英文Ethereum的缩写，意思是以太坊，它是一个开源的有智能合约功能的公共区块链平台，通过其专用加密货币以太币提供去中心化的以太虚拟机来处理点对点合约。
相关短语
1、Enterprise Ethereum Alliance：企业以太坊联盟，企业以太坊同盟，太坊区块链联盟。
2、Ethereum Foundation：以太坊基金会。
3、Ethereum Classic：以太坊经典，以太经典，以太坊原链，古典以太坊。
4、Enterprise Ethereum：企业以太坊，以太坊企业。
5、Ethereum virtual machine：以太坊虚拟机。
6、Decentral and Ethereum：加拿大。
7、Ethereum Island：以太坊岛。
8、Ethereum Classi：以太坊经典。
9、Ethereum blockchain alliance：以太坊区块链联盟。
3. Chainge技术沙龙（0414）-区块链技术的安全隐患
虚拟机设计
零钱整理
慢雾科技介绍
01| The Dao事件
以太坊第一个安全大事件
智能合约的取款
新建一个Bank，存入一部分钱，用Dao框架不停取钱。
取款-判断余额-取款操作框架-转空该账户下的所有钱。
简单的例子就是，你的银行卡有余额100万，你需要买一个10块钱的饮料，但是支付的过程有漏洞，所以你银行卡的所有钱都被转走。
一、外部调用
02| 以太坊黑色情人节
起源：第一转账时间是2.14
ETH节点统计
客户端、客户端版本、OS系统。整个系统的庞杂
蜜罐检测 （部署陷阱能检测出黑客的点来）
net_version
判断是主网还是测试网，只攻击主网
3000+主网节点完全暴露
eth_accounts
获取钱包账号，涉及钱包账号
eth_getBanlance
获取有多少钱，被盗46000+ETH
why?
unlockAccount 函数介绍
该函数将使用密码从本地的keystore 里提取private key 并存储在内存中,函数第三个参数ration 表示解密后private key 在内存中保存默认是300 秒; 如果设置为0,则表的时间，示永久存留在内存，直至Geth/Parity 退出。
详见:
https://github.com/ethereumgethereum/wiki/Management-APIs#personal_unlockaccount
节点存用户的keystore信息（严重危险）
eth_getBlockByNumber
墨子扫描引擎，扫描有问题的节点，慢雾的以太坊安全事件的披露
被盗ETH，市值，被盗钱包数
具体内容可以查看慢雾发布的 以太坊黑色情人节专题
生态相关
ETH：矿池、钱包、web3、smart contract、dapp
BTC:矿池、钱包、Lightning Network
BTC RPC
防御建议
管理数十万用户安全的接近百万的比特币
华人世界唯一被bitcoin.org网站展示的钱包
比特派多种区块链资产（BTC、ETH、Token、分叉）
冷热结合，确保安全
比特派-热钱包
比特护盾-冷钱包/硬件钱包
区块链安全事件
私钥决定了区块链资产的所有权，丢了私钥也就相当于丢了一切。私钥就是一个随机数，这个随机数的概率空间很大(256 位，即2^256)
钱包=生态入口
需要在安全的同时做到尽可能的开放
玩法的开放，技术的开放，通用的技术接口，生态的开放，把自己的资源进行导入。合作伙伴计划：技术咨询、区块链技术支持、开放平台、入口支持、生态支持、海外市场合作。帮助伙伴实现区块链转型或区块链项目孵化，安全、便捷实现真正落地的区块链应用场景。
联系方式 [email protected]
用户风控系统，数百万的数字货币用户。
最大可能保持我们的数字资产
骗子故事：抢数字货币份额，钱没到账，冒充官方，交出助记词
恶意钱包地址库
诈骗钱包、黑客钱包、羊毛党钱包
恶意网站库
钓鱼网站、空投网站、交易所、众筹
风险合约库
重名币、空格币、风险合约
安全事件库
历史安全事件提醒
最新事件提醒
盗币风险监控
安全意识教育
可能出现被盗的情况
游戏即资产，稀缺资源，成为游戏运营者。最后大BOSS死于暴露了自己的密钥。
通过社工（社会工程学）【欺骗的艺术】黑客攻击手法，虚拟景象做出错误判断让自己陷入危机。
人始终是系统中最薄弱的环节，币安背锅的黑客事件。大客户泄露自己的账户，调用API接口，自动交易。虽然没丢币但是黑客在期货市场盈利。
关于安全钱包的帖子（来自小白愤怒控诉，实际没有理解整个机制）：
1、我没私钥和交易密码，东西都在你们那我不知道安全在哪里
2、密语算个毛，你告诉我拿着你们的密语能做什么。
汽车和自行车事件，出了问题之后，弱势的一方被原谅。负责的是更大的一方。平台替没有安全意识的用户背锅。
对于大部分用户来说，交易所的安全性比普通用户自己管理的安全性要高，用户的安全意识没有提高，交给交易所帮助、协助你来管理你的钱包提示很多风险操作。
为什么要随机生成256位的密钥，为什么不能用户自己去设置，如果自己设置会处于一个集中的区域，随机值不够，私钥生成时就处于危险的状态。
自己的安全认识不够，所以自己造成的损失，先怼交易所先怼钱包。先想到得是你们的问题和漏洞造成的，不是我的操作失误和密钥泄露造成的。
币派做的是大神和小白的交流之间的翻译，做画漫画，写段子的逗比。
币小宝防骗指南漫画，贡献题材和内容。
4. 以太坊多节点私有链部署
假设两台电脑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
5. Entrynamenotfound
报错。
在调用queryBlockByNumber()方法时，向peer发送一个proposal，调用fabric的系统链码qscc，从下面的错误描述看出，由于链码执行出现错误，因此报了代码为500的错。
相对应的，peer端也有相应的错误日志打印，如下所示，即peer模拟执行交易失败。
查询流程分析
查询的流程涉及到SDK端、Peer端以及peer上运行的系统链码，下面进行分析：
SDK端
程序调用Channel对象的queryBlockByNumber()方法；
Channel对象创建QuerySCCRequest请求，设置Fcb为GetBlockByNumber，设置Args为通道的名字和区块号；
调用sendProposal方法将请求发给peer（通过Endorser对象的ProcessProposal方法进行grpc调用）。
Peer端
core/endoser/endorser.go文件中的ProcessProposal方法处理请求；
对proposal进行一系列预处理；
调用simulateProposal方法模拟执行交易；；
调用callChaincode方法将proposal交给智能合约执行；
调用core/chaincode/chaincodeexec.go中的ExecuteChaincode方法执行交易；
core/chaincode/exectransaction.go中的Execute方法执行交易，如果chaincode没有运行先调用launch方法启动chaincode；
然后调用theChaincodeSupport.Execute方法执行交易；
调用handler.sendExecuteMessage方法把proposal发给chaincode实例进行执行，由于是QueryScc请求，所以发给qscc合约进行执行。
Peer端的qscc系统链码
core/scc/qscc/qscc.go根据fcn的名字调用GetBlockByNumber方法进行执行；
调用core/ledger包中的GetBlockByNumber接口从账本中获取区块；
调用core/ledger/kvledger包中的kvLedger对象的GetBlockByNumber方法，从kv账本中获取区块；
调用common/ledger/blkstorage包中BlockStore对象的RetrieveBlockByNumber方法从区块存储中获取区块；
调用common/ledger/blkstorage/fsblkstorage包中的fsBlockStore对象的RetrieveBlockByNumber方法；
调用common/ledger/blkstorage/fsblkstorage包中的blockfileMgr对象的retrieveBlockByNumber方法；
调用common/ledger/blkstorage/fsblkstorage包中的index接口中的getBlockLocByBlockNum方法从leveldb的index中获取区块位置。由于从index中获取区块不存在，所以返回Entrynotfoundinindex错误。
6. Android，getBlockSize() 过时了用哪个方法获取磁盘大小
在API level 18中已经使用getBlockSizeLong () 来代替getBlockSize ()这个方法了。
但是需要注意的是，getBlockSizeLong ()这个方法在API level 18版本之前是没有的，如果开发的应用需要兼容18版本以前的系统，最好还是使用getBlockSize()方法。
7. Web3py简单使用方法（三）
一.Web3py的一些使用的例子：
1.查询区块：
···
web3.eth.getBlock(12345)
web3.eth.getBlock('')
web3.eth.getBlock('latest')
web3.eth.blockNumber
二.web3py还提供几个详细模块的api，具体可上文档查询。
1.Web3.eth : http://web3py.readthedocs.io/en/latest/web3.eth.html
2.Web3.shh : http://web3py.readthedocs.io/en/latest/web3.shh.html
3.Web3.personal : http://web3py.readthedocs.io/en/latest/web3.personal.html
4.Web3.version : http://web3py.readthedocs.io/en/latest/web3.version.html
5.Web3.txpool : http://web3py.readthedocs.io/en/latest/web3.txpool.html
6.Web3.miner : http://web3py.readthedocs.io/en/latest/web3.miner.html
7.Web3.admin : http://web3py.readthedocs.io/en/latest/web3.admin.html
8. ETH开发实践——批量发送交易
在使用同一个地址连续发送交易时，每笔交易往往不可能立即到账， 当前交易还未到账的情况下，下一笔交易无论是通过 eth.getTransactionCount() 获取nonce值来设置，还是由节点自动从区块中查询，都会获得和前一笔交易同样的nonce值，这时节点就会报错 Error: replacement transaction underpriced
在构建一笔新的交易时，在交易数据结构中会产生一个nonce值， nonce是当前区块链下，发送者(from地址)发出的交易(成功记录进区块的)总数， 再加上1。例如新构建一笔从A发往B的交易，A地址之前的交易次数为10，那么这笔交易中的nonce则会设置成11， 节点验证通过后则会放入交易池（txPool）,并向其他节点广播，该笔交易等待矿工将其打包进新的区块。
那么，如果在先构建并发送了一笔从地址A发出的，nonce为11的交易，在该交易未打包进区块之前， 再次构建一笔从A发出的交易，并将它发送到节点，不管是先通过web3的eth.getTransactionCount(A)获取到的过往的交易数量，还是由节点自行填写nonce， 后面的这笔交易的nonce同样是11， 此时就出现了问题：
实际场景中，会有批量从一个地址发送交易的需求，首先这些操作可能也应该是并行的，我们不会等待一笔交易成功写入区块后再发起第二笔交易，那么此时有什么好的解决办法呢？先来看看geth节点中交易池对交易的处理流程
如之前所说，构建一笔交易时如果不手动设置nonce值，geth节点会默认计算发起地址此前最大nonce数（写入区块的才算数），然后将其加上1， 然后将这笔交易放入节点交易池中的pending队列，等到节点将其打包进区块。
构建交易时，nonce值是可以手动设置的，如果当前的nonce本应该设置成11， 但是我手动设置成了13， 在节点收到这笔交易时， 发现pending队列中并没有改地址下nonce为11及12的交易， 就会将这笔nonce为13的交易放入交易池的queued队列中。只有当前面的nonce补齐（nonce为11及12的交易被发现并放入pending队列）之后，才会将它放入pending队列中等待打包。
我们把pending队列中的交易视为可执行的，因为它们可能被矿工打包进最新的区块。 而queue队列因为前面的nonce存在缺失，暂时无法被矿工打包，称为不可执行交易。
那么实际开发中，批量从一个地址发送交易时，应该怎么办呢？
方案一：那么在批量从一个地址发送交易时， 可以持久化一个本地的nonce，构建交易时用本地的nonce去累加，逐一填充到后面的交易。（要注意本地的nonce可能会出现偏差，可能需要定期从区块中重新获取nonce，更新至本地）。这个方法也有一定的局限性，适合内部地址（即只有这个服务会使用该地址发送交易）。
说到这里还有个坑，许多人认为通过 eth.getTransactionCount(address, "pending") ，第二个参数为 pending ， 就能获得包含本地交易池pending队列的nonce值，但是实际情况并不是这样， 这里的 pending 只包含待放入打包区块的交易， 假设已写入交易区块的数量为20， 又发送了nonce为21，22，23的交易， 通过上面方法取得nonce可能是21（前面的21，22，23均未放入待打包区块）， 也可能是22（前面的21放入待打包区块了，但是22，23还未放入）。
方案二是每次构建交易时，从geth节点的pending队列取到最后一笔可执行交易的nonce, 在此基础上加1，再发送给节点。可以通过 txpool.content 或 txpool.inspect 来获得交易池列表，里面可以看到pending及queue的交易列表。
启动节点时，是可以设置交易池中的每个地址的pending队列的容量上限，queue队列的上容量上限， 以及整个交易池的pending队列和queue队列的容量上限。所以高并发的批量交易中，需要增加节点的交易池容量。
当然，除了扩大交易池，控制发送频率，更要设置合理的交易手续费，eth上交易写入区块的速度取决于手续费及eth网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。
9. eth挖矿是什么原理
凡是涉及到币，就一定离不开挖矿。以太坊网络中，想要获得以太坊，也要通过挖矿来实现。说到挖矿，就一定离不开共识机制。
不知道大家还记得比特币的共识机制是什么吗？比特币的共识机制是 PoW (这是英文 Proof of Work 的缩写，意思是“工作量证明机制”）。简单来说，就是多劳多得，你付出的计算工作越高，那么你就越有可能第一个找到正确的哈希值，就越有可能得到比特币奖励。
但是，比特币的PoW存在着一定的缺陷，就是它处理交易的速度太慢，矿工们需要不断地通过计算来碰撞哈希值，这是劳民伤财且效率低下的。对区块链知识有涉猎的朋友们应该看到这样一种说法：
以太坊为了弥补比特币的不足，提出了新的共识机制，名叫 PoS(这是英文的缩写，意思是“权益证明”，也有翻译成“股权证明”的）。
PoS 简单来讲，其实就跟它的字面意思一样：权益嘛，股权嘛，你持有的币越多相当于你的股权越多，你的权益越高。
以太坊的PoS就是说：你持币越多，你持有币的时间越久，你的计算难度就会降低，挖矿会容易一些。
在以太坊最初的设定中，以太坊希望能够通过阶段性的升级，在前期依旧采用PoW来构建一个相对稳定的系统，之后逐渐采用 PoW+PoS，最后完全过渡到 PoS。所以，说以太坊的共识机制是PoS，没错，但是PoS只是以太坊发布之初的一个计划或者说目标，目前以太坊还没有过渡到 PoS，以太坊采用的共识机制仍是 PoW，就是比特币那个 PoW，但是又和比特币的PoW稍稍不同。
这里的信息量有点大，
第一个信息点是：以太坊目前采用的共识机制也是PoW，但是和比特币的PoW稍稍不同。那么，和比特币的PoW到底有什么不同呢：简单来说，就是以太坊挖矿难度可以调节，比特币挖矿难度不能调节。就好比咱们高考，因为各个省份的教学情况、生源人数都不一样，所以高考分为全国卷和各省自主命题。
以太坊说我赞成这样分地区出题，比特币说：不行，必须全国同一卷，大家难度都一样！
通俗解释，就是，比特币是利用计算机算力做大量的哈希碰撞，列举出各种可能性，来找到一个正确哈希值。而以太坊系统呢，它有一个特殊的公式用来计算之后的每个块的难度。如果某个区块比前一个区块验证的更快，以太坊协议就会增加区块的难度。通过调整区块难度，就可以调整验证区块所需的时间。
以太坊协议规定，难度的动态调整方式是使全网创建新区块的时间间隔为 15 秒，网络用 15 秒时间创建区块链，这样一来，因为时间太快，系统的同步性就大大提升，恶意参与者很难在如此短的时间发动51%（也就是半数以上）的算力去修改历史数据。
第二个信息点是：以太坊最初的设定中，希望通过阶段性升级来最终实现由 PoW 向
PoS过渡的。
时间追溯到 2014 年，在以太坊发布之初，团队宣布将项目的发布分为四个阶段，即 Froniter（前沿）、Homestead（家园）、Metropolis（大都会）和 Serenity（宁静）。前三个阶段共识机制采用 PoW（工作量证明机制），第四个阶段切换到 PoS（权益证明机制）。
2015年7月30号，以太坊第一个阶段“前沿”正式发布，这个阶段只适用于开发者使用，开发人员可于在以太坊网络上编写智能合约和去中心化应用程序 DAPP，矿工开始进入以太坊网络维护网络安全并挖矿得到以太币。前沿版本类似于测试版，证明以太坊网络到底是不是可靠的。
2016年3月14日，以太坊进入到第二个阶段“家园”，这一阶段，以太坊提供了钱包功能，让普通用户也可以方便体验和使用以太坊。其他方面没有什么明显的技术提升，只是表明以太坊网络已经可以平稳运行。
2017 年 9 月，以太坊已经进行到第三个阶段“大都会”。“大都会”由拜占庭和君士坦丁堡两次升级组成，这个阶段的的目标是希望能够引入 PoW 和 PoS 的混合链模式，为 PoW向PoS的顺滑过渡做准备。最近比较热门的“以太坊君士坦丁堡升级”升级的就是这个，在君士坦丁堡升级中呢，以太坊将对底层协议和算法做一些改变，来为实现 PoW 和
PoS奠定良好的基础。
以太坊挖矿会得到对多少奖励呢？赢得区块创建竞争成功的矿工会得到这么几项收入：
1、 静态奖励，5个以太坊；
2、 区块内所花费的燃料成本，也就是Gas，这部分我们上一期内容讲过;
3、 作为区块组成部分，包含“叔区块”的额外奖励，叔就是叔叔的叔，每个叔区块可以得到挖矿报酬的1/32作为奖励，也就是5乘以1/32，等于0.15625 个以太坊。这里我们简单解释一下“叔区块”，“叔区块”这个概念是以太坊提出来的，为什么要引进叔块的概念？这还要从比特币说起。在比特币协议中，最长的链被认为是绝对的正确。如果一个块不是最长链的一部分，那么它被称为是“孤块”。一个孤立的块是一个块，它也是合法的，但是可能发现的稍晚，或者是网络传输稍慢，而没有能成为最长的链的一部分。在比特币中，孤块没有意义，随后将被抛弃掉，发现这个孤块的矿工也拿不到采矿相关的奖励。
但是，以太坊不认为孤块是没有价值的，以太坊系统也会给与发现孤块的矿工回报。在以太坊中，孤块被称为“叔块”(uncle block)，它们可以为主链的安全作出贡献。 以太坊十几秒的出块间隔太快了，会降低安全性，通过鼓励引用叔块，使引用主链获得更多的安全保证(因为孤块本身也是合法的) ，而且，支付报酬给叔块，还能激发矿工积极挖矿，积极引用叔块，所以，以太坊认为，它是有价值的。
10. 【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刷新一次。
正常情况下，几十秒内就可以获取到区块信息了。
区块确认数=当前区块高度-交易被打包时的区块高度。