Robin Linus ZeroSync: Speeding up Bitcoin Initial Block Download (IBD)

Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics, brought to you by Swan Bitcoin. Today, Robin from the Zerosync project joins me to talk about zkPs, zero knowledge proofs, and how they can be used to help people quickly get started using Bitcoin, and in this case, ZeroSync helps people dramatically speed up IBD, Initial Block Download. So what does this mean? It could mean more people could run Bitcoin nodes, it might also help more people be private and verify things for themselves. So we talk a bit about the trade-offs around this and what's required to make it happen. Mempool.space is one of the sponsors of this show, and if you need to send an on-chain Bitcoin transaction, I recommend first checking mempool.space so that you can check the fee rate. Now, of course, mempool.space is open Open source, and you can host it yourself, and it makes it really easy to see the multi-layer ecosystem that Bitcoin is evolving into. You can see different things such as the mempool, the blockchain, or the Lightning Network. Mempool.Space are also coming out soon with a transaction accelerator service, so keep an eye out for more details on this product. And if you are with an enterprise, Mempool.Space also offers customized mempool instances with your company's branding, increased API limits, and more. Go and find out more at Mempool.Space/enterprise. When it comes to securing your Bitcoin, consider the hardware that you are using to hold your private keys and also to sign Bitcoin transactions. CoinKite dot com make it easy for you to do this with a range of hardware devices such as the TapSigner, the latest ColdCard Mark four, and the upcoming ColdCard Q one, which will have QR support. With the ColdCard, it has two secure elements, it's got NFC support, and it's really fast at signing transactions and it's also very reliable. Also, I really I really like that you can set it up without phoning home to the manufacturer. You can literally just plug it into the wall and generate your keys. That way, you can even bring your own entropy. So if you don't want to trust and you want to verify, you can bring your own entropy, whether that is through using dice rolls or entering your own seed, and you can initialize the device in that way, and then you can connect it with wallets such as Specter Desktop or Sparrow, Nunchuk, or Electrum. So to get your coldcard, go to coinkite dot com Code Laverara for a discount on your cold cards. And the lead sponsor of this show is Swan Dot Com. Swan Bitcoin make it easy for you to buy Bitcoin in a safe and easy way. Of course, Bitcoin can be volatile, but with Swan Bitcoin, there is a range of educational material that makes it easy for you to learn about Bitcoin at the same time as stacking. So it's easy to automatically stack some Bitcoin and automatically withdraw to your own self custody, because with Swan, automa- Automated withdrawals are free. So with Swan, you can do automated recurring purchase, and also you can do what's called smash buys or one-time buys. Swan makes it really easy for you to do all of this stuff, so go and check it out over at swan dot com. And now on to the show with Robin.

Thanks a lot for having me. Very excited.

Yeah, so Robin, I was, intrigued by some of what you're working on and what you were speaking about as well at the, Bitcoin conference. Obviously, we met, backstage there. And, I, yeah, I was basically, I was intrigued by this idea of what you're working on with Zerosync. And, maybe you wanna just help set the stage a little bit and perhaps set some of the context about what is a ZKP and, you know, what is this, what is some

Yeah, ZKP is a bit of a confusing term. It's called zero knowledge proof. Zero knowledge proofs have originally been invented for privacy, but, they have kind of been, rediscovered as a great tool for compression. And, those buzzwords that you hear all the time in, the altcoin sphere, like, zk rollups and such, they are usually, using validity proofs and not zero knowledge proofs, and they're using them to compress lots of transactions into a very succinct proof. And, we are spearheading the application of validity proofs to bit, to Bitcoin.

Gotcha. And so, I guess at a, at a high level, maybe just to understand, is it similar to this idea that, you know, when you do a hash, a hash function, it's deterministic, or if you're using a deterministic hash function, the same? You know, input value will always hash to the same, you know, shortened, hash output, and that's kind of what we're relying on here so that we can, as you said, use it as a validity proof to sort of prove that, you know, the content of these blocks or these transactions, et cetera, maps to this particular output. Is that kind of the high level idea here?

It's, it's related, but when you hash something, you don't actually know anything about the validity of what you're hashing. Like when I give you a block hash, it doesn't tell you anything about the validity of the block. And here, you actually get a proof of the validity of the block. And, yeah, that is quite big because, yeah, you can instantly verify lots of computation with just that little proof. It's actually a proof, which means even if your biggest enemy had created that proof, they can't fool you even the slightest bit.

