[clairty] add functions to query the transaction asset map as it is running

[jcnelson]

The (as-contract) built-in should be extended to take a list of post-conditions on assets moved by the contract, in order to guard against things the contract might do (or might get tricked into doing). In particular, the fact that a trait implementation can be passed into (as-contract) means that a contract can be coerced to run arbitrary Clarity code (by design), which means that the caller of (as-contract) should be able to defend the contract against attempts to do things like move tokens and assets.

[jcnelson]

Alternative: expose a way to query the asset map from Clarity. Then a contract that wanted to guard could do a lot more with this, and the cost assessment is a lot easier to tabulate.

[jcnelson]

Implement this as a special closure type that evaluates a code block, and then inspects the resulting asset map.

EDIT: Better yet, just add built-ins for querying the asset map at any point during the contract's execution.

[hstove]

I am unfamiliar with a use-case where a contract would use as-contract with a non-trusted trait. If an attacker was able to get a contract to transfer funds from itself, that seems like a full-stop exploit from a contract design standpoint.

[jcnelson]

Right; the problem is that this is a design foot-gun. Fundamentally, the problem is that developers may find themselves wanting to do some sort of dynamic dispatch to user-submitted (untrusted) code. The contract developer should be able to specify post-conditions on the contract-call in order to guard against the user-submitted code from moving assets it's not supposed to be moving. The wallet could theoretically analyze the call graph and figure out what the set of reachable asset movements are, but that doesn't let the developer write out what kinds of safety assumptions they intend the code to adhere to. Similarly, a SIP could be written to require certain types of trait implementations, like SIP 009 and SIP 010, to supply a wallet-parseable set of post-conditions, but this would require all wallet implementations to correctly parse this list and attach it to transactions.

What we really need is a way to query the transaction's ongoing asset map -- i.e. the set of token movements that have occurred over the lifetime of the transaction. This data structure gets fed into the post-condition processor, but not the Clarity VM. If we could expose it to the Clarity VM, then it's trivial for the developer to add arbitrary safety guards on asset movements before and after contract-calls (or anywhere in the code).

[jcnelson]

Re-assigning to @obycode, since this is part of the Clarity VM. Please feel free to re-assign!

[hstove]

One interesting use case:

With contract-based multisigs, signers cannot attest to post conditions when approving a transaction - they can only approve a specific contract call. While they can read the source code of whatever the transaction, it's possible that the actual asset transfer amounts are varied. For example, if conducting a swap from one token to another.

With this feature, the multisig contract can persist something similar to post conditions and verify that they're all correct after executing the contract call.