Proof of work predicate to limit the creation of spam transactions

Sway
1

Proof of work gated transactions

Purpose of this post

I want to see whether or not the community would be interested in something like this. If so, Charthouse Labs will post a more complete RFC with a proper spec.

Background

Spam transaction are an especially difficult issue to deal with on a network with low transaction fees. In particular if an app is sponsoring transactions there is always the possibility of griefing attacks draining sponsorship fees.

Proposal

Gate access to sponsored transactions via a set of capability tokens held by a predicate that requires a PoW proof to be calculated to be considered a valid transaction. A PoW proof requires that transactions have a computation cost, deters spam, but allows users to complete transactions.

Basic mechanism suggestion

POW predicate

A predicate that holds capability UTXOs. These UTXO can be released for a transaction given the following criteria.

  1. Accompanying any transaction a proof of work is included that uses the txId + a user selected salt that result in a hash with a difficulty level number of leading zero bits.
  2. That the capability coin is returned to the predicate after transaction completion

Capability minting contract

A contract that mints capability coins to the predicate.

PoW gated sponsorship

Protocols that would like to gate sponsorship behind PoW would create their own predicate that only released the sponsored funds if the capability UTXO is included as a transaction input.

Suggested predicate structure

Configurable {
uint256 difficulty
}
main(uint16 saltWitnessIndex)

The salt is included in witness data as to not modify the txId of the transaction.

The salt is then concatenated to the txId and hashed within the predicate. If the hash has difficulty number of leading zero bits and the tx returns the same number of capability tokens as are borrowed, the predicate resolves to true.

Drawbacks

  • Time sensitive transactions are not appropriate for transactions that require client side proving
  • Balancing difficulty to prevent spam and still have a positive user experience requires tuning
3 Likes
2

How can the distribution mechanism of capability tokens in the contract be effectively implemented while ensuring compliance with PoW requirements and preventing abuse?

3

To implement the distribution mechanism of capability tokens while ensuring compliance with Proof of Work (PoW) requirements and preventing abuse, a proposed solution involves using a PoW predicate that releases capability tokens only when a valid PoW proof is provided for each transaction. This mechanism ensures that tokens can only be spent when a computational cost is incurred, deterring spam. The distribution would be controlled by minting capability tokens to a contract, where the tokens are returned to the predicate once the transaction completes successfully.

4 Likes
4

Interesting idea! PoW as a way to protect against spam seems promising, especially for sponsored transactions. The main question is how to balance the PoW difficulty so it doesn’t discourage users but still effectively blocks attacks. I’m also curious about how the mechanism for returning capability tokens will be implemented to eliminate potential vulnerabilities.