分类 Crypto 下的文章

前言

节点稳定运行在版本 10.1.2 数个星期,尽管官方发布了 10.1.4 且 release note 第一段就加粗提示

It is recommended that all other node users upgrade to this version. Node users who do not upgrade put themselves at risk of a potential DoS attack following the hard fork.

我想着版本差距不大偷个懒,没跟进。然后就出事了。

今天一看节点全部不同步而且 P2P 下全部发现的周边节点都变成了Cold Peers, 而 Hot Peers 只剩下一个,而且一直处于无法同步满的状态。

完了。

  • 是新版本脱更主动排斥我的 10.1.2
  • 还是因为我所在的地区因为节点太稀少,或者被有意孤立(在 relays map 上我的节点确实是这96万平方公里独一份)
  • 还是因为如更新日志所说,我被攻击或意外分叉了呢

仔细想了想,前两项都是自己吓自己 ,按分叉的可能性做假设去求证,还好现在又deepseek ,一切处理起来轻松了许多,仿佛有几个大牛带着我干活。不用自己苦苦刨文档刷源码或者到各个国外论坛群组里跪求大佬解答。

好了,不啰嗦..开始正片

- 阅读剩余部分 -

随着版本迭代和 Conway 更新的上线,对运行节点的配置要求也水涨船高,目前为止 9.1.1 的配置要求是

Minimum System Requirements

  • An Intel or AMD x86 processor with two or more cores, at 1.6GHz or faster (2GHz or faster for a stake pool or relay)
  • Or, for MacOS, an Apple Silicon (M1, M2 or M3) processor
  • 24GB of RAM
  • 200GB of free storage (250GB recommended for future growth)

就内存和存储空间这两项,租用云服务器涨配置直接等同于加钱。
实施本地化部署部分节点后,变成一次性投入相对还好点。我这从最早期运营下来的节点,SSD从一开始 120G 升级到 256G,最近又因为空间不足又迫切需要升级到 512G 甚至 1T。

作为经典配置 1(block producer) + 2 (relay) + 1(test + cold wallet)
4个节点4台设备内存独立配置没有办法,但硬盘空间是否可以融合共享达到进一步节省成本的目的呢。

分析和试验了一下,还真可以!



- 阅读剩余部分 -

大活来了,从 1.35.* 升级到 8.*.*

一边操作一边备忘

概述

参考 247大佬的文章,做前置准备(链接在文末),主要是安装一些新的依赖,以及关键的两个

ghc要更新到 8.10.7 (在1.35.7版本已经升级满足)
cabal 需要更新到 3.8.1.0 (比较矛盾的一点,要升级到这个版本,需要ghc升级到 9.2.8)

因此,一个奇怪的顺序是
1 需要先升级ghc到 9.2.8,
2 然后升级cabal到 3.8.1.0
3 再次设置默认版本ghc为 8.10.7(降级)

最简单最理想的情况下,如无意外。做完前置准备。用官方已经编译好的bin文件直接替换就升级完了
需要自行编译的要进一步获取源码和配置

cntools是否需要配套更新待确认。

最优先目标是先把节点运行平顺过渡上 8.* 版本, stakepool 的管理工具功能的验证可以滞后。






- 阅读剩余部分 -

cnode 最近发布了 8.0.0 版本的更新,虽然是一个 mainnet release ,但没有打算那么早更新。只是打算作为提早了解的心态找个本地节点进行了尝试,没想到陷进去一整个晚上搞到焦头烂额。从下午一直反复试错,到现在得出结果已经是凌晨 1:26。淦!

主要发现的问题是cntools无法正常使用,表现在所有的wallet显示余额为0,无法对资金进行任何的操作。

按惯例先说结论

由于一个cntools的历史升级,改了查询余额的方式,改用了远程的API,而好死不死这个API因为某些原因在本地不好使。导致所有的资金操作卡死,因为任何的tx操作需要支付fee,余额0会直接导致失败。
提示

ERROR: payment and/or stake signing keys missing from wallet!

解决办法,根据官方的文档恢复旧方式查询(命令行查询 UTxOs 或使用本地部署那个远程API, 不去调用远端的API)


- 阅读剩余部分 -

其中一个relay节点,配置最低的一台。最近两个月不时掉线。掉线之后cnode进城自动重启后会清空 $CNODE/db/immutable/ 目录把整个区块链进行重新同步。
在同步过程耗费巨量时间之后可能在中途再度发生写入错误或者分叉,导致出错。周而复始又清空重新同步导致节点一直无法完成启动。而且持续大量写入SSD, 对硬件寿命和稳定性都造成严重的影响。

*先说结论,问题是否得到彻底解决未知,仍在观察中。具体操作直接跳到最后一段。

以下是这两个月来采取过的几个措施,收效一般。


- 阅读剩余部分 -