Author: ZmnSCPxj 2022-03-22 05:37:03
Published on: 2022-03-22T05:37:03+00:00
Bitcoin developers are currently discussing new constructs that enable new functionality on the bitcoin-dev mailing list. One proposal is to provide a general language that can be softforked in new opcodes later. However, there are two arguments against this approach, including the activation parameters debate and the need to keep the number of softforks low.To overcome these arguments, the author proposes using microcodes in Bitcoin SCRIPT, similar to the technique used in CISC microprocessors. The proposal includes defining a generic low-level language, a mapping from a specific high-level language to the above language, allowing users to define new microcodes by sacrificing Bitcoins, and indicating the microcode they wish to use to interpret their Tapscripts.The proposal defines a "RISC" language that is composed of general instructions and a micro-opcode language that maps the existing Bitcoin SCRIPT. Microcodes have several advantages like back-compatibility with existing instruction sets, easier and more scalable underlying design, and the ability to fix bugs in implementations of complex CISC instructions by uploading new microcode.Each `UOP_`-code has an equivalent tree of LLVM code. For each Opcode in the microcode, its sequence of UOpcode is taken and expanded into this tree, concatenating the equivalent trees for each UOpcode in the sequence. Then the LLVM is asked to JIT-compile this code to a new function, running LLVM-provided optimizers.Users can refer to a "base" microcode when defining a new microcode to implement new `OP_` codes or change existing `OP_` codes, and only have to provide the new mappings. Microcodes have a standard way of being represented as a byte sequence. Users can serialize their new microcode as a byte sequence, create a new transaction where one of the outputs contains a specified value and has the scriptPubKey of OP_TRUE OP_RETURN - which is a "microcode introduction output" that is provably unspendable, thus burning the Bitcoins.Once the transaction has been deeply confirmed, full nodes will process recognized microcode introduction outputs and store mappings from their hashes to the microcodes in a new microcodes index. Full nodes can then process version-`0xce` Tapscripts by checking if the microcodes index has the indicated microcode hash.The technique allows users to define "jets," which are sequences of low-level general operations that users have determined are common enough they should just be implemented as faster code that is executed directly by the underlying hardware processor rather than via a software interpreter. Bugs in existing microcodes can be fixed by basing a new microcode from the existing microcode and redefining the buggy implementation.In order to ensure that the JIT-compilation of new microcodes is not triggered trivially, users must sacrifice Bitcoins when petitioning for the jettification of some operations. All full nodes are affected by the need to JIT-compile the new microcode, so they benefit from the reduction in supply, thus getting compensated for the work of JIT-compiling the new microcode.
Updated on: 2023-05-22T18:34:23.507196+00:00