Published on: 2022-03-23T00:20:16+00:00
A proposal has been made to introduce microcodes for Bitcoin SCRIPT. The idea is to define a generic low-level language, called RISC, and map specific high-level languages to it. Users can sacrifice Bitcoins to define new microcodes that extend the functionality of Bitcoin SCRIPT. The proposed RISC language includes general instructions like arithmetic, SECP256K1 scalar and point math, bytevector concatenation, sha256 midstates, bytevector bit manipulation, transaction introspection, and more.The microcodes are compiled using LLVM and stored in a 256-long array of functions, where the array index corresponds to the `OP_` code. This allows for faster execution compared to expanding an OP-code SCRIPT to a UOP-code SCRIPT and interpreting it in a loop. However, there are concerns about introducing a significant new dependency to the consensus definition.To fix bugs in existing microcodes, a new microcode can be based on the existing one and the buggy implementation can be redefined. However, this requires existing Tapscripts to be re-spent to point to the new bug-fixed microcode, which incurs an on-chain spend.There is also a discussion about referencing microcodes in a simpler way. It is suggested that each microcode represents a language based on the current OG Bitcoin SCRIPT language. Tapscript versions can be replaced with microcodes, where each version is a slot for a microcode. The current OG Bitcoin SCRIPT would be just one of those slots. This approach reduces the cost of indicating a microcode to just one byte, as required currently.Efficiency in referencing microcodes is also considered. It is proposed to use a hash to refer to an entire language of redefined `OP_` codes, rather than individual opcodes. The use of a 50-bit hash or a 160-bit RIPEMD . SHA256 hash is sufficient to specify the microcodes with a low probability of collision. However, there is a concern about potential deliberate attacks if users of different SCRIPTs collaborate to define a single microcode.Specific microcodes can be used in Tapscript by opting for a specific `0xce` version and referring to the microcode through its hash. Race conditions can occur when reorganizing a newly-defined microcode, but this can be avoided by waiting for deep confirmation. Fullnodes may need to maintain multiple microcodes, which makes creating new ones expensive due to JIT compilation and the requirement to keep an index that cannot have items deleted. The advantage of using microcodes is that the size of the SCRIPT can be used as a proxy for CPU load, allowing for bounded CPU load without requiring a softfork.Namespace management is another issue discussed. Simplicity is suggested as a better platform than Bitcoin Script due to its narrow interface. However, specific microcodes are proposed as a solution to namespace management issues. They require opt-in usage and specific Tapscript versions, along with a hash to refer to the microcode. The only race condition occurs during reorganization, which can be avoided by waiting for deep confirmation. CPU load is bounded as long as there are no looping constructs and the number of `UOP_` micro-opcodes is limited.Another discussion focuses on the use of microcodes as a means of enabling new functionality in the Bitcoin consensus layer. The proposal suggests defining a generic low-level language and mapping specific high-level languages to it. This allows existing Bitcoin SCRIPT `OP_` codes to be mapped to `UOP_` micro-opcodes. Bugs in implementations can be fixed by uploading new microcodes based on the existing ones. To avoid trivial triggering of JIT-compilation, users petitioning for the jettification of operations must sacrifice Bitcoins.Overall, the use of microcodes in Bitcoin SCRIPT offers a way to extend functionality, fix bugs, and manage namespaces. It provides faster execution through LLVM compilation and allows for bounded CPU load. However, there are concerns about introducing dependencies, the cost of new functionality, and potential centralization pressure.
Updated on: 2023-08-02T05:56:00.974335+00:00