As the ecosystem grows, more and more small contracts will be created. Leveraging these contract will enable people to build faster, in a modular way and with confidence.
A few pieces are missing to make this a smooth process. Error handling is one thing (already being discussed there) and here I would like to focus on the dependency management itself.
For context, I am building Tansu.dev and I am depending on Soroban Domains. Everything is public if that helps:
Trust indication: it would be handy to have a way to link contracts to audits, reputation, etc. on-chain verification would be a natural plus. A simpler alternative is to make a trusted registry (here I am not sure if there is a concept of channel or registry in Rust, I guess so.) The OpenZepplin discussion goes along that way I think.
Dependency definition: ideally I think using the cargo.toml for that would be natural. Behind the scene it would be great if it could basically download the wasm for us, or the source and compile it as any other dependency. i.e. replace
mod domain_contract {
soroban_sdk::contractimport!(
file = "../domain_3ebbeec072f4996958d4318656186732773ab5f0c159dcf039be202b4ecb8af8.wasm"
);
}
with a simple use other_contract::stuff.
I think once we have something like this, we should add tools for Explorers to show you the list of dependent/dependencies of a specific contracts. Might be very simple if people already use the contract verification feature and I could see this workflow just sending the toml file. Of course we can also think about adding more metadata to contracts (and here linking to the initiative we are discussing about a metadata standard for Soroban Domains which can be used to add metadata to a contract.)
Testing and contract initialisation: that part might be harder. Right now if you want to depend on another contract, you need to deep dive into their test suite and figure out what you need to do on your side to make your own testing work. That's a lot of work. I am thinking that we could either have a mocking mechanism, or define a standard for projects to spin up their contracts easily. I think the initiative around the init/initialize standard method would go along that direction. What would be missing is providing a sort of minimal template to spin up the contract and have it functional. (I am also thinking about SorobanHub here and if we had such standard, SorobanHub could use it to directly populate some widgets)
What alternatives are there?
Solutions like Trustful (providing badges) or Tansu (soon to integrate Trustful and on-chain help to validate code and maintainers) are eventually going to help by providing a way to keep contracts and maintainers in check. But that only contribute to securing the supply chain, not improve the DX.
What problem does your feature solve?
This started as a Twitter conversation after Tomer's request for feedback. Thanks again for the outreach 🙇
https://x.com/PamphileRoy/status/1848414906070278633
As the ecosystem grows, more and more small contracts will be created. Leveraging these contract will enable people to build faster, in a modular way and with confidence.
A few pieces are missing to make this a smooth process. Error handling is one thing (already being discussed there) and here I would like to focus on the dependency management itself.
For context, I am building Tansu.dev and I am depending on Soroban Domains. Everything is public if that helps:
https://github.com/tupui/soroban-versioning/tree/main/contracts
What would you like to see?
Christmas list on top of my head 😄
with a simple
use other_contract::stuff. I think once we have something like this, we should add tools for Explorers to show you the list of dependent/dependencies of a specific contracts. Might be very simple if people already use the contract verification feature and I could see this workflow just sending the toml file. Of course we can also think about adding more metadata to contracts (and here linking to the initiative we are discussing about a metadata standard for Soroban Domains which can be used to add metadata to a contract.)init/initializestandard method would go along that direction. What would be missing is providing a sort of minimal template to spin up the contract and have it functional. (I am also thinking about SorobanHub here and if we had such standard, SorobanHub could use it to directly populate some widgets)What alternatives are there?
Solutions like Trustful (providing badges) or Tansu (soon to integrate Trustful and on-chain help to validate code and maintainers) are eventually going to help by providing a way to keep contracts and maintainers in check. But that only contribute to securing the supply chain, not improve the DX.