Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ease Cross-Contracts dependencies #1379

Open
tupui opened this issue Oct 23, 2024 · 0 comments
Open

Ease Cross-Contracts dependencies #1379

tupui opened this issue Oct 23, 2024 · 0 comments

Comments

@tupui
Copy link

tupui commented Oct 23, 2024

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 😄

  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant