Stacking Cats
OP_CAT's out of the bag.
Hey there!
Joel note: Today’s article is a precursor to some work we are doing on Bitcoin L2s. You can read our past work on innovations atop Bitcoin in our past issues here and here. If you are a founder building on Bitcoin at the early stages, we’d love to hear from you. Drop details at the link below.
Also wanted to thank Web3Lord, for being our community expert on all things Bitcoin. Let’s dig in..
What really are L2s? In essence, they are data compression mechanisms that help the L1 with heavy lifting. Another important caveat is that L2 should allow users to get their assets back on L1 without having to interact with it.
Decentralisation is the difference between regular high-performance databases hosted on a server in the cloud (like AWS) and blockchains like Bitcoin.
We want these chains to be easily verifiable, so the hardware requirements to verify these chains are often kept low. As a result of the conscious choice to make these networks more accessible and secure, they are not as quick. This is why chains like Bitcoin and Ethereum need a different layer that can tackle more complexity and speed.
According to the Ethereum Foundation,
Ethereum is an open-source platform to write computer code that stores and automates digital databases using smart contracts, without relying upon a central intermediary, solving trust with cryptographic techniques.
A few years ago, it was clear that Ethereum could not fulfil its vision with the existing L1. This is when Ethereum embraced a rollup-centric roadmap. Today Ethereum has a thriving ecosystem of L2s with $28 billion in locked value and $25 billion in market cap.
Bitcoin, on the other hand, is a bunch of instructions that define how you can spend your bitcoins. Until ordinals and BRC-20 (fungible tokens on Bitcoin powered by the Ordinal protocol) exploded, there wasn’t much to do on Bitcoin. It was a simple chain that moved money on-chain. Bitcoin's simplicity makes it less prone to bugs, but this comes with a cost.
Since there wasn't much to do on Bitcoin, miners made less in fees. With each halving on Bitcoin, miners are under increasing pressure to find new avenues for revenue. The security of the chain depends on how well miners are compensated.
Payments on its own (through Bitcoin) does not generate enough revenue for miners as the chart below shows. Expanding use cases is likely a good strategy to keep miners interested in Bitcoin. In January, Bitcoin miners made $1.3 billion in total revenue. Only 10% of this, or $131 million, was in fees. After halving, the $1.2 billion reward will come down to $600 million at the same price. Fee revenue will have to increase ~4.5x to compensate for halving rewards to ensure the same profitability for miners.
For other chains (mostly based on proof of stake consensus), fees don’t matter as much because they don’t have a supply cap. Moreover, they don’t need heavy external resources like a proof of work based chain like Bitcoin. The 21 million cap is part of the Bitcoin offering. It is what gives Bitcoin hardness and separates it from other chains. For Bitcoin, L2s are not just about scaling but also about ensuring that the security budget remains intact.
Udi Wertheimer, co-founder of Quantum Cats and Taproot Wizard, recently posted about the need for L2s on Bitcoin. This discussion was in the context of anticipated problems at the time of Quantum Cats mint.
The gist was of what he was trying to say was
Bitcoin has long confirmation times. Bitcoin has a 10-minute block time. If you want coffee, you pay using Bitcoin. The merchant doesn’t need to wait for the transaction to be included in the block (or for 10 minutes). As soon as your transaction hits the mempool, you can be on your way.
The problem arises when too many people chase a finite quantity of goods. Even if a merchant considers payments to be final as soon as a block is mined, there can be issues. Think of a scenario where 10,000 people are chasing 5000 concert tickets. In this case, the merchant must wait for at least one block to allot tickets to buyers. 10 minutes is too long a wait to buy concert tickets. Imagine a Taylor Swift concert where tickets are only sold with Bitcoin as a payment method. That’s a recipe for a lot of annoyed fans.The Lightning Network is fine for small payments, but it doesn’t scale. The capacity of the network stands at ~4.8k BTC. So when you need to process payments that are a meaningful percentage of this number, you need LN nodes to lock up that kind of capacity, which is difficult to achieve. (This might be why El Salvador doesn’t run on payments with Lightning network yet.. )
Any anticipated event would mean smaller transactions are priced out. Ideally, you do not want to make a $10 transaction when the fee is $7. Whenever there’s an anticipated event, some buyers or users are willing to pay high fees to miners to get into a block, pricing out other users who have nothing to do with the said event.
At the time of the Quantum Cats mint, the team let buyers reserve their Cats when the transaction hit the mempool instead of after it got confirmed. But as a result, it involved manually checking payments that’d soon confirm. This type of manual labour is not a luxury that regular businesses can afford in daily operations.
The Challenges of a Bitcoin L2
Let’s go back to what L2s are. Fundamentally, they are ways to compress data. The job of an L2 is to capture a bunch of data, process (run computations), compress, and tell the L1 that it has executed transactions as per the rules of the L1.
Technically, a big part of being an L2 is not having the final say. What that means is that the decision of a dispute rests with the L1.
If a user wants to exit the L2, they should be able to do so via the L1 without seeking any permission from the L2 operator. Of course, this should be possible as long as the user has played by the rules of the L1.
Now, if the L1 has to rule on anything that has happened on L2, it needs to understand what’s happening on the L2. Blockchains are closed systems. That is, the nodes' understanding of events is limited to the chain's consensus rules. Nodes don't understand anything that is not a part of the consensus rules - regardless of whether is the current temperature in Mumbai or the state of Ethereum or Stacks.
Simply speaking, there are two ways of going about a Bitcoin L2 –
Have another network that observes whether the L2 is following Bitcoin’s consensus rules with some way to move BTC from Bitcoin to the L2 and vice versa
Make additions to Bitcoin opcodes that expand its capabilities. Opcodes are a set of commands or instructions that can be used as building blocks to execute transactions. One of the aspects that the current set of opcodes lacks is the ability to analyse transactions. This aspect keeps developers from writing full-fledged smart contracts on Bitcoin. Please note that this design was intentional to ensure that Bitcoin remained as simple as possible.
There is currently development along both these lines. As for the first approach, the design differences lie in peg-in and peg-out mechanisms. When you send your BTC to the L2, you're essentially sending the BTC to an address that the L2 operator manages. Now, who vouches for whether this address owner is behaving honestly?
The ownership of your BTC has been transferred to the address owner (or the L2 operator). The operator is then supposed to release a wrapped version of the BTC to you on the L2.
Similarly, when you remove your BTC on L2, the operator should send the BTC to you at your Bitcoin address. The bridge’s security is a function of whether the approach is based on an honest majority or a single verifier. What I mean by that is if the design needs an honest majority of validators versus the design that works with just one honest participant to catch the operator in case of any wrongdoing, it is an inferior design.
Citrea, a zero-knowledge rollup on Bitcoin, is an example of the latter kind, where it relies on one honest verifier. Here’s how it works –
It processes several transactions on its zkEVM (zero knowledge Ethereum Virtual Machine) layer. It inscribes the proof of the batched transactions on Bitcoin. This can be verified by anyone running light clients on Bitcoin.
Unlike other L2s, it also submits transaction data in the form of state differences. So instead of all the transactions, the difference between the current and previous states is posted on Bitcoin.
(Joel note: In simple speak - any time you make a transaction, there’s a change in the ledger that blockchains are. Instead of parsing every transaction detail about who sent how much to whom, state-transaction records simply account for changes in balances on individual accounts after any given period of time. Think of it as final ledger balance snapshots).The most critical part of Citrea’s solution is a bridge that allows value transfer between Bitcoin and the zkEVM. This bridge is built on the current implementation of BitVM (Bitcoin Virtual Machine is currently being developed by the BitVM team led by Robin Linus).
An operator is responsible for peg-in and peg-out transactions. Verifiers are responsible for checking whether operators are behaving honestly. Provided there’s even one honest verifier, the system works as intended.
Source – Citrea Citrea is not a trustless bridge but a trust-minimised one, meaning it cannot function without placing any trust in a third party. Instead of trusting many third parties, it works even if there's just one honest third party. BitVM is currently based on optimistic fraud proofs.
In this situation, whatever proofs submitted by the zkEVM are assumed to be true until challenged by a verifier. Nothing is verified on-chain until a verifier challenges a proof. If the verifier challenges, the proof gets verified on-chain. In case the operator is wrong, their deposit gets slashed.
The second approach concerns introducing new opcodes to Bitcoin that will expand its functionality. Currently, one of the most discussed opcodes is OP_CAT. It was a part of the Bitcoin script initially but was discontinued by Satoshi in 2010. Think of it this way – when I concatenate two variables or fields of size 2 bytes, the resultant is of 4 bytes. Similarly, it is 8 bytes for two variables of 4 bytes.
If used recursively, the size can quickly get out of hand. It is speculated that it was due to the fact that it could have been used to bloat the chain and carry out denial-of-service (DDoS) attacks. This website is a brilliant resource for understanding what OP_CAT is and how and why it got removed from the list of opcodes in Bitcoin Script.
OP_CAT Enters The Chat
CAT stands for concatenate, nerd talk for joining things together. Like legos, it takes two distinct things, pieces them together, and creates a new piece. What could these things be? They could be numbers, letters, or other instructions within Bitcoin Script. It allows for the construction of covenants.
Think of covenants as IF-THEN statements. They allow more restrictions to be on how bitcoins are spent. The inclusion of covenants allows Script to analyse transactions, allowing it to gain the functionality to assess various attributes of a transaction – such as its outputs, values, and the conditions under which they can be spent – before completing the transaction.
This introspection capability is necessary for implementing covenants because it enables the enforcement of specific spending rules programmatically within Bitcoin transactions.
But wait, what about the bloating problem that forced cautious Satoshi to take the opcode out in the first place? After the Taproot upgrade, a single element on the Bitcoin stack can be as large as 520 bytes, no more. So, the taproot upgrade alleviates bloating and DDoS attack concerns related to OP_CAT.
Fundamentally, it unlocks features that can be created by joining transaction details, identities, hashes, etc. Some of the most critical features are –
Smart contracts. The ability to concatenate multiple data fields or instructions can translate into more sophisticated data handling.
Atomic transactions, which means having the ability to execute transaction A only if B is also executed. This can be done by concatenating transaction details and creating hash locks that can be unlocked simultaneously on both chains or on Bitcoin. This translates into the ability to create L2s with trustless bridges.
Creation of vaults. This can be achieved by concatenating multiple conditions, which can help add more conditions for how bitcoins can be spent. This is an example of a vault made by Rijndael.
Whenever the community decides to make OP_CAT a part of Bitcoin opcodes again, it will be through a soft fork. Soft forks are backwards compatible, meaning the network doesn’t split into two in case some miners or nodes choose not to upgrade to a version that includes this opcode. SegWit (2017) and Taproot (2021) were both soft forks. Because they are backwards compatible, soft forks are usually less contentious.
The OP_CAT opcode has already found its way back on Bitcoin Cash and Liquid (Bitcoin sidechain by Blockstream). But so far, we have not seen proclaimed use cases materialise on these chains. Whether this is because it is not as useful (or more difficult to use) or because these chains don’t have much traction in the first place is difficult to know.
If you are a shadowy supercoder using your powers to make Bitcoin fun again, we would love to talk to you. Bitcoin L2 space is heating up. As a follow-up, I will write about the state of Bitcoin L2s in the coming weeks. Drop us a note if you’d like to collaborate or share inputs as an operator building in the space.
Until then - signing off!
Saurabh Deshpande