On this episode of Archebyte, Ash Egan is joined by Lagrange’s founder and CEO, Ismael Hishon-Rezaizadeh to talk zero knowledge, storage proofs, and unlocking blockchain data.

Today, blockchains have a difficult time leveraging data from other chains, but Ismael and Lagrange are working to fix that. Leveraging ZK and storage proofs, Lagrange enables blockchains to better utilize blockchain data itself, removing the need to leverage offchain sources and the security risks that come with doing so.

Ismael walks us through using blockchains as databases, shifting trust from provers to verification layers, crosschain data access, and what all of this means for the future of crypto and onchain applications. 

📬 To keep up with the latest from Archebyte and receive articles and research from the rest of the Archetype team, subscribe to our newsletter: http://eepurl.com/iCApL2

- - - - - - - -

⌛ TIMESTAMPS

0:00 Intro

2:00 Crosschain data

3:05 Storage proof unlocks and limitations

6:40 Future storage proof use cases

10:34 Zero knowledge and inheriting trust

12:34 Advancements in ZK

14:45 Lagrange’s focus? State of crosschain data, block headers

18:56 How Ismael thinks around building a team

20:15 Where to learn more

‍

👋 FOLLOW US

Ismael: https://twitter.com/Ismael_H_R 

Lagrange: https://twitter.com/lagrangedev

Archetype: https://twitter.com/archetypevc

Ash: https://twitter.com/AshAEgan 

‍

🌐 LINKS

Lagrange Site: https://www.lagrange.dev/ 

Rec Proofs: lagrange.dev/recproofs

Lagrange Docs: ​​https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol 

‍

📜 TRANSCRIPT

ASH
Hello everyone, and welcome back to Archebyte. Each week on Archebyte, we have on the brightest minds in the crypto industry to tell us about what's top of mind for them. While Archetype’s Katherine Wu is usually the host of Archebyte, we're going to be introducing other guest hosts from the Archetype team this season. I'm your first host for this episode, Ash Egan, founder and general partner at Archetype. 

Today we're joined by Ismael, founder and CEO of Lagrange Labs. Lagrange Labs builds infrastructure that increases the expressivity of onchain data, particularly how state can be used onchain and between chains. Welcome to the show, Ismael. 

‍

ISMAEL
Thank you. Ash. Excited to be here. 

‍

ASH
So I want to start the conversation by restating how I describe Lagrange at the top of the show —  increasing the expressivity of onscreen data and particularly how state can be used onchain and between chains. There's a lot of ways to unpack that statement, but I like to think of it in two major areas. First off, onchain state. Secondly, crosschain state. Can you break down the state data access problem that exists today, both on a single chain and between chains? 

‍

ISMAEL
That's a great question, Ash. So to start with, I think it's important to think of what is the state of a blockchain. And the state of a blockchain, I believe, can best be defined by looking at the block header - a commitment to the chronology of the chain from genesis to a given point, that point being defined by height and block time. In the single chain context, data access has to do with being able to introspect into the history of the chain as well as into a depth of storage in the current state of the chain that's too large for the contract in the execution environment to touch itself. 

In the cross chain context, it comes into how between chains you can move these commitments to chronology - the block headers - in a way that allows you to aggregate data. So, single chain is about historical depth and breadth of the contract storage. Crosschain is typically about the ability to aggregate that depth and that breadth.

‍

ASH

I think an important context here is to define and talk about storage proofs. So storage proofs have been a topic of interest for a while and often they get used in the conversations about state access. Can you explain what storage proofs are and then what the unlocks that come about from storage proofs? 

‍

ISMAEL
That's another great question. So the way I like to think about a storage proof, simply put, is that it shows the inclusion of a state in the storage tre - a leaf in the storage tree - with respect to a given block header. As you start building more applications on top of that, you can cache and you can store block headers or you can have proofs of the connection between block headers that allow you to now access historical state with respect to a block header. And so what this enables you to do is in the execution environment to really be able to access some aspect of the state of a contract at a point in time with respect to the current execution client.

‍

ASH
What are some of the limitations of storage proofs as a primitive and what needs to be developed in order for them to scale and reach their full potential? And obviously, feel free to give a shout out to Lagrangian and your guys’ approach. 

‍

ISMAEL
I appreciate that and I definitely will. So the simplest analogy, I like to think about it as an Excel sheet. And we think about an Excel sheet as storing a large amount of data in a column row format. And a storage proof lets you look at a single cell of that Excel sheet, and that's very effective and that can be useful for a certain applications. But that isn't the totality of what you want to use Excel for. Typically you'd want to sum, aggregate, and compute over data within that spreadsheet in a way that requires more data access and more rich computation on top of that data access than you can get by looking cell by cell by cell. And so a storage proof, the way I see it, is looking at a single cell.

What we do - ZK MapReduce or ZK big data - has to do with being able to access a large amount of those cells at once and to be able to compute in aggregate across all of that access to data. And so the way we support this is by taking the common web2 processing models that work for large datasets - things like MapReduce, Sequel, Spark, and RDD - and being able to prove those and to prove that they've been executed properly on top of  large data access from within the blockchain.

‍

ASH
Maybe double click on the unlocks and what will come about with these increased capabilities?

‍

ISMAEL

Yeah, I think there will be a range of new applications that are built based on relationships to the underlying data that are a lot richer. And examples of that are going to be defi applications that, for example, derive pricing not from an offchain oracle, but from the blockchain itself. Since we have a series of dexes on that chain, the pricing of collateral is going to be based on what those dexes are currently trading at. The ability to say Hey, I from my contract want to access the state of another contract and a computation over the longitudinal state of that contract now becomes more accessible. You can look at user activity to determine airdrop eligibility or give VIP programs to your most active users without having to rely on anything besides the blockchain itself.

‍

ASH

I think that's helpful to really understand what the unlocks are. Maybe just to zoom out a little bit, we went through some of these existing use cases and applications and things like that. What do you think net new could be bred out of the ability to leverage storage proofs, looking ahead almost five, ten years or so?

‍
ISMAEL

That's a great question. And the way I think about it is there's two types of things that can and will be built. And I think you've touched on this in your question. There's the things that exist today that we can make them more secure, more performant, and just better overall user experiences. Then there's the things that we can't build today and that we can't have today that will now be able to start having.

And so I think it's very easy to envision the first bucket, the things that exist better. Defi primitives that are based on more security with ZK proofs alternatives rather than offchain oracles. Airdrop programs that aren't trusting a single actor offchain to compute properly but are actually based on the state of the blockchain. 

But then there's the new things, and I think the new things are often very exciting to look at. And there are a lot of those that I think are difficult to kind of envision today because the way we're primed to think about blockchains don't support this type of thinking. But the way I like to really describe it from a macro perspective is to think about the blockchain like a database and to think about the things you can build as things you can build on top of databases.

So for example, if you have an NFT contract and you now want to have another gamefiI application that is predicated on your ownership of an NFT in some certain collection, you can now have your gamefi contract in your autonomous world’s application, for example, directly query with, for example Sequel or some language that that you see fit, the state of a different contract.

Right now you can't really search over those properties in storage there isn’t sufficient computation support in virtual machines to do this. But as you start allowing yourself to coprocess or prove computation back to the chain itself, you can have these applications that are much more expressive there. 

‍

ASH
I think one way to summarize this could be you're creating almost a new design space that is able to leverage onchain data more easily. From a timing standpoint, when do you think these new use cases are going to come about? Are you spending time with developers to help bootstrap what those new use cases might be? What has been the approach? Curious to talk to that. 

‍

ISMAEL
Yeah. So we're spending a lot of time with developers we think are interested in pushing the boundaries of what they can do onchain. I would say that pushing the boundaries really comes into - your a solidity engineer or smart contract engineer and you are trying to develop something that right now can't be built securely. And you say, Well, I'm hitting all these walls. I don't know what to do. That's the type of developer I've been working with. So there are use cases that we're very excited about, things like contract secured revenue, distributing sequencer fees based on onchain activity, there's things like VIP programs for dexes and fee rebates for traders, there's things related to better being able to pre-process the state of the blockchain for other downstream ZK applications. 

As we start obviously building more and more complicated logic, you're going to start having ZK applications whose output is in fact an input to the next layer. And the examples that I always give is, if you think of ML models in web2, for instance, they typically are computing over data that's been processed by an ETL pipeline or any type of big data pipeline. So we start building all these applications, we will start seeing I think a lot of these things nesting on top of each other. 

‍

ASH
So as an active participant and investor in the space, zero knowledge, ZK, is a super hot topic. It's one of the hottest categories from an investment standpoint and just general excitement. Can you explain what unlocks ZK brings specific to Lagrange, whether for efficient computational reasons, trust minimization reasons, or maybe both of those?

‍

ISMAEL

Yeah. So I think the interesting thing about trust minimization is that people often think of ZK as a way to remove trust or to minimize the trust assumption of a protocol. But the way I typically like to think about it is as a way to inherit trust. It allows you to take a point or an actor in a protocol who you don't trust and allow you not to have to trust that actor, but instead be able to trust where the proof is verified. You shift the requirement of who you trust from the approver onto the verifier.

And in the context of blockchains, we have execution environments, for example, Ethereum, that have an incredibly high degree of security associated with their consensus. A massive amount of collateral in the range of, you know, 20 to 40 billion depending on what Ethereum's priced at any given day. And what that enables is for you to say, okay, the amount of trust I can provide as the person generating a proof for doing the computation is much less than what Ethereum I can provide as part of its consensus. Ethereum's a marketplace for trust, some people would call it. 

And so what you can do is you can take a proof that you've then computed and you can verify it where the only trust that's required is on where that verification takes place, which is in a high trust quotient space like a blockchain. And so that's what makes ZK exciting in the web3 context, because you can start building larger and larger applications that don't have to shift the trust away from the blockchain instrument design to maximize trust.

‍

ASH

How about talking through some of the more recent technological advancements in ZK like recursion and folding? How do they contribute to improvements in storage proofs and computation? 

‍

ISMAEL
The thing that also makes ZK very exciting back to your previous question is how fast moving it is. I think the amount of research, the amount of good teams doing research in this space is only increasing and it's an amazing trend to see.

And we think in particular the work that's being done with efficient proof recursion and efficient folding lends itself very well to the types of computation we do, which are highly parallelizable and span over very large amounts of data that are fundamentally data parallel. So things that improve the speed of how you can compose proofs together allow you to remove sequential bottlenecks in computation, where if you want to compute something that's done in a MapReduce style over, you know, 10,000, 20,000 storage slots, the traditional modalities would be sequential where you'd have to go through Storage Slot 1, Storage Slot 2, all the way to the end.

When you can do that in parallel and then recurse and compose proofs together, what you can do is you can build applications that are logarithmic, for example, with respect to the data they're computing over. So some of the work our team recently did with the paper we presented, Rec Proofs, shows an updatable vector commitment scheme built with any type of recursive or folding snark that his updatable in logarithmic time where you start treating proofs like data structures the way you would traditionally treat programing language like data structures, for example.

And so a lot of the advancements that we see now come into the types of computation we can compose together, the types of constraint systems we can compose together, the heterogeneity of constraint systems we can compose together, the ability to use efficient lookup arguments to minimize the amount of repetitive computation you have to do, as well as broader innovations the underlying constructions themselves and broader innovations to the hardware that these proofs are run on. And all of them really point to the same end, where we ideally are going to have smaller proofs, lower proving times, and lower verification costs. 

‍

ASH
I want to spend some time talking through Lagrange’s focus where Lagrange has been focused on tackling problems in the crosschain ecosystem, in interoperability. Can you give us sort of a state of crosschain data today and then where Lagrange steps in and helps make this interoperability paradigm easier to digest and transact and consume?

ISMAEL

Yeah, I think this ties back to one of the initial points that we talked about earlier - the block header. The block header is the commitment to the chronology of a chain and most crosschain protocols that have existed today all move block headers between chains. They'll take the block header from Ethereum and they'll move it onto Polygon and they will check the inclusion of a receipt or an event. They'll check the inclusion of a transaction if there were bridging. And that's how they function. 