Gotcha. Going to understand because of the, the trust levels that we're talking about here, right? As you said, yeah, you don't have to trust the ZKP proof provider, it is literally a proof, you are able to verify that.

Yes, exactly as.

Gotcha. I mean, there

can always be problems in the implementation and stuff, but, in general, the concept is actually a proof, a mathematical proof.

I see, gotcha. And so, do you wanna just tell us a little bit about how this could be used? used in Bitcoin and just outlined a little bit of the, the high level basics for us.

Yeah, there's a range of applications to Bitcoin. The, the first or like most obvious application is to compress the Bitcoin blockchain. So currently it's five hundred gigabytes, and with a validity proof, you can compress it in less than a megabyte. And, yeah, that would, make it much faster to bootstrap a full node.

Gotcha. And so that's, yeah, so I think that's really the, the bottom line is that we could dramatically speed up- How quickly it is for a new person to onboard a new node when they're starting up, because today, you know, you have to, if you sit there and you're downloading all the blocks from Genesis, you are downloading over five hundred gigabytes, depending on the size of your computer and your internet speed, it could take a while, right? Especially if you're on an old Raspberry Pi and it takes a long time to download and validate and all of this stuff. Maybe if you're on, let's say, a reasonably fast desktop computer with a high-speed internet connection, maybe it's a few- hours, but even then, that's a desktop computer and it has to be on all the time. So I guess that's, that's kind of what we're getting at. And I, I've seen, I guess I would say there are two different uses. Maybe it would be useful for you to spell this out also, because, you know, in altcoin land, there are people who are using it to, let's say, compress transactions, or they're trying to use it almost like a, like a lightning network sort of thing to kind of speed up the transactions. But what we're talking

Exactly, yeah. We are building a validity proof of the Bitcoin blockchain itself, not a layer two on top of the main layer, but the main layer itself.

Gotcha. And so some of this stuff can get confusing because sometimes people talk about soft forks in the context of ZK having a ZKP verifier for Bitcoin. So to be clear, for this project, for Zerosync relating to the IBD, the initial block download, is a soft fork required for this?

No, no software is required. We basically, we are just compressing the chain and, we can just compress the chain without asking anyone and, it's individual, decision, every user can, can decide if they wanna sync, using a conventional sync or if they wanna use proof. So that fits very neatly. Gotcha.

Yeah. And so can you walk us through, how this would work to help people speed up their IBD using, you know, the ZeroSync proof?

Yeah, you would download the, the proof from somewhere. I will come to that later, w-well, where you would download that exactly, but you would download that proof. And in that proof, there's a UTxO set commitment, then, you would also download the UTxO set and match it against, the commitment in the proof, and then you can be That this UTXO set is actually correct. So you just copy it into your chain state folder and run Bitcoin Core as you're used to as a pruned full node.

I see. And, and even some of those aspects that you were talking about, copying to your chain state folder and things like this could be automated as well, right? Like software developers could come up with, you know, a wallet that automatically does all this in the background. Just to be clear, I guess you're just explaining sort of for the developers and the more power users what's actually happening in the background.

Yeah, yeah A simple patch to Bitcoin Core or even an external tool like a simple Python tool or something like that.

Yeah, I see. And so just to explain also what we're talking about there is, you know, today when you download Bitcoin Core and if you just run it by default, it's gonna download all the headers, all the blocks, and it will verify from, there's like an assumed valid point, I think, I, I don't know exactly, it might be six months or twelve months back, and the node is gonna verify all the signatures from that point forward. Now, now if It's gonna verify from, you know, from day one, genesis block. Yeah. But in this model, it's, it's different to that. Instead of downloading all the blocks, all five hundred gig of the blocks, we are instead downloading the, a proof of the UTXO set, which is like five gigs or ten gigs, roughly, right? And so then the user is able to just quickly onboard and start transacting or receiving coins because he can generate an address and receive coins and do all this stuff very quickly because he doesn't have to download that five hundred gigs, he's just- Downloading an equivalent of the UTXO set, state, yes, and proving it, that's correct, right?

Yes. Yeah. And verifying the UTXO set is much cheaper, like five gigabyte of UTXO set is just a, a bit of hashing, and when you have five gigabyte of blocks in comparison, you have to verify all the signatures in there, which is usually the bottleneck. So, it becomes way cheaper, like it's less data and less verification on that data.

