 Time for snacks. I welcome everybody. I'm Hamza Abbas-Allah. This work is done jointly with Georg Fuchs-Pawa, Beta-Gazio, and Caring Client. I'll start up by talking about Lite-Client blockchain bootstrapping as a problem, then define snacks, succinct and interactive arguments of chain knowledge, and then show you how to construct snacks from proofs of sequential work schemes, and then show you how to use snacks to solve the problem of bootstrapping generically. In Lite-Client blockchain protocols, you have a full-node prover and a Lite-Client miner. The prover stores the entirety of the blockchain. The Lite-Client has minimal information about the chain, say its genesis block. The protocol we require to satisfy three properties, that the effort to verify is sublinear, the communication is sublinear, and the protocol is an interactive. If it additionally satisfies that the prover's effort is sublinear and there are no set-up assumptions, then that's even better. Our protocol achieves all of these properties. In a bootstrapping protocol, the verifier having the genesis block here be zero. After potentially reading a bunch of proofs from different provers, its ultimate goal is to output a commitment to the stable prefix of the blockchain. This is powerful if the prover ends up having the commitment to the stable prefix of the blockchain. It can also become a full-node miner itself, but also it can verify different statements about transactions in the blockchain. In this example, I'm having two blockchains, Bitcoin and Chia. Bitcoin is a proof-of-work blockchain, Chia is a proof-of-space blockchain, and we have our bootstrapped verifier. Then, any prover can prove statements about, say, the i-th block in Bitcoin and the j-th block in Chia by opening their respective blocks and providing their respective proofs. So having a commitment to the blockchain is a powerful tool. Solutions to this problem exist. You have snarks, generic solutions, you have an interactive proof-of-work, you have like-liant. Some limitations of these work exist. Either they have some set-up assumptions or limited applicability, applied for proof-of-work blockchains, but not for proof-of-space blockchains, for example, or limited usefulness. Some of them do not even have the notion of a commitment. But more interestingly, a fly client and a Nipah Pau, they work in a model where you have multiple provers, assuming one of them is honest. This is the only case where the verifier has any guarantees. If the verifier is talking to a malicious prover, there are no guarantees whatsoever. In this work, we define a classical proof system that underlies bootstrapping and some other light-client protocols. We construct snacks from labeling proof-of-signature-work scheme. In the Beber, we unify and generalize these schemes and provide a new one. We show how to use these snacks to generically solve the problem of bootstrapping. The advantage of our work is it provides classical soundless guarantees. You have classical soundless, measurable guarantees for the verifier that treats malicious proof. The work is simple, generic, and modular, and it allows for exchange of ideas between the theory of proof-of-signature-work schemes and light-client blockchain applications. In one slide, the way we do our construction, we assume that we have a blockchain. This is the underlying graph of a blockchain. It has a simple path, but it could have additional edges, in this case, these dotted edges. If you have the underlying graph of a proof-of-signature-work scheme, I'm giving an example here. Of a scheme that I will show in the paper and in the presentation. Then we can show how to intertwine the computation of the blockchain and the proof-of-signature-work scheme by absorbing the blockchain computation into that of the proof-of-signature-work scheme, such that we derive guarantees on the blockchain from the sequential guarantees on the proof-of-signature-work scheme. This is in picture, like you have two graphs, you define one augmented graph and we show how to label the graph and utilize the proof-of-verifier of the proof-of-signature-work scheme to build a proof-of-verifier for the snack, such as an interactive argument of chain knowledge. If you're interested in light-client applications, like put-strapping or in proof-of-signature-work schemes, then hopefully see you in the full talk. Thank you.