On December 17th, I learned that the inscription CIAS was going to be published on Celestia, and I planned to work on a temporary basis to write a script to brush the inscription. Now, I have a lot to complain about Celestia and its Cosmos ecosystem, as well as the CIAS event itself.
In fact, it is not difficult to write a script for brushing inscriptions, which 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 find a quick implementation.
I first went to the Celestia official website and Github to take a look, and there are no use cases for developers to build user scenarios, mainly node operation and other related documentation. Of course, this is understandable, because Celestia is not a ToC blockchain. Celestia just mentions in an obscure place that it is based on Cosmos and that it is possible to interact with its mainnet with CosmJS.
So I went straight to CosmJS. But what about Cosmos, it’s not even good at documentation. **I went directly to Github, and according to common sense, generally this kind of JS will have a use case on Github. But its tutorial is hidden in a secondary page.,And after clicking on it.,Follow its configuration to do a pass.,Finally, an error is reported.。
**This error is not an environmental problem.,It’s because its tutorial hasn’t been updated with the tutorial version.**Often the name of this class is changed and that can’t be tuned, etc.。 I switched to the version of the npm library on the old tutorial version, and there are still some use cases that don’t work, so I gave up after tossing for a while.
So I googled it again, and it turned out that the correct documentation was on the official website instead of Github, which was a bit counterintuitive. **Again, isn’t it good to update the Github readme tutorial to the official website?
After getting the correct tutorial, I quickly completed the two steps of building the wallet and connecting the nodes, and started to build the flood transaction module. To put it simply, this module is a for loop that processes transaction signatures + network requests. But here are some problems:
All transaction methods in the CosmJS library only expose the parameters of the transaction itself, but its sequence is not exposed (the sequence is analogous to the nonce in the ETH workshop, which is a transaction counter set to prevent replay attacks, and after each transaction is issued, the nonce and sequence are automatically +1).
Sequence is actually that it connects to the network to obtain it when signing (chainId, etc.) when signing, and it has to go through sendTokens() -> signAndBroadCast -> sign(). **Going to the network to request and waiting for the return every time a transaction is submitted will affect the speed of the brush, and will also increase the useless network requests, which is not good for flooding, and of course not conducive to accelerating/canceling a transaction. **
Let’s review ETH Web3JS’s method of sending transactions, where you can specify the nonce yourself. But not in CosmJS. I still think that the design of the ETH Fang is much more reasonable, you can directly specify the nonce to cancel/accelerate the transaction, if a transaction is stuck, you can customize a nonce with the same transaction to replace the stuck transaction, of course, it can also be used for our flood attack.
Due to time constraints, there were several other functions in the library that needed to be modified, ** I decided not to use Proxy to dehook the rewrite, but to modify it directly in the CosmJS library. **
The idea of the script to trigger the flood transaction is to continuously initiate the transaction through the for loop and generate a signature, send it to the RPC node, and after initiating a transaction, the sequence/nonce will be +1, and after initiating 20 transactions, the cycle will be recycled.
Sequences are only pulled locally before the start of each flood cycle, and there is no need to re-request sequences from nodes after each transaction, as is the default in the CosmJS library. The chainId, on the other hand, is written as a fixed value and does not have to be repeatedly requested from the node. (Editor’s note: The number of loops here is set relatively low, and it is clear that the author is not so violent.) Someone, when typing the Conflux inscription, changed the number of cycles per cycle to 1000, sending out about 200 different transactions per minute)
Eventually, I got a rudimentary Celestia script, which I briefly tested after CIAS unplugged on the night of December 17th, and sent out hundreds of transactions. After the CIAS resumed in the early hours of December 19th, I did hit some CIAS (about 1,800). But there are still other things to complain about:**
On December 17th, Celestia’s RPC node had a serious data out-of-sync problem, the block height of different RPC nodes is very different, and when you request the node to the sequence of your account, the return result is basically inconsistent, which is very painful. The Celestia block explorer is also unavailable, and it is basically blind. It can be said that at this time, although the Celestia network is not down and can still produce blocks, it is estimated that it is almost to the limit.
On the same day, the CIAS inscription official saw that Celestia was about to be unable to bear it, and temporarily announced that all the inscription minting transactions on the chain after the height of block 48460 were invalid, which was quite a trend of “unplugging the network cable of the exchange”. And CIAS’s own website collapsed.
There is no comment on the perception that the Cosmos chain’s native consensus protocol does a poor job of consensus on blocks, but it is clear that the purpose of CIAS pulling out the network cable last night is intriguing.
On December 17th, it’s hard to pick a node with the fastest synchronized data, because almost all RPC nodes are overcrowded and often unresponsive. I later tried to write some code that automatically switches nodes.
The format of the inscription in CIAS itself is not quite consistent with other inscriptions, for example, in the json of brc-20, all numbers are strings, while in CIA-20 it is a number.
The cost of CIAS inscriptions soared to 1.5~2U per inscription when it was the highest last night, and some people even paid 80U for an inscription. Such a high fee reflects the limited TPS, and the founder of Celestia claims that he can process 10k transactions per second, which is obviously nonsense.
Overall, the experience of the night of December 17th was one sentence: Celestia was definitely not prepared to deal with large-scale traffic, and it was very perfunctory in terms of RPC node configuration (it is hard to imagine that dozens of RPC nodes can be blown up in 1 hour). **
On the night of the 19th, the situation was much better, except for the soaring gas fee, there was no big problem in other aspects, it can only be said that Celestia, as a DA network dedicated to 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.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
After writing the Celestia script and typing the inscription, he complained: The basic skills of Cosmos are not solid
Author: Wuyue, Geek Web3
On December 17th, I learned that the inscription CIAS was going to be published on Celestia, and I planned to work on a temporary basis to write a script to brush the inscription. Now, I have a lot to complain about Celestia and its Cosmos ecosystem, as well as the CIAS event itself.
In fact, it is not difficult to write a script for brushing inscriptions, which 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 find a quick implementation.
I first went to the Celestia official website and Github to take a look, and there are no use cases for developers to build user scenarios, mainly node operation and other related documentation. Of course, this is understandable, because Celestia is not a ToC blockchain. Celestia just mentions in an obscure place that it is based on Cosmos and that it is possible to interact with its mainnet with CosmJS.
So I went straight to CosmJS. But what about Cosmos, it’s not even good at documentation. **I went directly to Github, and according to common sense, generally this kind of JS will have a use case on Github. But its tutorial is hidden in a secondary page.,And after clicking on it.,Follow its configuration to do a pass.,Finally, an error is reported.。
**This error is not an environmental problem.,It’s because its tutorial hasn’t been updated with the tutorial version.**Often the name of this class is changed and that can’t be tuned, etc.。 I switched to the version of the npm library on the old tutorial version, and there are still some use cases that don’t work, so I gave up after tossing for a while.
So I googled it again, and it turned out that the correct documentation was on the official website instead of Github, which was a bit counterintuitive. **Again, isn’t it good to update the Github readme tutorial to the official website?
After getting the correct tutorial, I quickly completed the two steps of building the wallet and connecting the nodes, and started to build the flood transaction module. To put it simply, this module is a for loop that processes transaction signatures + network requests. But here are some problems:
All transaction methods in the CosmJS library only expose the parameters of the transaction itself, but its sequence is not exposed (the sequence is analogous to the nonce in the ETH workshop, which is a transaction counter set to prevent replay attacks, and after each transaction is issued, the nonce and sequence are automatically +1).
Sequence is actually that it connects to the network to obtain it when signing (chainId, etc.) when signing, and it has to go through sendTokens() -> signAndBroadCast -> sign(). **Going to the network to request and waiting for the return every time a transaction is submitted will affect the speed of the brush, and will also increase the useless network requests, which is not good for flooding, and of course not conducive to accelerating/canceling a transaction. **
Let’s review ETH Web3JS’s method of sending transactions, where you can specify the nonce yourself. But not in CosmJS. I still think that the design of the ETH Fang is much more reasonable, you can directly specify the nonce to cancel/accelerate the transaction, if a transaction is stuck, you can customize a nonce with the same transaction to replace the stuck transaction, of course, it can also be used for our flood attack.
Due to time constraints, there were several other functions in the library that needed to be modified, ** I decided not to use Proxy to dehook the rewrite, but to modify it directly in the CosmJS library. **
The idea of the script to trigger the flood transaction is to continuously initiate the transaction through the for loop and generate a signature, send it to the RPC node, and after initiating a transaction, the sequence/nonce will be +1, and after initiating 20 transactions, the cycle will be recycled.
Sequences are only pulled locally before the start of each flood cycle, and there is no need to re-request sequences from nodes after each transaction, as is the default in the CosmJS library. The chainId, on the other hand, is written as a fixed value and does not have to be repeatedly requested from the node. (Editor’s note: The number of loops here is set relatively low, and it is clear that the author is not so violent.) Someone, when typing the Conflux inscription, changed the number of cycles per cycle to 1000, sending out about 200 different transactions per minute)
Eventually, I got a rudimentary Celestia script, which I briefly tested after CIAS unplugged on the night of December 17th, and sent out hundreds of transactions. After the CIAS resumed in the early hours of December 19th, I did hit some CIAS (about 1,800). But there are still other things to complain about:**
Overall, the experience of the night of December 17th was one sentence: Celestia was definitely not prepared to deal with large-scale traffic, and it was very perfunctory in terms of RPC node configuration (it is hard to imagine that dozens of RPC nodes can be blown up in 1 hour). **
On the night of the 19th, the situation was much better, except for the soaring gas fee, there was no big problem in other aspects, it can only be said that Celestia, as a DA network dedicated to 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.