Excellent. And so in your view, who is the target market? Who is the target user Are we talking like mobile phone users here? Are we talking just what would have otherwise been a light client, let's say Electrum or Sparrow or Specter user? Who is the target user for this kind of ZeroSync protocol?

I would think that in the future, like in the next decade or so, all Basically all Bitcoin apps will become, fully validating with, some kind of proof system, I would say, like I would expect that, just because proof systems are growing so fast and it's getting more and more easy to actually do something like, like we are doing, improving the, the, the Bitcoin blockchain. So I think at one point, mostly every Bitcoin app will be fully validating by using a proof. There will always be still some conventional nodes, I think, because, the higher, the more high value use cases, the more incentive you have to just go through Through, the, the, the initial, eight hours of syncing or so, but, in, in, it would be great to have every phone being a validating node, a fully validating node.

And so can you explain for us that difference in the different types of nodes then? So as an example, we have the archival node, we have a full node, and then we have, let's say, a Zerosync node, and then maybe there's this like light client. So could you just explain the difference in those?

Yeah, so there would be conventional nodes, Notes in the future they would also provide the UTXO set, so they would make a, a checkpoint maybe four times a day or something, and, then when others wanna sync, they get this checkpointed UTXO set from them, and, yeah, then, you, you would still have, pruned full notes, pruned full notes that have been synced with, with a proof, and, also in, that is not Our first goal, but in the future we would want to support light clients as well. that requires to make the UTXO set, a bit more like the, the Ethereum tree, tree, because, when you're, when you're a light client, you wanna prove all UTXOs of a particular address. Like, you ask a server for your balance, and you don't want them to withhold any of, of your UTXOs. So the server has to prove to you that this set of UTXOs is actually all the UTXOs that you own None of them are missing.

It's checking completeness. Yeah, that is

complete, exactly. for that we would have to adjust our UTXO set commitment a bit. Currently, we are using UTXO and UTXO can't, can't prove completeness, but that is definitely doable, like-

Right. And so let's just summarize those different things so people are clear. So archival node means your node has downloaded all of Bitcoin's blocks and retains all of those blocks, and it has them in memory or in the hard drive somewhere so it can call them as it needs, right? So I guess we can call that the best level, let's say. Then the next level is a full node that once had all the blocks, but has now pruned away the old ones. So that would be a pruned full node, because it is still a full node because you verified all the blocks. And then, let's say another way, another step is to have a Zerosync node, right? So this node never downloaded all the blocks. It just quickly caught up to the state based on this commitment, this ZKP proof This verif- and verified in that way, and then just caught up from that point and just was downloading the new blocks on, you know, from that point on, in an ongoing fashion. So is that basically, you think that's, you would say that's a fair summary of, let's say, some of the types of nodes that we're talking about here?

Yes. You can have different, different other things. For example, you could sync with a, with a proof and then you s- assume valid, so, sorry, assume UTXO. That means you give a UTXO set to your node and it assumes that it's correct, but in the background it does the conventional sync and, proves that, the, the UTXO set is actually correct. So this way you, you could instantly sync but have, the, the conventional full node security as well.

I see. I Caught up, but actually in the background, your node is running the checks as well to sort of, kind of make sure it's all legit basically. And actually that would be a good point to help, if you could distinguish the difference in these different projects, 'cause maybe some listeners will be a bit confused or maybe not see exactly where the, the lines of demarcation are. So if you could explain the difference, let's say we've got UTXO, which is sort of, sort of similar, sort of related, there's S3muTXO, which you just mentioned,

I would say the main point of UTXO is to compress the UTXO set, because the more users Bitcoin has, the more the UTXO set grows, and, yeah, if we had a billion users, then we would have to have at least a billion UTXOs, and, having that in memory is, probably not possible for most, consumer devices, and, that's why the inventors of UTXO came up with that idea of, using a UTXO set commitment, that is Constant size and, then you only need inclusion proofs for the UTXOs that have been consumed in the latest block. And, yeah, that reduces the, the overhead of the UTXO set from, from multiple gigabytes down to kilobytes or something. And, the problem with it in comparison to, to zk notes is, that UTXO notes still have to do the initial sync. They still have to download the entire blockchain once. And, it's even a bit more overhead because When you're running that UTXO node, you, you need to have those inclusion proofs attached to every block, UTXO inclusion proofs, and, I think they made it quite fast, but still, you have to do the, the, the initial download, and that's why it's a nice com- it, it can be nicely combined with a proof because, our proof, it would allow you to run a UTXO node basically instantly because, you can catch up to the latest state with the proof and then from From then on, you, listen for, UTXO blocks.

