区块链中文技术社区 - 2021年12月
type: channel
link: https://bcskill.com/index.php/2021/12/
description: 区块链,EOS,Ethereum,IPFS,Dapp技能学习
items: Go多个pkg的单元测试覆盖率
items: 什么是以太坊eth伦敦升级?会带来哪些改变?
items: Transaction gasPrice (0) is too low for the next block, which has a baseFeePerGas of
items: ubuntu更新软件源报错： Certificate verification failed: The certificate is NOT trusted.
items: ubuntu 挂载新磁盘
items: go api restful 相关代码
items: 了解 Geth 客户端：快照加速机制
items: Goland crack

Go多个pkg的单元测试覆盖率
type: item
date: 2021-12-31T17:34:53+08:00
description: 在go test命令后面添加 -cover参数开启测试覆盖率统计，其结果如下： ok models 0.012s coverage: 71.4% of statements in models -coverpkg 标记来指定要被统计的代码包之后，未被指定的代码则肯定不会被统计，即使是被直接测试的那个代码包。go test -coverpkg=./... pkg2可以跑pkg2下的所有单元测试及pkg2所用到的其他包的覆盖率情况。 但是由于go不支持go test -coverpkg=./... ./...如果我们有多个pkg，则无法一次性统计出所有的测试覆盖率和跑完全部单元测试。所以需要挨个跑完单元测试然自己来合并覆盖率的结果： src ├── pkg1 │ ├── pkg11 │ └── pkg12 └── pkg2 ├── pkg21 └── pkg22 go test -coverprofile=pkg1.cover.out -coverpkg=./... pkg1 go test -coverprofile=pkg1.cover.out -coverpkg=./... pkg2 -coverprofile用来指定统计测试覆盖率信息的输出路径，其内容如下： mode: set models/bot.go:32.40,46.18 12 1 models/bot.go:49.2,57.35 5 1 ... 第一行是测试覆盖的mode，可取值为：set,count,atomic。剩下的行遵循以下的格式： name.go:line.column,line.column numberOfStatements count 所以对每个pkg跑完单元测试后可以用以下的命令来合并： echo "mode: set" > coverage.out && cat *.cover.out | grep -v mode: | sort -r | \ awk '{if($1 != last) {print $0;last=$1}}' >> coverage.out 然后用go自带的工具来将其输出为HTML： go tool cover -html=coverage.out -o cover.html 把整个流程串起来写成脚本如下： #!/bin/bash set -e profile="cover.out" htmlfile="cover.html" mergecover="merge_cover" mode="set" for package in $(go list ./...|grep -v src); do coverfile="$(echo $package | tr / -).cover" go test -covermode="$mode" -coverprofile="$coverfile" -coverpkg="$package" "$package" done # merge all profiles grep -h -v "^mode:" *.cover | sort > $mergecover # aggregate duplicated code-block data echo "mode: $mode" > $profile current="" count=0 while read line; do block=$(echo $line | cut -d ' ' -f1-2) num=$(echo $line | cut -d ' ' -f3) if [ "$current" == "" ]; then current=$block count=$num elif [ "$block" == "$current" ]; then count=$(($count + $num)) else echo $current $count >> $profile current=$block count=$num fi done < $mergecover if [ "$current" != "" ]; then echo $current $count >> $profile fi # save result go tool cover -html=$profile -o $htmlfile go tool cover -func=$profile 转载自：https://singlecool.com/2017/06/11/golang-test/

