CosmWasm Roadmap Feedback summary
Last month ICF published the Roadmaps for 2024. The CosmWasm team was included there as well. Then, the period for comments was opened, and now we have some feedback collected. We want to share what we learned from it.
Documentation needs to improve
The documentation is one of the pain points, and we are aware of that. We tried to improve on that, but we needed more. Recently, we reconsidered where we are documentation-wise once more, considering the feedback we collected last year. We find two equally important lacks:
- Intro-level documentation
- Technical documentation is out-of-date and desynchronized
The intro-level documentation is difficult to maintain because we deal with two areas — Rust and CosmWasm. If we take a look into Solidity, it is slightly simpler, as the language and Smart Contracts framework are closely related. In our case, the platform is built in the existing language, which is not the easiest to learn. There is always a question of whether we should teach Rust while introducing Smart Contracts or assume Rust knowledge. The community prefers the first solution, but it is problematic. To be comprehensive, we would need only to scratch the surface of the language, and we think people deserve good learning materials about that. Because of that, we decided to meet somewhat in the middle — we would build up more entry-level tutorials, but we would not try to make yet another Rust teaching resource. Still, we will not assume Rust expertise, and when using some Rust tools for the first time, we will provide resources where they can be learned — most likely the link to the Book chapter or Rustlings.
Keeping documentation up-to-date is a simpler part. The biggest problem is that when we implement new things in our crates, we often need to remember which documentation should be updated. The easy part is doc-comments to generate proper docs.rs documentation, but there are also readmes and sometimes additional resources where the change should be referred. To improve our documentation, we decided to have a dedicated person responsible for knowing the relations between our crates and documentation and either updating and improving it or chasing developers to make a change to fix the documentation. We believe our codebase is big enough to make this step, and we put more pressure on documentation correctness.
Testing
The second most mentioned problem is testing issues. Unfortunately, testing is not an easy thing here. There are two difficulties here. First is that the CosmWasm is built on top of two different stacks — Go for integration with the Cosmos SDK and Rust for building smart contracts. That makes it very difficult to test the whole smart contract with only Rust unit tests utility. We often do that using the cw-multi-test framework, but it is not always enough. The good thing about cw-multi-test is how much feedback we can get from those tests. The framework is executing the Rust Smart Contract natively, giving the full insight into what went wrong — including full call stacks on panics and the possibility to run the test under an lldb debugger. Also, the workflow with such tests is straightforward — update your smart contracts and run a cargo test on your project, and you immediately see test results. On top of that, cw-multi-test is easy to set up on any existing CI platform.
On the other hand — the fact of testing contracts in isolated environments creates serious challenges working with this platform. All of them have the same root cause — as we cannot use golang modules or relayers in MTs, all of their logic has to be reimplemented in the MT environment. We are focusing on finally delivering MT implementation in Q1 2024, but more pieces need to be added in the future — proper custom messages testing, for example.
All the mentioned problems are also solved by the other testing approach — testing compiled Wasm smart contract on the real blockchain — either a testnet or the local docker-based network. There are existing tools encouraging such an approach — test-tube by Osmosis is most likely the best-known one. This approach has its own downsides. The biggest one is the difficulty of debugging the Wasm binaries. It is not only impossible to run tested smart contracts under a debugger, but it also lacks a full call stack when the test fails. That makes such an approach not a competition but a complement of the multitests. This makes it appealing to dive more into this year, looking for opportunities to integrate this approach more into the ecosystem.
Other notes
Besides testing and documentation, there were also comments that were not repeated but still are relevant.
One of them was to introduce a sort of Smart Contracts execution parallelization. The idea seems interesting, as it might improve execution performance, but the topic is more complex. One of the most important things about CosmWasm is its reliability. Unfortunately, reliable parallelization is difficult. It might be tempting to simply allow parallel execution of distinct contracts, as they would never have a race to update the same items in the storage. Still, we need to keep in mind there is a notion of queries, and we would need to decide how to solve the situation when one contract queries state the other one that is executed in parallel. And the problem is that we don’t only want it to be safe. As for that, simply guarding the state with some RW lock would be sufficient. On top of that, we need this behavior to be deterministic — so the state update and query to this state have to always happen in the same order. Given that we consider this feature too complex to commit to in 2024, we acknowledge it, and we might put some work into further investigation.
The other issue pointed out is contract-to-contract erroring. We are aware of this being a subject for improvement, and it’s simple enough, so we decided to work on this earlier. The better solution for that one should be released this year with CosmWasm 2.0.
Positives
Besides the feature request, the CosmWasm team got a lot of positive feedback. We are happy to hear that people like the actor model we build on. It is not the easiest pattern to follow, but it gives strong guarantees, and we are pleased that we were able to deliver it in a form that our users accept.
Also, the overall CosmWasm 2024 Roadmap is appreciated. People are hyped about our focus on documentation, and like that, we plan to put work into IBC, smart accounts, and ZKP verification if ICF 2024 grants cover. We will take that into account when we will order our work.
Concluding our comments on the Roadmap proposal feedback — we are happy about our users’ activity. That makes it easier to establish our priorities and ensures that we correctly identify our pain points. That makes our plans easier, as there is no guessing on what people need. We hope to deliver more good quality software to our users in 2024.
