DEP 0002: Smart Contract Composability

status: deprecated

Current Situation

When creating the DAO, we needed to invent the concept of protocol owned liquidity in DarkFi. Without this, in order to have on chain DAO treasuries, the DarkFi blockchain would have to recognize funds held by both the money and DAO contracts as valid. This introduces a security risk if there is an error in the DAO contracts.

Additionally it means that liquidity could only be held by the DAO contract, and any liquidity held by other contracts would have to be recognized by the consensus as valid. This would restrict the protocols that could work with on chain liquidity to a small hardcoded subset due to security.

Motivated by the desire to enable protocol owned liquidity, we created the concept in money::transfer() of the spend_hook.

Firstly a quick recap of how money::transfer() works. During the mint phase of creating coins, we construct a coin C = hash(…, spend_hook, user_data). The … contains coin data such as value, token ID and other attributes. During the burn phase we produce a deterministic unlinkable nullifier.

This is a more general ZK concept of committing to several attributes, and then later either full on revealing them or more specifically applying constraints to the attributes. To enable protocol owned liquidity, we introduced the coin attributes spend_hook and user_data, motivated by these desires:

  • Generalize protocol-owned liquidity enabling any third party to write contracts that own liquidity.
  • Stronger security model for on chain liquidity by only depending on the money contract when composed with contracts like the DAO.

When a coin is spent, the spend_hook is revealed publicly. The money::transfer() call enforces that the subsequent contract called in the tx matches the spend_hook. In our example, spend_hook = DAO, and then our tx will have two calls: [money::transfer(), DAO::exec()]. When spending a coin where the spend_hook = DAO, then money::transfer() will check the next contract in the tx will match the spend_hook.

Now you might ask some questions:

  • Here we are listing DAO, but actually we need a stricter check that the call is DAO::exec() and not some other DAO method call.
  • We need to enforce which DAO we are operating on.

This is where the user_data is used. We can commit to several things including which function is called in the contract. Since in the DAO, only DAO::exec() can be composed, we just sidestep this and enforce that when a tx has two calls, then the DAO one must be DAO::exec(). We then use the user_data to store the DAO bulla.

Motivation: Limitations of Current Approach

The current approach enables contracts to own liquidity, which is how we can have DAO on chain treasuries. We have the ability for contracts to directly call other contracts. However this calling mechanism is static.

We desire now to generalize the DAO calling mechanism, so any contract could be called. Currently DAO::exec() deserializes the money::transfer() calldata, and then enforces its checks on it inside wasm. These checks are hardcoded.

It would be very useful if instead this data or code were to be dynamic. Therefore a DAO proposal could be called, not to call money::transfer() but instead to call another contract. This system would then be generic and usable with other contracts, such as an algorithmic streaming contract making calls on a ZK NFT.

Proposal: Introspective Params

The current ContractCall struct looks like:

pub struct ContractCall {
    /// ID of the contract invoked
    pub contract_id: ContractId,
    /// Call data passed to the contract
    pub data: Vec<u8>,
}

We propose to change the data field to this:

pub struct ContractCall {
    /// ID of the contract invoked
    pub contract_id: ContractId,
    /// Named call data passed to the contract
    pub data: HashMap<String, Vec<u8>>,
}

This way contracts can query each other's calldata in a dynamic compatible way. Some part of the params for a contract may be specific to that contract. Another part might be generic, which shares the same struct with multiple other contracts. This enables contracts to query an interface from another contract's calldata, deserialize that data and work with it, without having to hardcode a dependency, e.g DAO::exec() hardcoding a dependency on money::transfer() params.

Note on Auth Modules

An alternative approach is introducing the concept of auth modules. So for example, with the DAO, a user could deploy their own contract on chain with specific logic, then make a proposal to execute that contract. We could also supply our own auth module with hardcoded branching support for several common contract types.

However while this may be desirable in some cases where complex logic in DAO proposals are required, it presents several downsides:

  • The supplied auth module will hardcode support for a few contract types and not be properly generic.
  • User deployed contracts could be expensive and error prone.
  • For efficiency the DAO would probably end up hardcoding support for several contract types directly, as well as other composable contracts.