I see. And so typically then, in a ZeroSync example, you would download, let's say, five gigs worth of the UTXO set, a few megs of the proof, and then you're basically caught up.

yeah, but when you're running a UTXO node, you wouldn't even have to download the UTXO set.

Oh, I see. So you're talking about like a combination of the ideas, right? If you did like a UTXO and ZeroSync, This would be, I like first

the proof and then the UTXO node, because the UTXO node is great to s- to stay in sync, but, our proof is awesome to,

to get the IBD done quickly. Yeah. I see. And then now contrasting that with assume UTXO, which is another idea from James Ob, and I know he's trying to push that forward as well. Could you contrast that idea?

Yeah, it is similar since, it allows you to start your node instantly. You give it a UTXO set, and then, it assumes that this UTXO set is valid and, starts listening for new blocks instantly. But, it cannot verify the, the UTXO set instantly. It has to do the entire catch up, to be certain at the end that it was actually the correct UTXO set. And, this can be greatly combined with, our proof as well, because you can prove a UTXO set Set, then give it to the Bitcoin, Bitcoin Core node via, the assume, assume UTXO option, and then, yeah, you can instantly run your node and also catch up in the background to be absolutely certain that, it was actually correct, and even if there's a bug in our proof, then you would catch it with, with this approach.

Interesting. And so we can view this like a, a scaling technique and maybe a verifying technique to help people quickly onboard and maybe it- It might help users use Bitcoin in a less trusting way or a non-trusting way compared to today, where a lot of users are basically in a, in a custodial situation or maybe they are self-custodying, but they are using a light client that calls out to, let's say, a public Electrum server, let's say they're using Sparrow or something like this, and it calls out to a public server, then they're doxing their privacy. So I guess you could also argue this might help privacy too.

Definitely, yes, yeah.

Okay.

And there are lots efficient and, also more privacy-preserving. And, yeah, I think that, that, that will be great in particular for mobile users. And in general, like there are about fifty thousand full nodes, but they're estimated to be millions of Bitcoin users, so, there's a huge asymmetry and there's a huge room, for improvement for more people running. Yeah, because you have to ask the question,

why aren't those users using a full node, right? And, maybe for some of them, they don't know that they should be doing that Probably difficult, maybe the software isn't easy and the user experience isn't easy for them to just download and use Bitcoin Core, they want, or they want the features that some other product has, so there's probably a range of reasons for that, but hopefully, Zerosync might be part of, part of an answer there to help them, step up their sovereignty, let's say. so from your presentation, I've seen you, you spoke about, I think one of your slides talked about the different levels of what can be verified. So for example, you said there There's a quote-unquote assume valid, which is an existing setting in Bitcoin today, and then there's also the full chain state proof. Can you just outline what's going on there? And is it right to say ZeroSync would be a full chain state proof? Yes,

we are building the full chain state proof in three stages. The first stage is, the headers chain proof, which is very similar to an SPV client. It's, the most simple proof, but that's the best, best way for us to get started. And, the most That is that we are already augmenting the chain with a new, with a new data structure. we are building, a header chain, sorry, we are building, a Merkle tree over the headers, so you can easily, you can use that for succinct proofs of inclusion for basically every block or every transaction at the end. And that is already quite cool, 'cause people have been talking about such things for quite a while, but it's hard to find consensus on them. But, when you implement it in a proof, you Requires no activation drama whatsoever. It's just, just works instantly. And if you don't like our Merkle tree, if you want some kind of other Merkle tree, you can just build your own Merkle tree. The second stage, is what we call the assume valid proof. Assume valid because there is an option in Bitcoin Core that, allows you to assume that, the scripts are valid until, a certain block. That is basically what our proof does. It verifies everything except for the script data. So So it does already verify the UTXO set, the inputs and outputs, the fees, the coin emission schedule, and, basically every, Bitcoin rule except for, the, the script validation. And, yeah, the third stage would be the full chain state proof that verifies everything. The other two proofs are verifying, including the, script validation.

