Is it possible when there are more than 1 secret contract in `lib.rs` and how a contract calls to some functions of another contract?

I’m developing a dApp which simulate how a coop-group should work.

Lets say I have 2 contracts: one is used to describe vendors (DC, DS, AC, DU) and another is used to describe a SDC: SDC properties and handle SDC functions.

And the vendor-contract will call some functions in SDC-contract.

At the moment, I see it will be put into the src/lib.rs file, in this case, is it possible that I can separate them into 2 files? and how can I achieve that?

Or I can put them into the same lib.rs without any issues, right?

1 Like

hello, do you guys have any updates? Please kindly help me. Thanks.

I could be wrong here, but it seems to me like you’d want to set this up so that each contract has its own src/ directory. Here’s an example:

secret_contracts
|
|_contract_1
|  |_src
|     |_lib.rs
|_contract_2
   |_src
      |_lib.rs

TBH, I’m not sure how the actual entry point into the contract code is detected. The reason I think separate lib.rs files are necessary is because each contract has its own config object in the migrations file (e.g. migrations/2_deploy_contracts.js), and the deploySecretContract() function provided is writing a single .wasm and .txt address file for an individual config.filename. So if you put two contracts in the same lib.rs file, currently they would have the same address listed in the .txt file, which wouldn’t make sense.

For the question of how one contract calls the other, I’m not quite sure how this happens. I assume that there should be a way to pass the first secret contract’s address into the constructor of the second one when doing the migration, and using something similar to EthContract::new(&contract_addr) (except with a secret contract instead of an [#eth_contract()] annotation of course), like in the Voting example here.

Unfortunately I can’t seem to find a similar [#secret_contract] annotation in the current eng_wasm_derive library, and the [#pub_interface] annotation doesn’t seem to be used for that functionality, so hopefully the team can clarify how to do this.

2 Likes

hi @crypto_mentions,
Is the eth_contract a smart_contract? If thats the case, this is how to call some functions from some available smart contracts on network.

The project layout which you suggest is an idea which I thought about.

Or the 2nd contract is on the same level with src/lib.rs.
But it only appropriates for in case which the 2nd one isn’t exposed for interacting with client side.

How do you think?

hi @adi, may you clarify this one for us also?

Yes, as far as I can tell, the #[eth_contract] annotation refers to a smart contract. Currently, we can only call smart contracts on the Ethereum network as a callback, after the secret contract method execution has finished. i.e., we can’t currently call a smart contract function that returns a value and retrieve this value for use in the Enigma secret contract.

I assumed that you wanted both secret contracts accessible from the client side. I agree with you that if the second contract doesn’t need to be exposed to a client other than the first contract, it may be easier to just wrap the second contract in the first one (e.g. implement another struct with its own methods, but expose everything through the first contract). This is really just another way of combining the two contracts into a single one, but it may be useful from an abstraction / logic perspective to do so (and may make it easier to split them apart later).

1 Like

I think this ties into the thread about contract migration, where it said they don’t currently support composition of secret contracts due to issues of scalability.

In Etherium you can call Contract B from Contract A. If Contract A has a flaw you can replace it
and link the new one to Contract B. The problem with this is it’s difficult to parallelize; the
network could become highly interdependent. However, without at least something, how can
non-trivial dapps be built, and bugs be patched?

Would it be feasible to have namespaces where many contracts can interact within that namespace?
Contracts within the namespace would be considered part of the same dapp, and have access to the underlying storage cache. This allows for dapps to evolve and should still allow for network scalability and security. Anything out of that scope could require an oracle. If dapps become monolithic, perhaps these can have a gas penalty on each transaction based on size.

2 Likes

hi guys, just re-ask this question again. Hopefully you guys can help!
It’s really helpful to me if this one can be clarified.

It can be called how to structure a large (complex) dApp and I really want to know how to do it within Enigma (or Rust).