The Github documentation of Cosmos is not well written, and many parts of the CosmJS library are not optimized. My experience is not very smooth.
Written by: Wuyue, Geek Web3
On December 17th, I knew that Celestia was going to have the inscription CIAS, and I planned to write a script to brush the inscription on a temporary basis. Now, I have a lot to complain about Celestia and the Cosmos ecosystem in which it exists, as well as the CIAS event itself.
In fact, it is not difficult to write a script for brushing inscriptions. It is mainly divided into three modules: wallet construction, connecting nodes, and flooding transactions. The first two steps only need to be found in the developer documentation of the target public chain to quickly implement them.
I first went to the Celestia official website and Github to look around. There were no use cases for building user scenarios for developers. They were mainly documents related to node operation and so on. Of course, this is understandable, because Celestia is not a ToC blockchain. Celestia only mentioned in an inconspicuous place that it is based on Cosmos and can interact with its mainnet using CosmJS.
So I went straight to CosmJS. But what can I say about Cosmos? Even the documentation is not good. I went directly to Github. According to common sense, this kind of JS will generally have use cases on Github. But its tutorial is hidden in a secondary page, and after clicking in, follow its configuration and finally report an error.
This error is not an environmental problem, it is because its tutorial has not been updated with the tutorial version. Often the name of this class is changed and that cannot be adjusted, etc. I switched the npm library version on the old tutorial version, but some use cases still didn't work, so I gave up after struggling for a while.
So I Googled it again and found that the correct document was on the official website instead of Github, which was a bit unreasonable. Again, wouldn’t it be nice to update the Github readme tutorial to point to the official website?
After getting the correct tutorial, I quickly completed the two steps of building the wallet and connecting the node, and started building the flood transaction module. This module is simply a for loop that processes transaction signatures + network requests. But here we encounter some problems:
All transaction methods in the CosmJS library only expose the parameters of the transaction itself, but its sequence is not exposed (sequence is analogous to the nonce in Ethereum, which is a transaction counter set to prevent replay attacks. Each transaction After the transaction is issued, both nonce and sequence are automatically +1).
The Sequence is actually obtained by connecting to the network when signing (chainId, etc.), and it needs to go through sendTokens() -> signAndBroadCast -> sign(). Going to the network to request and wait for a return every time a transaction is submitted will affect the speed of brushing and increase useless network requests, which is not good for flooding, and of course is not conducive to accelerating/cancelling a transaction.
We can review the method of sending transactions in Ethereum Web3JS, in which you can specify the nonce yourself. But this is not possible in CosmJS. I still think the design of Ethereum is much more reasonable. You can directly specify a nonce to cancel/accelerate transactions. If a transaction is stuck, you can customize a transaction with the same nonce to replace the stuck transaction. Of course, you can also use for our flooding attack.
Since time is very tight and there are several other functions in the library that need to be modified, I decided not to use Proxy to hook and rewrite them, but to modify them directly in the CosmJS library.
The idea of the script triggering the flooding transaction is to continuously initiate transactions and generate signatures through a for loop, and send them to the RPC node. After initiating a transaction, the sequence/nonce will be +1. After initiating 20 transactions, the cycle will be repeated again.
Sequence is only pulled locally before the start of each flooding cycle. It is not necessary to re-request sequence from the node after each transaction like the CosmJS library's default requirement. The chainId is written as a fixed value, so there is no need to repeatedly request the node. (Editor's note: The number of loops here is set relatively low, obviously the author is not that violent. When someone was writing Conflux inscription, he once changed the number of loops per cycle to 1000, and almost 200 different transactions were sent out every minute. )
Finally, I got a simple Celestia script. After CIAS unplugged the network cable on the night of December 17, I briefly tested this script and sent hundreds of transactions. After CIAS continued to fight in the early morning of December 19, I did hit some CIAS (about 1800). But there are still other things to complain about:
- On December 17, Celestia's RPC nodes experienced serious data out-of-synchronization problems. The block heights of different RPC nodes are very different. When you request the Sequence of your own account from the node, the returned results are basically inconsistent, which is very painful. The Celestia block explorer is also unavailable, which is basically confusing. It can be said that although the Celestia network is not down at this time and can still produce blocks, it is estimated to be reaching its limit.
- On the same day, CIAS Inscription officials saw that Celestia could no longer bear it, and temporarily announced that all Inscription casting transactions on the chain after the height of block 48460 were invalid, which was quite like "the exchange pulled the network cable." And the CIAS's own website is down.
- Some people think that the consensus protocol native to the Cosmos chain does a poor job of consensus on blocks, and they do not comment on this, but obviously the purpose of CIAS unplugging the network cable last night is intriguing.
- On December 17, it was difficult for you to select a node that synchronized data the fastest, because almost all RPC nodes were crowded and often unresponsive. I later tried to write some code to automatically switch nodes.
- The inscription format of CIAS itself is not consistent with other inscriptions. For example, in the json of brc-20, all numbers are strings, but in cia-20 it is a number.
- The cost of CIAS inscriptions was at its highest last night, soaring to 1.5~2U per piece. Some people even paid 80U to get an inscription. Such high handling fees reflect the limited TPS. The founder of Celestia claims that it can handle 10k transactions per second, which is obviously nonsense.
Overall, my experience on the night of December 17th can be summed up in one sentence: Celestia definitely did not take measures to deal with large-scale traffic at that time, and it was also very perfunctory in RPC node configuration (it is hard to imagine that dozens of RPC nodes can be destroyed in one hour) ).
The situation improved a lot on the night of the 19th. Except for the soaring gas fee, there were no major problems in other aspects. It can only be said that Celestia, as a DA network that specializes in distributing data to light nodes, has temporarily withstood the test. But I don’t know if there will be any other pitfalls in the future.
