Author: Antoine Riard 2022-09-30 02:00:30
Published on: 2022-09-30T02:00:30+00:00
In a recent email exchange, Antoine Riard and Jeremy Rubin discussed the use of covenant-based drivechain designs and recursive-covenant "embedded" sidechains as a solution to double-spending issues. They explored the possible security bounds and impacts on funds, along with variants of pegging mechanisms that influence the soundness of game-theory backing up functionaries' execution.Riard shared an entry he started for the ZmnSCPxj design on Github. In his post, Rubin showed techniques that could accomplish something similar using ANYPREVOUT with a one-time trusted setup ceremony. Rubin presented general techniques that could be applied to many different types of covenants. He started by building a Peano counter graph, which was a simple 1 to 5 counter that had inc / dec. To handle arbitrary deposits/withdrawals, Rubin suggested dividing the deposit amount into a counter UTXO per bit. To enforce that only one vote per block mined is allowed, Rubin ensured that all signatures set the input sequence to 1 block. When a counter reaches the Nth state, it represents a certain amount of accumulated work over a period where progress was agreed on for some outcome. Rubin also discussed several setup variants, including xpubs, single-party pre-signing, MuSig Multi-Party, unaggregated multi-party, and soft forking away trust. The advantage of such an optimization is theoretically nice because it means that only the non-destructuring recursive part of the computation is subject to the one-time-setup trust assumption, which might be of use in various other protocols.The email thread discusses a covenant model that relies on one-time setup and minimizes costs until the graph is a Directed Acyclic Graph (DAG), consisting of one or more components. The model defines covenants as a set of sets of transaction intents, potentially recursive or co-recursive, and a verifier generator function that generates a function that accepts an intent that is any element of one member of the family of intents and a proof for it and rejects others. It also includes a prover generator function that generates a function that takes an intent that is any element of one member of the family and some extra data and returns either a new prover function, a finished proof, or a rejection if not a valid intent. The covenant is verified under certain assumptions, including multi-sig covenant with at least 1-n honesty, Sha256 collision resistance, Discrete Log Hardness, and a SGX module being correct. In addition, there is perfect impedance match between the Prover, Verifier, and a set of intents. Composability is also possible as the Terminal State can pay out into a pre-specified covenant from any other family of covenants.
Updated on: 2023-06-16T00:14:26.229314+00:00