Robin Linus from the ZeroSync project joins me to talk about how ZKPs can be used to help people quickly get started using Bitcoin. We discuss:

• What ZKPs are and what they can be used for
• Speeding up IBD
• Contrasting ZeroSync with utreexo and assumeutxo
• UTXO set commitment
• Blockstream satellite
• What’s being verified? 
• Different types of nodes

Links: 

• Site: zerosync.org
• Twitter: @ZeroSync_ 
• Twitter: @robin_linus

Sponsors:

• Swan Bitcoin
• CoinKite.com(code LIVERA)
• Mempool.space

Stephan Livera links:

• Follow me on Twitter @stephanlivera
• Subscribe to the podcast
• Patreon @stephanlivera

Podcast Transcripts:

Stephan Livera 2:56

Now on to the show with Robin welcome to the show thanks a lot

Robin Linus 3:17

thanks a lot for having me very excited yeah

Stephan Livera 3:19

So Rob and 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 uh backstage there and uh yeah I was basically I was intrigued by this idea of what you’re working on with xero sync and maybe you want to just help set the stage a little bit um and perhaps set some of the contexts about what is a ZKP and you know what is this some of the stuff that you’re working on

Robin Linus 3:44

Yeah ZKP is a bit of a confusing term um it’s called zero-knowledge proof zero-knowledge proofs have originally been invented for privacy but um they have kind of been uh rediscovered as a great tool for compression and um those passwords that you hear all the time in the outgoing sphere like ZKP Roll-Ups and such they are usually uh using validity proofs and not zero-knowledge proofs and they’re using them to compress lots of transactions into a very succinct proof

Robin Linus 4:14

And we are spearheading the application of validity proves to the to bitcoin

Stephan Livera 4:18

gotcha and so I guess at high level maybe just to understand is it similar to this idea that you know when you do 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 uh 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

Stephan Livera 4:49

these blocks of these transactions Etc maps to this particular output is that kind of the high-level idea here

Robin Linus 4:56

it’s related um but when you have 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 um yeah that is quite big because um yeah you can instantly verify lots of computation with just that little proof um it’s actually a proof which means even if your biggest enemy had created that proof they cannot fool you even the slightest bit

Stephan Livera 5:26

gotcha so that’s an important point to understand because of the trust levels that we’re talking about here right as you said you don’t have to trust the ZKP proof provider it is literally proof you are able to verify that

Robin Linus 5:36

yes exactly yes

Stephan Livera 5:43

Gotcha

Robin Linus 5:44

I mean there can always be problems in the implementation and stuff but um in general the concept is actually a proof a mathematical proof

Stephan Livera 5:53

I see gotcha so do you want to just tell us a little bit about how this could be used in Bitcoin uh and just outlined a little bit of the high-level basics for us 

Robin Linus 5:58

yeah there’s a range of applications to Bitcoin the first or the most obvious application is to compress the Bitcoin blockchain So currently it’s 500 gigabytes and with validity proof you can compress it in less than a megabyte and um yeah that would uh make it much faster to bootstrap a full node

Stephan Livera 6:25

gotcha and so that’s yes I think that’s really the bottom line is that we could dramatically speed up how quickly it is for a new person to onboard a new uh  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 500 gigabytes depending on the size of your computer and your internet speed it could take a while right especially

Stephan Livera 6:52

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 um so I guess that’s kind of what we’re getting at and 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 in uh you

Stephan Livera 7:20

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 lightning Network sort of thing to kind of speed up the transactions um but what we’re talking about in this case with zero sync is not that what we’re talking about here is the initial block download just so listeners are clear right

Robin Linus 7:37

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

Stephan Livera 7:48

gotcha and so some of this stuff can get confusing because sometimes people talk about soft Forks in the context of having a ZKP verifier for Bitcoin so to be clear for this project for zero sync relating to the IBD the initial block download is a soft Fork required for this 

Robin Linus 7:57

