An interview with John Light
Leading up to the Alpen x Starknet announcement, the Insider Edition caught up with John Light to discuss bitcoin rollups’ progress three years after his HRF-sponsored report was released
Alpen Labs and Starknet have announced their partnership to build a unified rollup ecosystem on bitcoin. At the core of the partnership are R&D efforts to make Alpen’s Glock-based, zk-verifier accessible to other protocols. This R&D will be funded by a grant from Starknet’s protocol stewards, the Starknet Foundation, and will see the verifier be released as a public good, enabling any system to integrate with Glock and Strata (Alpen’s bitcoin bridge).
Having followed this space for a little over 3 years now, it feels that this Alpen and Starknet’s announcement has been a long time coming. Walk with me:
12 years ago, Starknet co-creator Eli Ben-Sasson presented on zero-knowledge proofs at a bitcoin conference in San Diego. He described how this emerging technology could help bitcoin scalability and add greater privacy to peer-to-peer payments. He was one of the first people to present research on this design space.
9 years on, Trey Del Bonis penned the first blog post on how a ZK rollup on bitcoin might be designed. A few months after this blog was released, John Light released the research report “Validity Rollups on Bitcoin” that was partially sponsored by StarkWare, the creators of Starknet. It was the first research report covering how validity rollups might improve bitcoin’s transaction throughput, create more expressive execution layers, and improve privacy. Both Light and Trey now work at Alpen Labs.
At the heart of this partnership are individuals who have long been advocating for the use of zero-knowledge proofs to improve bitcoin’s use as peer-to-peer money. Some for over a decade. It’s exciting to see this subculture come into bitcoin’s mainstream and bring novel protocols into production.
Still, there is nuance when we talk about “ZK on bitcoin”. Many people compare it to ZK systems being leveraged in other ecosystems. This comparison is unfortunate for two reasons. One, it undermines the efforts of researchers and developers who are trying to achieve what was once thought to be impossible. And two, it doesn’t fully articulate the trust assumptions and tradeoffs that these systems make to achieve their goal of verifying zero-knowledge proofs.
To cut through the noise, I sat down with Alpen Labs’ Technical Product Manager and bitcoin rollups pioneer, John Light, to discuss the recent Starknet partnership, unified rollup ecosystems, and if ZK is, in fact, the best way to scale bitcoin.
I’ve edited the transcript down for brevity and readability. Assume any errors are my own. — Janusz
Interview with Light
Janusz: A little over a year ago, I remember you gave a talk on this idea of interoperable rollups and execution layers. So I’m looking at this partnership and it makes me wonder, is this the ultimate goal? To build a network of interoperable execution layers that share a single bitcoin bridge?
Light: Well, I kind of gave the game away in that talk. It was certainly very forward looking, but we have had this vision for how our platform would evolve over time. In some ways this partnership with the Starknet Foundation is a big step forward towards realizing that vision. The plan is for them to be one of the first, if not the first, execution domain to run alongside Alpen on top of Strata (Strata is Alpen’s bitcoin bridge). Once you go from one to two, there’s a clear path to going from two to three, three to four, four to n, and you eventually have a world where a virtually unlimited number of execution domains can plug into this shared verifier. This gives different execution layers access to trust-minimized BTC without having to deploy a different verifier for all of these different execution domains on bitcoin Layer 1.
So I think we’re going to see a world where there are different heterogeneous execution domains plugged into bitcoin. These layers will benefit from trustless interoperability, potentially fast preconfirmations for transfers between them, and I think that’s going to ultimately result in a better UX than the fragmented alternative. The fragmented alternative being a world where everybody has to maintain their own verifier, bridge, and so forth. In that world, if you want to do transfers between layers, you either have to do atomic swaps or go through the very slow process of transferring funds on the base layer. The vision is to build an interoperable world of execution layers, not a fragmented one. The Starknet Foundation partnership definitely contributes to that.
Janusz: I mean this is definitely the endgame. The partnership mentions “Glock” specifically as a shared verifier, to enable the bridge. I assume it’s a type of “optimistic-ZK verifier” that we can do on bitcoin today. What’s the difference between Glock and the BitVM family of protocols that started this wave of ZK verification?
Light: I would consider BitVM and Glock to be two different techniques for achieving the same kind of trust model - this 1-of-N trust assumption. In BitVM, you’re doing this bisection game where you want to find the specific computation you know somebody did incorrectly and basically force them to equivocate. And that’s a game where the data is posted onchain and is where the game is actually played out. In the early iterations of BitVM, this required many rounds of interactivity. With BitVM2, the goal was getting this down to two or three rounds of interactivity so that anybody could be the challenger. We (teams from the BitVM alliance) have proven there is a way to do this and there are working implementations of BitVM2 on testnet today. We have one running on testnet right now.
But, the amount of data that you have to put onchain for the assertion and disprove transactions is very high. It ends up costing a lot in bitcoin terms, and that directly correlates to the amount of stake that each of the operators has to put up to be a part of the operator set. The stake has to cover the cost of running the challenge game. The high cost of putting all this data onchain ends up bloating the cost of the protocol overall.
The high costs affect the economic efficiency of the bridge and that inefficiency is eventually passed down to the user. So Glock, which is short for garbled locks, improves this by moving most of the data offchain. It uses garbled circuits to create this new primitive that we call “conditional disclosure of secrets”. In this model, if one of the participating parties lies about something, they disclose a secret (the secret being their private key).
It’s a very different way of achieving the 1-of-N trust model. The BitVM family of protocols and the Glock family of protocols descend into two different rabbit holes. Engineers can go down both and then make a decision on what to optimize for a given use case.
Janusz: My understanding is Glock is using a novel proving system to support this garbled circuits mechanism. Could you quickly highlight the reason for doing so?
Light: The thing that was interesting to us about using this novel DV Pari SNARK, instead of Groth16, was that it results in much less data that needs to be communicated, and stored, by operators and watchtowers; like orders of magnitude difference. We were concerned that without some pretty hardcore optimization, or additional breakthroughs to Groth16, that the setup process for operators would take months. You might even have to ship out specific hard drives that are capable of just dealing with the amount of data that had to be communicated and stored as a part of this protocol.
This isn’t impossible, but we wanted to make this more practical and have it to where someone could run the software on consumer hardware or a standard cloud setup. But, there’s been a lot of optimizations from the BitVM alliance as well around Groth16 which may make it more practical.
Janusz: I want to pivot a bit with our remaining time here. Three years ago, you released the Validity Rollups on Bitcoin paper. It was the first official write up on how rollups on bitcoin might work. Looking back on it, how has the journey been since writing the paper?
Light: It’s definitely been quite a journey, for sure. One of the big breakthroughs was Casey Rodarmor releasing the witness envelope technique as a part of the Ordinals protocol. Following that release, rollup developers figured out that these envelopes would actually be useful for building rollups and using bitcoin as a data availability layer.
That wasn’t obvious immediately. But it worked, and people were able to build what’s known as a sovereign rollups on bitcoin. Sovereign rollups are rollups without verifiable bridges.
It became more of a phenomenon as more people figured it out. Eric Wall was one of the first to present on the possibility of using bitcoin block space for sovereign rollups. Then, the Sovereign SDK was perhaps the first team to ship a proof-of-concept. Rollkit from Celestia built their own demo around the same time.
I think it quickly snowballed from there. For the first time, a large group of people were talking about building rollups on bitcoin. The obvious question then became “how do we get BTC onto the rollup”? For a period of time there, we were stuck in the pre-BitVM paradigm where you had to settle for an honest-majority multisig. It was the best we could do.
Then the BitVM paper dropped and changed everything. Suddenly we moved on from honest-majority multisigs, with at best some proof-of-stake baked in, to working on bridges that really had this 1-of-N trust assumption. From there, BitVM has accelerated from the concepts laid out in original paper to an entire family of protocols. As mentioned, we also have the new Glock family of protocols and there’s other implementations, such as BitVMX and BitSNARK, that were inspired by BitVM. Most people are now focusing on gabled circuits and it’s seen as the state-of-the-art for what’s possible on bitcoin right now.
Teams are working to improve all the things we mentioned earlier; economic efficiency, interactivity, the amount of data being communicated offchain and being put onchain, etc. Now, we’re pretty confident that we can get these costs down to a small amount of data; basically some proof data, and maybe a counterproof, onchain. With the latest optimizations, this is a relatively small amount of data and is practical for production use.
But, this is still a federation, right? We haven’t moved on from the “federation paradigm” for bitcoin bridges. Now, it’s certainly a significant improvement compared to an honest-majority multisig. Users only have to trust a single member of the federation. However, there’s clearly a next step that has yet to be realized, which I discussed in my paper, which is actually getting rid of the federation. We should look to build a trustless and permissionless verifier that people can directly interact with through bitcoin Script.
That’s going to require a soft fork. This conclusion has not changed. Currently the script size to verify a validity proof is too big to fit in a single bitcoin block. So a soft fork is still on the to-do list, but a lot of the other components are ready and it’s great to see teams building rollups within the restrictions that bitcoin has in place today.
That’s what people are excited about. People are pushing forward with improving the state-of-the-art because there are real improvements here. But ultimately, I think we should build rollups to ensure they have all the things we love about bitcoin; bitcoin native, permissionlessness, trustlessness, decentralization, and censorship resistance.
Why should we give up these properties just because we’re on an L2?
Janusz: The closing question I have is why should bitcoiners continue to follow the developments of rollups? What would you say to people who are reading this to motivate them to read the original paper and follow the development of Alpen and others?
Light: The benefits are nuanced. Rollups certainly improve the trust assumption regarding federated bridges for the average user.
You go from having to trust an honest-majority to only having to trust a single member of the federation to get your bitcoin out of the system. That’s a big improvement in my opinion since we have seen federations where multiple nodes have been knocked out. Raising the bar to fully compromise the system is a huge breakthrough.
And if you’re an operator, you have unilateral exit capabilities because you are 1 of the N federation members. So for operators, who are used to operating in bitcoin bridges where they need cooperation from other parties to get their funds out of the system, it drastically improves the trust model. I think that’s a big deal for them. Especially when you’re talking about operators who want to put a significant amount of bitcoin into the system. This assumption nearly eliminates their counter-party risk.
Beyond the trust model, there’s so much potential to build new execution domains that add new capabilities for bitcoin that we don’t see directly on the layer 1. Whether that’s bitcoin-like side systems with additional opcodes, or execution environments that are quite different from bitcoin (e.g. privacy systems or expressive smart contract layers), it’s going to be really cool to experiment with bitcoin the asset. This experimentation gives us a peek into the future of what it could be like if we had softforks that enabled trustless verification directly on bitcoin. I hope we don’t hold ourselves, and bitcoin, back from realizing the full potential here. There’s going to be glimmers and hints of what’s to come and developers are really going to push the limits over the next few years.
Based on what I’m seeing now, it’s really something that we should all look forward to. It’s exciting and I’m looking forward to seeing what the future holds.