Reduction of allocated stake requirements via light clients

[kayabaNerve]

With the context of the problem statement in #400, a question is raised:

Can we ensure the SRI in a pool cannot be drained, removing the need to allocate stake to secure it?

Most other networks solve this by writing the value of the SRI-equivalent off to 0 upon multisig compromise, not allowing it to be used for profit statements. Serai is distinct for being robust against multisig compromise and would need a distinct mechanism.

Light clients are the immediately accessible idea. If we are able to independently validate the InInstructions received from external networks, we're able to prevent the multisig from printing fake sriXYZ and in the process, draining the XYZ:SRI liquidity pool.

We aren't however, as stolen XYZ may be looped back into the multisig to give the appearance of the multisig having legitimately received fresh XYZ in order to execute swaps with. We'd need to prove, with each new XYZ received, no prior misbehavior has occurred.

Naively, this would require moving all scheduling logic currently in the processor on-chain and on-chain executing it with full views of the external chain state also included on-chain.

Practically, we actually could discuss compiling the scheduling logic from the processor into a no-std variant which we then execute with RISC Zero. Even if the Serai chain only has the block hash from the external network, we'd be able to prove all TXs are as expected for the cost of a STARK. We would not have to hand-write any ZK circuits ourselves either.

There is still an exploit window under this proposal. A malicious multisig could send itself legitimate external XYZ, dumping them into the XYZ:SRI pool. After draining the SRI side that way, they wouldn't provide backing to arbitragers swaps in the other direction. They'd simply walk away with the XYZ given that any Burns from SRI aren't expected to appear on-chain for several blocks.

In order to prevent this, under this proposal and in general, the stake allocation requirement cannot use the spot price of XYZ:SRI, yet instead must use some TWAP to ensure any attempt to so dump XYZ hits the capacity limit and errors. That way, while XYZ can still be sold to maximize profit, the XYZ taken and the SRI profited would be less than the stake allocated by the malicious actors.

This tail commentary is already noted in #394, leaving this issue with the idea of on-chain STARK proofs of proper behavior to prevent the ability to drain the SRI side of the pools when turning malicious. This would halve stake requirements.

Please note, technically, Parity has built an off-chain storage system for Substrate so blobs (such as STARK proofs) can be sent around the network without explicitly appearing on chain. This would be beneficial for us as we'd want the proofs to be replaceable with more efficient proofs in the future and ideally the latest proof would roll up all prior proofs.

[kayabaNerve]

I believe we'd need to use a distinct IVC scheme in order to fold proofs. Ideally, they don't have prover overhead with iteration depth and have verification cost increases capped at logarithmic to historical size.

Nova, to my understanding, does meet these requirements.

[kayabaNerve]

RISC Zero does have their own IVC scheme: https://www.risczero.com/news/continuations

[kayabaNerve]

ZK proofs would also prevent validators from silently dropping received coins, letting them steal them without increasing the on-chain stake allocation usage.

[kayabaNerve]

#459 supersedes this via its usage of a price oracle preventing draining the SRI from a pool without allocating greater stake.

#459 also doesn't solely work for networks which offer finalization and doesn't require an experimental ecosystem/moving the entire processor to no-std/tens of KB blob storage updated every few minutes.

[kayabaNerve]

We can use functional encryption to process an external blockchain, run the Serai processor, and output the next run's state + a signed digest of events. The practical issue this would be serialized and the time to execute FE likely exceeds the time between blocks. It also requires compiling the entire Bitcoin (for example) blockchain into a FHE circuit and a trusted setup.