no so Focus required we basically we are just compressing the chain and uh we can just compress the chain without asking anyone and uh it’s an individual uh decision every user can decide if they want to sync using a conventional sink or if they want to use a proof

Stephan Livera 8:22

can you gotcha yeah and so can you walk us through how this would work to help people speed up their IBD using you know the zero sync proof

Robin Linus 8:37

Yeah you would download the proof from somewhere I will come to that later where you were done with that exactly but you would download that proof and in that proof, there is a UTXO all-set commitment then you would also download the UTXO set and match it against the commitment and the proof and then you can be certain that this UTXO site is actually correct so you just copy it into your chain State folder and run Bitcoin core as you’re used to as a prune full node

Stephan Livera 9:07

I see, and so and even some of those aspects that you’re talking about copying to your train 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

Robin Linus 9:27

yeah exactly it could be a simple patch to bitcoin core or even an external tool like a simple Python tool or something like that

Stephan Livera 9:36

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 going to download all the headers all the blocks and it will verify from uh there’s like an assume valid point I think I don’t know exactly it might be six months or 12 months back and the node is going to verify all the signatures from that point forward not and now if you turn that flag off manual it’s going to verify from you know from day one Genesis block um but in this model it’s different to that instead of downloading all the

Stephan Livera 10:10

blocks all 500 gigs of the blocks we are instead downloading the proof of the utxo set which is like five gigs or 10 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 um and do all this stuff very quickly because he doesn’t have to download that 500 gigs he’s just downloading an equivalent of the utxo set State yes and improving it that’s correct right

Robin Linus 10:42

yeah and verifying the UTXO set is much cheaper five gigabytes of UTXO set is just a bit of hashing and when you have five gigabytes of blocks in comparison you have to verify all the signatures in there which is usually the bottleneck so uh it becomes way cheaper like it’s less data and less verification on that data

Stephan Livera 10:58

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 zero sync protocol

Robin Linus 11:22

um I would think that in the future like in the next decade or so all basically all Bitcoin apps will become uh fully validating with um some kind of proof system I would say like I would expect that um just because proof systems are growing so fast and it’s getting more and more easy to actually do something like we are doing and proving the Bitcoin blockchain so I think at one point mostly every Bitcoin app will be fully

Robin Linus 11:51

validating by using a proof there will always be still some conventional notes I think because um the higher the more high-value use cases the more incentive you have to just go through uh the initial uh eight hours of syncing or so but um in it would be great to have every phone being a validating note a fully validating node 

Stephan Livera 12:19

and so can you explain for us the difference in the different types of nodes and so as an example we have the archival node we have a full node and then we have let’s say a zero sync node and then maybe this is like light client so can you just explain the difference it knows

Robin Linus 12:36

yeah so there would be conventional nodes conventional archiving nodes um also they would in the future they would also provide the UTXO set so they would make a checkpoint maybe four times a day or something and then when others want to sync they get this checkpointed UTXO set from them and um yeah then you you would still have um pruned full nodes fruitful notes that have been synced with um with a proof and um also in there is not our first

Robin Linus 13:13

goal but in the future we would want to support light clients as well requires to make the utxl set um a bit more like the Ethereum tree uh tree because um when you’re a light client you want to approve um 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 um this set of UT exhaust is actually all the UTXOs that you own and right now

Stephan Livera 13:46

that it’s complete it’s checking together

Robin Linus 13:48

it’s complete exactly and for that we would have to adjust our utx all set commitment a bit currently we are using utxl and utxl cannot can improve completeness

Stephan Livera 13:57

I see okay but so it’s definitely let’s just 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 that’s kind of the 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

Stephan Livera 14:32

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 zero sync 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 very 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 uh 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 

Robin Linus 15:09

yes you can have different uh different other things for example you could sync with proof and then use assume valid uh sorry assume UTXO um that means you give a UTX also to your node and it assumes that it’s correct but in the background, it does the conventional sync and um proves that the UTX all set is actually correct so this way you could instantly sync but have um the conventional phone out security as well

Stephan Livera 15:40

I see so it’s like you quickly get caught up but actually in the background you’ll know it 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 because maybe some listeners will be a bit confused or maybe not see exactly where the lines of demarcation are so if you could explain the difference

Stephan Livera 16:03

let’s say we’ve got UTXO which is sort of sort of similar sort of related there’s assume UTXO which you just mentioned and there’s zero sync so could you just explain the difference in those three

Robin Linus 16:14

uh I would say the main point of view 3XL is to compress the UTXOset because the more users Bitcoin has the more the UTX also grows and um yeah if we had a billion users then we would have to have at least a billion new UTXO and having that in memory is uh probably not possible for most uh consumer devices and that’s why the inventors of UTXO all came up with that idea of using a UTX offset commitment that is constant size and then you only

Robin Linus 16:48

need inclusion proofs for the UT excels that have been consumed in the latest block and um yeah that reduces the overhead of the utxl set from multiple gigabytes down to kilobytes or something and um the problem with it in comparison to to zknotes is that u3 EXO node 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 note um you need to have those inclusion proofs attached to every block

Robin Linus 17:26

UTXO inclusion proofs and um I think they made it quite fast but still um you have to do the initial download and that’s why it’s a nice com it can be nicely combined with the proof because um our proof it would allow you to run a UTXO node basically instantly because um you can catch up to the latest state with the proof and then from then on you uh listen for uh utrexo blocks

Stephan Livera 17:58

I see and so to be clear then in a zero sync 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

Robin Linus 18:11

um yeah but when you’re running a u3 XL note you would not even have to download the UTX also

Stephan Livera 18:15

oh I see so you’re talking about like a combination of the ideas right if you did like c3xo and zero sync you could sort of run them together in parallel let’s say now this would

Robin Linus 18:25

be first the proof and then the u3 XL node because the u3 XL is great to stay in sync but um our proof is awesome to

Stephan Livera 18:37

to get the IBD done quickly 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

Robin Linus 18:47

um yeah it is similar since um it allows you to start your node instantly you give it a UTXO set and then it assumes that this UTXO offset is valid and uh starts listening for new blocks instantly but um it cannot verify the UTXO set instantly it has to do the entire catch up um to be certain at the end that it was actually the correct utxl set and um this can be greatly combined with um our proof as well because you can proof a utxl set then give it to the Bitcoin node

Robin Linus 19:27

UTXO option and then yeah you can instantly run your node and also catch up in the background to be absolutely certain that uh it was actually correct and even if there is a bug in our approved then you would catch it with um with this approach

Stephan Livera 19:41

interesting and so we can view this like a scaling technique and maybe a verifying technique to help people quickly on board and maybe 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 custodial situation or maybe they are self-custering 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

Robin Linus 20:19

definitely yes sir okay and there are lots of ways to make those slide clients more efficient and also more privacy preserving and um yeah I think that that would be great in particular for mobile users um in general like there are about 50 000 full nodes but they are estimated to be millions of Bitcoin users so there’s a huge asymmetry and there’s a huge room for improvement for uh

Stephan Livera 20:43

yeah because we have to ask the question why aren’t those users using a full node right and um maybe for some of them they don’t know that they should be doing that maybe for some of them it’s a monetary class so it’s you know it’s too technically difficult maybe the software is not easy and the user experience is not easy for them to just download and use Bitcoin call they want or they want the features that some other product has so there’s probably a range of reasons

Stephan Livera 21:08

for that um but hopefully zero sync might be part of part of an answer there to help them step up their sovereignty let’s say um so from your presentation I’ve seen 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’s headers chain 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 zero sync would be a full chain State proof

Robin Linus 21:43

