以太坊隐藏字段

『壹』 以太坊我是a段投资有风险吗

有风险。
因为虚拟财产在有的国家是受法律保护的。但大多数国家对于虚拟货币的监管力度还是不够的，这也使得投资虚拟货币存在较大的风险，所以投资者需要谨慎对待。
投资以太坊是安全的，所谓的不安全，主要是因为类似以太坊的数字货币是网络安全犯罪的热门目标，因为黑客能轻易地隐藏自己的踪迹，并且不受中央银行或政府的监管。由于加密货币没有实物商品的支持，被黑客攻击的投资者也就没有任何法律或刑事追索权。
其中一个最大的问题是，罪犯很难被抓获，因为他们藏匿于网络，并且抢劫也很猖獗。网络安全专家说，随着首次代币发行的数量增加，黑客黑入交易所，比如Coinbase或个人钱包等事件也反映了此类情况。全文导读：根据区块链数据显示，BitMEX交易所目前资产为32亿美元，共有14个交易对，币种数量为8个，24小时成交额为20.97亿美元，通过这些数据可以看出，BitMEX交易所还是比较受投资者欢迎的，不过对于部分投资者来说并不了解BitMEX。

『贰』 CentOS 中 /etc/sysconfig/network-scripts/ifcfg-eth0 中哪些字段是必须的 比如 NETWORK和BROADCAST

DEVICE=eth0
ONBOOT=yes
这两个是必备的。
如果你是自动获取ip，加上
BOOTPROTO=dhcp
如果是手动配置。
BOOTPROTO=static
IPADDR=xxxxx IP
NETMASK= 掩码
GATEWAY= 网关
DNS1= DNS

『叁』 以太坊区块链之Bug --2020/05/19

为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。注意这里的前提条件是相同的地址在相同的节点发送交易。

以下是nonce使用的几条规则：

● 当nonce太小（小于之前已经有交易使用的nonce值），交易会被直接拒绝。

● 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；

● 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。

● 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。

         第一个字段 AccountNonce ，直译就是账户随机数。它是以太坊中很小但也很重要的一个细节。以太坊为每个账户和交易都创建了一个Nonce，当从账户发起交易的时候，当前账户的Nonce值就被作为交易的Nonce。这里，如果是普通账户那么Nonce就是它发出的交易数，如果是合约账户就是从它的创建合约数。

为什么要使用这个Nonce呢？其主要目的就是为了防止重复攻击（Replay Attack）。因为交易都是需要签名的，假定没有Nonce，那么只要交易数据和发起人是确定的，签名就一定是相同的，这样攻击者就能在收到一个交易数据后，重新生成一个完全相同的交易并再次提交，比如A给B发了个交易，因为交易是有签名的，B虽然不能改动这个交易数据，但只要反复提交一模一样的交易数据，就能把A账户的所有资金都转到B手里。

当使用账户Nonce之后，每次发起一个交易，A账户的Nonce值就会增加，当B重新提交时，因为Nonce对不上了，交易就会被拒绝。这样就可以防止重复攻击。当然，事情还没有完，因为还能跨链实施攻击，直到EIP-155引入了chainID，才实现了不同链之间的交易数据不兼容。事实上，Nonce并不能真正防止重复攻击，比如A向B买东西，发起交易T1给B，紧接着又提交另一个交易T2，T2的Gas价格更高、优先级更高将被优先处理，如果恰好T2处理完成后剩余资金已经不足以支付T1，那么T1就会被拒绝。这时如果B已经把东西给了A，那A也就攻击成功了。所以说，就算交易被处理了也还要再等待一定时间，确保生成足够深度的区块，才能保证交易的不可逆。

Price 指的是单位Gas的价格，所谓Gas就是交易的消耗，Price就是单位Gas要消耗多少以太币（Ether），Gas * Price就是处理交易需要消耗多少以太币，它就相当于比特币中的交易手续费。

GasLimit 限定了本次交易允许消耗资源的最高上限，换句话说，以太坊中的交易不可能无限制地消耗资源，这也是以太坊的安全策略之一，防止攻击者恶意占用资源。

Recipient 是交易接收者，它是common.Address指针类型，代表一个地址。这个值也可以是空的，这时在交易执行时，会通过智能合约创建一个地址来完成交易。

Amount 是交易额。这个简单，不用解释。

Payload 比较重要，它是一个字节数组，可以用来作为创建合约的指令数组，这时每个字节都是一个单独的指令；也可以作为数据数组，由合约指令来进行操作。合约由以太坊虚拟机（Ethereum Virtual Machine，EVM）创建并执行。

