Are programs going to be huge?

[fiatjaf]

I know no one will write anything using raw Simplicity operators, but even then the operators that are going to be used are built upon these raw operators and thus identified by the merkle root of the expression that constitutes them, right?

How large are these merkle roots? I wonder because a Bitcoin opcode is 1 byte, but a merkle root is probably not less than 20 bytes (?), I think a few bytes could end making a lot of difference. Am I wrong?

[roconnor-blockstream]

In the current incarnation of Simplicity, the known jets (aka discounted jets, or sometimes just "jets" for short) is a known, and consensus critical set. We have a catalogue of these known jets and assigned them a unique prefix free code. So for example, the code for the bip0340-schnorr-verify jet is the bit sequence '11011000100' (subject to change). This is specified in Appendix B.1.5.1.1 (subject to change) of the Simplicity Tech Report. The Simplicity parser decodes this string, looks it up in the jet catalogue and finds the merkle root for this jet, and adds it into the merkle root computation.

After all the jets and combinators are traversed the resulting merkle root of the whole expression is compared with the merkle root specified in the scriptPubKey being redeemed to ensure it matches.

[ProofOfKeags]

Does this mean that jets are specified in a different section of the transaction? Couldn't they be ascertained by just doing the DAG traversal and checking each of the nodes against the catalog?

Similarly, why not just index the jets by the merkle root of the expression tree they are meant to replace?

[roconnor-blockstream]

Currently the set of jets will be fixed for a given tapleaf version. In the Liquid blockchain we can maybe use the dynamic federation mechanism to softfork in new jets, but that hasn't really been designed yet.

We could just index jets by their Merkle root. But as fiatjaf notes, there is a concern that this would really bloat the serialization of programs.

My original intention was to add an even-more-segregated-witness mechanisms to hold Simplicity programs and have the P2P layer negotiate whatever encoding they want. But I've decided that is too far reaching for a first iteration.

[ProofOfKeags]

The downside of this approach is that if you wanted to implement jets in a client that weren't enumerated in the consensus mechanism there would be no way to optimize code you see on the blockchain. Obviously weights require consensus, but in theory there is nothing stopping individual clients for jetting out any arbitrary merkle root. This would allow transactions crafted by anyone to be verified in an optimized fashion at the discretion of the node runner. Maybe this is the wrong tradeoff to make (network bandwidth + blockchain footprint vs. eager jetting) but it certainly makes jets a lot less modular in the interpreter environment since they'd have to be invoked by the transaction in order to take advantage of them. But the way I see it is that this would allow wallets to be dumber and doesn't require them to be maximally up to date.

[roconnor-blockstream]

I'd go even further, and say that witness data doesn't need to be "in the blockchain" at all. Users only need to come to consensus on what transactions are valid. The do not need consensus on why those transactions are valid. And to prevent DOS attacks we only need to agree that this block full of transactions are all valid and the cost (network / cpu) of all the reasons why those transactions are valid is less than some threshold X. This could let us divorce the finer details of communications in the P2P layer from the block-weight.

But this is all a bit far out there, so I'm skipping it for the time being and integrating Simplicity in the existing Segwit system with fixed jets (per tapleaf). Hopefully we can learn things from this first revision.