yes um we are building the full chain say proof in three stages the first stage is um the headers chain proof which is very similar to an SPV client it’s um the most simple proof um but that’s the best way for us to get started um the most interesting bit about that is that we are already augmenting the chain with a new uh with a new data structure we are building um a header shame I’m 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 blocker every transaction at the end and that is already quite cool because people have

Robin Linus 22:25

been talking about such things for quite a while but it’s hard to find consensus on them but when you implement it improve you get it in a trustless manner and it requires no activation drama whatsoever just works instantly and if you don’t like our Market tree if you want some kind of other Market tree you can just build your own Market tree the second stage um is what we call the assume valid proof I assume valid because there is an option in Bitcoin core that allows you

Robin Linus 22:55

to assume that the scripts are valid until a certain block and that is basically what our proof does it verifies everything except for the script data 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 um the the script validation and yeah the third stage would be the full chainsaw proof that verifies everything the other two proofs are verifying including the script validation

Stephan Livera 23:32

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 uh cover more things or it’ll prove more things um yes so the idea is to use a can benefit from that verification that’s being done um and so I as I understand it’s like you are centrally Computing that proof and 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 do you see it.

Robin Linus 24:09

kind of um it is an issue to prove the existing um 800 000 blocks or what we have and um doing that um yeah we will do that probably with specialized Hardware we’re talking to people like that it’s becoming a big thing that uh Hardware um Builders they are building Asics and fpgas for um 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 and we don’t want to

Robin Linus 24:48

become the central approver that provides the proof for everyone we want we want it to decentralize as much as possible and um yeah other projects are already they have already solved this problem of how do you um prove a block in a distributed manner and we will basically just copy that and uh yeah

Stephan Livera 25:09

gotcha so just to be clear for listeners zero sync is it a business is it a project can you just explain what’s the structure of this and how would it be sustainable going forward as well 

Robin Linus 25:28

yeah we’ve founded a Swiss non-profit and um yeah we our hypothesis is that this is very valuable um to the entire Bitcoin ecosystem we think that’s very valuable infrastructure and if that is the case then probably there will be people who want to fund it and um if not we should probably work on something else but right now it looks it looks good and people are interested in it and uh it looks like at least for the next year we will find funding and see how far we can get and what we can deliver in that time

Stephan Livera 25:56

great and so maybe the case will be there might be some wallet providers who say hey this is the infrastructure we’re going to 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 um and so uh also um that reminds me I know block stream has been looking at implementing this into block stream satellite so could you explain a little bit about how that’s going to work

Robin Linus 26:25

yeah blocks through satellite is very exciting because it allows you to sync the Bitcoin blockchain from basically anywhere on Earth as soon as long as you have a satellite dish you can uh use their satellite to sync the blockchain the main problem here is that it’s very bandwidth constrained currently syncing from scratch takes maybe a month or so definitely multiple weeks and um yeah that setting is obviously a great match for for our chainsaw proof

Robin Linus 26:54

because um in particular in combination with the u3XO node you could just download the chainsaw proof and then run the UTXO node and you could instantly sync by via the block stream satellites

Stephan Livera 27:16

I see and so in that far long future or maybe not so far for long future but let’s say users find ways to use this and maybe there’s wallet software and things that have a nice ux so basically that user can download an app on his phone and it will quickly kind of sync up to what the current state of the blockchain is it will quickly be able to sync up with

what’s the state of the utxo set and so he can just kind of really quickly onboard and start uh I guess receiving and spending in a non-custodial way self-custodial way

Stephan Livera 27:43

while doing some form of verification even if it’s not downloading the blocks and verifying themselves

Robin Linus 27:52

yes exactly

Stephan Livera 27:53

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 zero syncs again or is it more like you could you know I mean just for the sake of example let’s say I use zero sync 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 zero sync again

Robin Linus 28:26

um yeah in the most simple way he would just rethink like I would just sync the last week of blocks and um but when we make that utxl set commitment more sophisticated then it would be possible to just download the Delta of the utxl set commitment that you just download what’s that