什么是以太坊eth伦敦升级?会带来哪些改变?
type: item
date: 2021-12-31T10:09:36+08:00
description: 在过去数月里，以太坊核心开发者一直在进行伦敦网络升级的工作。它是继柏林升级（四月在主网实现分叉）后的一次升级。尽管各个网络的升级区块高度目前还未定，但纳入伦敦升级的 EIP 已经确定了。根据升级规范，EIP 如下： ➤ EIP-1559: Eth1.0 费用市场变更 ➤ EIP-3198: BASEFEE 操作码 ➤ EIP-3529: 减少gas返还 ➤ EIP-3541: 拒绝以 0xEF 字节开头的新地址 ➤ EIP-3554: 难度炸弹延迟至 2021 年 12 月 现在看看每个 EIP 的详细内容吧！ EIP-1559: Eth1.0 费用市场变更 EIP-1559 是以太坊史上最令期待的变更之一，也是伦敦升级里带来最大变更的EIP。这份 EIP 将在网络区块里引入“基本费用 (basefee)"，它会追踪 gas 价格，这些价格来自网络将接受的、基于对区块空间需求的交易。这意味着钱包和用户将可以更容易预测他们交易的价格。另外，EIP-1559 新增了一种交易类型，用户可以指定他们愿意支付的最高限额，当他们把这个最高限额费用发送给矿工时，会获得最高限额费用减去基本费用与矿工小费之和的差值退款。最后，这份 EIP 还将导致部分交易费被烧毁，这一点被社区的大部分人认为是以太坊网络经济上的一个重要改善举措。 一篇简单的文章难以涵盖EIP-1559 的机制、裨益与影响。这份清单汇总了这份 EIP 各方面内容。还有关于 EIP-1559 的一期 PEEPanEIP， 这是完整视频。 EIP-3198: BASEFEE 操作码 这份 EIP 是与 EIP-1559 搭配的。它只是简单添加了一个BASEFEE操作码，它返回的是执行交易所在的区块的基本费用。这将使得智能合约可以在链上访问这个值，这有助于提交欺诈证明和创建去信任的 gas 价格衍生品。通过这期由Ratan Rai Sur 主讲的 PEEPanEIP，读者可以对这份 EIP 有一个全面的认识。 EIP-3529: 减少 gas 返还 在伦敦引入的另一个重大变更是取消了操作码SELFDESTRUCT 的 gas 返还和减少了操作码 SSTORE 的 gas 返还。虽然设立返还的初衷是希望激励开发者在可能的情况下清除状态，然而现实是，这导致了Gas Token的出现，反而增加了状态大小。利用这些返还的 gas，Gas Token 可以在 gas 价格很低的时候填满状态，然后在 gas 价格上升的时候获得执行这些交易的返还。 除此外，gas 返还还会导致区块执行时间的变化。在伦敦升级之前，多达 50% 的返还 gas 可以在同一个区块里进一步执行计算。也就是说，在实际上，最大的区块容量可达 1.5 倍的 gas limit。EIP-2539 把"执行 gas 返还"从 50% 下调到最多 20%。这一变更将有助于抵消由 EIP-1559 引入的额外区块大小变化，因为 EIP-1559 允许区块使用的 gas 是现在 gas limit 的两倍。 EIP-3541: 拒绝以 0xEF 字节开头的新地址 EIP-3541 是一个简单的变更，为以后更广泛的 EVM 改善奠定基础，想看 EIP-3540。这份 EIP 将使得以 0xEF 比特开头的新合约无法部署。现有的合约将不受影响。主网进行伦敦升级后，以 0xEF 开头的最短字节序列与现有合约的开头序列并不匹配，它们可以保留作为识别与 EIP-3540 语义相符的合同的方式。请注意：EIP-3540 将要求一次额外的网络升级来部署。值得注意的是，如果 EIP-3540 从未被部署，EIP-3541保留下来的开头字节也在其他方案里使用。 EIP-3554：2021难度炸弹延迟至2021年12月 EIP-3554 延迟难度炸弹，也以冰河时代为人所知。难度炸弹或冰河时代是以太坊引入的一种机制，在网络过渡到权益证明时”冻结“挖矿。由于权益证明的过渡还未准备好，我们需要推迟炸弹的”爆炸“时间。这在过去已经进行过三次：在大都会(EIP-649)、君士坦丁堡 (EIP-1234) 和穆尔冰川 (EIP-2384)。 尽管之前的延迟时间都相当长，但这次核心开发者选择了较短时间的延迟，把难度炸弹推迟到2021年12月。到时，网络不是要进行到权益证明的过渡就是另一次网络升级。 这就是纳入伦敦升级的整个变更列表了。测试网的升级区块高度和相关的客户端发布版本很快会在以太坊基金会博客上发布。 转载自：https://zhuanlan.zhihu.com/p/388789965

