Fadroma (dev tooling) - Funding proposal

Hello there SN community!

Since its been 20+ days since we’ve posted our Github grant proposal and we’ve seen no activity on it we decided to post it here. We hope we reach better visibility and gather more feedback.

Fadroma - Secret Network smart contracts development tooling

Project Description

The purpose of the Fadroma suite of tools is to facilitate the rapid prototyping, continued development, and maintenance of decentralized services and applications. It consists of a Rust library to serve as a foundation for building smart contracts, and a TypeScript-based build system for deploying smart contracts and interacting with them from JavaScript. The result is a portable and accessible development environment for smart contracts that abstracts away a large part of the grunt-work and lets you focus on your product logic.

Problem / Solution

As a smart contract developer, I need to focus on the business logic of what I’m writing. For that, I need to iterate on a tight feedback loop. Therefore, I start my project with Fadroma because it lets me automate the repetitive workflow steps and provides me with reusable building blocks to streamline contract development. This empowers me to maintain high development velocity and deliver a reliable product.

  • Fadroma has integrated the LocalSecret local network;
  • Fadroma allows me to test contract and cross-contract interactions natively (Rust);
  • Fadroma allows me to write deploy scripts;
  • Fadroma keeps track of deployments and allows deployments to continue from where they stopped if interrupted;
  • Fadroma provides me with receipts for all deployments.

As a full-stack Web 2.0 developer being onboarded to blockchain development, I expect a streamlined, comphrehensive development environment that builds on top of the similarities between the Web 2.0 and Web 3.0 operational model, provides clear affordances towards approaching the areas where the two differ (e.g. viewing smart contracts as a serverless deployment platform that is metered per operation rather than per CPU hour). I want to easily write abstractions to communicate with smart contracts from JavaScript.

  • Fadroma provides me with building blocks for writing client interfaces for contracts.

Detailed product description

logo-2

Over the past year and a half, we’ve been developing Fadroma as our in-house repository of Secret Network-related capabilities. It has been instrumental to realising the Sienna Network project. From the start, we decided to keep a common library to facilitate the rapid prototyping, continued development, and maintenance of decentralized services and applications based on CosmWasm.

Fadroma currently consists of:

  • a Rust library to serve as a foundation for smart contracts (e.g. composable contracts, derive macro)
  • a TypeScript build system for deploying smart contracts and interacting with them from JavaScript, which is nearly ubiquitous

Fadroma’s architecture went through several changes since its inception. We are currently approaching a 1.0.0 stable release with support for secret-cosmwasm-std 0.10, secretjs 1.4.0 and a legacy mode based on secretjs 0.17.5. It is capable of building smart contracts in a Docker container, and deploying them to either a containerised local devnet, the pulsar-2 testnet, or the secret-4 mainnet using a scripting API that allows us to declaratively express the complex deployment and configuration procedures of an evolving DeFi system using concise TypeScript. There is also a Mocknet mode which runs smart contract binaries in the standard WASM runtime of Node.js, and allows their behaviours to be validated without having to spin up.

Fadroma code is covered by Rust test suites, and lcov reports. For testing smart contracts, we provide the Ensemble feature (for integration testing from pure Rust) and the Mocknet (which runs smart contract binaries in a simulated environment based on Node.js’s built-in WASM runtime, enabling fast-forwarded exploration of dynamic multi-user, multi-contract system behaviour). Fadroma’s main dependencies are Node.js >=16 and Docker; containerised builds make it possible to build a Fadroma project without having a Rust toolchain at all.

It is feasible to add rootless builds (with Podman), containerless reproducible builds (with Riff) and/or remote builds (using a custom, build service).

Go-to-Market plan

Fadroma is already open-sourced and even used in production, powering major apps on Secret Network.

As an open-source project, Fadroma is intended to become a common foundation for the community to build on, and a standard component of Cosmos developers’ workflows in the way Truffle and Hardhat are for EVM ecosystems.

Regarding announcements, marketing and community:

The product is already live and it is in use by major apps on Secret Network.

  • We intend to build and support a community for developers using Fadroma
  • Announcements, blog posts, tech guides and examples are on our radar for easier user onboarding

Value capture for Secret Network ecosystem

Fadroma improves day-to-day operations of developers on Secret Network.

To continually improve the viability of the blockchain paradigm as a foundation for the decentralized software ecosystem of tomorrow, the tooling used for developing smart contract-based products needs to be qualitatively better than those currently being used for mainstream Web development.

