写Celestia脚本后有感：Cosmos很多工作没搞好

作者：雾月，极客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网络虽然没宕机，还能出块，但估计也快到极限了。

  
  

  I know that there is going to be an inscription in the world when the author is a geek on the foggy month, and I plan to write a script to brush the inscription temporarily. Now I have a lot to say about the ecology where I live and the activity itself. In fact, it is not difficult to write a script to brush the inscription, which is mainly divided into three modules: wallet construction, connection node flooding transaction, and the first two steps only need to be found in the developer's document of the target public chain. I first went to official website and watched a circle of use cases that are not oriented to developers and users. Of course, this is understandable because it is not a new blockchain, but it can interact with its main network by mentioning that it is based on its use in an inconspicuous place, so I went straight to it, but I can't even do the document well. According to common sense, this kind of blockchain usually has use cases on the internet, but its tutorial is hidden in a secondary page, and after clicking on it, it will make a final error according to its configuration. This error is not an environmental problem, but it is because its tutorial is not available. With the update of the tutorial version, the name of this class is often changed, which can't be adjusted, and so on. I switched the version of the library on the old tutorial version, and some use cases still didn't work. After a while, I gave up, so I googled it and found that the correct document was in official website instead of on it. It's a bit unreasonable to update the tutorial again. Isn't it good to point to official website? After I got the correct tutorial, I quickly completed the two steps of wallet construction and started to build a flood trading module. This module is simple. It's a cycle of dealing with the network request of transaction signature, but here we encounter some problems. All the transaction methods in the database only expose the parameters of the transaction itself, but they are not exposed. Analogously, in Ethereum, the transaction counter is set up to prevent replay attacks. After each transaction is sent out, it is automatically connected to the network when signing, and it is also necessary to go to the network to request and wait for the return every time a transaction is submitted, which will affect the speed of brushing and increase the useless network. Network request is not good for flooding, of course, it is not good for accelerating the cancellation of a transaction. We can review the method of sending transactions in Ethereum, in which you can specify them yourself, but not in the library. I still think the design of Ethereum is much more reasonable and can be directly specified for canceling accelerated transactions. If a transaction is stuck, you can customize the same transaction to replace the stuck transaction, and of course it can also be used in our flooding attack. Due to the tight time, there are several other libraries that need to be modified. I decided not to rewrite the function, but to modify the script directly in the library to trigger the flood transaction. The idea is to initiate a transaction through circulation and generate a signature to send it to the node, and then initiate a transaction and then re-circulate it for a cycle. It is only necessary to pull it to the local area before the start of each flood cycle, and it is not necessary to re-request the node after each transaction as the default of the library, but to write it as a fixed value. It is not necessary to repeatedly request the node for the editor's note that the number of cycles here is set low. Obviously, the author is not so violent. Someone changed the number of cycles in each cycle to almost send out different transactions every minute when typing the inscription. Finally, I got a simple script. After unplugging the network cable on the night of the month, I simply tested the script and sent out hundreds of transactions. After continuing to type in the early morning of the month, I did hit some places, but there were still other places to vomit. The nodes on the month were seriously out of sync, and the block heights of different nodes were very different. When you request your account from the node, the results returned are basically inconsistent, which is very painful, and the block browser can't be used basically. It can be said that at this time, although the network can still block without downtime, it is estimated that it is approaching the limit. 比特币今日价格行情网_okx交易所app_永续合约_比特币怎么买卖交易_虚拟币交易所平台

• 当天，CIAS铭文官方眼见Celestia快扛不住，临时宣布48460号区块高度后上链的铭文铸造交易全部无效，颇有“交易所拔网线”之风。而且CIAS自己的网站也崩了。

• 有人认为Cosmos链原生的共识协议，在区块的共识方面做的很差，对此不作置评，但显然昨晚CIAS拔网线的目的耐人寻味。

• 12月17日时，你很难选中一个同步数据最快的节点，因为几乎所有的RPC节点都被挤爆了，经常无响应。我后来尝试写了一些自动切换节点的代码。

• CIAS本身的铭文格式，和其他铭文不太一致，比如brc-20的json里，所有数字都是字符串，而cia-20里的却是一个数字。

• CIAS铭文的成本昨晚最高时，飙涨到了每张1.5~2U，甚至有人付出了80U打了一张铭文。这么高的手续费反映的就是TPS有限，Celestia创始人自称，每秒可以处理10k笔交易，显然是在扯淡。

总体下来，12月17日当晚的体验就是一句话：Celestia当时肯定没做好应对大规模流量的举措，在RPC节点配置方面也很敷衍（很难想象1小时就能打炸几十号RPC节点）。

19号当晚这种情况好了很多，除了gas费飙涨之外，其他方面倒没什么太大问题，只能说Celestia作为一个专门给轻节点分发数据的DA网络，暂时性的经受住了考验，但不知道以后还会不会有什么别的坑。