How to call a procedure of a public smart contract?

[Dominik1999]

Feature description

What should be the standard behavior to call a public smart contract?

In Ethereum, it is quite normal to call smart contract functions of foreign accounts (to use the Miden terminology). In Miden, we need that feature whenever an account with a public shared state exists. As far as I understand, there are four ways to call a public smart contract function:

1. Local tx & note: Users can create a note directed to the public smart contract. The contract owner can execute a local transaction and consume that note.
2. Network tx & note: Users can create a note directed to the public smart contract. The Miden operator can execute a network transaction against the account and consume that note.
3. Direct local tx: Users can execute the public smart contract directly. They need to get the full account state from the Miden operator, execute a local transaction, and send the contract (diff) back on-chain.
4. Direct network tx: Users can execute the public smart contract directly. The Miden operator can execute a network transaction against the account and consume that note.

What should be the canonical way for which use case to use, and how would the smart contract owner and caller know and define it?

1. This is bad UX and not what users expect from a smart contract (which should always execute). Maybe there are certain use cases where this makes sense
2. This sounds like the canonical way. However, the note creator "caller" would need to know the parameters when creating that note. How are the parameters passed from the contract to the caller / note creator?
3. This is also bad UX and we will run into nasty race conditions if several users want to call the smart contract at the same time.
4. This is similar to solution 2. How would the local client know what to call? And how would those network transactions be sequenced / prioritized?

Especially when a builder of a public smart contract deploys such a contract. How does he express that it should be called via 2. or 4.? In MASM we cannot define that certain procedures should only be callable via note scripts but not transaction scripts. Do we need that?

Maybe this is already solved and thought through.

Why is this feature needed?

No response

[bobbinth]

I'm assuming by "public smart contract" we mean an account that is managed by the network (e.g., there is an account deployed that anyone can update and the network will probably be the one updating it). This is different from foreign account though which is an account included in a given transaction as a "read-only" account.

If the above is correct, the option 2 is the right way to go - but to touch on other options:

• Option 4 is not something I've thought about before - so, not clear to me how this would work.
• Option 3 is going to create a lot of contention if multiple people try to update the account at the same time - so, this is not going to work.
• Option 1 could actually work but then it is not really a "public smart contract". For example, there could be an app running in some account and it is managed by either one entity or a set of entities that can execute transactions agains this account (e.g., this could be a DEX). Such an account would be similar to a rollup or a validium (depending on whether it is public or private).

2. This sounds like the canonical way. However, the note creator "caller" would need to know the parameters when creating that note. How are the parameters passed from the contract to the caller / note creator?

My assumption here is that if I'm interacting with a public smart contract, the creator of this smart built some "front end" for it. This front end would generate a transaction request which I'd be able to execute against my account. Let's take a counter contract as an example:

• Let's say the contract exposes a single increment procedure which takes a single parameter - a u32 value - by which the counter should be incremented.
• The "front-end" for the counter contract (could be written in Rust or TS or w/e) would collect the required data from the user (e.g., the value the counter should be incremented by) and would generate a transaction request.
• The user then would take this transaction request and execute it agains their account (e.g., via the wallet). This would produce the required note.

This whole process should be as transparent to the user as possible. For example, I go to the counter contract website, it prompts me to enter the increment value, once I do this a transaction request is generated and sent to my web wallet, the wallet prompts me to confirm the transaction, and then executes/submits it to the network. So, from the user's standpoint, they just enter the number and then click "confirm" on the message shown from the wallet.

I think this all should be possible today - but we should double-check.

[partylikeits1983]

This whole process should be as transparent to the user as possible. For example, I go to the counter contract website, it prompts me to enter the increment value, once I do this a transaction request is generated and sent to my web wallet, the wallet prompts me to confirm the transaction, and then executes/submits it to the network. So, from the user's standpoint, they just enter the number and then click "confirm" on the message shown from the wallet.

This is possible currently with the client, but the question is what happens to the note that increments the counter contract? Seems like there are 3 options:

1. The user who created the note executes it against the public counter contract in a separate transaction. I think there is still a possibility of a race condition if there are lots of transactions against the public smart contract.
2. The owner of the contract executes the note against the counter contract. Seems like there is a possibility of censorship here, but at least the owner can sequence the notes, preventing a race condition.
3. The node executes the note against the counter contract. Not sure if this is currently possible. Would be very useful if the node could sequence the note execution transactions.

[bobbinth]

Yeah, the first option is not a good idea because, as you mentioned, it leads to race conditions which may result in poor UX (though, there may be some use cases where this is accessible).

The third option is the way to go here. We call this option "network transactions" and is not implemented yet - but there is already work on it (e.g., 0xMiden/miden-node#692) and hopefully we'll add the basic support for this relatively soon (e.g., in a few weeks).

The second option is also interesting because it removes the burden from the network - but you are right, there is a possibility of censorship (though, this censorship should be detectable). Would be good to brainstorm some solutions to this - e.g., could we do some kind of forced note inclusion, or maybe we could have accounts where the owner is executing transaction most of the time, but sometimes the network can also execute them.

For now, until we have network transactions implemented, I think we should use option 2 as a stop-gap solution.