We’d like for Fadroma to provide a streamlined workflow for rapid development of Secret Network-based products, guiding developers’ attention towards extensive high-level validation of smart contracts’ behaviour, and preventing them from getting bogged down in platform details.

Eventually, we’d like for Fadroma to become the frontend for an extensive library of pre-validated templates for smart contracts that can be customised and deployed with little to no coding, similar to what OpenZeppelin provides for Ethereum, or CosmWasm Plus provides for Cosmos.

Additionally, Fadroma IBC support will make it easier to use Secret Network as a privacy provider for unencrypted Cosmos blockchains.

In short:

The more users Fadroma has → the more developers work on Secret Network → the more adoption of Secret Network.

Statistics

The project is used by two of the major projects on Secret Network:

  • Sienna
  • Shade (based on feature requests, PRs, and feedback received)

We don’t have any telemetry built-in the project, but based on GitHub statistics for project clone we have ~1000 unique clones for this month. These are mainly Secret Network users (or soon to be users) as the project only supports SN.

Demo

In this demo we demonstrate some of the features of Fadroma.

asciicast

Team members

Team Website

Team’s experience

We have extensive experience developing smart contracts, tooling and infrastructure for blockchain networks and blockchain based projects for the past 6yrs.

Some of our previous work can be seen on our website and GitHub org.

Team Code Repos

Team LinkedIn Profiles

Development Roadmap

Delivery

  • Publish JS components to NPM
    • @hackbg/fadroma yet to be published
  • Publish Rust components to Crates.io
  • Install the whole toolkit with nix-shell https://advanced.fadroma.tech

Contract development and testing

  • Ensemble - write inter-contract-communication tests in Rust, by simulating blockchain behaviour and state without spinning up an actual node
  • Mocknet - which runs smart contract binaries in a simulated environment based on Node.js’s built-in WASM runtime, enabling fast-forwarded exploration of dynamic multi-user, multi-contract system behaviour
  • View test coverage reports
  • Toolkit for common types and common functionality
  • Composable trait that allows you to compose self-contained subsystems into a single contract

Macros

  • Derive contract macro
    • Generate CosmWasm boilerplate
    • Generate interfaces to write contracts as composable components. Some of the built-in components:
      • Killswitch
      • Admin
      • Auth (viewing key, permits)
  • Derive canonize macro - easily convert between structures containing addresses (Humanized/Canonized form)

Contract operation

  • Integration with secretcli - Rust library to programmatically interact with secretcli
  • Support system keystore in the same way as secretcli to import mainnet/testnet private keys

Distribution

  • Versioning scheme: 1.0.0 upcoming
  • Documentation at https://fadroma.tech: guides need another refresh
  • Decide contribution policy and governance mechanisms that allows the community to have their needs met while preserving hack.bg’s prerogative on the design and direction of the project

Milestones:

(:shushing_face: what’s been done so far)
0.1. Declarative macro trying to make CosmWasm look like Redux (dropped)
0.2. First project built and deployed with Fadroma on CW0.10.
0.3. Localnet container management.
0.4. Procedural macro for flexible generation of composable smart contracts and components.
0.5. Receipts system - record of uploaded and instantiated contracts
0.6. Ensemble - Rust multi-contract integration testing environment.
0.7. Mocknet - JavaScript/WASM integration testing environment. Test production builds, fast.
0.8. Pluggable builder interface supporting containerised and raw builds, incl. from past commits
0.9. Pluggable uploader interface, currently supporting uploads from local files.
0.10. Comprehensive domain model of smart contract operations workflow, providing a foundation for idiomatic client libraries and ops scripts.
(:point_down: we’re here)

  • 1.0. CW1.0 support
    • Stabilize current code:
      • Publish stable version of build system (Fadroma Ops 1.0)
      • Publish current state of contract framework (Fadroma Engine 0.10 with legacy secret-cosmwasm 0.10)
    • Implement CosmWasm 1.0 support:
      • Publish beta version of contract framework (Fadroma Engine 1.0 with secret-cosmwasm 1.0 and cosmwasm 1.0)
        • Update existing library features to support the newest CW1.0
        • Support CW1.0 IBC features
      • Publish beta version of build system with CW1.0 support
        • Support latest secretjs and cosmwasm-js
        • Support multiple devnet containers for local testing of IBC transactions
        • Support CW1.0 Mocknet