V、R、S 是交易的签名数据。以太坊当中，交易经过数字签名之后，生成的signature是一个长度65的字节数组，它被截成三段，前32字节被放进R，再32字节放进S，最后1个字节放进V。那么为什么要被截成3段呢？以太坊用的是ECDSA算法，R和S就是ECSDA签名输出，V则是Recovery ID。

R,S,V是交易签名后的值，它们可以被用来生成签名者的公钥；R，S是ECDSA椭圆加密算法的输出值，V是用于恢复结果的ID

『肆』 以太坊交易(tx) 分析

更多请参考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相对应的，比如 60 对应就是 operation PUSH1,合约编译后的字节码即为一组的 operation 。

合约部署其实就是实例化一个 contract 对象，并将 data 的值设给 Code属性 。

创建合约的tx中，input字段对应的是合约的字节码，即指令数组。

其中 input 字段对应所要调用的函数签名的前四个字节（771602f7）以及对应的参数（1,2）

其中 input 字段为所要调用的合约函数签名的前四个字节（72a099b7）

关于函数调用，Call会把对应的Code读出来，依次解析，Code中会把所有的public签名的函数标志（4字节）push到栈里。然后依据 input 中需要调用函数的签名标志（前4字节）来匹配 Code， 匹配之后跳转到对应的 opcode 。

『伍』 以太坊中的国际银行账号iban

简单地说，以太坊中的iban账号是以太坊为了和传统的银行系统对接而引入的概念，web3.js中提供了以太坊地址和iban地址之间的转换方法。

iban这个概念源于传统的银行系统，其英文全称为 International Bank Account Number ，即国际银行帐号。iban的作用是为全球任意一家银行中的任意一个账户生成一个全球唯一的账号，以便进行跨行交易。一个iban账号看起来像这样：

iban地址最多可以包含34个字母和数字，其中的字母大小写不敏感。在iban
中包含以下信息：

以太坊引入了一个新的IBAN国别码：XE，其中E代表Ethereum，X代表非法币（non-jurisdictional currencies）。同时，以太坊提出了三种BBAN的编码格式：direct、basic和indirect。

direct编码方案中的BBAN为30个字母/数字，只有一个字段：账户编号。例如，以太坊地址 转换为direct方案的BBAN账号，就得到 。

可以使用web3.js中的 web3.eth.Iban.fromEthereumAddress()
方法来执行这一转换：

basic编码方案与direct方案的唯一区别在于，其BBAN长度为31个字母/数字，因此该方案不兼容IBAN。

indrect编码方案中的BBAN长度为16个字母/数字，包含三个字段：

例如，一个采用indrect编码方案的以太坊iban账号，看起来是这样：

前面的 XE 表示国别码， 81 为校验和，后面的16个字符就是indrect编码的BBAN，其中：

如前所述，使用 web3.eth.Iban.fromEthereumAddress() 方法，可以将一个以太坊地址转换为direct编码方案的iban账号。与之对应的，可以使用 web3.eth.Iban.toAddress 方法，将一个采用direct编码方案的iban账号，转换回以太坊地址。例如：

iban账号中的校验和用来帮助核验一个给定字符串是否为有效的iban账号。可以使用web3.js中的 web3.eth.Iban.isValid()
来进行执行校验。例如：

原文： http://blog.hubwiz.com/2018/06/03/ethereum-iban/

『陆』 以太币挖矿，用什么来挖

以太币挖矿教程

1、在硬盘上新建文件夹，比C:Eth。之后所有挖矿软件就存放在这里。

2、下载以下软件

1)Geth——选择Geth-Win下载然后解压

2)Ethminer——下载解压到同一个文件夹，重命名为“miner”

3)Ethereum Wallet(以太坊钱包)——下载Win以太坊钱包，解压之后重命名“wallet”

安装好所有软件

3、打开命令提示符(同时点击Win和R键或者点击开始菜单然后输入cmd)。命令提示符是命令行解析器，让你在操作系统中执行命令输入的软件。

之后你就拥有以太坊钱包了。但是没有余额，所以接下来你需要建立ethminer。暂时可以最小化钱包了。

挖矿

『柒』 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

『捌』 以太坊event log查询与解析

从 ethereum json-rpc文档 的文档中找到一个同时指定多个事件以 OR 或者 AND 查询的方法.以下是查询 Approval 或 Transfer 事件的方法：

topics 字段中指定查询条件的语法参考上面链接。

通过 getTransactionReceipt 在ropsten测试网上查询到交易号为 的交易详情

