Account implementation late binding

[hackaugusto]

Goals:

1. Decouple interface from implementation (i.e. Alice should be able to send a note to Bob, which calls Bob's receive_asset without having to know the implementation)
2. Interface discoverability (i.e. Alice should be able to determine if Bob implements an interface prior to generating a note)
3. Code evolution (i.e. Bob should be allowed to update its implementation, and that should be allowed without breaking Alice's note sent to a different implementation)
   1. Note: It may not always be desirable to allow for code updates. I think this is an orthogonal problem and won't go over it here.
4. The executor of an transaction should be able to determine if Alice's note uses only APIs provided by Bob's account.
   1. note: this does not prevent a note from calling an interface that doesn't exist, because it is possible for a transaction that update's the account interface to be bundled together with a transaction that called a removed method. However that is an edge case.

Constraints

1. After Alice created a transaction with an output note to Bob, the note source code can not change, meaning that:
   1. The identifier used by the note for function calls stays the same
   2. So does the order and types of the arguments to this call
   3. This requires ABI compatibility. ABI stability in turn requires a call convention and data layout.

Design space

1. Goals.1 and Goals.2 required a way to determine an external symbol
   1. The symbol could be defined as the hash of a function signature, e.g. hash("receive_asset(asset)"). This is the approach taken by Solidity. The advantages here is that one can control the size of the symbol very easily (better than name mangling). If we use a word we can also prevent collisions
   2. This identifier could also defined with a registry
2. Goals.2 require a form of registry with the account itself (a linking table of sorts, mapping symbols to implementations).
   1. This can easily a modified Merkle Tree. The values of the tree could be public or not.
      1. If the tree leaves are symbols, and we define an order these elements should be laid out, a parent would represent an interface. This could be as simple as lexicographical order of the function signatures.
      2. A Merkle tree can not be used because one has to define the supported interfaces and their corresponding interface. One approach is that by convention the left child of the root defines the interfaces, and the right child defines their implementations. Each node in the tree would be prefixed with their position in the tree, and the implementation would be correlated to the implementation if 1. there are one merkle proof for each 2. the prefixes of both matches.
   2. We could trade off easy of usage by using a plain list instead of a Merkle tree, but there are some downsides like space usage and loss of privacy
3. Goals.3 could be as simple as updating the aforementioned Merkle root
4. Goals.4 could be done by parsing the Note's code prior to execution, and checking all the call instructions.

Note: I often call this dynamic binding too, but that can be confusing with runtime dynamic binding. So instead I'm going try to stick to late binding to make it a bit clearer that this does not happen program execution

[hackaugusto]

In the description above, the Accoun's linking table, and the the way the registry is used to link a symbol to an implementation would be part of the protocol. However the way the symbol is defined would be by convention, e.g. the user could add a symbol 0x0001 even if they don't know a signature that corresponds to it.

The above would also lack any type of validation if the table is not public. For that reason I would add one escape hatch, with would be the auth_tx symbol would have their implementation defined outside of the linking table described above. That would allow Alice to authenticate a transaction, even if the table is completely corrupt. The transaction kernel would have well defined symbols, so the user would be able to recover an account that had a previously corrupt linking table.

[bobbinth]

Achieving goal 1 (decoupling interface from implementation) would be difficult for technical reasons (because of how MAST works) - but I would also argue that it is undesirable, especially if we allow code upgradeability.

The reason for this is that when I create a note which calls some methods on an account I want to bind this note to the exact implementation of what is going to be executed. Otherwise, the recipient could update the code of the account and executing the note would result in something that I didn't intend. A simple example of this would be an atomic swap described in #22. If the implementation of send_asset is not fixed, the recipient could swap it out for a noop, and claim all assets in the note without creating an "exchange" note in response.

There are other benefits to binding interfaces to implementations - so, I'd say this is "a feature, not a bug".

Regarding goal 2 (interface discoverability) - this really depends on whether account data is stored on chain or off chain. For off chain accounts, there is no interface to discover - so, the owner would need to reveal the part of the interface which is relevant for a given transaction.

For accounts which are stored on-chain, the plan is to store serialized AST for each interface method - so, it would be fairly easy to figure out which methods are available. There could be other ways as well (i.e., a list of MAST roots which the ASTs compile into).

Regarding goal 3 (code evolution): as mentioned above, I don't think it is a good idea to allow changing implementation of a given method as it could lead to all kinds of security issues. We can always allow users to add or remove methods to an account. This does affect code root for the account - but that shouldn't be a problem.

Regarding goal 4: it is a bit more tricky. A note could have conditional statements which allow it to be executed against different accounts. So, just by looking through call instructions it wouldn't be possible to tell which subset of them is applicable to a given account. As of right now, I don't know of a better way than trying to execute a note against a given account to see if execution succeeds.

[hackaugusto]

would be difficult for technical reasons (because of how MAST works)

I lack knowledge here, any pointer on where can I get up to speed with how it works?

If the implementation of send_asset is not fixed, the recipient could swap it out for a noop, and claim all assets in the note without creating an "exchange" note in response.

This is a very good point. I would usually take the approach of considering the other party adversarial and design the feature in a way it doesn't rely on cooperation. That is one of the benefits of requiring from both parties a commitment to the swap.

I also wonder how this will impact evolution of the ecosystem, because this means that Alice needs a whitelist of trusted send_assets to use for token swaps, that in turn puts trust on the maintainers of the list and makes it harder to deploy new Account wallets with newer implementations.

Another thing to consider, is that we don't have to commit to only one form of binding. So that interfaces that benefit from the late binding can use it, otherwise the stay with the default static binding. (Lots of speculation on my part here, no idea how that would be implementation wise :) )

[hackaugusto]

I also wonder how this will impact evolution of the ecosystem, because this means that Alice needs a whitelist of trusted send_assets to use for token swaps, that in turn puts trust on the maintainers of the list and makes it harder to deploy new Account wallets with newer implementations.

Humm, I guess one way to remove this constraint is to have verifiable contracts, similar to design-by-contract. The idea is to somehow define a contracts within the kernel, one contract would be "Call procedure {x} on Bob's account, this procedure must return a note address to me", that way only the kernel has to be trusted, which is already the case, and there is no need to manually review every wallet code and white list it. And there is no need to know how Bob produced the note, just that it somehow happened. This would for instance allow Bob to do two swaps at the same time, as a market maker. Alice sends T1 to Bob in exchange for T2, Charlie sends T2 to Bob in exchange of T1, Bob, aggregates both of these exchanges on a single transaction, and make sure that whatever differences in amounts from T1 and T2 are satisfied. This is obviously a bit hand wavy, there are things like when should the contract checks be performed. But could be an interesting avenue to think

[bobbinth]

I lack knowledge here, any pointer on where can I get up to speed with how it works?

This basically follows from programs being described as MASTs (see here). In the MAST model, the root of the MAST commits to the entire program, not not just its interface. So, even if you change a single instruction, the MAST root would change.

"Call procedure {x} on Bob's account, this procedure must return a note address to me", that way only the kernel has to be trusted, which is already the case, and there is no need to manually review every wallet code and white list it. And there is no need to know how Bob produced the note, just that it somehow happened.

I think it would be more tricky than that as we may want to impose specific conditions which might be difficult to specify generically. For example, we may say that a note can be consumed only by someone who has a given public key for a specific signature scheme and only after some period of time (or even something much more complicated than that).

Overall, I think the way MAST works currently gives us pretty good way to balance various concerns. When you invoke a procedure by its MAST root, you know exactly which code will be executed. There could be a set of well-known procedures which people would evolve over time (e.g., via "improvement proposals"). The basic wallet interface described in #22 could the the first set of such well-known procedures. This also sets up a good process for ensuring that well-known procedures don't have bugs etc.

You could always do something on your own and add arbitrary code on your account, but then anyone invoking this code would need to examine it. I don't think it's a bad thing either. As a developer (or even a user), you probably shouldn't call any code which could do something you don't know - that's an easy way to lose money.