Stephan Livera 28:43

that you could actually download the difference and then just exactly oh very clever okay so then and then that might be more useful let’s say it’s been my computer’s been offline for three months so it’s like I say it’s like some laptop sitting there I haven’t used 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 that hypothetical future it could sync up that difference and then

Robin Linus 29:07

Yes

Stephan Livera 29:08

 I could just be running um in a verifying uh way or in a validating way so I guess what’s the implication then if more clients become fully verifying I mean what do you see that doing for the ecosystem 

Robin Linus 29:24

yeah, on the one hand I would say um the entire system becomes more decentralized because the entire security relies on basically every user verifying every transaction and yeah that scales poorly in the plane setting but using a proof that would actually scale and um so I think that is a great Advantage but on the other hand there is also the problem of the data availability problem because our proof can verify mostly all consensus rules but it cannot verify

Robin Linus 29:57

data availability 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 um I think it’s not that big of an issue because as long as they are honest um full notes they will never go into a state for which they don’t have the block and when they have the block they

Robin Linus 30:22

will keep sharing the block and as long as there’s at least one honest note that is sharing the blocks then there is no data availability problem um also there are few mitigations for example when you think you could do it such that you don’t think to the latest tip you just drink to like 100 blocks back and then you download the latest hundred blocks and then you

Robin Linus 30:46

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 uh withholding some blocks and the other thing is that um 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

Robin Linus 31:18

we have still 50 000 conventional nodes and then, on the other hand, there’s like let’s say tens of millions uh ZK nodes because everybody is running a ZK node on their phone yeah so that could be like orders of magnitudes how things could work out and then you could try to trick 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 other notes believe in a in a chain state for which the others don’t have the block requires you to mine that block uh you

Robin Linus 31:54

cannot 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 uh make the ZK nodes believe in it and um that is basically a 51 percent attack so it all boils down to the 51 percent attack and uh if you can do that then you can probably do more harm and you don’t really need our proof for it or not so uh 

Stephan Livera 32:18

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 what you uh 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 be like hey something’s up here we need to like you know check something and hopefully there’d be enough let’s say normal non-zk nodes in the future

Stephan Livera 32:48

and you know of course there’ll be kind of a hardcore community of people who are just running them anyway because they don’t want to do any ZK stuff they just want to do the normal um you know fully archival node let’s say um and so yeah that’s an interesting one also um there is an interesting caveat with all this and you pointed this out in the talk but if you could elaborate a bit you said the longest chain rule must be verified on the Node level so can you just elaborate on that and explain that caveat 

Robin Linus 33:16

yeah that’s pretty much more caveat it’s not a fundamental problem um it’s I just pointed it out because um 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 cannot verify the longest chain rule um yeah the longest chain rule means um if I have two peers telling me conflicting story Pier One Believes In Chain a and Pier two Believes In Chain B

Robin Linus 33:42

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 the proof because the proof is only aware of a single chain at a time like it cannot prove you cannot provably connect it to a peer-to-peer Network that’s that just doesn’t work so you can only prove a single chain but as long as you are connected to a peer-to-peer Network where you have at least a single at least one on a spear then you can

Robin Linus 34:13

receive a change say approved for the state that they believe in and you can receive a chain State proof for uh what other peers believe in and then you can directly like you can instantly compare it and see uh first which one is the correct chain or like ah both chains actually valid and the second one is um which one is the longest chain and uh yeah the proof makes it much easier to verify that

Stephan Livera 34:39

okay gotcha yeah so it comes down to uh a very long-standing rule heaviest chain or most accumulated proof of work on the Valor chain I think that’s reasonably well understood um and so in terms of uh zero think 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 uh what does it take

Robin Linus 35:06

we started a year ago um we got an initial research Grant from geometry research and that helped us to build a first um prototype um at first prototype as I said um 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 um proving a single block or like proving a full block takes about four hours currently and for us it’s of course way too long we have to get it down to 10 minutes

