delvingbitcoin

Chia Lisp For Bitcoiners

Chia Lisp For Bitcoiners

Original Postby roconnor-blockstream

Posted on: March 13, 2024 14:44 UTC

Simplicity and Chia Lisp, two programming languages, exhibit distinctive features and approaches towards blockchain programming paradigms.

One notable feature in Simplicity is its use of "pruning," where programs are committed via a Merkle Tree structure, allowing for the trimming of unexecuted branches when the program is revealed. This contrasts with Chia Lisp's approach, where if statements evaluate both branches. The pruning feature in Simplicity not only offers potential privacy benefits but also reduces on-chain data.

Both languages support a concept referred to as "delegation," which permits the attachment of new code at redemption time in controlled ways. In Chia Lisp, this is achieved by adding quoted code as an input. Conversely, Simplicity employs a special combinator for attaching code at a specific location during redemption time, usually requiring the hash of this attached code to be signed. However, the detailed workings within Chia Lisp regarding this aspect remain unclear.

Delegation introduces challenges, particularly concerning softforking new opcodes. In scenarios where unallocated opcodes are treated as successful operations (op-success) and new code containing such opcodes can be attached at redemption time, it results in bypassing checks intended to run. Chia Lisp's approach to this issue involves treating softforked opcodes to return nil, with the computation’s outcome hinging on whether the opcode fails or not. A similar strategy could potentially be applied in Simplicity by allowing only softforks of jets that return an equivalent of nil.

Furthermore, there are several minor yet noteworthy design differences between the two. For instance, Simplicity's implementation does not allow for "run-time" allocation, with the maximum memory use calculated upfront based on the program's structure before evaluation begins. This is contrasted with an alternative approach that would utilize a pool of maximum-sized allocations. This methodology stems from Simplicity's lack of general recursion, although it can be somewhat mimicked using the delegation mechanism. Consequently, types in Simplicity programs are always of statically bounded size, underscoring a fundamental difference in how resource utilization is managed compared to other languages.