一文读懂以太坊—ETH2.0,是否值得长期持有?
ETH 2.0 的影响：以太坊网络用户会很高兴，因为 ETH 将改变其费用结构，用户将为交易支付更少的费用。这意味着当前的矿工将减少每笔交易的新包含费用，而不是以太坊的拍卖式费用市场，但预计由于 PoS 的能源效率提高和数量的增加，他们的每笔交易成本将下降。由于成本较低，用户和验证者都受益，因此交易量会更高。
ETH 2.0 降低的成本和更高的速度将使更多类型的 Defi 交易成为可能，并为新的和不同类型的安全令牌、NFT 和其他分布式金融应用程序提供机会，这些应用程序在 ETH 1.0 中没有经济意义。
ETH 2.0 还将允许使用零知识汇总和乐观汇总的更复杂和更便宜的智能合约。通过汇总，所有交易数据都以比使用常规基于区块链的交易更便宜的方式捆绑并在以太坊上可用。汇总所需的计算负载是在链下完成的，进一步提高了吞吐量和交易成本效率。
分片将使网络民主化，最终使普通用户能够在个人设备上操作以太坊。越来越多的网络参与者将进一步分散区块链。ETH 的发行量也会减少；ETH 联合创始人 Vitalik Buterin 曾表示，在 ETH 2.0 下，新代币的发行量应在每年 10 万至 200 万之间，低于目前的每年 470 万，这可能会增加硬币需求。
总结：
ETH 2.0 升级将使这个有益的全球去中心化智能合约系统能够以其速度、安全性和可靠性的愿景向前发展，减少其碳足迹，并为投资者提供公平的竞争环境，通过赌注他们对 ETH 的未来拥有民主发言权以太坊。以太坊 2.0 是对已经最广泛用于智能合约的区块链网络的必要升级。随着加密货币、智能合约 Dapp 和 NFT 的接受度不断增长，以太坊 2.0 网络的可扩展性无疑将吸引更多用户，使其成为首选服务。
用Go来做以太坊开发⑤事件日志
智能合约具有在执行期间“发出”事件的能力。 事件在以太坊中也称为“日志”。 事件的输出存储在日志部分下的事务处理中。 事件已经在以太坊智能合约中被广泛使用，以便在发生相对重要的动作时记录，特别是在代币合约（即ERC-20）中，以指示代币转账已经发生。 这些部分将引导您完成从区块链中读取事件以及订阅事件的过程，以便交易事务被矿工打包入块的时候及时收到通知。
为了订阅事件日志，我们需要做的第一件事就是拨打启用websocket的以太坊客户端。 幸运的是，Infura支持websockets。
下一步是创建筛选查询。 在这个例子中，我们将阅读来自我们在之前课程中创建的示例合约中的所有事件。
我们接收事件的方式是通过Go channel。 让我们从go-ethereum core/types 包创建一个类型为 Log 的channel。
现在我们所要做的就是通过从客户端调用 SubscribeFilterLogs 来订阅，它接收查询选项和输出通道。 这将返回包含unsubscribe和error方法的订阅结构。
最后，我们要做的就是使用select语句设置一个连续循环来读入新的日志事件或订阅错误。
我们会在下个章节介绍如何解析日志。
Commands
Store.sol
event_subscribe.go
智能合约可以可选地释放“事件”，其作为交易收据的一部分存储日志。读取这些事件相当简单。首先我们需要构造一个过滤查询。我们从go-ethereum包中导入 FilterQuery 结构体并用过滤选项初始化它。我们告诉它我们想过滤的区块范围并指定从中读取此日志的合约地址。在示例中，我们将从在 智能合约章节 创建的智能合约中读取特定区块所有日志。
下一步是调用ethclient的 FilterLogs ，它接收我们的查询并将返回所有的匹配事件日志。
返回的所有日志将是ABI编码，因此它们本身不会非常易读。为了解码日志，我们需要导入我们智能合约的ABI。为此，我们导入编译好的智能合约Go包，它将包含名称格式为
现在我们可以通过日志进行迭代并将它们解码为我么可以使用的类型。若您回忆起我们的样例合约释放的日志在Solidity中是类型为 bytes32 ，那么Go中的等价物将是 [32]byte 。我们可以使用这些类型创建一个匿名结构体，并将指针作为第一个参数传递给解析后的ABI接口的 Unpack 函数，以解码原始的日志数据。第二个参数是我们尝试解码的事件名称，最后一个参数是编码的日志数据。
此外，日志结构体包含附加信息，例如，区块摘要，区块号和交易摘要。
若您的solidity事件包含 indexed 事件类型，那么它们将成为 主题 而不是日志的数据属性的一部分。在solidity中您最多只能有4个主题，但只有3个可索引的事件类型。第一个主题总是事件的签名。我们的示例合约不包含可索引的事件，但如果它确实包含，这是如何读取事件主题。
正如您所见，首个主题只是被哈希过的事件签名。
这就是阅读和解析日志的全部内容。要学习如何订阅日志，阅读上个章节。
命令
Store.sol
event_read.go
首先，创建ERC-20智能合约的事件日志的interface文件 erc20.sol :
然后在给定abi使用 abigen 创建Go包
现在在我们的Go应用程序中，让我们创建与ERC-20事件日志签名类型相匹配的结构类型：
初始化以太坊客户端
按照ERC-20智能合约地址和所需的块范围创建一个“FilterQuery”。这个例子我们会用 ZRX 代币:
用 FilterLogs 来过滤日志：
接下来我们将解析JSON abi，稍后我们将使用解压缩原始日志数据：
为了按某种日志类型进行过滤，我们需要弄清楚每个事件日志函数签名的keccak256哈希值。 事件日志函数签名哈希始终是 topic [0] ，我们很快就会看到。 以下是使用go-ethereum crypto 包计算keccak256哈希的方法：
现在我们将遍历所有日志并设置switch语句以按事件日志类型进行过滤：
现在要解析 Transfer 事件日志，我们将使用 abi.Unpack 将原始日志数据解析为我们的日志类型结构。 解包不会解析 indexed 事件类型，因为它们存储在 topics 下，所以对于那些我们必须单独解析，如下例所示：
Approval 日志也是类似的方法：
最后，把所有的步骤放一起：
我们可以把解析的日志与etherscan的数据对比:
Commands
erc20.sol
event_read_erc20.go
solc version used for these examples
要读取 0x Protocol 事件日志，我们必须首先将solidity智能合约编译为一个Go包。
安装solc版本 0.4.11
为例如 Exchange.sol 的事件日志创建0x Protocol交易所智能合约接口:
Create the 0x protocol exchange smart contract interface for event logs as Exchange.sol :
接着给定abi，使用 abigen 来创建Go exchange 包：
Then use abigen to create the Go exchange package given the abi:
现在在我们的Go应用程序中，让我们创建与0xProtocol事件日志签名类型匹配的结构体类型：
初始化以太坊客户端：
创建一个 FilterQuery ，并为其传递0x Protocol智能合约地址和所需的区块范围：
用 FilterLogs 查询日志：
接下来我们将解析JSON abi，我们后续将使用解压缩原始日志数据：
为了按某种日志类型过滤，我们需要知晓每个事件日志函数签名的keccak256摘要。正如我们很快所见到的那样，事件日志函数签名摘要总是 topic[0] ：
现在我们迭代所有的日志并设置一个switch语句来按事件日志类型过滤：
现在要解析 LogFill ，我们将使用 abi.Unpack 将原始数据类型解析为我们自定义的日志类型结构体。Unpack不会解析 indexed 事件类型，因为这些它们存储在 topics 下，所以对于那些我们必须单独解析，如下例所示：
对于 LogCancel 类似：
最后是 LogError ：
将它们放在一起并运行我们将看到以下输出：
将解析后的日志输出与etherscan上的内容进行比较： https://etherscan.io/tx/0xb73a4492c5db1f67930b25ce3869c1e6b9bdbccb239a23b6454925a5bc0e03c5
命令
Exchange.sol
event_read_0xprotocol.go
这些示例使用的solc版本
ethtool原理介绍和解决网卡丢包排查思路
之前记录过处理因为LVS网卡流量负载过高导致软中断发生丢包的问题， RPS和RFS网卡多队列性能调优实践 ，对一般人来说压力不大的情况下其实碰见的概率并不高。这次想分享的话题是比较常见服务器网卡丢包现象排查思路，如果你是想了解点对点的丢包解决思路涉及面可能就比较广，不妨先参考之前的文章 如何使用MTR诊断网络问题 ，对于Linux常用的网卡丢包分析工具自然是ethtool。
2020年06月22日 - 初稿
阅读原文 - https://wsgzao.github.io/post/ethtool/
ethtool - utility for controlling network drivers and hardware
ethtool is the standard Linux utility for controlling network drivers and hardware, particularly for wired Ethernet devices. It can be used to:
Most features are dependent on support in the specific driver. See the manual page for full information.
ethtool 用于查看和修改网络设备（尤其是有线以太网设备）的驱动参数和硬件设置。你可以根据需要更改以太网卡的参数，包括自动协商、速度、双工和局域网唤醒等参数。通过对以太网卡的配置，你的计算机可以通过网络有效地进行通信。该工具提供了许多关于接驳到你的 Linux 系统的以太网设备的信息。
接收数据包是一个复杂的过程，涉及很多底层的技术细节，但大致需要以下几个步骤：
NIC 在接收到数据包之后，首先需要将数据同步到内核中，这中间的桥梁是 rx ring buffer 。它是由 NIC 和驱动程序共享的一片区域，事实上， rx ring buffer 存储的并不是实际的 packet 数据，而是一个描述符，这个描述符指向了它真正的存储地址，具体流程如下：
当驱动处理速度跟不上网卡收包速度时，驱动来不及分配缓冲区，NIC 接收到的数据包无法及时写到 sk_buffer ，就会产生堆积，当 NIC 内部缓冲区写满后，就会丢弃部分数据，引起丢包。这部分丢包为 rx_fifo_errors ，在 /proc/net/dev 中体现为 fifo 字段增长，在 ifconfig 中体现为 overruns 指标增长。
这个时候，数据包已经被转移到了 sk_buffer 中。前文提到，这是驱动程序在内存中分配的一片缓冲区，并且是通过 DMA 写入的，这种方式不依赖 CPU 直接将数据写到了内存中，意味着对内核来说，其实并不知道已经有新数据到了内存中。那么如何让内核知道有新数据进来了呢？答案就是中断，通过中断告诉内核有新数据进来了，并需要进行后续处理。
提到中断，就涉及到硬中断和软中断，首先需要简单了解一下它们的区别：
当 NIC 把数据包通过 DMA 复制到内核缓冲区 sk_buffer 后，NIC 立即发起一个硬件中断。CPU 接收后，首先进入上半部分，网卡中断对应的中断处理程序是网卡驱动程序的一部分，之后由它发起软中断，进入下半部分，开始消费 sk_buffer 中的数据，交给内核协议栈处理。
通过中断，能够快速及时地响应网卡数据请求，但如果数据量大，那么会产生大量中断请求，CPU 大部分时间都忙于处理中断，效率很低。为了解决这个问题，现在的内核及驱动都采用一种叫 NAPI（new API）的方式进行数据处理，其原理可以简单理解为 中断 + 轮询，在数据量大时，一次中断后通过轮询接收一定数量包再返回，避免产生多次中断。
(1) RX errors
表示总的收包的错误数量，这包括 too-long-frames 错误，Ring Buffer 溢出错误，crc 校验错误，帧同步错误，fifo overruns 以及 missed pkg 等等。
(2) RX dropped
表示数据包已经进入了 Ring Buffer，但是由于内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
(3) RX overruns
表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显，overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一，上面那台有问题的机器就是因为 interruprs 分布的不均匀(都压在 core0)，没有做 affinity 而造成的丢包。
(4) RX frame
表示 misaligned 的 frames。
网线上的packet首先被网卡获取，网卡会检查packet的CRC校验，保证完整性，然后将packet头去掉，得到frame。网卡会检查MAC包内的目的MAC地址，如果和本网卡的MAC地址不一样则丢弃(混杂模式除外)。
网卡将frame拷贝到网卡内部的FIFO缓冲区，触发硬件中断。（如有ring buffer的网卡，好像frame可以先存在ring buffer里再触发软件中断（下篇文章将详细解释Linux中frame的走向），ring buffer是网卡和驱动程序共享，是设备里的内存，但是对操作系统是可见的，因为看到linux内核源码里网卡驱动程序是使用kcalloc来分配的空间，所以ring buffer一般都有上限，另外这个ring buffer size，表示的应该是能存储的frame的个数，而不是字节大小。另外有些系统的 ethtool 命令 并不能改变ring parameters来设置ring buffer的大小，暂时不知道为什么，可能是驱动不支持。）
网卡驱动程序通过硬中断处理函数，构建sk_buff，把frame从网卡FIFO拷贝到内存skb中，接下来交给内核处理。（支持napi的网卡应该是直接放在ring buffer，不触发硬中断，直接使用软中断，拷贝ring buffer里的数据，直接输送给上层处理，每个网卡在一次软中断处理过程能处理weight个frame）
过程中，网卡芯片对frame进行了MAC过滤，以减小系统负荷。（除了混杂模式）
网卡驱动程序将IP包添加14字节的MAC头，构成frame（暂无CRC）。Frame（暂无CRC）中含有发送端和接收端的MAC地址，由于是驱动程序创建MAC头，所以可以随便输入地址，也可以进行主机伪装。
驱动程序将frame（暂无CRC）拷贝到网卡芯片内部的缓冲区，由网卡处理。
网卡芯片将未完全完成的frame（缺CRC）再次封装为可以发送的packet，也就是添加头部同步信息和CRC校验，然后丢到网线上，就完成一个IP报的发送了，所有接到网线上的网卡都可以看到该packet。
产生中断的每个设备都有一个相应的中断处理程序，是设备驱动程序的一部分。每个网卡都有一个中断处理程序，用于通知网卡该中断已经被接收了，以及把网卡缓冲区的数据包拷贝到内存中。
当网卡接收来自网络的数据包时，需要通知内核数据包到了。网卡立即发出中断。内核通过执行网卡已注册的中断处理函数来做出应答。中断处理程序开始执行，通知硬件，拷贝最新的网络数据包到内存，然后读取网卡更多的数据包。
这些都是重要、紧迫而又与硬件相关的工作。内核通常需要快速的拷贝网络数据包到系统内存，因为网卡上接收网络数据包的缓存大小固定，而且相比系统内存也要小得多。所以上述拷贝动作一旦被延迟，必然造成网卡FIFO缓存溢出 - 进入的数据包占满了网卡的缓存，后续的包只能被丢弃，这也应该就是ifconfig里的overrun的来源。
当网络数据包被拷贝到系统内存后，中断的任务算是完成了，这时它把控制权交还给被系统中断前运行的程序。
网卡的内核缓冲区，是在PC内存中，由内核控制，而网卡会有FIFO缓冲区，或者ring buffer，这应该将两者区分开。FIFO比较小，里面有数据便会尽量将数据存在内核缓冲中。
网卡中的缓冲区既不属于内核空间，也不属于用户空间。它属于硬件缓冲，允许网卡与操作系统之间有个缓冲；
内核缓冲区在内核空间，在内存中，用于内核程序，做为读自或写往硬件的数据缓冲区；
用户缓冲区在用户空间，在内存中，用于用户程序，做为读自或写往硬件的数据缓冲区；
另外，为了加快数据的交互，可以将内核缓冲区映射到用户空间，这样，内核程序和用户程序就可以同时访问这一区间了。
对于有ring buffer的网卡，ring buffer是由驱动与网卡共享的，所以内核可以直接访问ring buffer，一般拷贝frames的副本到自己的内核空间进行处理（deliver到上层协议，之后的一个个skb就是按skb的指针传递方式传递，直到用户获得数据，所以，对于ring buffer网卡，大量拷贝发生在frame从ring buffer传递到内核控制的计算机内存里）。
网卡工作在数据链路层，数据量链路层，会做一些校验，封装成帧。我们可以查看校验是否出错，确定传输是否存在问题。然后从软件层面，是否因为缓冲区太小丢包。
一台机器经常收到丢包的报警，先看看最底层的有没有问题:
(1) 查看工作模式是否正常
(2) 查看检验是否正常
Speed，Duplex，CRC 之类的都没问题，基本可以排除物理层面的干扰。
Why rx_crc_errors incrementing in the receive counter of ethtool -S output?
Check ethtool -S output and find where are the drops and errors.
Check the numbers corresponding to rx_crc_errors .
显示了p1p1 的接口类型，连接模式，速率等等信息，以及当前是否连接了网线（如果是网线Supported ports 就是TP，如果是光纤则显示Fiber），这里例举下3个重要关键词
Supported ports: [ FIBRE ]
Speed: 10000Mb/s
Link detected: yes
ethtool
Counters Troubleshooting for Linux Driver
Why do I see rx_crc_errors in ethtool output?
ping请求错误分析
ifconfig 命令详解
ethtool 命令详解
ethtool 解决网卡丢包严重和网卡原理
eth2.0还能挖矿吗
可以挖，但是记账方式从PoW转为PoS，质押ETH的方式挖矿，类似于IPFS的挖矿（代币是FIL），根据持有的币量和时间，产出BETH，可以1:1兑换成ETH，然后以太坊会进入通缩时代。产出按地址结算，每个地址质押上限是32个ETH，下限也是这个数目，才能参与挖矿，不排除未来会组建矿池，吸引散户加入，凑够32枚组建一台矿机。因为地址的分散性，有效的降低了主网被算力攻击的风险，一旦发现就没收质押币，成本巨大。通过这种方式，不怎么消耗电力，可谓清洁能源式挖矿，通缩时代也让囤币的矿工收益越来越大。截至2021年6月12日，以太坊2.0内测阶段，质押了545.09万枚ETH。
一、比特币挖矿机，就是用于赚取比特币的电脑，这类电脑一般有专业的挖矿芯片，多采用烧显卡的方式工作，耗电量较大。用户用个人计算机下载软件然后运行特定算法，与远方服务器通讯后可得到相应比特币，是获取比特币的方式之一。
二、2013年流行的数字货币有，比特币、莱特币、泽塔币、便士币(外网)、隐形金条、红币、极点币、烧烤币、质数币。目前全世界发行有上百种数字货币。
三、挖矿实际是性能的竞争、装备的竞争，由非常多张显卡组成的挖矿机，哪怕只是HD6770这种中低端显卡，"组团"之后的运算能力还是能够超越大部分用户的单张显卡的。而且这还不是最可怕的，有些挖矿机是更多这样的显卡阵列组成的，数十乃至过百的显卡一起来，显卡本身也是要钱的，算上硬件价格等各种成本，挖矿存在相当大的支出。
四、支取比特币需要多达数百位的密钥，而多数人会将这一长串的数字记录于电脑上，但经常发生的如硬盘损坏等问题，会让密钥永久丢失，这也导致了比特币的丢失。“粗略估计，丢失的比特币可能达到160多万个。比特币虽然标榜自己“防通货膨胀”，但是它却容易受到持有大量比特币的大庄家的控制，有贬值的风险，涨跌堪称过山车
数字货币在中国合法吗?
不合法。
央行提示称，尚未发行法定数字货币，也未授权任何机构和企业发行法定数字货币，无推广团队。目前市场上所谓“数字货币”均非法定数字货币。
此外，某些机构和企业推出的所谓“数字货币”以及所谓推广央行发行数字货币的行为可能涉及传销和诈骗。
扩展资料：
虚拟货币是非法币的电子化，其最初的发行者并不是央行。这类虚拟货币主要限于特定的虚拟环境里流通。而数字货币是可以被用于真实的商品和服务交易,但只有国家发行的数字货币才是法定数字货币。
2013年央行联合五部委曾发布《关于防范比特币风险的通知》，明确将比特币等非法定数字货币定义为虚拟商品，它不是以货币和法币形式存在。
参考资料：目前市场上所谓“数字货币”均非法定数字货币--人民网