About the project:
Fadroma is an application framework for the Cosmos family of smart contract platforms. It automates the boring parts of smart contract development and lets developers focus on the product logic. This enables the delivery of reliable products and maintenance of high development velocity. Fadroma currently supports Secret Network, and will soon support other CosmWasm-based blockchains and beyond.
About the author:
Adam is a med school dropout and reformed Web freelancer (previously considered irredeemable). Having built some systems for far-off lands such as Wales and Ethiopia, he started following the crypto world in 2017 after overhearing critical insights at a pub in Prague. He thinks a world where identity is minimal would create more space.
1. Developing smart contracts becomes an increasingly demanding job along with the growing number of blockchains with specific use cases and dev tools that improve the development processes. So how did you come up with Fadroma and what problems does the tool resolve?
Our high hopes for the future of distributed ledger technology make it easy to overlook a certain lack of infrastructural tooling which pervades smart contract ecosystems. While creating your own cryptocurrency can be done in an afternoon, it’s the novel applications of those blockchain tokens that generate actual value.
When I first started writing smart contracts for Secret Network, I was unable to find any tools or frameworks to take care of the low-level details and enable me to reliably go off the beaten track and pursue novel ideas. Therefore, the core issue that Fadroma addresses is bringing the expressivity and flexibility of the Web 2.0 stack to the exciting new world of Web 3.0 development.
Case in point. Cosmos smart contracts are, essentially, state machines. This is an age-old programming model which is very well understood and common among many different types of software. Therefore, many interesting and useful things can be easily implemented in the distributed execution environment of Cosmos-based blockchains.
Cosmos refers to this as the “actor model”; this is closer to Alan Kay’s original paradigm of “object-oriented programming” than the majority of OOP implementations that have proliferated since he invented the term all the way back in 1967! It’s a simple and well-thought-out programming model that’s been with us for over half a century, so by this point, things should be really easy, right?
In practice, the CosmWasm 0.10 API used by Secret Network enforced certain design choices that require the developer to write a lot of boilerplate code, and even duplicate some code when defining the contract-specific API surface. This made contracts needlessly bothersome to write, distracting to read, and somewhat confusing to maintain. More importantly, it obfuscated the fundamental simplicity of the platform; it slowed you down and limited your imagination.
Hence, the first incarnation of Fadroma consisted of a declarative Rust macro that automatically generated the more verbose form of the contract code from a simpler description of the contract functionality. I wanted it to look basically like the Redux data store – which is itself a somewhat bastardized state machine, and whose semantics are familiar to many developers.
This macro evolved alongside the contracts that used it; and several contracts into a project, the macro’s complexity started to outgrow its usefulness. Declarative macros are really cool feature of Rust, but after a certain point, they become difficult to maintain because of their odd syntax. You can have a look at the source code of the “fadroma-declare-contract” to see exactly how far they can go. Besides, updating the whole datastore on every change is cheap in a managed dynamic language (such as the ones I come from, Python and JavaScript), but terribly inefficient when you’re working in a gas-metered environment.
By this point, the training wheels were off. We had to move beyond this initial implementation; in the case of storage, we needed to be able to access it on a more granular level. The storage helpers provided by Cosmwasm-plus only obfuscated things more; and indeed, at one time Fadroma contained no less than three slightly different ways of addressing the platform storage – even though it takes the form of a simple key-value store, something which is also very commonplace. In the case of Cosmos, it was not without its pitfalls that needed to be worked around in order to be able to model any business domain as smart contracts.
In the meantime, the contracts had to be tested and audited; therefore, a method for building and deploying them in an automated and reproducible way had to be established. There was actually a dispute around the audit – I wanted to demonstrate that the auditors were overlooking a critical omission, and to resolve the issue beyond a shadow of a doubt. For that, deployment and testing scripts were written. Those later evolved into the TypeScript side of Fadroma.
2. Writing smart contracts on Secret Network was the starting point of noticing some key operational issues on the Cosmos blockchain. In that case – automating the repeatable and default parts of the code. How did you cope with that?
“Users don’t care about the tech stack” is an oversimplification used to justify narrow-sighted technology choices. Privacy-conscious users care about the fairness and legibility of the platform, and there’s a yarn or two to be spun about how internal technological choices evolve to enable that.
A premier example of such an initiative is https://reproducible-builds.org/ – they’re the flagship initiative for making sure that – at least as far as these major FOSS projects that that power the free Internet of today are concerned – the software doesn’t rot over time (it’s a thing). I tried applying some of their principles when deciding what’s in scope for the initial stable release of Fadroma Ops.
One cool thing Fadroma Ops can do is replay the evolution of a smart contract project over development time. The deployment procedures and state transitions involved in maintaining your smart contract-based product can be scripted in JavaScript or TypeScript, and by writing a migration for each phase of your project’s deployment, you can effectively retrace the steps that lead to a particular state of the append-only production environment. It even lets you build and deploy past commits from Git history without leaving your working tree. This makes it easy to isolate and diagnose issues, and to confirm the integrity of your production system for points in the past.
Secret Network made an important step in establishing a verifiable distributed computing environment by making the checksum of every executable uploaded to the network into an integral part of its core crypto workflow. Fadroma enables you to express and reason about checksum-verified inter-contract dependencies, transactions and callbacks. It is these things that make complex smart-contact deployments non-trivial, same as any other distributed system: it can take a large number of coordinated changes to get the system from state A to state B so that everything interacts with each other in an expected way. Were we in an environment where we could delete everything and start from scratch, there would be a ton of established build tools we could leverage. On a public blockchain, however, time moves only forward, and every transaction becomes part of a permanent ledger, and I guess the mainstream programming world just hasn’t caught up with this type of computing (maybe it’s because Secret Network is one of very few candidates that actually provide the following core feature on their permanent distributed ledger: privacy). So, in order to be able to model and execute the synchronized migration of two core DEX components consisting of 100+ smart contracts in total, Fadroma Ops (which originally concerned itself only with generating JavaScript interfaces from contract schema) had the chance to grow into a mini-build system for Secret Network smart contracts.
3. Can Fadroma be utilized on other blockchains as well, though, and if so, how do you think the tool will evolve in the future?
I see no reason to use anything else but Secret Network 😀 But the general operational structure of Secret Network is the same as most other Cosmos-based projects, so support for a generic CosmWasm build target and deploy workflow is our immediate next goal. That’s also a variant of the task “get different versions of the same thing to build and run in the same context” a.k.a. the dependency hell game – Secret Network runs on a heavily modified CosmWasm 0.10, while the latest CosmWasm 0.16 has added many new features and changed the signatures of some of the core APIs.
The next thing I want to see in Fadroma is better support for interoperation with EVM-based networks. There is no shortage of build tools and language dialects for those, and Fadroma could be made to interoperate with any platform that our next project requires.