Robin Linus 35:44

Of course throwing up at it helps to some degree but um 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 context optimizations most notably um parallelization so that people can improve in parallel so we would Chunk Up the blocks into small chunks of transactions let’s say 10 20 30 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

Robin Linus 36:17

and this will give us a speed up of probably 100x 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 to solve

Stephan Livera 36:30

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 

Robin Linus 36:48

yeah um 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 100 gigabyte of Ram or so which most people just don’t have and um but we can check it up as I said we take the Thousand blocks or so and chunk them up into uh did I say blocks a thousand transactions uh and then we chunk them up in in chunks of like 30 or so and then um they get distributed to everybody uh who connects to the network to the proving Network and then they can prove

Robin Linus 37:23

chunks of it and then they send it to the to the through aggregators and then aggregators um just keep recursing on those proofs and uh yeah maybe I should introduce the idea of proof recursion proof recursion means um I verify a proof in a proof and I have like if I have two proofs and I can verify them both in the same proof and then I get like a merkel-like structure of proofs and um yeah this way you can aggregate lots of batches into more layers until you have a single route proving all the transactions contained in the block

Stephan Livera 38:01

I’m curious then is that relying on some sense of altruism by people to be part of that distributed approver 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 um but basically the question is it relying on altruism well quote-unquote altruism let’s say

Robin Linus 38:25

yes there might be there might be some ways to monetize it but we think that it might also work out for just altruism um if there are if there’s 100 people worldwide who are willing to run a regular computer at home uh that would suffice

Stephan Livera 38:46

I see and so with these hundred people have to be running it continuously or is it it’s like a continuous proving thing right

Robin Linus 38:50

yeah it depends on the frequency and how many proofs you want to have if you want to have a proof every 10 minutes then you need someone to prove it every 10 minutes but um you could gain some uh some advantages like some performance Advantages if you’re batch proving like if you prove only like uh batches of like let’s say 150 blocks or something then uh that could be a bit more performant than proving every block

Stephan Livera 39:18

I see so the way is you might have some intervals and like you said it might be like on every 150 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 the latest to the chain tip 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

Stephan Livera 39:50

you know few hours or maybe the last day of blocks something like that maybe it’s a little bit more feasible um although that said for mobile clients probably need to be it probably needs to be relatively close to the chain tip just because of download um capacity and maybe people are in places with a bad connection or not a lot of data on their plan so they can’t just download you know gigabytes and gigabytes but how are you sort of seeing that you would just try to find a happy medium compromiser.

Robin Linus 40:19

yeah, exactly and 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 um like we can probably expect that the cost of proving drops exponentially just like everything like all costs yeah

Stephan Livera 40:39

stuff yeah gotcha and I mean you could sort of view it like a Bitcoin version of seti at home right if people remember yeah except uh that there was like this OG or it’s not maybe like 15 20 years old there was like this computer program that people were using and they sort of felt like they were chipping into the search for extraterrestrial life it was kind of a similar maybe you have a similar kind of program like that that people can download and run it on their computer and contribute let’s say uh computing power to the approval to the proof uh machine let’s say 

Robin Linus 41:13

exactly yeah the few others that are similar like finding uh twin primes or something uh

Stephan Livera 41:20

right and I think there’s some protein folding thing I don’t know exactly something like that

Robin Linus 41:25

um and I feel like these things show that it is feasible in practice that people are altruistic enough to do some to do these kinds of computation uh just pro bono 

Stephan Livera 41:40

gotcha yeah and let’s talk a little bit about the longer term this is one other idea I saw you mentioned and we spoke about it I think while we were backstage um you mentioned this idea of compute indexes or filters uh and that this could be used for let’s say lightning or other layer two things uh can you explain a little bit about what that idea is and just elaborate on that 

Robin Linus 42:03