Rationale: The Secret Network upgrade to CW1.0 will be a major milestone reached. Having support of CW1.0 in Fadroma will make development more efficient while preserving the already useful toolkit provided so far and make CW1.0 contracts from other chains easily transferrable to Secret Network to be tested and deployed. Cross-chain IBC testing will be easier.

(:point_down: what we need support for)

  • 1.1. Milestone: Stability (week 00-06)
    • Improve test coverage and documentation of existing features
    • Improve smart contract boilerplate macros (Fadroma Derive)
      • Fix known issues
        • There is an edge-case where an interface can go out of sync with the current implementation
      • Optimize the API
    • Publish stable version

Rationale: After reaching the milestone for Fadroma - CW1.0 support, more time has to be put on stability, performance, fixing known issues and polishing the experience for developers using it. We aim to make the project even more lightweight and well structured. Better up-to-date documentation and more examples are in the scope of this milestone.

  • 1.2. Milestone: Additional features (week 06-12)
    • Project scaffolding (Fadroma Create)
    • Contracts identify themselves by default (standard query API for retrieving version, source URL, API schema)
    • Improve performance of reproducible builds (bypass Docker/Mac IO bottleneck)
    • JavaScript REPL for interacting with deployed contracts
    • Backtraces/source maps/coverage when testing from Mocknet

Rationale: Project setup has to be quick for seamless development experience. We want to work on improving this by adding project scaffolding for Fadroma. Additionally we’ve spotted some tricky workflows while working on Secret contracts - such as the need of keeping track of old builds and deployments so we want to improve on that.

The REPL is a handy tool we believe will improve dev UX - wether it is a quick contract config that has to be made or an experiment.

  • 1.3. Milestone: Additional features 2.0 (week 12-18)
    • Create devnet from mainnet snapshot
      • Allow selection of mainnet block number to get blockchain state from to run your contracts against;
      • Configure custom nodes to interface for this feature.
    • Upload from remote URL - build contracts in CI, deploy manually
    • Reliable gas profiling.

Rationale: In this milestone we want to focus on handy features we’ve used in other tools while developing on other blockchain ecosystems. We believe these are the logical next step in developing Fadroma.

Grant request

The total grant request is $89,597 (or the equivalent of SCRT at daily exchange rate on payment or USDT).

$13,337 awarded at the time of grant approval and payments on each milestone completion after.

We propose this grant timeline and funding breakdown:

Milestone Estimated Date Amount
1. Grant Accepted Present (T0) $13,337
2. M1.1 Completed T0 + 6 weeks $25,420
3. M1.2 Completed T0 + 12 weeks $25,420
4. M1.3 Completed T0 + 18 weeks $25,420
Total $89,597

Additional Information

10 Likes

I am not a developer, I would love to see input from the devs on this.

But I do know a good deal about the technical side of things and that one of the main concerns I see from the devs is that we need more and better types of tooling. And it appears to address a large variety of needed tooling.

Our current UX for devs has a high level friction and so I am happy to support anything that helps make our network more attractive to build in and easier to onboard to.

The ask seems reasonable to me, and addresses a real concern that impacts our effectiveness.

My initial stance is YES. And look forward to further feedback from those with indepth dev knowledge for confirmation of this being the type of thing that improves capacity and experience.

4 Likes

Thanks for the replies! Looking forward for more feedback (and more dev feedback :slight_smile: )!

1 Like

Thank you for posting this on the forums :slight_smile:

Are you still aiming for a grant, or would you like to transition it to an on-chain community pool spend proposal?

1 Like

Hey @pmuecke

On-chain community pool spend proposal is also an option.

Is there any specific additional requirement that the proposal has to meet for it to be passed as a CPSP?

1 Like

Short update on the thread.

As mentioned in the initial post we’ve been working on the CW1.0 support in the meantime. This is now implemented and merged with this PR: Feat/cw1 support by aakamenov · Pull Request #139 · hackbg/fadroma · GitHub.

1 Like

Definitely in support of the excellent work that Fadroma is doing. The Shade Team uses components of the Fadroma project across a wide range of product development. This toolkit is a huge benefit for the entire ecosystem of smart contract developers.

-Carter W.

5 Likes

slabs was on vacation I think. Perhaps that’s why they haven’t reviewed yet

1 Like

Thanks!

We’ll be interested to also know if the proposed milestones and features ahead sound reasonable and will be beneficial as our assumption is.

2 Likes

Yeah, totally forgot about that. Nevertheless the engagement and feedback here is more valuable than what we’ve got in the github issue so far :smiley:

1 Like

