Earlier this year,
@darwinzer0 and I introduced Evaporation as a means to prevent leaking execution information through the
gas_used metadata. As a result of our efforts, two new API methods
were added to SN.
This post is to request comments from the community on the SNIP-50 specification before a PR is opened to merge it. Going forward, we advise
all contracts to implement this specification, so your feedback is greatly appreciated.
This file has been truncated.
title: "Evaporation: Privacy for Wasm Execution Gas"
author: "Blake Regalia (@blake-regalia), Ben Adams (@darwinzer0)"
# SNIP-50 - Evaporation: Privacy for Wasm Execution Gas
This document describes a specification for contracts to implement, as well as a set of best practices to use, in order to prevent leaking execution information through the `gas_used` transaction metadata.
**Evaporation** is a concept that was introduced to overcome privacy risks associated with the publicly viewable `gas_used` field in transaction results' metadata. Evaporation refers to the practice of deliberately consuming extra gas during execution in order to pad the metered `gas_used` amount before it leaves the enclave.
With evaporation, clients can now instruct contracts on exactly how much gas their execution should consume, yielding a consistent `gas_used` across all methods. Evaporation is similar to the `padding` field in this regard; it allows clients to parameterize their message in order to mitigate data leaking through the publicly viewable execution metadata. Whereas `padding` is used to fill the length of encrypted messages, _evaporation_ is used to fill the `gas_used` field.
particularly like the " Optimistic Execution" property that is created as a cause of this SNIP spec. LGTM!