Hi again,
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.
---
snip: 50
title: "Evaporation: Privacy for Wasm Execution Gas"
status: Draft
type: Specification
author: "Blake Regalia (@blake-regalia), Ben Adams (@darwinzer0)"
created: 2023-04-28
---
# 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.
## Rationale
show original
6 Likes
particularly like the " Optimistic Execution" property that is created as a cause of this SNIP spec. LGTM!
2 Likes