作者：雾月，极客Web3
12月17日时，我知道Celestia上要出铭文CIAS，打算临时赶工写一个刷铭文的脚本。现在，对于Celestia及其所在的Cosmos生态，还有CIAS这个活动本身，我都有挺多想吐槽的。
其实，写一个刷铭文的脚本不难，主要分为三个模块：钱包构建、连接节点、泛洪交易。前两步只需要在目标公链的开发者文档里，就能找到快速实现的方法。
我先去Celestia官网和Github看了一圈，并没有面向开发者build用户场景的用例，主要都是节点运行等相关的文档。当然这可以理解，因为Celestia并不是一个ToC的区块链。Celestia只是在一个不起眼的地方，提到自己是基于Cosmos的，用CosmJS就可以与其主网交互。
于是我就直奔CosmJS。但Cosmos怎么说呢，连文档都做不好。我直接去的Github，按常理说，一般这种JS都会在Github上有使用用例。但它的教程隐藏在一个二级页面里，而且点进去以后，按照它的配置做一通，最后报错。
这报错还不是环境问题，是因为它的教程没有跟随教程版本更新，经常这个类名字改了那个调不了等等。我在老的教程版本上切换了npm库的版本，依然有些用例跑不通，折腾了一会就放弃了。
于是又谷歌了一下，结果发现正确的文档在官网而不是Github上，这有点不符合常理。再次，Github的readme更新一下教程指向官网不好吗？
拿到正确的教程后，我迅速完成了钱包构建、连接节点这两个步骤，开始构建泛洪交易模块。这个模块说简单了就是一个处理交易签名+网络请求的for循环。但这里却又碰上一些问题：
CosmJS库里所有的交易方法，都只暴露出了交易本身的参数，但它的sequence却没有暴露出来（sequence类比于以太坊里的nonce，是为了防止重放攻击而设置的交易计数器，每笔交易发出后，nonce和sequence都自动+1）。
Sequence居然是它在sign签名的时候去连接网络获取（chainId等也是），要经过sendTokens() -> signAndBroadCast -> sign()。每次提交交易都去网络请求等待返回会影响刷的速度，也会增加没用的网络请求，对于泛洪是不利的，当然也不利于加速/取消某笔交易。
我们可以回顾下以太坊Web3JS的发送交易的方法，其中你可以自己指定nonce。但CosmJS里不可以。我还是觉得以太坊的设计要合理很多，可以直接指定nonce用于取消/加速交易，如果一笔交易卡住了，你可以自定义一个nonce相同的交易去替代卡住的交易，当然也可以用于我们的泛洪攻击。
由于时间很紧张，还有其他几个需要修改的库里的函数，我决定不使用Proxy去hook重写了，而是直接在CosmJS库里修改。
脚本触发泛洪交易的思路是，通过for循环不断的发起交易并生成签名，发送给RPC节点，发起一笔交易后sequence/nonce就+1，发起20笔交易后，再重新循环一个周期。
Sequence只在每次泛洪周期开始前，拉取到本地，不必像CosmJS库默认的那样，每次交易后都向节点重新请求一遍sequence。而chainId则写成固定的值，不必反复向节点请求。（编者注：这里的循环次数设置的比较低，显然作者还没那么暴力。某人在打Conflux铭文时，曾将每个周期的循环次数改为1000，每分钟差不多发出去200笔不同的交易）
最终，我得到了一个简陋的Celestia脚本，12月17日当晚CIAS拔网线后，我简单测试了一下这个脚本，发出去了几百笔交易。在12月19日凌晨CIAS继续开打后，我确实打到了一些CIAS（大概1800个）。但还是有其他要吐槽的地方：
12月17日，Celestia的RPC节点出现了数据严重不同步的问题，不同RPC节点的区块高度差异很大，你向节点请求自己账户的Sequence时，返回的结果基本不一致，让人很痛苦。Celestia区块浏览器也不可用，基本抓瞎。可以说，此时Celestia网络虽然没宕机，还能出块，但估计也快到极限了。当天，CIAS铭文官方眼见Celestia快扛不住，临时宣布48460号区块高度后上链的铭文铸造交易全部无效，颇有“交易所拔网线”之风。而且CIAS自己的网站也崩了。
总体下来，12月17日当晚的体验就是一句话：Celestia当时肯定没做好应对大规模流量的举措，在RPC节点配置方面也很敷衍（很难想象1小时就能打炸几十号RPC节点）。
19号当晚这种情况好了很多，除了gas费飙涨之外，其他方面倒没什么太大问题，只能说Celestia作为一个专门给轻节点分发数据的DA网络，暂时性的经受住了考验，但不知道以后还会不会有什么别的坑。
