On a better smart contracts interface

[Arvolear]

Project

compiler

Describe the feature

Overview

Currently, there is no way for the outside observer to deduce a simplicityhl smart contract interface. The entrypoint (spend) functions are hidden under the witness fields, which makes source code parsing and witness generation extremely tedious. This issue proposes a way to standardise the spending interface.

Impact

Having a clean smart contract interface would enable, first and foremost, two things:

1. Non-leaky autogenerated witness construction for calling specific entrypoints. We are already doing this generation in simplex, but it's far from being ideal due to witness parsing complexity.

2. Clean presentation of the "spend" inside a wallet (Blockstream App). Users will be able to see which function of the smart contract is being called.

High-level feature request

Before

Here is a dummy simplicityhl contract that showcases the complexity of understanding the spending interface:

fn deposit(data: u256) {
    // ...
}

fn withdraw(sig: Signature) {
    // ...
}

fn claim(sigs: [Signature; 2]) {
    // ...
}

fn main() {
    match witness::PATH {
        Left(deposit_data: u256) => deposit(deposit_data),
        Right(withdraw_or_claim: Either<Signature, [Signature; 2]>) => match withdraw_or_claim {
            Left(withdraw_sig: Signature) => withdraw(withdraw_sig),
            Right(claim_sigs: [Signature; 2]) => claim(claim_sigs),
        },
    }
}

After

The proposed change:

entry fn deposit(data: u256) {
    // ...
}

entry fn withdraw(sig: Signature) {
    // ...
}

entry fn claim(sigs: [Signature; 2]) {
    // ...
}

One way of doing this

Instead of requiring a user to specify a main function in every contract, the compiler may generate it automatically.

Every entry function will be assigned a special funcid = sha256(<function name + parameter types>)[0:4].

In our example:

• The funcid for deposit is sha256("deposit(u256)")[0:4] = 0xb15ec5fa.
• The funcid for withdraw is sha256("withdraw(Signature)")[0:4] = 0x397bbc03.
• The funcid for claim is sha256("claim([Signature;2])")[0:4] = 0x6c29f44d.

Then, to spend a contract via an entrypoint function, a contract will expect a witness variable PATH to exist and start with a funcid. The compiler will build a "virtual binary tree" inside the main function in a deterministic (and known) manner that parses the PATH variable and deduces which function the user is intending to call.

The compiler may output a special JSON file specifying such entrypoints. The offchain tools may then provide functionality to build the witness for users only by accepting this JSON, a function name, and its parameters.

---

Hope this request is not a super long shot. I'd love to hear your opinion regarding this.

[stringhandler]

I don't particularly see the need for a unique function id, since we don't allow overloading. The method name would be sufficient as an id. (Unless there is a different need for hashing it? The only other reason I can think for doing this would be to use the same space for all methods, e.g. u32, but I can't really see a use case for that because contracts can't be upgraded, so no need to reserve space.)

I agree with the problem, but there are other solutions to throw into the ring:

1. A purely rust-like solution would look something like this, assuming we had enum support or multiple match arms:

fn deposit(data: u256) {
}

fn withdraw(data: u256) {
}

fn main() {
  match witness::PATH {
     "deposit" -> deposit(witness::DATA),
     "withdraw" -> withdraw(witness::WITHDRAW),
};

The entry keyword could be used to auto generate this main method, or potentially we could add an attribute like:
2.

#[entry()]
fn deposit(data: u256) {

I'll admit that an entry keyword would be easier to add to the chumsky parser, however, it does introduce an attack that would need to be mitigated. (NOTE: the attribute entry is also possibly affected) The attack is basically an attacker introducing an entry keyword in a module that is imported by an unsuspecting user, and now the attacker has a way to spend the funds by calling their backdoor.

A safer option may be to add a macro in the main, although less elegant, there can only be one main:

fn main() {
    entry_paths!( deposit, withdraw);
}

I'd like to also at this time suggest killing two birds with one stone by creating formal names for these entry points and stopping a witness swiping attack.

In your above example, the data passed into deposit is not committed to in the sig_all_hash and is malleable. This is true for any witness inputs. Obviously signatures do not need to be committed to, but everything else in the witness data is malleable.

To combat this slightly, I suggest adding specifically named witness values or potentially a new node type in simplicity itself:
witness_call_data::<name>, which are also included in any sig_all_hashchallenges automatically. The action (which you refer to asPATH), could be a convention used for which method to call. The generated code would then take fn deposit(data: u256)and autogenerate thesewitness_call_datavalues:witness_call_data::ACTION(orwitness_call_data::PATHif you prefer) andwitness_call_data::DATA`.

Signatures should not be part of the witness_call_data unless they are actual data, for example, oracle signatures. These signatures should remain in witness namespace directly, for example witness::SIGNATURE, and should be called as such.

We do need to think about how raw simplicity deals with this though, and that is why I suggest a new node type (i.e. witness_call_data).

[Arvolear]

A purely rust-like solution

The multiple match arms is also a good idea imho, but it may result in a slightly bigger script size and cost (if matching is O(n) instead of O(log n)).

---

The attack is basically an attacker introducing an entry keyword in a module that is imported by an unsuspecting user, and now the attacker has a way to spend the funds by calling their backdoor.

This is an extremely conservative issue. I think this has never happened even in the Ethereum world.

---

I suggest a new node type (i.e. witness_call_data)

Agree that witness malleability may be a huge problem if a smart contract is not properly implemented (in general), but this is probably out of scope of this feature request.

[stringhandler]

The multiple match arms is also a good idea imho, but it may result in a slightly bigger script size and cost (if matching is O(n) instead of O(log n)).

N is so small anyway, but the simplicity program would be pruned, so any implementation would be const.

This is an extremely conservative issue. I think this has never happened even in the Ethereum world.

This is a subjective opinion. I'm not sure how Eth's implementation affects our code here? I raise it here because any implementer would need to add tests to make sure this is not possible.