eth开发入门门槛
⑴ 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算法，不足之处，请批评指正。
⑵ ETH是什么怎样购买才好
ETH是以太币的编码，而以太币是以太坊区块链上的代币，以太币目前有不少人在投资交易。于新手而言，可能对以太币的操作方式有些迷糊，其实，以太币交易仅需于领域王国上预测其价格涨跌走势判断正确即获利。虽说单笔交易最低5美元，交易周期短至30秒，但注意不要频频交易与重仓交易。
⑶ eth钱包开发（nodejs）（一）
tips： sendEthTransaction方法将eth转账和token转账合并，转账eth时将tokenValue赋值为0，转账token时将value赋值为0即可
⑷ 【ETH钱包开发04】web3j转账ERC-20 Token
在上一篇文章中讲解了ETH转账，这一篇讲一下ERC-20 Token转账。
【ETH钱包开发03】web3j转账ETH
1、直接用web3j的API
2、java／Android调用合约的 transfer 方法
不管用哪种方式来转账，你都需要先写一个solidity智能合约文件来创建ERC-20 Token，然后部署合约，最后才是通过客户端来调用。
注意：erc-20 token转账和eth转账的区别如下：
1、erc-20 token创建交易对象用的是这个方法 createTransaction
2、erc-20 token需要构建 Function ，它其实对应的就是erc-20 token合约中的那些方法。它的第一个参数就是ERC20中那几个方法的名称，第二个参数的话就是对应合约方法中的参数，第三个参数是和第二个参数对应的，按照我那样就行了。转账的话就是 transfer ，我们从合约的 transfer 可以看到第一个参数是收款地址，第二个参数是金额，所以 Function 这里对应起来就好。
这种方法不需要使用web3j封装的方法，而是直接调用solidity合约的方法。
步骤
1、web3j加载一个已经部署的合约
2、验证合约是否加载成功 isValid
3、如何加载合约成功，则调用合约的 transfer 方法
注意：
1、这里的 TokenERC20 是根据solidity智能合约生成的对应的Java类，用于java／Android和智能合约交互的，如果你对这里不太清楚，不妨看看我之前的一篇文章。
以太坊Web3j命令行生成Java版本的智能合约
2、如果加载合约失败，可能的一个原因是合约对应的Java类中的 BINARY 的值不对，这个值是你部署合约成功之后的bytecode，你最好检查对比一下。
我发送一笔交易，可以通过这个地址查询
https://rinkeby.etherscan.io/tx/
⑸ 006：MPT与RLP|《ETH原理与智能合约开发》笔记
待字闺中开发了一门区块链方面的课程：《深入浅出ETH原理与智能合约开发》，马良老师讲授。此文集记录我的学习笔记。
课程共8节课。其中，前四课讲ETH原理，后四课讲智能合约。
第二课分为三部分：
这篇文章是第二课第二部分的学习笔记：MPT与RLP。
MPT，Merkle Patricia Tree，结合了Merkle Tree（默克尔树）和 Patricia Tree（帕特里夏树）的一种数据结构。
RLP，Recursive Length Prefix，一种编码方法。
这是两个非常重要的数据结构，在以太坊的区块和交易中都有用到。
先分别介绍一下Merkle Tree 和 Patricia Tree。
Merkle Tree 和 Patricia Tree Merkle Tree 和 Patricia Tree
默克尔树的解释：对每一个交易计算其散列值（Hash），再对两个散列值求他们的散列值。如果是奇数个，就把最后一个重复一次。最后得到的一个散列值就是默克尔树根的值。如图，交易1、1、2、3的散列值分别是HASH0、HASH1、HASH2、HASH3。HASH0和HASH1结合在一起计算散列值得HASH01，HASH2和HASH3结合在一起计算散列值得HASH23，接下来HASH01、HASH23结合在一起，计算散列值得HASH0123。
采用默克尔树的好处是可以方便的判断一个交易是否在区块中。
Patricia Tree，可称为压缩前缀树。如上图右半部分。相同的前缀在同一分支中，后面一同的部分分叉出来，如test和toast，都有相同的t，est和oast在两个分支中。
这个结构的好处是节省空间，因为每一级的键值可以是多个字符。
了解了Merkle Tree 和 Patricia Tree后，再来看这两者混合后的产物——MPT。
这里的原理知识单独来看不易理解，和具体的例子结合起来才更容易理解，此处先放上课件截图。在后面的例子中再做说明。
Merkle Patricia Tree 规格 Merkle Patricia Tree 规格
在MPT中，还涉及到三个小的编码标准。主要规则如图。下面结合两个例子说明一下。
三个编码标准 三个编码标准
HEX编码的例子：从ASCII码表中可以查出，b的十六进制编码为62，o的十六进制编码为6F，F在十六进制中就是15的意思。因为这是个叶子节点，最后加上0x10表示结束，也就是16。所以最后的编码为[6 2 6 15 6 2 16]
HEX-Prefix编码的例子：[6 2 6 15 6 2 16]，将其最后的0x10去掉，[6 2 6 15 6 2]。前面补一个四元组，其中（倒数）第0位是区分奇偶信息的，[6 2 6 15 6 2]是偶数位，第0位是0；第1位是区分节点类型的，这是叶子节点，第1位是1。所以这个四元组就是0010是2。“如果输入key的长度是偶数则再添加一个四元组0x0在flag四元组之后。”，所以，最终的前缀是0x20。本例最终的结果，[32 98 111 98]，即[0x20, 0x62, 0x6F, 0x62]
下面是综合性的例子，通过它可以很方便地理解前面的理论知识。值得多看几篇，仔细休会。
初始的key-value对为：
其中，<>中的数据为key的16进制编码。
MPT.jpg MPT.jpg
因为4组数据都有公共的6，所以这个节点的值为6，长度为1，奇数；节点类型：扩展节点；所以前缀就是0001，即1。
这是个扩展节点，它的值是一个Hashvalue，它指向一个分支节点。Hashvalue，具体指的是分支节点RLP编码的结果的散列值。（RLP见下小节）
分支节点。上面4组数据的第2位是4和8两种情况。在4的位置上存的是下面的扩展节点的散列值，在8的位置上存的是下面的叶子节点的散列值。
叶子节点。以68开头的只有一个了。所以这个节点上的四元组就是6f727365了。它是偶数位。前缀是0x20（同前文HEX-Prefix编码的例子）。这个叶子节点的value值为'stallion'。
扩展节点。在64之后，公共的部分是6f，这个扩展节点的key即为6f，前缀为0000，即00。这个扩展节点的value存放的是一个hashvalue，指向下一个节点，一个分支节点。
分支节点。646f已经表达完，这个节点的value值就是646f对应的值，'verb'。
除此之外，646f之后就是6，所以在这个分支节点的6位置上有一个散列值，指向下一个节点。
扩展节点。在646f6之后，公共的部分是7，其长度为1，奇数。所以前缀为0001。这个节点的value是一个散列值，指向下一个节点。
分支节点。646f67已经表达完，这个节点的value值就是646f67对应的值，'puppy'。
除此之外，646f67之后就是6，所以在这个分支节点的6位置上有一个散列值，指向下一个节点。
叶子节点。key为5，value为'coin'。长度为1，奇数，前缀0011，即3。
整个分析过程结束。可结合上图和前文的理论多加复习。
这小节也是理论性较强，通过例子可以方便理解。先放上课件，再根据我的理解举更多的例子。同样，学习方法也是理论和例子配合学习。其中，list的例子在下篇文章的上机实验部分再列举。 RLP的编码标准 RLP的编码标准 再举几个例子 再举几个例子
⑹ 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网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。
⑺ 【ETH钱包开发02】导入钱包
本文主要讲解通过助记词、keystore、私钥 3种方式来导入钱包。导入钱包就是说根据输入的这3者中的一个去重新生成一个新的钱包。导入钱包的过程和创建的过程其实是差不多的。
根据助记词导入钱包不需要原始密码，密码可以重新设置。根据用户输入的助记词，先验证助记词的合规性（格式、个数等）,验证正确后，配合用户输入的密码重新生成一个新的钱包。
验证助记词的合规性（格式、个数等）
助记词导入钱包
通过私钥导入钱包其实和创建钱包的过程基本一致。因为私钥在导出的时候转换成了16进制，所以在导入私钥的时候，要把16进制转换为byte数组。
keystore就是钱包文件，实际上就是钱包信息的json字符串。导入keystore是需要输入密码的，这个密码是你最后导出keystore时的密码。将keystore字符串变成walletFile实例再通过 Wallet.decrypt(password, walletFile); 解密，成功则可以导入，否则不能导入。
这是Web3j的API，程序走到这里经常OOM!
具体原因的话，我就不多说了，细节大家可以看这里
https://www.jianshu.com/p/41d4a38754a3
解决办法
根据源码修改 decrypt 方法，这里我用一个已经修改好的第三方库
修改后的解密方法
导入Kestore
1、导入助记词和私钥是不需要以前的密码的，而是重新输入新的密码；导入Keystore则需要以前的密码，如果密码不正确，会提示地址和私钥不匹配。
2、关于备份助记词
用过imtoken的同学可以看到imtoken是可以导出（备份）助记词的。这个一开始我也很困惑，后来了解到其实它实在创建钱包的时候，在app本地保存了助记词，导出只是讲数据读取出来而已。还有一点，imtoken一旦备份了助记词之后，之后就没有备份那个功能了，也就是说助记词在本地存储中删除了；而且导入钱包的时候也是没有备份助记词这个功能的。
⑻ iOS开发ETH钱包
框架：web3swift => https://github.com/matter-labs/web3swift
1、创建钱包
2、导入钱包
3、获取余额
4、转账
5、调用智能合约
注意：
1、网络的切换
测试网 let web3 = Web3.InfuraRinkebyWeb3()
主网 let web3 = Web3.InfuraMainnetWeb3()
2、转账相关的，必须配置
KeystoreManager
TransactionOptions
3、调用智能合约，参数不对，会直接返回nil
⑼ 【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刷新一次。
正常情况下，几十秒内就可以获取到区块信息了。
区块确认数=当前区块高度-交易被打包时的区块高度。
⑽ ETH开发实践——合约地址是怎么得来的
在把智能合约成功部署到ETH网络时，会得到合约地址，那么，这个合约地址是由什么决定的呢？合约地址由合约创建者的地址(sender address)和这笔部署交易中的nonce(发送者的累积交易次数)决定，将 sender 和 nonce 经过RLP编码后，再进行Keccak-256(SHA3)散列， 最后裁掉前面12个字节即得到合约地址。
example in js: