Transcription
Sweet. We're live, guys. Give us a second for some people to join in on the stream and for us to retweet this. Here we go.
So, for everyone tuning in, we are about to talk about Hibachi and the win upgrade, um, on Celestia and SP1. We have succinct co-founder Uma with us, the one and only, and also Verun from Hibachi and Hashflow. So, uh, lots to unpack on this upgrade. U, but we'll while we get started, why don't you guys just give a quick background on yourselves and and the projects that you represent, right?
So hey guys, uh Varun here, so from Hibachi, uh and uh we are a privacy-first per exchange, uh that also happens to be pretty fast. So so that's the that's the quick, short and sweet background, uh using Celestia underneath and SP1 for proving uh and making sure that we are not doing anything funny.
Love it. Uma, um I'm Uma. I'm the co-founder and CEO of Succinct. Uh we're building a ZKVM SP1 that powers Hibachi and other verifiable exchanges and then the prover network that generates proofs fast and cheap for SP1 users.
Brilliant. So before we get into Hibachi and win specifically, I just want to give some like background context on where the industry is at right now. So I think everyone's aware of the success of Hyperlid. Um and hyperlquid is a central limit order book, uh which is a CLO essentially, and it's CLOs have kind of emerged now as like an actual viable thing to build on chain, and they are kind of the status quo state-of-the-art um markets for like tradi, but now we can build them on chain and with lots of new properties that you can't have offchain. And so uh I see hibachi as an emerging leader in a new category of of CLOs, and specifically within this whole category of CLOs there's this thesis that I like to call CLOs on blobs, which is that roll-ups specifically have certain advantages over, you know, general-purpose building a CLO on a general-purpose chain, um which we'll get into, but uh with that background, let's talk specifically about hibachi and this win upgrade. Um I know that it has a lot to do with privacy. Um but why don't you Verun take a stab at unpacking what win is and why you think this is a differentiator in this overall CLO market and then uh maybe Uma can also chime in as well.
No absolutely. So uh I think I mean win, it was like kind of uh named after the infamous win uh incident.
Yeah. Yeah. Yeah. So uh you give a background to that for people who aren't aware. So TL;DR is there this hyperlquid whale account that ended up losing lots and lots of money, like like a hundred million or something, something like that, you know. So so uh so so so bas, and one of the reasons why that happened is because everything he was posting was was basically public to everybody, u given the fact that Hyperlid is a L1 and and as a result anything you do is is onchain and therefore visible, and in this particular case uh that was a little too visible for anybody to to use that to their advantage, right? So, and then obviously that massively backfired and and uh at least that's the story that that we've been told and we've seen. So, uh but anyway, so I think this is one of the reasons why we decided to go with the whole win upgrade. The idea was that not to so how did we achieve three things, right? The whole purpose here was you maintain a fast CLB that is like actually on par with the OKXs, the Binances of the world. Uh you don't allow user positions or balances or any of that to be public and be audit or be visible to anybody. Right? So now if you achieve these two things that's cool, like you know how you how does this is pretty much every other exchange does, like Coinbase etc. Uh so so what makes this like you know interesting? So the last point being uh well how do you preserve these two properties while also allowing uh users to exit from the exchange in a world where the exchange stops posting proofs, right? So uh uh have a fast latency in a low-latency uh clob, uh make sure the user information is not publicly available to anybody, and then also allow users to verify Y that the order book was correctly run using ZK proofs, and uh lastly uh allow for exits in in a in a world where the exchange stops posting proofs, right? And this is the first step towards that end goal, right? So and that's the general motivation behind this. Yeah, we we'll get more into that too, but like this is whole notion of verifiable finance VI or VApps, uh which is like a more general version of that that that I know succinct is is helping to pioneer. Um, I don't know if you want to chime in at all on the on win and and the the specific features you think that differentiate it in this landscape.
Yeah, I think uh Verun maybe you touched upon this a little bit, but this idea of centralized and therefore also can be private but verifiable is a pretty interesting area of the design space that I think hasn't been explored as much. And then you have people like Verun who are starting to explore it with Habachi. And I think in general that design pattern, as Nikki said, there's going to be verifiable finance, verifiable apps is something that's going to like continue over the next few years. Also, sorry, that's a fire alarm going off, so I'm going to mute myself.
New York New York does that to mfer.
Yeah, you keep going. It wasn't that loud.
Oh, okay. Okay. Um, yeah, it's just loud for me. Um so yeah, I think um the VAP paradigm of centralized and verifiable is very interesting, and I think there's a few key properties of it that actually end in like better product experiences for users, which I think is like the ultimate northstar. So first of all, you have this like real-time um feedback where the user can submit a transaction, get a confirmation in real time. So it doesn't even feel like you're using a chain; you don't have to like wait for block times or whatever. So that's awesome. Next thing is like privacy. Um, which I think in any web 2 app people expect that. Um, not all your data is like fully publicly available. Obviously, like there's certain benefits to having your data fully available in terms of verifiability, but now at least you have a spectrum of options that developers can choose from. And then if they think privacy is the trade-off their users are looking for, then they can have that option. And then finally, for the developers, the last benefit is actually like you can just code whatever you want. So Run, I don't know if you have thoughts on this, but I think it'd probably be impossible to code something like Hibbachi in the EVM. Like that idea is just completely ridiculous, right?
Yeah. No, I I mean that's fair. I think the design philosophy we you know adhering to here is that don't put everything on chain. In fact, that's a stupid idea to put everything on chain, right? So like especially like uniswap and a way or compound are outliers. But if you want to go and add more complexity to your application, per being one of them, uh it's it's just nearly like it's not possible to, at least not with what's available today. It's not possible to achieve like a really high-performant application like the NASDAQs, the Binances and so on and also expect that to be running on a decentralized L1, right? So I think the right approach here is to run the applications like the way they're meant to be and then only verify the critical operations on chain as necessary and when necessary, right? So and that I think is a sufficient uh uh that is a pretty sweet spot, right? So therefore like VAP or or VFI, whatever you call it. So yeah.
Yeah, I totally agree. I I think there's also this uh notion of I mean people talk about like decentralized a lot, right? But decentralized is sort of a blanket term that encompasses a lot of different potential features for an application. And I think verifiability is one of the most important ones especially for an exchange because it's all about like custody of your funds. And when you have verifiability and the ability to exit, which is what that post people have asked me like, well, why do you post data if it's all private and encrypted anyway? And it's because it enables you to reconstruct the state and exit the chain if you have to, which is just so crucial. Like I I don't think people will put their funds at risk, at least not like um you know users with a lot of like whales essentially. Um so anyway, but but then like you're not by also choosing to be a single sequencer, you can have this ultra-fast latency. Now you sacrifice one component of decentralization, which is censorship resistance. But like that could very well be a trade-off that actually users want to make. So it's kind of interesting how we're opening up the design space here. So I really agree with Uma. So anyway, like moving on. Um I'm curious just to understand at a high level for the viewers how win works like under the hood, like what happens from when a user is placing a trade to that trade getting matched by the you know operator to then you however it interacts with succinct SP1 and and maybe even a prover network and with Celestia and that whole like life cycle. I'm curious to dive into that a little bit with Verun and Uma and I want to hear like Verun's experience working with these stacks. Um, you know, they're they're they're relatively uh new. This is like really new tech, you know, both SP1 and and Celestia. I think people are um would be excited to hear what it's like from a builder who's actually shipped a product. Uh, you want to go first, Emma, or you want me to?
You go first, Vern.
Yeah, let's hear it from the dev.
All right, so sounds good. Uh, well, so so uh, yeah, I think I think the general flow here is right you run an offchain, right? So on your AWS, like pretty centralized, like there is like no decentralization at CLB level, but that's also by design. I think uh that's kind of how you achieve that low latency you want for performance, right? So uh then the second step becomes once the orders once once the trading is done, the matching is done, how do you know the matching was performed correctly, right? So what's going on behind the scenes is all the trades that users post and that they sign with the with their keys, right? So basically uh what what the ZK circuit is proving is it's making sure that trades were signed by the user's keys and then and it's checking to see the trading algorithm uh it followed the steps and make sure the liquidations happen correctly. Uh verifying against your co- like that. So it's checking the entire trading logic and then and and and then basically uh making sure that the state transactions that happened, aka the user balance is changing, they happened according to the rules that have been pre-laid out, right? That's the guest program; that's what it's doing. And then once that thing is done, the zk proof has been you know computed, that gets posted to uh the respective base chains where the users have uh put in their deposits, right? That's the uh zk side of things, and the other component obviously is you have zk proofs; that's cool, but then how do you know that this proof was was in fact pointing to uh the CLO, right? So not some random item, right? You know. So so that's sort of where DA becomes important; like you need data to be able to prove that, but then posting all this information on a public DA basically once again goes back to uh you know we just exposed user information, which is something many users like don't want. So this is all where the whole encryption comes into play. What you're saying is we encrypt the information before we post that to Celestia uh the CLO and blob, right? So, so that's basically uh the reason why we're encrypting it and posting that so that user information is not public and then uh more importantly, right? So now that you have a proof that and you have encrypted state on on on on a DA, this is what allows you to exit, like let's say if the exchange actually I think you mentioned censorship resistance here, so I think this is also where like if for some reason the exchange stops posting, the worst thing it can do right now as a centralized operator is not include transactions in the proof. Right? So, and if a user starts detecting that the proofs are not, you know, his transactions are not being included in the proof, right? Or if there is uh any sense that that is the case, then today we have the decryption key, but then the end goal, the end state is going to be use a set of validators that can basically uh freeze the contract and then and then use uh the decryption key uh to basic uh to allow for exit without the exchange's permission. Right? So that's that's the end state we want to get to, and that's kind of how the entire system is set up. So, so, uh, before we move on, like how was your experience building on SP1 and and pretty good actually, really, really seamless. So, I think that I think uh uh pretty much did the entire thing in about two weeks. Uh, right. So, I think uh uh Orelian, big shout out to that. So, so I think uh it was it was uh a pretty pretty uh straightforward setup. So, I think uh that that was pretty stellar. So I think uh uh that that that's a good shout out to the entire SP1 engineering team to to uh for for answering our questions at like midnight. So and and Celestia, how how is it working on the same same absolutely uh right? So I think Celestia and then Nuke and others were working with Celestia, sorry, satings team separately, and then our team was actually working with Nuke directly to because this thing started like was three months ago where I proposed this to Jacob uh this is what we should do and then and then the whole thing got together and we got it done in like a month and a half uh so it was actually that the whole idea from design to iteration, shipping something like it pretty much built, yeah, it was like in the last three and a half months we built a lot, so and I think it was like just everyone coming together and coordinating that was that was phenomenal. So the cool thing too is that this uh your idea essentially has uh created an entirely new like product category for for Celestia, private DA um essentially, and there's a reusable component that we uh foresee a lot of demand for because there's a lot of applications that want the verifiability that DA gives you but without having to actually publish everything fully publicly. And so, um, it's going to be really cool to see that product like kind of spin out from this, uh, initial, you know, work with you and grow into something of its own.
Um, Uma, what's, uh, what's your, you have anything you want to highlight about like the architecture, how it works under the hood or SP1's role in in win and and I don't know, your experience working on this project?
Yeah, I think uh the thing Verun said that was cool is like it took them two weeks to kind of like migrate it. Um which is, you know, pretty short amount of time. That's insane, honestly.
Yeah. Which is awesome. And then I think like something that was really cool for me to see was just the dream of literally just write Rust. Just write your logic in Rust is true, you know, like Verun and your team, I think you have zero ZK cryptography people, right? And you were still able to like use all this stuff, and I think it's just yet another proof point that like ZK is actually very easy to use. It's actually here. It's actually being used in production. It's actually being used to power real stuff that secures real value with real users. Um, so I think as like someone who's building kind of like a more platform technology, and I'm sure this is the case for you, Nick, too, it's really rewarding to see the actual people building on top like see success and like use it. Um, so that was very cool to like see it all come together.
Yeah. And Uma, do you see like a lot of synergy between Succinct and Celestia going forward?
Oh, yeah, definitely. I mean I think basically if you're writing this like really high-throughput specialized application using a ZKVM, you are not going to just like use Ethereum DA like that's just it's like old-generation technology. Um and so yeah, I think like Celestia makes a lot of sense for all of these use cases. And then conversely, if you're just posting data to Celestia, like Celestia is so minimal that you can't do execution out there, right? So you're just posting data, but you need to be able to verify what that data is actually doing and like what impact that has on like the balances and the state roots and like having all those rollups talk to each other. And obviously ZK is going to be the only way you're going to do that. And the only way people are going to use ZK in a same way is with ZKVMs. So I think it's actually super complimentary. I so so agree.
Yeah. Um, and the future is like coming a lot sooner than I think people expect. So, while we're on that topic, actually, just quickly, I mean, part of the CLOs on blobs thesis, um, is the idea that the CLOs are going to eat a lot of DA because, you know, if you're posting every trade on chain, these are about every five milliseconds there's like a bunch of trades updating everything. Um, that ends up being a ton of transaction volume. Um, so I'm curious just from Verun's perspective like how how do you see the demand for DA growing as a function of like the success of Hibachi and I and I guess also this equally applies to succinct and the prover network and just succinct in general and that like the more trades the more like proving uh capacity you need. So I guess this is like you know relevant to both Celestia and succinct, but I'm curious to to hear the way you think about it, Vern.
Yeah, no, I think uh yeah, I think I saw the data like just last week we were already like in the top five of of post last year. Uh I haven't what the number is today, but uh but no, I think and this is like with us like not even doing that much volume, like we're still in the bootstrapping phase. So so with this going like up, I can I can yeah, that demand is going to be a lot lot higher. So, so that that is already something. I was gonna tell Jacob like, "Hey, I think this demand is about to increase significantly." So, uh uh yes, that's going to be a lot. And each transaction is like what 100 bytes or or do you do you have that number off the top of your head?
Roughly each order, I should say. I don't know the number and I have to quickly check to see exactly what
Yeah. Yeah. Anyways, I I've I've had this conversation with a few other CLO builders and um yeah, typically it's about 100 bytes per per trade order, and then like if you start thinking about, you know, even just doing a thousand TPS, which is not that much for a CLO, um it it really adds up over time.
I don't know, Uma, you have a have have something you want to say?
I mean, yeah, the same calculations you were doing for DA also apply to proving; like a thousand QPS adds up for, you know, the types of proofs that are being generated. And I think like the interesting thing here um that's applicable for both Celestia and sustained network is CLOs have real economic activity, right? Like Hyperlid, obviously everyone's like oh they make so much revenue, um I'm sure your guys' protocol will also make a lot of revenue, and then you know we are providing the services that make like having that revenue be possible, so then there is actual real revenue to be like paid back to like both for DA and for proving and these networks. Um, so for me that's why it was very interesting to have this sort of application because like real economic activity is like at the lifeblood of crypto, and obviously per taxes are like the number one PM application.
Yeah. Yeah. On that point. I mean, um, when Eclipse was doing their Turbo Tap campaign on on top of Celestia, which which was just like a a stress test of like what throughput can Eclipse and Celestia support, and they were doing I don't know more more TPS and
Salana in and certain points in time and everything worked, but everyone was like, well, but this is all kind of BS, spam transactions.
And the interesting thing about this whole CLBS thing is that it's going to be similar amounts of TPS, if not actually significantly more, but is also economically like valuable transactions that would actually pay for block space for proving. So I'm I'm very much um on board with with that.
Um, Uma, one more question for you is basically like what this is a very interesting moment for ZKVMs. I think win is a a specifically interesting example in that it also, you know, is a privacy-oriented um design. Do you like why now for ZKVMs and what do you think that like privacy is also an angle that you guys are going to be leaning more heavily into because it's not just succinctness but also the zero-knowledge component of ZK?
Um, yeah, the why now question around ZKVMs is a good one. I think like if you look at the arc of ZKVMs, we announced SP1 a little over a year ago, but then to get it audited and production ready was like August, September 2024, and then to get it like fast and we get our turbo upgrade in like February and then since then it's only been four months. So often as actually Verun probably will tell you the hardest part about using a ZKVM is actually not the ZKVM part because it makes it so easy because it is just writing normal REST code. It's actually like the rest of the protocol like building a good per exchange is just really really difficult, like the business logic is really difficult. So you can I think the why now is like super clear. It's like okay, this stuff was like fast and production ready only even like at the start of this year. Then you have to build out your whole protocol, which is really hard and that takes a few months, and now we're starting to see these systems go live.
Um, and so it makes sense that all these things take some time and now we're starting to see like the beginnings of real economic value secured by CKVMs. So it's like a particularly nent exciting time.
Um, in terms of privacy, I think for most of our use cases actually like and most rollups and stuff, I would say the grand majority of block space today is default public, right? Like Bitcoin, Ethereum, every single rollup, Salana, even these verifiable exchanges for the most part, Hyperl is default public. So, I think Hibachi is maybe one of the only ones that's private but verifiable.
Um, I think we don't obviously if we're if you're using our prover network um you have to be doing stuff that's public because all the provers are public. So I think we'll actually still continue having more of a focus on default public things because that's also like where the bulk of our customer demand is. Um, and then Hibashi is using like a separate private network um to like service their use case and needs. But now that we have that set up we can serve more private customers. So maybe there will be more somewhere. I like that.
Um, so we have maybe around like five 10 minutes left. I wanted to just quickly Verun give you an opportunity to address any of the FUD uh around this. I saw some people some privacy purists being like this is not real privacy because real privacy would be private from operator. Um I also saw L2B saying like oh how how can you exit if the contract is you know controlled uh you know by an EOA or whatever. What's this I want to give you the floor to to address these comments.
Yeah. Know I mean uh look I think that the thing uh that L2B pointed out like the EOA uh controls the upgradability at the moment. I mean it's it's correct like you know they're not wrong but also I don't think uh uh this like super early stage of the product. So to expect us to have like a 100 people validate a set to to upgrade contracts is like pretty unreasonable, right? So so I don't think uh so I don't think it's like either or. Uh I think the way we're thinking about it is start with something that works great and then eventually either just get rid of the upgradability completely or or or decentralize that set right so so yes the concern that L2B raised was valid and I think uh we're working towards uh getting to that point. Right? So but it's not going to happen overnight. It's going to take uh few iterations before we get there where the product is more mature. Right?
Now on the second point around the operator having access to the user information like that is the part uh I think it's it's it's a pretty reasonable trade-off to make right so because from an exchange point of view most of the users don't want their transactions publicly available on the blockchain or like the positions be tracked but they are completely okay with the operator having access to it right so uh yes you can argue that in an ideal scenario no one sees it. But objectively speaking, if you look at Binance, Coinbase, Vbit, etc., uh people are literally giving KYC information there, right? So, and they're still using it. So, uh obviously by using DEX, you're already bypassing that step. And then now I think uh all the operators doing is they're using plain text to match orders. And we can do client side encryption and then and then run for example we can run the whole thing inside a trusted environment and uh and make it like a complete darkpool if you want to but then that just a massive scalability cost and then and then also uh over time if you want to build because that just adds latency right away right so that's at least millisecond latency added instantly and then on top of that you know if you want to scale to like much larger markets like I think there's a limitation of 128 uh and we have forgot like the the Intel SGX uh memory uh capacity. So so I think I don't think we can scale to like Binance level if you really want to go if you go this part. So, so as a result we like okay for now if you want to achieve like that sub millisecond or even like you know low single-digit millisecond latency while obscuring the transactions from public uh visibility like you know you do in L1's or L1 dexes this is actually a pretty good sweet spot to achieve those things like yeah like there's no free lunch right but in this case uh we think that's that's a pretty reasonable trade-off to achieve what we're achieving right so that being We actually looking into other ways to see if you can do something like that. Maybe you can do some kind of uh auto matching on encrypted data and then comput a zk proof but then that brings up all fully homomorphic encryption and things like that which is again it's computationally expensive and the extra benefit of doing that is like almost non-existent at least for an exchange user who's you know more wanting to do like high-frequency trading things like that. Maybe if you're doing like messaging or building something like signal that is that is a different use case alto together, right? So that's not what we're building.
Yeah. Yeah. I think there's there's room for like a fully fully private, you know, decks or something, but I think that that's a different category of product than what you're trying to build. And that that would make very different trade-offs and that's that's great.
Um, but I think that you guys want to provide the right amount of privacy while still providing latency and all the other things that are actually enable you to be competitive with like centralized exchanges pretty much. So, I'm I'm totally with you on that.
Um, so as we wrap up, I I I know you guys are all you guys both are champions of this verifiable app, verifiable finance movement. Um I just want to hear your guys bigger visions for um succinct and and hibachi in in the role of like advancing this verifiable verifiability movement and and in general like what are you guys road maps going forward? What can people um expect uh from from your guys projects over the next few months?
Yeah, I'm happy to go. Um I think one comment I wanted to make on what you were saying earlier Nick is I think often crypto people are really maximalist and like oh if it's not fully private it doesn't count and I think verune and like especially the moment right now is builders who are much more pragmatic. It's like okay we are going to improve on the sex uh experience because we can't take your funds and not all your positions are open but yeah the operator can see your trades.
Um, and so I think like the market I think is starting to reward these more like pragmatic not doesn't have to be at one end of the spectrum views and I think that's really good from like a UX product perspective.
Um, so yeah, something I'm excited to see more of. In terms of a road map, I think I mean over the next few months we're launching our protocols mainnet. So right now it's um you can still test net nice and yeah so that's exciting. We're opening it up to like provers all across the world.
Um, so that's going to be exciting. That's coming very soon. And yeah, continuing to make SP1 the best DKVM, faster, cheaper, have the most provers on our network. Um, and then really continue supporting like all these app builders. I feel like Hibachi is just the start of, you know, let's directly write a high throughput application in a ZKBM and then put it out in the world. I think there's going to be a lot more of these apps out there and even some other people who've been experimenting it with it behind the scenes. So I'm excited to like continue supporting them, continue building the ecosystem.
Yeah. Yeah. It really is a totally new paradigm for building applications. Write it write it in Rust and then just prove it and ship it. It's it's really mind-blowing.
Um, Vern uh yes. So our product road map right now is more user centric just making the change really really good. So things you can expect like in the coming weeks is like even like this week with TPSL I think you you asked me many people asking about the Python SDK and uh things like uh making the deposit withdrawals like even more seamless. So, so those are like the short-term wins. Then we can expect wault uh uh walts to take, you know, come back uh or actually be a next feature that is going to be coming up very shortly. And then and and then I think one of the bigger features, you know, we are planning to build right now is like build out a full-on unified account system that allows you to do basically spot, hedging, add multiolateral, native lending, all these things using one account. So the goal is to minimize the margin requirements or the collateral needed to do more interesting things, right? So and you're doing these things from a features point of view. Then obviously also uh bootstrapping liquidity. So the goal is to like these things that make traders uh user experience far far more superior and then also continue to do things that allow you to bootstrap liquidity. Right? So it's more product driven at this moment and uh and I think uh that's how it's going to be, right? So uh that is the uh I would say short to midterm road map that we can you can expect from us in the next uh 10 to 12 months.
Amazing. Well guys, thank you so much for joining. Thanks everyone in the audience for tuning in. Um, excited for the future of succinct verifiable apps zk uh hibachi and clubbs on blobs. Um, lots to look forward to uh in the next few months. Um, thanks thanks again for joining.
Yeah. Yeah. Good.