这个交易从 "from": "" 发送到合约地址 "to": "" .这个合约为ERC20代币合约.从 topics 的第一个元素可以看出合约中产生了 Transfer 事件(topics第一个元素一定是事件的keccak哈希). topics 的第二个字段是转出代币的地址，第三个字段是接收者地址.ERC20代币 Transfer 事件的签名为

我们注意到 Transfer 事件的第一个和第二个参数被标记为 indexed , 因此他们的值被放在 topics array 中. 由于tokens参数没有标记为 indexed , 所以他的值被放在 data 字段. 如果事件中有多个字段未标记为 indexed ， 那么他们的值都会被记录在 data 字段中。

『玖』 以太坊的ABI编码

ABI全称Application Binary Interface, 是调用智能合约函数以及合约之间函数调用的消息编码格式定义,也可以理解为智能合约函数调用的接口说明. 类似Webservice里的SOAP协议一样；也就是定义操作函数签名，参数编码，返回结果编码等。

使用ABI协议时必须要求在编译时知道类型,即强类型相关.

当一个智能合约编译出来后, 他的abi接口定义就确定了. 比如下面的智能合约:

生成的字节码:

生成的abi定义:

可以看出, 生成abi包含了2个定义: 函数 lotus , 事件 Log_lotus , 各个字段含义见上. 根据该abi定义,就可以生成调用该智能合约函数的abi格式的数据了.

格式简单的可以表示为: 函数选择器+参数编码

一个函数调用的前四个字节数据指定了要调用的函数签名。计算方式是使用函数签名的 keccak256 的哈希，取4个字节。

函数名如果有多个参数使用,隔开，要去掉表达式中的所有空格。在geth客户端,通过命令可以得到hash:

由于前面的函数签名使用了四个字节，参数的数据将从第五个字节开始。

根据参数类型,编码规则有所区别:

除了bytes,和string, 其他类型的数据不足32字节长度的需要加0补足32字节. 动态长度的编码在例子中介绍.

函数: function baz(uint32 x, bool y) :

调用: baz(69, true)

生成的数据如下:

返回结果是一个bool值，在这里，返回的是false:

函数: f(uint,uint32[],bytes10,bytes)

调用: (0x123, [0x456, 0x789], "1234567890", "Hello, world!")

函数选择器: bytes4(sha3("f(uint256,uint32[],bytes10,bytes)"))

对于 固定大小的类型 值 uint256 和 bytes10 ，直接编码值。

对于 动态内容类型 值 uint32[] 和 bytes ，我们先 编码偏移值 ，偏移值是整个值编码的开始到真正存这个数据的偏移值（这里不计算头四个用于表示函数签名的字节）。

所以参数编码数据依次为：

尾部部分的第一个动态参数， [0x456, 0x789] 编码拆解如下：

最后我们来看看第二个动态参数的的编码， Hello, world! 。

所以最终结果是:

『拾』 比特币区块里的各个字段含义(先写了个nonce)

nonce是个啥意思？根据bitcoin wiki

nonce是一个4-byte大小的区域，nonce的值设定使得该块的hash是以一串0开头的。
对于块数据的一点点改变（比如nonce）都会引起block hash的巨大变化。由于逆向预测hash值相对应的一组bit值（hash原文）是不可行的，在尝试足够多的nonce值且计算每个nonce值相对应的block hash之后可以找到一个满足有指定数量 0 bits (0比特位) 的hash值。而 0 bits的数量值是由difficult设定的。最终产生的hash须得是一个小于当前difficulty值。
因为这个迭代的计算耗费时间和资源，块的出现也就是得到了正确的nonce值，这构成了 proof of work

关于以太坊里的nonce 网上很多解释，很多一上来就是 交易计数器 ， 然而却把跟POW有关的丢了吗？事实上以太坊里的nonce有两种意思，一个是proof of work nonce，一个是account nonce。

那智能合约呢？合约也算是Account的一种，那也有nonce吗？

是的，而且合约里面的nonce也差不多，也是一个counter。在智能合约里，nonce的值代表的是该合约创建的合约数量。只有当一个合约创建另一个合约的时候才会增加nonce的值。但是当一个合约调用另一个合约中的method时 nonce的值是不变的。

在以太坊中nonce的值可以这样来获取（其实也就是属于一个账户的交易数量）：

但是这个方法只能获取交易once的值。目前是没有内置方法来访问contract中的nonce值的，除了自己定义一个counter来计数...

那好，再来看一下Ethereum Block中的nonce：
以太坊和比特币区块链一样，也需要proof of work（计划转移到股份证明也早已在做了）。在比特币区块链中，pow应该是要算出一个符合难度要求的值，通常是以一串0开头的。这个难度一直在变化。可以查看 比特币区块链的POW难度变化 。