But as we've talked about, the amount of data you can access from that commitment is far larger than just a single event or what we can think of as a single cell on an Excel sheet. What you can now start doing is to take the same applications with the same security, the same devex, the same integrations, and you can allow them to do things with the data that they already have and are predicating their functionality off of, but that are much richer.

So for example, you can start moving price feeds between chains. Not the Chainlink price feed, but the price feed you can actually derive from the historical state of a chain. You can have a defi application on Polygon that's pricing its collateral based on the state of an Ethereum pool and then sending its asset over the liquidate later. You can build yield aggregators that assess multichain positions and use that to allocate and position assets accordingly. And they can do that without having to compromise the underlying security because it's all based on the same commitment to the chronology of the chain that they're already using. 

And so where we see crosschain today to make it very concrete with your question, is as a place where we have all of the primitives and the building blocks in place to have these expressive data rich crosschain relationships, we just don't have the tooling to inherit trust from them.

ASH

Looking ahead, like, let's say five years from now, which is an eternity in crypto, times that by two for ZK - so the design space for storage proofs and interop is massive. What do you think Lagrange looks like in five years? And what do you think you're going to be focusing on? 

‍

ISMAEL
Yeah. So we believe Lagrange is going to be the eminent company in the space for big data style computation over state. The way we see it is when any application wants to have a computation that spans over a meaningful amount of single chain or crosschain data, whether that be defi was that big gamefi, whether that be ETL and data transformations for other types of ZK pipelines, we believe that they'll come to Lagrange to do that. We believe that because we're the only team in the space who's not focusing on storage proofs as a standalone, but focusing on them as a component of a broader computation architecture. And we believe that that has very deep roots in the space and very deep roots in how applications will continue to be structured. 

One of the things I like to say is that being in crypto, we all implicitly believe that there has to be more block space and consumption of that block space. They'll have to be more applications being built, more people using things, and the corollary of that that we can't escape is that there will be more data. And there will need to be tools that can meaningfully compute over that for the future that we all believe in crypto to truly be utilized. 

‍

ASH
Yeah, and it's look, it's not an easy thing to answer what things might look like in five years time, but I think that's helpful for the audience to conceptualize. You've hinted at your team of super competent researchers and developers - would love to share for the audience, how should other entrepreneurs and founders think around building a world class team with that combination of being deeply knowledgeable on the research side, but also having the ability to ship product?

‍

ISMAEL
The way we typically like to think about building a strong team is really about finding the people who are twofold — one, the most qualified to tackle the problem that our company addresses, and two, people who are genuinely passionate about tackling that problem. And I think as you start building teams of people who genuinely enjoy the solving of a problem and are generally qualified to actually solve that problem, that's how you can build the best companies. 

The good thing about research and research engineering is that there are people who've done this for a very, very long time without any expectation that doing so is going to lead to some monetary end, they did it because they were passionate about it. And now a lot of these primitives are applicable in the blockchain context and are highly financially viable as fundamental to businesses that are being built. And we typically have looked for and been able to find people at that intersection who are passionate and qualified to work on this stuff. And then across that, I think it's important to see what your company does well and what your team does well and the things you want to enhance on. Do you need more research skill? Do you need more implementation skill? Do you need more business skill? And then to be very honest with yourself and be honest with your team and reach those accordingly. 

‍

ASH
How can the audience learn more about Lagrange and really unpack some of the stuff we had on today? 

‍

ISMAEL
Yeah, so we have a very good paper we put out at SBC this year, Rec Proofs, that walks through a lot of our research into updatable batch proofs that are proving system and data structure agnostic. And so that's on our website at lagrange.dev/recproofs. And we also have good technical documentation on our products at lagrange.dev/docs. And expect more soon in terms of open source code and APIs to play with.

ASH

Thank you. This has been a lot of fun, Ismael. Really appreciate you taking the time. 

‍

ISMAEL
Thank you, Ash.

‍

- - - - - - - -

DISCLAIMER: The information in this video is the opinion of the speaker(s) only and is for informational purposes only. You should not construe it as investment advice, tax advice, or legal advice, and it does not represent any entity's opinion but those of the speaker(s). For investment or legal advice, please seek a duly licensed professional.