I see. And so you're building that up in progression, in progression, so that there's steps there, and then over time your proof will- Cover more things or it'll prove more things, so the idea is the user can benefit from that verification that's being done. and so I, as I understand, it's like you are centrally computing that proof, and you, you're gonna, maybe there might be clients who download that proof and they can use that proof. Is that the right understanding here or how, how, how, how do you, how do you see it?

Kinda. it is an issue to prove the existing, eight hundred thousand blocks of what we have and, Doing that, yeah, we, we will do that probably with, specialized hardware. We are talking to people like the, it, it's becoming a big thing that, hardware, builders, they, they, they are building ASICs and, FPGAs for, for, for proof systems, and we will probably use something like that for the initial catch-up, but once we have proven the chain, we just share that proof and then everybody else can, extend that chain proof with the next block as soon as it arrives. we We don't want to become the central prover that, provides the proof for everyone. We, want, want it to decentralize as much as possible. And, yeah, other, other projects are already, they, they have already solved this problem of how do you prove a block in a, in a distributed manner, and we will basically just copy that. And, yeah.

Gotcha. And so just to be clear for listeners, Zerosync, is it a business? Is it a project? Can you just explain what's the structure of this and how

Yeah, we've funded, a Swiss nonprofit and, and we, our hypothesis is that this is very valuable to the entire Bitcoin ecosystem. We think it's very valuable infrastructure, and if that is the case, then probably there will be people who wanna fund it. And, if not, we should probably work on something else. But, right now it looks, it looks good and, people are interested in it, and, it looks like at least for the next year we will find funding and, see how, how far we can get and We can deliver in that time.

Great. And so maybe the case will be, there might be some wallet providers who say, "Hey, this is the infrastructure we're gonna use, let's chip in some money." Maybe that's the way it could go. And so the wallet, they might have their own business model, I mean, who knows? and so, also, that reminds me, I know Blockstream has been looking at implementing this into Blockstream Satellite, so could you explain a little bit about how that's gonna work?

Yeah, Blockstream Satellite is, very exciting 'cause it allows you to sync the Bitcoin blockchain from basically anywhere on Earth as so-- as long as you have a satellite dish, you can, use their satellite to sync the blockchain. the main problem here is that it's very bandwidth constrained. Currently syncing from scratch down, takes maybe a month or so, definitely multiple weeks. And, yeah, that setting is obviously a great match for, for our chain state proof because, in particular in combination with With a U3XO node, you could just

download the, the, the chain state proof and then run the U3XO node and, you could instantly sync via the block, blockstream satellites. I see. And so in that far-far The state of the UTXO set, and so he can just kind of really quickly onboard and start, I guess, receiving and spending in a non-custodial way, self-custodial way, while doing some form of verification, even if it's not downloading the blocks and verifying themselves.

Yes, exactly.

Got it. And so could you also explain a little bit about how it would work if you do this and then, let's say, your node goes offline and now you need to catch up again? So would it be sort of like you use Zerosync again, or is it more You could, I mean, just for the sake of example, let's say I use Zerosync right now today, and then I turn the computer off, I turn it back on in one week's time, my computer just needs to download one week's worth of blocks, or is there another way that I could just Zerosync again?

yeah, in the most simple way, you would just resync, like, you would just sync, the last week of blocks. And, but when we make that UTXO set commitment more sophisticated, then, it would be possible to just download, the delta of the UTXO set commitment that, you just download what's new. So I could actually

download the difference and then just- Yes. Exactly. Yeah. Oh, very clever. Okay, so then, and then that might be more useful, let's say it's been

It maybe it's like my cold storage, I don't really use it that often, but now I could turn it on and in, in that hypothetical future, it could sync up that difference and then I could just be running, in a verifying, way or in a validating way. So I guess what's the implication then if more clients become fully verifying? I mean, what, what do you see that doing for the ecosystem?

