RCP-250528A: Analysis of anti-spam measures

[dr-orlovsky]

RGB spam prevention

What we try to prevent is the fact that a user of RGB contract may create large operations, either in size, or in verification computational effort, paying nothing for that, and offseting the price to the future owners of the asset under the contract. This type of attack may significantly affect user experience and even make an asset unusable.

Even with zk compression of the history, it will be the future users paying the larger price for the production of zk-proofs to the provers at least once.

Spam in RGB may be produced in several ways:

• creating a lot of operations and/or outputs;
• adding unused extra data to each input witness;
• call computationally expensive locking conditions.

Scenario analysis

To address that the following strategy is proposed

Lots of operations and outputs

On bitcoin, each operation takes a bitcoin onchain transaction (otherwise it doesn’t get to the history), and each output - a Bitcoin UTXO. This is a native way how we prevent spam with Bitcoin and Liquid.

For Prime, we may also leverage the const of transaction, or it will be required to activate PoW mining (see below).

Unused extra data in input witnesses

Recommend to contract devs to check that they are unset. This requires adding an opcode for the check and modification of the existing issuers.

When a user-produced global state is used in a contract, the issuer must strictly define and restrict its properties.

Computationally expensive custom lock scripts

In RGB-I-1 we will need to link the max script complexity to the PoW, which can be produced using nonce operation field.

To make this backward-compatible the following actions must be taken in RGB-I-0:

• codex devs must set input_complexity to 0, otherwise they risk the contracts to be spammed;
• introduce a flag for contract issuers (in contract meta) to prohibit any lock scripts;
• introduce reserved fields for future flags in codex and contract meta;
• in RGB-I-1 indicate the specific PoW algorithm with those flags.

Since in RGB-I-0.1-0 there is no way to add custom lock libs to the consignments, the contracts having input_complexity set to 0 are safe from the spam. Contracts, which would like to leverage lock scripts, can provide them in the codex and restrict their complexity to the fixed level, being thus protected from the spam as well.

Required changes to v0.12 RC1

• reserved feature flags in codex and contract meta;
• add operation_libs in the consignment v1 which will work only for Prime consignments

Implementations

• Release candidate 2 AluVM/ultrasonic#6
• Bring changes from ultrasonic RC2 AluVM/sonic#25