SNIP-25 - Improved privacy for SNIP-20 tokens
This document outlines updates to the SNIP-20 specification with the introduction of decoys. A decoy, in this context, is a false or 'dummy' account that is intermingled with real accounts during transactions. The main function of these decoys is to act as distractions or misdirections to potential attackers, thereby making it more difficult to pinpoint the actual accounts involved in a transaction.
The concept of decoys is designed to strengthen privacy measures by ensuring that account information remains concealed during transaction processes. By intermixing real accounts with these 'decoy' accounts, a level of uncertainty and complexity is created, which can deter potential attackers trying to discern the actual accounts being updated. Additionally, randomness is integrated into the execution messages, providing an extra layer of protection by creating uncertainty in storage access patterns.
"Should", "May", and "Must", notation in this document conforms to the standards set by RFC-2119
Contracts that support the existing SNIP-20 standard are still considered compliant, and clients SHOULD be written so as to benefit from this feature when available.
Secret Network smart contracts provide computational privacy through the use of Trusted Execution Environments, which process encrypted data securely without revealing it publicly on chain. However, the patterns at which data is accessed when processing confidential transactions can leak crucial information. In the example of a SNIP-20, each account balance may be stored privately, but the access pattern is public, so an untrusted host OS can potentially learn private information by monitoring accesses to the key-value storage. For example, each user's balance is kept in a key-value store, and each account is associated with a consistent, encrypted key. By keeping track of the keys fetched from the storage, an outside observer can decipher the receiver of a SNIP-20 transfer.
In order to effectively incorporate decoys, it is necessary to randomly interweave decoy addresses with the real addresses, ensuring that the real addresses are included within the sequence. Decoys SHOULD be used for every message exposed to storage access pattern attacks, and for every transaction that does, it MUST include the decoys parameter. Provided decoy addresses MUST be treated and utilized as if they were genuine addresses and MUST be used in a way that is indistinguishable from real addresses. Execution messages which accept the decoys field MAY also accept the entropy field, which is an optional Binary used to introduce randomness by providing additional read and writes to the decoy addresses that are included in the message. How entropy is implemented is left to the developer's discretion. For example, one MAY include the decoys field and not the entropy field and use Secret VRF for randomness.
The existing Redeem, Deposit, Transfer, Send, Burn, TransferFrom, SendFrom, BurnFrom, and Mint messages now SHOULD accept the decoys field.
Example Transfer message with decoys field included, and optional entropy field omitted (How randomness is implemented is left to the developer's discretion).
{
"transfer": {
"recipient": "secret1jxlkaddg4nvsvnjylx94xnwrjprqvvp20r4hxd",
"amount": "1000000000000000000",
"memo": "Transfer for services rendered",
"decoys": [
"secret1zpaxzv6yggvmj4jj7md94rjxvnpa6q07asxyyh",
"secret12g3ujhpkunstpdg78f8fny0r59zg6e9kghgpxy"
]
}
}{
"transfer": {
"status": "success"
}
}Batch operations are used for handling multiple token transfers or operations in a single transaction. In the case of batch messages, the decoys parameter SHOULD be defined in the actions module and imported into the messages module:
Batch Transfer Message:
BatchTransferFrom {
actions: Vec<batch::TransferFromAction>,
entropy: Option<Binary>,
padding: Option<String>,
}Batch Transfer Action:
pub struct TransferFromAction {
pub owner: String,
pub recipient: String,
pub amount: Uint128,
pub memo: Option<String>,
pub decoys: Option<Vec<Addr>>,
}Refer to SNIP-22 for further reading on batch operations.
How randomness is implemented is left to the developer's discretion.