On the one hand, I would say, the, the entire system becomes more dezen-decentralized Because the entire security relies on, basically every user verifying every transaction, and, yeah, that scales poorly in the, the plain setting, but, using a proof that would actually scale. And, so I think that is a great advantage. But on the other hand, there's also the problem of the data availability problem, because, our proof can verify mostly all consensus rules, but it can't verify data availability. By, by design, it's not downloading the block, so it doesn't know If the blocks are actually available or not. And, there are some concerns that this might become a problem at some point. I think it's not that big of an issue because as long as there are honest, full nodes, they, they will never go into a state for which they don't have the block, and when they have the block, they will keep sharing the block, and as long as there's at least one honest, node that is sharing the blocks, then there is no data availability problem. also there are a few miti-mitigations For example, when you sync, you could, could do it such that you don't sync to the, to the latest tip, you just sync to like a hundred blocks back, and then you download the latest hundred blocks, and then you have verified that at least the latest hundred blocks exist, and that mitigates most of the attacks that people can think of what you could actually do by, withholding some blocks. And the other thing is that, all kinds of network split attacks. Well, I should explain that there is actually an issue with Those network split attacks because, let's assume there is a future where, we succeeded in building everything and it works all great, then, it would be likely that we have some scenario that is like we have still fifty thousand conventional nodes and then on the other hand, there's like, let's say tens of millions, zk nodes because everybody is running a zk node on their phone, so that could be like orders of magnitudes how, how things could work out. And then, you could try to trick the, the zk nodes into believing into a block state or into a chain state that the others don't believe in because they don't have the block for it. But making that, making the, the, the other nodes believe in a, in a, in a chain state for which the others don't have the block, requires you to mine that block. you can't make them believe in any block, that is not possible. You can only make them believe in valid blocks, so you do have to mine those blocks to, make the zk nodes believe in it. And, that is basically a The fifty-one percent attack, and if you can do that, then you can probably do more harm, and you don't really need our proofs for it or not.

I see. Yeah, I think that's an interesting way to put it. And so essentially, you're relying on the same checks that normal Bitcoin nodes do anyway. And in that scenario, you would see people fall out of sync, and so people might send a transaction and be like, "Wait a sec, I don't see that transaction. Where, you know, what's going on?" And then at that point, people would be like There'd be enough, let's say normal non-ZK nodes in the future, and, you know, of course there'll be kind of a h- a hardcore community of people who are just running them anyway, 'cause they don't want to do any ZK stuff, they just want to do the normal, you know, fully archival node, let's say. And so, yeah, that's an interesting one. Also, there is an interesting caveat with all this, and I-- you, you pointed this out in the talk, but if you could elaborate a bit,

That's pretty much more caveat, it's not a fundamental problem. it's, I, I just pointed it out because, in an earlier talk, I confused someone and they got really mad at me for saying that it would prove all consensus rules, even though it can't verify the longest chain rule. Yeah, the longest chain rule means, if I have two peers telling me conflicting story, peer one, believes in chain A and peer two believes in chain B, then, I have to figure out which is the longest chain, which chain contains the most work. And, yeah, the same thing has to be done with a proof, because a proof is only aware of a single chain at a time. Like, it can't prove-- you can't provably connect it to a peer-to-peer network that just, that just doesn't work. So you can only prove a single chain, but as long as you're connected to a peer-to-peer network where you have at least, a single, at least one honest peer, then, you can receive a chain state proof for, for the state that they believe in, and you can Or, what other peers believe in, and then you can directly, like, you can instantly compare it and see, first, which one is the correct chain, or like, are both chains actually valid? And the second one is, which one is the longest chain? And, yeah, proof makes it much easier to, to, to verify that.

Okay, gotcha. Yeah, so it comes down to a very long-standing rule, heaviest chain or most accumulated proof of work on the valid chain. I think that's, I think that's reasonably well understood. and so in terms of ZeroSync, the project, what's required to sort of see this brought to life or, you know, what's required at this point? Where are you guys at today? And, what, what does it take?

we started a year ago. we got an initial research grant from, Geometry Research and, That helped us to build, a first, prototype, and that first prototype, as I said, is doing this assume valid proof, validating most of the consensus rules except for, the script validation, and, that works as a prototype. However, it's still horribly slow. Proving a single block or like proving a full block takes about four hours currently, and four hours is of course way too long. we have to get it down to ten minutes. of course, throwing hardware at it helps to some degree, but, there are lots of other optimizations that we can do. there's a list of simple optimizations that we can do and a list of more complex optimizations, most notably, parallelization so that people can proof in parallel. So we would chunk up the blocks into small chunks of transactions, let's say ten, twenty, thirty transactions something, and then, person A gets the first chunk, person B gets the second chunk, and so on, and then, we aggregate that into one block proof, and this will give us a speed up of Probably a hundred x or something, and also makes it possible to do the proving on consumer hardware. Currently, we have a very beefy server to do it, and, it's still too slow.