Transaction gasPrice (0) is too low for the next block, which has a baseFeePerGas of
type: item
date: 2021-12-29T16:28:51+08:00
description: 问题描述 为了对比数据方便，排除发起交易gas消耗引起的账户余额差别，会将hardhat test 脚本中设置发起交易，设置gasPrice：0 await contract.withdraw({from: accounts[15], gasPrice: 0}) 执行hardhat test时报以下错误 Transaction gasPrice (0) is too low for the next block, which has a baseFeePerGas of 8 解决方案 hardhat-config.js中设置initialBaseFeePerGas: 0 networks: { hardhat: { ... initialBaseFeePerGas: 0 } } 参考 https://github.com/nomiclabs/hardhat/issues/1216 https://github.com/nomiclabs/hardhat/blob/8e219bfc4112488953508eddd826d537bc71e803/docs/hardhat-network/reference/README.md

ubuntu更新软件源报错： Certificate verification failed: The certificate is NOT trusted.
type: item
date: 2021-12-27T11:45:06+08:00
description: sudo apt install ca-certificates sudo apt-get update 参考 https://blog.csdn.net/sinat_38800908/article/details/102839087

ubuntu 挂载新磁盘
type: item
date: 2021-12-27T09:55:00+08:00
description: 查看是否有没有挂载的磁盘lsblk 格式化sudo mkfs.xfs /dev/vdb 3.进行挂载 sudo mount /dev/vdb /data 4.查看是否挂载成功 df -h 5.查看UUID lsblk -f NAME FSTYPE LABEL UUID FSAVAIL FSUSE% MOUNTPOINT sr0 iso9660 config-2 2021-12-23-15-00-00-00 vda ├─vda1 └─vda2 ext4 b986dc3b-6b82-44d5-acb8-6cbad5e357d5 42.9G 9% / vdb ext4 0a3f332c-78d4-46dc-9843-c953447d048f 933.2G 0% /data 6.通过修改/etc/fstab实现自动挂载，添加如下配置即可 sudo vi /etc/fstab UUID=0a3f332c-78d4-46dc-9843-c953447d048f /data ext4 defaults 0 0 添加完成后，执行sudo mount -a 即可生效 参考文档 https://www.cnblogs.com/logBlog/p/11981761.html https://blog.51cto.com/u_12348890/2092339

go api restful 相关代码
type: item
date: 2021-12-25T15:09:00+08:00
description: https://github.com/emicklei/go-restful https://github.com/emicklei/go-restful-openapi https://blog.csdn.net/whatday/article/details/109278845

