Published on: 2022-11-04T23:07:56+00:00
ZmnSCPxj has proposed the implementation of new opcodes in Taproot to improve efficiency and avoid duplicating data in the witness. One potential opcode is a form of OP_MERKLEUPDATEVERIFY that checks a merkle proof against a root and verifies if replacing the leaf with some hash using the proof yields a specified updated root. Another proposal is a limited version of OP_EVAL for cases where different spend paths cannot be split into different tapleafs.ZmnSCPxj suggests reusing pay-to-contract to store a commitment to the state in Taproot. This involves using the Taproot outpoint script as the public key corresponding to the pay-to-contract of the Taproot MAST root and an internal public key. The internal public key can also be a pay-to-contract, allowing for the commitment of a covenant state. This proposed opcode would determine if the internal public key is a pay-to-contract of the current state on the internal-internal pubkey. If an expected new state exists, it would compute a new Taproot internal pubkey and recomputes the pay-to-contract on the new state. This approach eliminates the need for quining and OP_PUSHSCRIPT, only requiring a way to compute the new state from the old state.Trey Del Bonis discusses the idea of using granular transaction introspection opcodes from Elements for rollups. He acknowledges that the actual proof verification process is complex and suggests implementing a specific opcode for more efficient proof verification. This opcode would take the serialized proof, a verification key, and the public input as separate stack items. The public input includes various commitments and data from the transaction outputs, and the rollup batch data itself. Trey also expresses interest in Simplicity Jets that facilitate rollups, particularly pairing-friendly curve operations.The conversation between AdamISZ/waxwing and John Light explores the minimal functionality required for general-purpose off-chain contracting that is provable. They discuss the verification of bilinear pairings on-chain and the use of a covenant opcode for implementing rollups/sidechains with client-side computation and compact state update. They also touch on the security models of Optimism and Arbitrum, as well as the use of trusted setups in different security models.Greg Sanders inquired about a concise cheat sheet for transaction introspection/OP_ZKP and their uses in different rollup architectures. While such a cheat sheet does not exist yet, Trey Del Bonis has written a detailed technical post on how these components can be used in a validity rollup. However, more research and design work are needed to provide the requested details.John Light's report titled "Validity Rollups on Bitcoin" explores the benefits of validity rollups for Bitcoin and existing layer two protocols like the Lightning Network. The report examines the history, technical workings, and potential risks and benefits of implementing validity rollups on Bitcoin, highlighting their potential to improve scalability, privacy, and programmability without compromising Bitcoin's core values. The full report can be found at bitcoinrollups.org, and feedback from the Bitcoin dev community is welcomed.In summary, there are ongoing discussions and proposals regarding the implementation of new opcodes in Taproot to enhance efficiency and avoid data duplication. Transaction introspection opcodes from Elements are being considered for rollups, along with the need for efficient proof verification. The conversation also touches on security models, trusted setups, and the potential benefits of validity rollups for Bitcoin. John Light's report provides a comprehensive examination of validity rollups and their potential impact on Bitcoin's scalability, privacy, and programmability.
Updated on: 2023-08-02T08:05:02.174011+00:00