Yeah. And actually, can you explain a little bit about that idea that instead of just having one centralized proving institution or server, this idea that you might try to dis-distribute it? Could you explain how that would work?

Yeah. in the naive setting, it's Quite complicated because you have to have the entire block verification in a single proof, and this takes about a hundred gigabyte of RAM or so, which most people just don't have. And, but we, we can chunk it up. As I said, we take the thousand blocks or so and chunk them up into, did I say blocks, a thousand transactions, and then we chunk them up in, in chunks of like thirty or so, and then, they get distributed to everybody, who connects to the network, to the proving network, and then they- They can proof chunks of it and then, they send it to the, to the, to aggregators and then aggregators, just keep recursing on those proofs and, yeah, maybe I should introduce the idea of proof recursion. Proof recursion means, I verify a proof in a proof. And I have like, if I have two proofs, now I can verify them both in the same proof and then I get like a Merkle-like structure of proofs. And, yeah, this way you can aggregate lots of, batches into, into more layers Of a single root proving all the transactions contained in the

block. I'm curious then, is that relying on some sense of altruism by people to be part of that distributed prover or solver network? Right? There's not really a monetary incentive for that, but maybe you would sort of-- Depends, there might be some more hardcore users out there who, let's say, want to contribute, but basically the question is, is it relying on altruism? Yes. Well, quote unquote altruism, let's say. There

might be, there might be some ways To monetize it, but, we think that it might also work out for just altruism. if there, if there's a hundred people worldwide who, who are willing to run a regular computer at home, that, that would suffice.

I see. And so would these hundred people have to be running it continuously, or is it, it's like a continuous proving thing, right?

Yeah, it depends on the frequency, how, how many, how many proofs you wanna have. If you wanna have a proof every ten minutes, then, you need someone to Gain some, some advantages, like some performance advantage, if you, if you batch proving, like if you prove only like, batches of like, let's say, a hundred fifty blocks or something, then, that could be a bit more performant than, proving every block by itself.

I see. So, so the way is you might have some interval, and like you said, it might be like on every hundred fifty blocks, and then so the users, they can just zero sync up to that and then download manually the last hundred blocks or whatever to catch up to As it's called, to the latest block, and that's just kind of the way it works. And depending on how many computing resources you have who are contributing, you can sort of set that time interval to something that makes sense, right? Whether it's download this, and you get maybe you have to download the last, you know, few hours or maybe the last day of blocks, something like that, maybe it's a little bit more feasible. although that said, for mobile clients, it probably needs to be-- it probably needs to be relatively close to the chain tip just And maybe people are in places with bad connection or not a lot of data on their plan, so they can't just download, you know, gigabytes and gigabytes. but how, how are you sort of seeing that? You would just try to find a, a happy medium compromise there?

Yeah, exactly. And I, I think the more popular it gets, the more people will be altruistic and, contribute, computational resources to the proving, and on the other hand, it will get cheaper over time. Like We can probably expect that the cost of proving drops exponentially, just like everything, like all cost of computation, just

like Moore's law stuff, yeah, gotcha. And I mean, you could sort of view it like a, a Bitcoin version of SETI at home, right? Like if people remember that there was like this OG, it's not OG, maybe like fifteen, twenty years old, there was like this computer program that people were using and they, they sort of felt like they were chipping into the search for extraterrestrial life, and it's kind of a You can download and run it on their computer and contribute, let's say, computing power, to the prover, to the, to the proof machine, let's say.

Exactly, yeah. Like a few others that are similar, like finding, twin primes or something.

Right. I think there's some protein folding thing, I don't know exactly, something like that.

And I feel like these things show that it is feasible in, in practice that people are altruistic enough to, to do some To do these kinds of computation, just pro bono.

Gotcha. Yeah. And let's talk a little bit about the longer term. This is one other idea I saw you mention and we spoke about it, I think while we were backstage. You mentioned this idea of compute indexes or filters, and that this could be used for, let's say, lightning or other layer two things. can you explain a little bit about what that idea is and just elaborate on that?

