Add optional evaporation field

[blake-regalia]

This issue represents a feature request to add support for a new optional field in every message for the upcoming SNIP-25.

This feature is similar to the padding field in that it allows clients to tune their message in order to reduce data leaked through the publicly viewable metadata of executions. While padding is used to fill message length, users are still exposed to data leaking through the gas_used field of transaction results.

We've implemented a proof-of-concept using storage writes, but are experimenting with other operations as well.

It's important to note that even if the cost of the underlying operation were to change, this approach remains flexible enough to compensate since the client determines the multiplier.

Rationale

The public gas_used result of a contract execution leaks data about the code path taken.

In its simplest form, attackers can use this information to distinguish between the following execution methods with high confidence: create_viewing_key, set_viewing_key, increase_allowance/decrease_allowance, send/transfer, revoke_permit, and so on.

In some situations, an attacker might even be able to narrow or deduce the values of certain private variables.

While more precise solutions would involve modifications to the compute module, we propose an approach that can be deployed with contracts as-is and in a manner that is guaranteed to take place within the enclave.

Evaporation

We introduce the concept of "evaporation", by which extra gas is deliberately and deterministically consumed during execution in order to pad the gas_used.

Users may include an optional evaporate field in every message. The value of the field should be an integer that specifies an arbitrary multiplier for some fixed-cost operation.

Using evaporation, wallets can compute a precise multiplier to provide as input during execution in order to produce a gas_used value that effectively obscures the nature of the transaction.

Requests

Name	Type	Description	optional
evaporate	number	Number of times to perform the predefined fixed-cost operation in order to consume extra gas.	yes

Example

{
  "transfer": {
    "recipient": "<address>",
    "amount": "100",
    "padding": "-------",
    "evaporate": 620,
  },
}

[darwinzer0]

After much testing we have gone the route of implementing a new gas_evaporate API function. The relevant PRs can be found at:

SecretNetwork: scrtlabs/SecretNetwork#1388
cosmwasm: scrtlabs/cosmwasm#13

[darwinzer0]

Added PR #75