yeah the chain proof can be turned into a chain processing proof that it can process the chain and uh you can give it basically any kind of function that it should uh it should check the chain data for and then uh it can just do that in a provable way um it might sound a bit abstract but um a concrete example would be for example for lightning nodes um if the proof proves to them that um the unilateral Channel Clauses of all of the last two weeks for example um this way they would not have to download the entire chain they just download the proof and exactly the data

Robin Linus 42:46

that they are looking for in the chain because that is what the lightning node does it scans the block for unilateral Channel closes and then it looks if one of those unilateral Channel closes was one of their own channels and um yeah with the chain processing proof you can just filter the chain for exactly that data and you can have arbitrary filters whatever suits you uh you can basically build a custom proof for it

Robin Linus 43:13

and then process the chain using that that custom proof like more you would use our chainsaw proof and then on top of that uh you would have an adapter that allows you to uh to add any kind of um computation to it and um yeah this can be interesting for all kinds of protocols that are built on top of Bitcoin another interesting application um is domain name systems um you can most things about domain name systems are actually easy you can just represent them as an nft on bitcoin and then you can send them around and you

Robin Linus 43:47

can buy them for Bitcoins and sell them and stuff but a few things are complicated for example if you register a domain then you want to be certain that nobody else registered it before so you kind of have to prove that nobody registered it and um yeah that is complicated if you don’t process the entire chain but with a trade say proof on with a chain processing proof you could just um yeah scan the chain for all uh registrations of domains and then create like some kind of local tree maybe a

Robin Linus 44:19

market Patricia tree or something that’s creates a commitment something like a UTX commitment over all domains and um yeah that would make domain name systems on top of Bitcoin much more efficient than the Current Designs

Stephan Livera 44:38

I say so 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 zero sync prover to say hey can you show me any uh lightning uh 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 uh those a filter that tells you what um the information that’s relevant for you on whether you had any of your channels unilaterally closed on the other party

Stephan Livera 45:18

the other party tried to close it and now you need to know whether you need to do your Justice transaction or your penalty close transaction as an example um and maybe in the future there’ll be other L2 implications or things that might be useful to 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 want to I don’t know you want to see um has there been a contract close action on the Chain as an example something like this yeah exactly that

Robin Linus 45:49

yeah, exactly that 

Stephan Livera 45:50

yeah okay um 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 the episode recently let me just try and summarize kind of high level for the Layman how I see it and you tell me if I’m getting it wrong if you want to elaborate so basically what we’re talking about here is a way to you know zero sync is this way for clients users

Stephan Livera 46:14

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

Stephan Livera 46:43

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 zero sync protocol and it’s also as you mentioned earlier possible to be combined with other ideas such as utrexo which means you could both to quickly download and catch up in a really fast way to get up and

Stephan Livera 47:22

running even on a mobile phone as an example um 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 enough assumption uh if we’re if you’re using Bitcoin and you’re bullish on bitcoin I think you’re probably going to assume that to be true um and it’s a project that is you know looking for funding looking for supporters um and uh yeah what do you think Fair summary or anything else you want to add there

Robin Linus 47:57

yeah you needless that’s exactly it is 

Stephan Livera 48:01

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 or support you guys

Robin Linus 48:12

Yeah on xerosync.org that’s our homepage there, you can find all kinds of information our uh our paper that we wrote about our prototype, and also yeah you can find contacts you can telegram channel on Twitter GitHub um all these channels.

Stephan Livera 48:31

fantastic well all the links will be in the show notes and Robin thank you for joining me and explaining I think it’s it’s an exciting idea and uh it might be you know we’re saying Bitcoin don’t trust verify this might be something that uh helps more people actually do that so thanks for your thanks for your work and thanks for joining me today.

Robin Linus 48:51

yeah thanks a lot for having me

Stephan Livera 48:53

Show notes are available at stephanlivera.com make sure to share the show so more people can learn about Bitcoin thanks for listening and I’ll see you in the Citadels.