SDK is not abstract enough which degrades Aztec design

[shiqicao]

Aztec's design is very generalized and abstract, however the SDK doesn't keep the abstraction and often offer very specialized API. This hides the true value of Aztec.

Example 1,

It always assumes auth witness is a hash. What if I want to design an account contract which only allows even function selector?

Example 2,

It always assumes the signature of entrypoint of account contract, actually Aztec allows it to be anything. It always assumes that the entrypoint is called "entrypoing" and it takes AppPayload, etc. See the code from DeployMethod

  private getSelfFeePaymentMethod(originalPaymentMethod?: FeePaymentMethod) {
    if (!this.address) {
      throw new Error('Instance is not yet constructed. This is a bug!');
    }
    return new AccountEntrypointMetaPaymentMethod(
      this.wallet,
      this.artifact,
      'entrypoint',
      this.address,
      originalPaymentMethod,
    );
  }

Solution

To avoid this, one method is to create sample account contract which fully exercise account contract features and freedom. For example, 1, what if an app wants user to sign actual function calls(name, parameters, etc) instead of just hash. 2, support multiple entrypoints. 3, support different entrypoint parameters than AppPayload.

[linear]

from nico:

Indeed, the SDK is very new and we're still in the process of figuring out the right abstractions to keep it flexible enough to build all kinds of applications, while also ensuring we're not introducing privacy-leaking footguns.

Your point re. account contracts is well understood, it currently assumes a bit too much about account entrypoints (a task that needs to be left for the wallet to carry out). I'm curious about your comment mentioning authwits however, could you expand on that please?

[shiqicao]

by the way, who is "nico"?

[nventuro]

(I'm Nico)

[shiqicao]

Our app is not yet ready for public, so I can't disclose what we are working on. But I can provide some hypothetical use case,

1. entrypoint function called foo,
2. foo takes a list of contract call descriptions, which include function signatures instead of function selectors,
3. authwit is Schnorr key signs the list of contract call descriptions, instead of signing the hash of calls.

The current SDK can't support this use case.

[linear]

from nico:

Ahh, I see. Unfortunately two things are currently called 'authwit', so there is some confusion. You are talking about authwits from the point of view of an account contract verifying that it should make a contract call then. If so then yes, this is part of the broader issue of the SDK currently assuming too much about what account contracts look like.

I understand you not being able to share many details, but it'd help if you could expand on the capabilities you're after, and the kind of values you'd want to sign over.