了解 Geth 客户端：快照加速机制
type: item
date: 2021-12-16T14:47:07+08:00
description: 本文为 Geth 客户端有问必答系列的第一篇文章，大家可以就 Geth 客户端的问题踊跃提问，我会每周用一篇小文章回答得票最高的问题。本周呼声最高的问题是：你能说说 flat 数据库结构与 legacy 结构的主要区别吗？ 以太坊的状态 在深入了解加速结构（acceleration structure）之前，我们先回顾一下以太坊的 “状态” 概念、在涉及到不同层次的抽象时又是如何存储的。 以太坊有两种不同类型的状态：账户的集合；每一合约账户存储槽的集合。从 完全抽象的角度 来看，两种数据都是 键-值 对。账户集合把地址映射到该地址的 nonce、余额，等等。而一个合约的存储领域把任意的值（由该合约定义并使用）映射到某个值。 但糟糕的是，虽然把这些键值对存储成扁平数据（flat data）可以非常高效，但验证它们的正确性在计算上就会变得很难。每当对数据修改时，我们都要自下而上对所有数据做哈希运算。 为免去总是对整个数据库做哈希运算的需要，我们可以把数据库分割成连续的小片，然后建立出一种树状结构！最原始、最有用的数据就放在叶子节点上，然后树上每一个内部节点都是该节点以下内容的哈希值。如此一来，当我们要修改某些值时，就只需做对数次的哈希运算。这种数据结构其实有一个路人皆知的名字，就是 “默克尔树”。 但还没完，这种办法在计算复杂性上还是有所欠缺。默克尔树结构虽然在修改现有数据时非常高效，但是，如果插入数据和删除数据会更改底层小数据块的边界，那就会让所有已经算好的哈希值全都变为无效。 这时候，与其盲目地对数据库分组，我们可以使用键本身来组织数据、基于共同前缀将数据都安排到树状格式中！这样插入和删除操作都不会影响到所有节点，只会影响到从树根到叶子路径上的（对数个）节点。这种数据结构就叫 “帕特里夏树”。 把上面两种办法合在一起 —— 帕特里夏树的树状分层和默克尔树的哈希算法 —— 就是所谓的 “默克尔-帕特里夏树”，也是实践中用于代表以太坊状态的数据结构。无论是修改、插入、删除还是验证，都只有对数复杂度！唯一的小小例外是，有些键会在插入前做哈希运算（存入树中），以平衡整棵树（A tiny extra is that keys are hashed before insertion to balance the tries）。 以太坊的状态存储 上文解释了为什么以太坊要用默克尔帕特里夏树结构来存储其状态。遗憾的是，虽然所需操作的速度都很快，但每一种选择都有所牺牲。更新操作和验证操作的对数复杂性 意味着对 每一个单独的密钥 的读取和存储都是对数复杂的（logarithmic reads and logarithmic storage）。这是因为树状结构的每一个内部节点都要单独保存在硬盘上。 此时此刻，账户树的深度确切是多少我不知道，但在大约一年以前，账户状态就已填满了 7 层高的树。这就意味着，每一次树操作（例如读取余额、写入 nonce）都要触达至少 7～8 个内部节点，因此会做至少 7～8 次持久数据库访问（persistent database accesses）。LevelDB 组织数据时最多也是 7 层，所以还有一个额外的乘数。最终的结果是，单次 状态访问预计会放大为 25～50 次随机的 硬盘访问。你再乘上一个区块中的所有交易的所有状态读取和写入，你会得到一个 吓人 的数字。 [当然，所有客户端实现都在尽力降低开销。Geth 使用更大的内存区域来缓存树节点；还使用了内存内的修剪机制、避免将几个块之后就会删除的数据写入硬盘。不过这需要另外一篇文章才能讲清楚。] 可怕之处还在于，这个数字就是运行一个以太坊节点、保证能全时验证所有状态的成本。 我们能做得更好一点吗？ 并不是所有访问都要一视同仁 以太坊的运行依赖于对状态的密码学证明。只要我们还想保持对所有数据的验证能力，就绕不开硬盘读写放大问题。也就是说，我们 —— 可以并且也事实上 —— 相信我们已经验证过的数据。 不断重复验证每一个状态物是没有意义的，但如果每次从硬盘中拉取数据都要验证一次的话，就是在做这样没有意义的事。默克尔帕特里夏树结构本质上是为写入操作设计的，但反过来就成了读取操作的负担。我们摆脱不了它，也无法让它瘦身，但 这绝不意味着 我们在每一个场合都必须使用它。 以太坊节点访问状态的场景可大致分为以下三类： 在导入一个新区块的时候，EVM 代码的执行会产生或多或少基本平衡的状态读取和写入次数。不过，一个用于拒绝服务式攻击的区块可能会产生远多于写入操作的读取操作次数。 当节点运营者检索状态的时候（例如调用 eth_call 及类似操作），EVM 代码执行仅产生读取操作（当然也可能有写入操作，但这些操作产生的数据最终会丢弃掉，不会持久化到硬盘里面）。 当节点在同步区块链的时…

Goland crack
type: item
date: 2021-12-15T09:22:00+08:00
description: https://www.macwk.com/article/jetbrains-crack https://macwk.com/soft/goland 仅供学习推荐