Yeah. the, the chain proof can be turned into a chain Proof that it can process the chain and, you can give it basically any kind of function that it should check the, the, the chain data for, and then, it can just do that in a provable way. it might sound a bit abstract, but, a concrete example would be, for example, for Lightning, for Lightning nodes, if the proof proves to them that, the unilateral channel closes of all, of the last two weeks, for example, this way they wouldn't have to download the entire chain, they just download, the Proof and exactly the data that they are looking for in the chain, because that is what a lightning node does. It, it scans the block for unilateral channel closures and then it looks if one of those unilateral channel closures was one of their own channels. And, yeah, with a chain processing proof, you can just filter the chain for exactly that data. And, you can have arbitrary filters, well, whatever suits you, you can, you can basically build a custom proof for it and then process the chain using that, that custom proof. Like more you would use our chain state proof, and then on top of that, you would have an adapter that allows you to, to add any kind of, computation to it. And, yeah, this can be interesting for all kinds of protocols that are built on top of Bitcoin. Another interesting application, is domain name systems. You can, most things about domain name systems are actually easy. You can just represent them as, as an NFT on Bitcoin, and then you can send them around, and you can, buy them for bitcoins and sell them A few things are complicated. For example, if you register a domain, then you wanna be certain that nobody else registered it before. So you kinda have to prove that nobody registered it, and, yeah, that is complicated if you don't process the entire chain. But with a chain state proof or with a chain processing proof, you could just, yeah, scan the chain for all, registrations of domains and then create like some kind of Merkle tree, maybe a Merkle Patricia tree or something that, creates a commitment U-- something like a UTXO set commitment over all domains, and, yeah, that would make domain name systems on top of Bitcoin much more efficient than the, the, the current designs.

I see. So, as- essentially, it can act like a special kind of filter, and users could do kind of like a query, let's say, they could be a lightning user, and they could query the ZeroSync Prover to say, "Hey, can you show me any, lightning channel?" Channel closes because I need to know if I need to do a justice transaction because somebody's trying to cheat me or whatever, show me for the last one week, and it will kind of feed you those, a filter that tells you wh-what, the information that's relevant for you on whether you had any of your channels unilaterally close on the other party, the other party tried to close it, and now, now you need to know whether you need to do your justice transaction or your penalty close transaction as an example, and maybe in the future there'll be other L2 implications or things that might be Use this kind of filter for, whether it's, you know, Lightning or ARC or DLCs, maybe DLCs like there's a bet and you wanna, I don't know, you wanna see, has there been a contract close action on the chain as an example, something like this.

Yeah, exactly that.

Yeah. Okay. So I think those are most of the key questions. So let me just, again, we've been through a lot of technical stuff, like, kind of like we did with, with the episode recently, let me just try and summarize kind of high level for the What we're talking about here is a way to, you know, zero sync is this way for clients, users to quickly download and prove the current or a recent UTXO set of Bitcoin, meaning they can quickly catch up and quickly start transacting in a validating way where currently many of those users are custodial or light client users, now they would actually be verifying, at least using a zero knowledge proof to verify, even if they're not able to do it the traditional way. And so the implication of this means We could have a lot more users who are verifying, and you could, I, I argue it's going to help the network become more robust in a way because more people are verifying, there's less people trusting. you could also argue that it's more private for those users because now they're not asking a public Electrum server or some wallet, centralized wallet server to feed them their balance and their transactions, they're able to check it themselves using this ZeroSync protocol, and it's also, as you mentioned earlier, possible to be- Combined with other ideas such as UTXO, which means you could both quickly download and catch up in a really fast way to get up and running, even on a mobile phone, as an example. the downside, as you mentioned, is that there are certain caveats that you have to verify the longest chain rule at the node level, so you need there to be enough honest nodes, but I think that's a, probably a safe, safe enough assumption, if we're, if you're using Bitcoin and you're bullish on Bitcoin, I think you're probably gonna assume that to be true And it's a project that is, you know, looking for funding, looking for supporters, and, yeah, what do you think? is it a fair summary or anything else you wanna add there?

Yeah, you nailed it. That's, that's exactly it, yes.

Okay, fantastic. So look, for any listeners who want to support you or find out more, what's the best place for them to find you guys and, you know, learn more or support you guys?

yeah, on zerosync dot org. That's our homepage, there you can find,

That we wrote about our prototype and, also, yeah, you can find contacts, you can Telegram channel, Twitter, GitHub, all these channels.

Fantastic. Well, all the links will be in the show notes. And Robin, thank you for joining me and explaining. I think it's an, it's an exciting idea and, it might be, you know, we say in Bitcoin, don't trust, verify. This might be something that, helps more people actually do that. So thanks for your work and thanks for joining me today.

So more people can learn about Bitcoin. Thanks for listening, and I'll see you in the citadels.