Thoughts after writing Celestia script: Cosmos has many shortcomings

极客 Web3

2023-12-20 10:53

Read this article in 12 Minutes

AI summary

View the summary

Original Title: "Reflections After Writing Celestia Scripts: Cosmos Has Not Done Enough Work"

Original Author: Wuyue, Geek Web3

On December 17th, I learned that there will be a new CIAS inscription on Celestia and decided to quickly write a script to farm it. I have many criticisms about Celestia, the Cosmos ecosystem it belongs to, and the CIAS event itself.

Actually, it is not difficult to write a script for brushing inscriptions, which mainly consists of three modules: wallet construction, node connection, and flood trading. The first two steps can be quickly implemented by referring to the developer documentation of the target public chain.

I first visited the Celestia website and Github, and didn't find any use cases aimed at developers building user scenarios. The main focus was on node operation and related documentation. Of course, this can be understood, because Celestia is not a ToC blockchain. Celestia only mentions that it is based on Cosmos in an inconspicuous place, and can be interacted with its mainnet using CosmJS.

So I went straight to CosmJS. But Cosmos, how should I put it, can't even do the documentation well. I went directly to Github. Normally, this kind of JS would have usage examples on Github. But its tutorial was hidden on a secondary page, and after clicking on it and following its configuration, it ended up with an error.

This error is not caused by the environment, but because the tutorial did not update with the tutorial version. Often, class names are changed and certain things cannot be called. I switched to an older version of the npm library, but some test cases still did not work. After struggling for a while, I gave up.

So I googled it again and found out that the correct documentation is on the official website instead of Github, which is a bit counterintuitive. Once again, wouldn't it be better if the tutorial in Github's readme was updated to point to the official website?

After obtaining the correct tutorial, I quickly completed the two steps of wallet construction and node connection, and began building the flood transaction module. Simply put, this module is a for loop that handles transaction signatures and network requests. However, I encountered some problems here:

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 nonce in Ethereum, which is a transaction counter set to prevent replay attacks. After each transaction is sent, both nonce and sequence are automatically incremented).

Sequence actually connects to the network during sign signature (including chainId), and it needs to go through sendTokens() -> signAndBroadCast -> sign(). Requesting network connection and waiting for response every time a transaction is submitted will affect the speed and result in unnecessary network requests, which is not conducive to flooding, nor is it conducive to accelerating/canceling a transaction.

We can review the transaction sending method of Ethereum Web3JS, in which you can specify the nonce by yourself. However, it is not possible in CosmJS. I still think Ethereum's design is much more reasonable, as you can directly specify the nonce to cancel/accelerate transactions. If a transaction gets stuck, you can customize a transaction with the same nonce to replace the stuck one, which can also be used for our flooding attack.

Due to the tight schedule and several other functions that need to be modified in the library, I have decided not to use Proxy to hook and rewrite, but to directly modify it in the CosmJS library.

The idea of triggering a flood transaction through a script is to continuously initiate transactions and generate signatures through a for loop, send them to the RPC node. After initiating a transaction, the sequence/nonce will increase by 1. After initiating 20 transactions, the cycle will start again.

Sequence is only pulled to the local before each flooding cycle, there is no need to request the sequence from the node after each transaction like the default behavior of the CosmJS library. The chainId is set to a fixed value and does not need to be repeatedly requested from the node. (Editor's note: The loop count here is set relatively low, obviously the author is not that aggressive. Someone once changed the loop count for each cycle to 1000 when writing Conflux inscriptions, sending out about 200 different transactions per minute.)

Finally, I got a rudimentary Celestia script. On the night of December 17th, after CIAS disconnected the network, I tested this script briefly and sent out hundreds of transactions. After CIAS resumed the attack on December 19th, I did manage to hit some CIAS (about 1800 in total). However, there are still other things to criticize:

·On December 17th, Celestia's RPC node experienced severe data desynchronization issues, with significant differences in block heights between different RPC nodes. When requesting the Sequence of your own account from the node, the results returned were inconsistent, causing great frustration. The Celestia block explorer was also unavailable, causing significant confusion. It can be said that although the Celestia network was not down and could still produce blocks, it was likely approaching its limit.

·On that day, CIAS Mingwen officials saw that Celestia was about to collapse, and announced that all the Mingwen casting transactions that were put on the chain after block height 48460 were invalid, which was reminiscent of the "exchange pulling the network cable" incident. Moreover, CIAS's own website also crashed.

·Some people believe that the native consensus protocol of Cosmos chain has done poorly in terms of block consensus. We will not comment on this, but it is clear that the purpose of CIAS pulling the network cable last night is intriguing.

On December 17th, it was difficult to select a node with the fastest synchronized data because almost all RPC nodes were overloaded and often unresponsive. I later tried writing 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, while in cia-20, they are a number.

·When the cost of CIAS inscriptions reached its highest point last night, it soared to 1.5~2U per inscription, and some even paid 80U for a single inscription. This high transaction fee reflects the limited TPS. The founder of Celestia claimed that they can process 10k transactions per second, but it's obviously just talk.

Overall, the experience on the evening of December 17th can be summed up in one sentence: Celestia definitely did not prepare well for handling large-scale traffic, and the configuration of RPC nodes was also very perfunctory (it's hard to imagine dozens of RPC nodes being blown up in just one hour).

On the night of the 19th, the situation improved a lot. Apart from the skyrocketing gas fees, there were no major issues. It can only be said that Celestia, as a DA network specifically designed for distributing data to light nodes, temporarily withstood the test, but it is unknown if there will be any other pitfalls in the future.