Question about the rgbasm of `ifa_lib_inflation()`

[cymqqqq]

Description:
The part validation of inflation is as follows:
// Check that input inflation rights equals issued supply + allowed inflation put a8[0],ERRNO_INFLATION_EXCEEDS_ALLOWANCE; add.uc a64[1],a64[0]; // result is stored in a64[0] test; // fails in case of an overflow sps OS_INFLATION; // check sum of inflation rights in input equals a64[0] test;
Here we can see that the sps instruction is used in the above code, but there is a load_revealed_inputs function defined here:

And, `context.op_info.prev_state`, the prev_state is extracted from the consignment:

But the utxo-bind rgb asset transfer history is defined in the consignment, so I think maybe we should use the sas instruction to validate(because the owned_state is used here, but not prev_state) instead of sps. When we perform the inflate action, we directly use a new utxo with a fixed amount of rgb asset to execute the inflate operation.

[St333p]

I'm really sorry I missed this issue for such a long time.

TLDR: sps and sas operators perform two different checks and are both used in ifa_lib_inflation

The long story

An inflation operation contains:

• inflation rights in input
• inflation right in output (change)
• asset allocation in output (newly minted assets)
• ISSUED_SUPPLY global state
• ALLOWED_INFLATION metadata

Here is the relevant AluVM code that checks the validity of inflation operations.

        // Check reported issued supply equals sum of asset allocations in output
        put     a8[0],ERRNO_ISSUED_MISMATCH;  // set errno
        ldg     GS_ISSUED_SUPPLY,a8[1],s16[0];  // read issued supply global state
        extr    s16[0],a64[0],a16[0];  // and store it in a64[0]
        sas     OS_ASSET;  // check sum of asset allocations in output equals issued_supply
        test;
        cpy     a64[0],a64[1];  // store issued supply in a64[1] for later

        // Check reported allowed inflation equals sum of inflation rights in output
        put     a8[0],ERRNO_INFLATION_MISMATCH;  // set errno
        ldm     MS_ALLOWED_INFLATION,s16[0];  // read allowed inflation global state
        extr    s16[0],a64[0],a16[0];  // and store it in a64[0]
        sas     OS_INFLATION;  // check sum of inflation rights in output equals a64[0]
        test;

        // Check that input inflation rights equals issued supply + allowed inflation
        put     a8[0],ERRNO_INFLATION_EXCEEDS_ALLOWANCE;
        add.uc  a64[1],a64[0];  // result is stored in a64[0]
        test;  // fails in case of an overflow
        sps     OS_INFLATION;  // check sum of inflation rights in input equals a64[0]
        test;

The code blocks perform 3 different checks that jointly guarantee the correctness of the inflation operation:

• block 1 checks that the total amount of minted assets equals the ISSUED_SUPPLY global state, which can thus be used to compute the circulating supply of the asset
• block 2 checks that the change amount of inflation rights in output equals the ALLOWED_INFLATION metadata
  • here sas is used to compare sum of outputs of type inflation to the value stored in a64[0] register, i.e. ALLOWED_INFLATION metadata
• block 3 checks that the total inflation right in input equals the sum of minted assets and change inflation rights
  • here sps is used to compare sum of inputs of type inflation to the value stored in a64[0] register, i.e. ALLOWED_INFLATION + ISSUED_SUPPLY