Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Several folks wrote about issues to look for in Cosmos-based blockchains. I have a personal list of these but it's nice to see a large external list! Cosmos is built via writing Go code at the infrastructure layer, as opposed to writing code in a virtual machine like the EVM. This creates many unique issues.

The first mentioned class is non-determinism. If different groups of validators see different proofs at the end of execution of a transaction then the blockchain will come to a halt. Randomness, Go maps (randomly determine where to start in a map), timestamps from the local machine, concurrency and floats by different platforms.

The second class are in protocol panics. Code executes within the BeginBlock/EndBlock that panics will lead to a chain halt. Hence, panics should be handled in a nice way. This can happen via bad math operations, bulk coin sends for blacklisted addresses and added in panics.

A third thing to watch out for is unmetered computation. Only stateful things have gas meters. For instance, reading/writing to state within a callable message. However, BeginBlock/EndBlock do not. So, if a user can setup code to end in these locations, it can be real bad. Additionally, bad loops on non-state operations can cause halts as well.

The next one is Key Malleability and Prefix Iteration. In Cosmos, all state is simply a key-value store. For storage, it's recommended to add a prefix to a data type so that you don't overwrite the wrong things or create collisions. Even checking for existence by a prefix needs to be done carefully. I remember thinking about these collisions myself but most developers are smart enough to add a large string to the beginning of the data to signify a datatype.

An iterator is created for going through a KVS space. When using an iterator, adding the prefix to the store is crucial. Otherwise, unintended data could be iterated over the top of. Iterators are inclusive of the first byte but exclusive of the end byte. So, this can create a bad iterators over the top of data.

Cosmos developers need to consider gas. The KVS does contain automatic gas charging for storage reads and writes but sometimes more needs to be done. However, adding more gas for specific operations can be necessary to prevent spam. Cosmos is known to have high levels of congestion and not having a good way of handling this during peak load. The gas stuff on Cosmos feels like a blackbox to me atm.

Overall, a good series of issues! They're going to do a CosmWasm and IBC post in the future, which will be good for everyone in the space. I look forward to seeing the post and adding to my list of test cases on Cosmos based blockchains.