Also heavily in support of this prop! Please bring this to the community pool if needed :slight_smile: .
I would highly encourage you to protect the value of the grant after you got it.
I’ve heard multiple stories of some here getting burned by not selling the provided SCRT into USDT/USDC after price drops.

1 Like

We’ll do so, thanks!

1 Like

Cool, thank you for the feedback!

I absolutely love what you guys are doing personally as a developer I would DEFINITELY use some of the features you talked about. Digiline validator fully supports this proposal, whether it’s a grant or an on-chain proposal.

Some of the features I’m most looking forward to using are:

  • Composable contracts components. They are such a great idea and will make complex contracts much easier to read and write. I will definitely use it
  • The ensamble multi-contract integration testing environment. This is basically a no-brainer for building complex dApps. In the past I’ve had to write javascript code to do this kind of testing, having a Rust solution for it would help a lot.
  • Contract identification. This feature isn’t hard to build into your contract at all, but keeping it up to date with changes can be harder, since it’s likely that you’ll forget to add something at some point, so an automatic solution for this is awesome :slight_smile:

I do have some questions about milestone 1.3, however:

  • Could you please clarify what “Upload from remote URL” is about? You can just give your CI platform a seed that it can use to upload new contracts, or if you don’t want to do that for security reasons you can just wget the .wasm file from your CI and upload that into the network. Or am I just misunderstanding the feature?
  • Could you clarify “Reliable gas profiling”? Is this about profiling the gas usage in the contract, similarly to how cpu profilers work for traditional software or is this just to generate a more accurate gas usage on the frontend? If it’s the former, please reach out to us on discord because we would LOVE to integrate this feature in the Secret IDE to make it show flamegraphs with gas usage and perhaps show in-context what the gas usage of every function is.
1 Like

First of all - thanks for the feedback! We’re glad you find Fadroma valuable.

Yes. The idea is for Fadroma’s CLI commands to be extended with one that allow pointing to a wasm blob hosted somewhere (by pointing to an URL) and upload that instead of building it locally or manually downloading (extra step).

We came up with this while we were working towards shortening the feedback loop in dev cycles by automating builds in the CI, caching build artifacts and creating automatic release and tag with the build version. We think this is going to be helpful in such setups to allow easier and faster contract upload.

E.g. fadroma upload URL_TO_YOUR_GH_RELEASE.

Re. gas profiling - the former.

We’ve had gas issues in the past which originated from not being able to properly set correct gas amounts for contract executions which in turn originates form lack of good tooling to automate the gas profiling. Doing this manually is a tedious process. Some might say - “yeah, man, but you do it once and thats it”, but this is not the case when you are developing and trying to optimize your contract. Then you are in a need of an automation.

Currently the goal is to collect gas data from tests against the local network and exposing that similar to how its done in Hardhat here: GitHub - cgewecke/hardhat-gas-reporter: Gas usage per unit test. Average gas usage per method. (eth-gas-reporter for Hardhat). Since CosmWasm does not expose gas info at the unit tests level (Allow printing gas reports from contracts (debug mode) · Issue #746 · CosmWasm/cosmwasm · GitHub), in the way that hardhat/evm does, we aim to collect the gas info by running tests against the local dockerized network or the MockNet (or even a live network puslar-2 or other). At the end Fadroma will provide a standardized output and file containing the results so that they can be fed directly in any other tool/sdk and a nice-looking table.

So yeah - we’ll be happy to connect and work together on integrating that to Secret IDE as well once its built :slight_smile: .

3 Likes

Support this. One way or another needs to get funded.

1 Like

We’ve decided to go trough a Community Pool Spend Proposal. We’ll be updating the proposal in the following days. :slight_smile:

1 Like

Could you expand on what happened with the SCRT Labs grant process and why community pool funding is now being pursued instead?

Hey @winston our experience with the grant process was not great - we’ve been waiting for a month to start a conversation with somebody responsible for the grants. After we had the call and explained our vision and idea about this proposal we’ve been told to wait for a review to which we didn’t get any feedback regarding the tech side of the proposal at all. Instead we were told the grant program is now being put on freeze because of current market conditions.

Thus we decided to pursue a community pool funding, as suggested by @pmuecke, so we can afford to continue working on the development of Fadroma.

2 Likes

Hi @facelessman21 - thanks for explaining the situation.

It sounds like the grant proposal wasn’t turned down based on merit but because of broader cost saving measures.

Given that both Sienna and Shade benefit from the tool, it’s an easy yes from me.

2 Likes