Ⅰ 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
Ⅱ 打包区块是什么意思
意思如下
在其他区块链系统中,区块打包是有时间限制的,在一段时间内区块能打包多少交易就打包多少,时间到了就会生成区块。如果有剩余的交易,那就等下次喽。
Ⅲ 以太坊怎么维护
以太坊的维护是通过矿工节让激点进行的坦洞袜。矿工节点是指通过计算机挖矿获得以太币的节点，在维护以太坊网络的同时也在为自己获取收益。这些矿工节点会通过算力竞赛的方式来争夺下一个区块的产生权，通过解决数学难题来获得下一个区块的产生权，并将新的区块添加到区块链中。在添加新的区块时，矿工节点需要验证该区块中的所有交易是否合法，例如是否满足账户余额的要求、是否满足智能合约的要求等。如果验证通过，该区块就会被添加到区块链中，否则就会被拒绝。
除了矿工节点的维护，以太坊还有一些其他的维护措施，例如节点管理、智能合约审核等。节点管理是指通过增加节点数量来提高网络的稳定性和安全性。智能合约审核是指对新的智能合约进行审核和测试，确保其符合规范并且没有漏洞，以避免因为智能合约问题导致的安全事故。
总之，以太坊的维护是通过矿工节点、节点管理和颤橡智能合约审核等多种措施来保证网络的安全性和稳定性。
Ⅳ 【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.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网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。
Ⅵ Gas 机制是如何运作的
以太坊是目前第二大公链，它和比特币不一样，以太坊上的可以实现的功能更多，如果比特币是一个可以进行加减乘除的计算器，那么以太坊就是一台功能完备的计算机。以太坊系统的复杂度超过比特币好几个数量级。
在以太坊中，用户可以自己写一个智能合约，然后把智能合约放到以太坊中执行。智能合约的执行需要消耗资源，而以太坊上的资源是有限的。
在计算机系统中，停机问题（https://zh.wikipedia.org/wiki/停机问题）目前还没有办法完全证明。这个问题简单来说就是没办法判断一个程序是否能够在有限的时间内结束运行。
如果一个用户提交了一个死循环程序到以太坊中，那么就会无限的执行下去，从而将以太坊网络击垮。而使用 gas 机制则可以解决这个问题，智能合约中，每段代码的执行都会消耗一定量的 gas，在用户提交交易的时候需要指定好。如果 gas 消耗完了，那么智能合约就必须停止，交易也会被撤销，如果智能合约执行完成， gas 还有剩余，就会退还给用户。
需要特别说明的是，即使交易失败，用户也需要支付 gas 费用，因为以太坊为这些错误的交易也付出了计算资源。
除了这点之外，gas 还可以用来激励矿工，用户提交交易所消耗的 gas 费用最后都会给到矿工，矿工会优先去打包那些提供了更高 gas 价格的交易，在以太坊中，如果希望自己的交易早点被打包，可以设置更高的 gas 价格。
g as 机制是以太坊系统的命脉。
gas 本质就是维护以太坊网络安全，这是从两个方面来做到的，一方面通过 gas 来衡量计算量，一方面使用 gas 来吸引更多的矿工，矿工的数量越多，以太坊网络就越安全。
gas 只能用于交易中，用户不会接触到 gas，gas 会在交易的提交的时候直接通过以太币来兑换。
智能合约中，每个操作都会消耗一定的 gas 。每个操作都对应一个 Opcode，下面是一些常见的 gas 消耗，完整的 gas 消耗说明看这里：https://github.com/crytic/evm-opcodes
以太坊中的交易最后会被确认，打包成区块，这样交易才算是完成，但是在一个区块中，可以打包的交易是有限的，以太坊通过 gas 来限制可以打包的交易数。这样就让被打包的机会成为了一个稀缺的资源。
用户提交一个交易后，gas 量可以看做是一个固定的值，矿工为了做到最大收益，就会选择那些 gas 价格更高的交易。
很多以太坊的用户经常吐槽 gas 费过高，其实这里的过高不是指 gas 本身过高，而是指 gas 对应的以太坊价格过高。
因为 Gas 的价格不是固定的，而是波动的，简单来说就是根据供需关系来决定的，如果同时需要用以太坊的用户多，那么Gas 的价格就贵，如果用户的人少，那么 Gas 的费用就会少。
以太币的最基本单位是 wei，1 ETH = 10 ^18 wei，而衡量 gas 价格的单位则是 gwei，1 ETH = 10 ^ 9 gwei。
在提交交易的时候，需要设定两个参数，一个是 gas 的最大消耗量（gas limited）和 gas 的价格，gas 的消耗量通常情况下会比较固定，不会有太大的变化，主要是 gas 的价格会波动很大。
在上面我们说到矿工会挑选那些 gas 费用比较高的交易进行打包。所以 gas 的价格设置得越高，那么总的 gas 费用就会越高。如果想让当前的交易尽快被确认，那么就需要设置一个当前相对来说比较高的 gas 价格。
其实对当前 gas 价格最清楚的就是那些矿工，所以矿工们也提供了一些服务，让用户可以实时地了解到当前 gas 价格的分布。比如 GasNow 就是一个比较常用的服务，现在很多钱包中都在使用这个来为钱包的用户提供 gas 价格建议。
如果你提交的交易不紧急，那么使用当前的平均 gas 价格就可以，如果需要提交紧急的交易，那么就需要设置更高的 gas 价格。
文 / Rayjun
Ⅶ 交易是如何打包进区块的
一直以来有困惑
1.私钥确定是完全不能重复的吗？虽然是256位二进制。
2.节点说的是矿工节点吗，还是所有的节点
3.矿工是如何一边打包交易一边破解随机数的，交易被确认的过程不是在网络中广播的过程吗？
比如，我在打包，你也在打包，咱们俩是打的同一个吗？
还是各自打包各自的，谁破解谜题了谁的区块就得到认可。
或者说咱们面对的是同一个交易池吗？
我不能理解的是交易是如何被打包进区块的，比如有一万笔交易，只有1000笔被确认，但是这一万笔都被广播了，莫非会有一些处于“未确认”的状态？等待着被打包进下一个区块？
在区块链研习社咨询后，思路清晰了许多。
1、私钥并不是完全不重复，只是说在地球上，这种重复的概率几乎为0 ；
私钥是程序生成的256位二进制的随机数。他的大小是10^76这个量级的。宇宙所有原子的量级大概是10^80。重复的概率微乎其微。
2、节点就是矿工，你的电脑也可以作为一个节点，虽然算力很小；
3、交易在一个内存池（队列）里，矿工尝试打包，取出交易，计算难题，计算出来了，于是加上自己的签名，完成确认过程。没有准确的时间先后的问题。
但是我还有疑惑，是不是可以这样理解，在未找到答案之前，有许多区块，谁找到答案，谁的区块就被打到区块链中，进而区块中的交易被确认，并且可以进行下一步的交易。
接着就有了下面的回答：
一个交易可能在不同的节点上的队列里 ，就像你在一班排第三，在三班可能排第九。
然后有一个区块打包会包含这个交易，其他节点处理是会把交易抛弃掉。所以，一个交易只能被包含到一个区块里。
区块提交后，其他节点进行同步，同步该区块，并对区块中的每个交易进行验证，如果发现有交易是本地队列已经有的，就将该交易从自己的队列里剔除。
又有了新的困惑，不是说验证只需要查默克尔树吗，为何要对每笔交易都验证？按理说是需要验证每笔交易，这样才能有效剔除自己队列中的交易。那么，是不是在后期查询中需要默克尔树呢？
下一步的解惑。