Interview = nil_ Foundation: Build a Proof market and realize the vision of "everything can be ZK"

Since EDCON in Montenegro in April, “ZK” has become the hottest word this year, and the expansion of the narrative space brought by Ethereum has reached a new high point. Many people believe that this will be a new market of hundreds of billions of dollars, creating more opportunities and wealth stories, such as “ZK mining”. Of course, as a new era that has not yet arrived, ZK also means that many opportunities are difficult for us to accurately identify at the moment.

What the future of ZK will look like still needs more imagination. And the Proof market built by the =nil; Foundation has aroused my infinite fantasies about this era of hundreds of billions of dollars. Recently, I had an in-depth conversation with =nil; Foundation co-founder Mikhail Komarov (hereinafter referred to as Misha), talking about =nil; Foundation, zkLLVM and Proof market related topics.

Interview Summary

1. People use ZK for information compression, which is the most exciting “misuse” of this technology stack.

2. The generation of ZK proofs should be outsourced to producers who provide such professional services, forming a professional producer network to respond to market requests.

3. In the current Proof market, the phenomenon of PEV (prover extractable value) has appeared.

4. The Proof market is not yet fully decentralized, and this will be the work center of the team for some time to come.

= nil; origin

Misha has been in the encryption industry since 2013. The first thing he did after entering the circle was to study the C++ implementation of Bitmessage. This is a Bitcoin messaging protocol, and although it has since been broken several times, many people were crazy about it at the time. Later, Misha began to do a series of development work with Dan Larimer (ie BM, founder of Steemit, Bitshares and EOS) around BitShares, and met Konstantin Lomashuk who later made Lido in the process. At that time, Konstantin had some Bitshares-related encryption projects in his hands and wanted to create a Steemit fork specifically for Russia, namely Golos Network.

It was 2016, and Misha started a new journey with Dan and Konstantin as Golos CTO. But after two years, Misha was tired of Golos, he thought that the product designed by Dan was not satisfactory, its internal structure was not suitable, and its quality was not enough. As a result, Misha left related projects like Golos and Steemit and founded Nil with Konstantin in April 2018.

Misha’s original idea was to prevent people from encountering the instability problems that existed on Golos and Steemit, such as lack of proper data management, architecture, security, etc. Therefore, the purpose of Nil is to bring the achievements of the database management industry to the encryption industry, bringing more reliability, security, scalability, etc. to this field. Of course, what Misha didn’t expect was that his new journey would lead to the very center of the scalable future of the encrypted world.

**BlockBeats: Please briefly introduce your background, such as how did you start the encryption business, and why did you join the encryption industry? **

Misha: That was a long time ago. I got involved in the crypto industry around 2013, when I was working on the C++ implementation of Bitmessage. You may remember that Bitcoin-like messaging protocol that everyone was crazy about back then, and it was hacked a few times, but it was still hot back then.

Then I started developing everything around BitShares and Dan Larimer (ie BM, creator of Steemit, Bitshares and EOS) and then I met Konstantin Lomashuk, now you probably know him because of Lido. At that time, he had some Bitshares-related encryption projects in his hands and wanted to create a Steemit fork specifically for Russia. So we did Golos, I became CTO in 2016, and we’ve been working together since then.

But in April 2018, I got tired of Golos because Dan designed products that were unsatisfying, his products never ran for long, and while they did work, I don’t think the internal architecture was to me It fit and the quality wasn’t enough, so I left Golos and Steemit and all other projects and started Nil in April 2018.

My goal at the beginning was to stop people from encountering the problems I had with Golos and Steemit, such as not having proper data management, architecture, security, etc., everything was very unstable. I didn’t think that was a good solution, so I founded Nil with Kosta to bring the work of the database management industry to the encryption industry, because it means reliability, security, scalability, etc. The story after that is the development of Nil.

**BlockBeats:=nil; When did the Foundation start paying attention to zero-knowledge proofs? **

Misha: Looking back, around 2020, when we finished the first DBMS (database management system) prototype, we realized some problems. To be honest no one had really tried to do that before we tried to integrate database management systems with the encryption industry, and when we were done with this project we realized that the trust assumption was not what we wanted.

Everyone has to trust us if it’s going to work, whether it’s using our data or otherwise. We thought about how to reduce this assumption of distrust, how to make it as trustless as possible, then we realized that we might need to use some kind of technology, we need a cryptographic tool to achieve this goal, so we for this purpose A cryptography suite is built.

At that time, the industry was still in the early stage of development, and there was no development environment such as Arc Works. We thought that since we had theoretical concepts and some experiments, we had to try it. We built a suite and built a proof system of our own. Then we worked with people from the Ethereum Foundation and the Mina Foundation to build a circuit compiler. In order not to generate proofs ourselves, we have established a Proof Market for introducing market dynamics into proof generation.

In building the compiler with the folks at the Mina Foundation, we’re also working with the folks at the Solana Foundation. In that process we realized we needed Proof of State, and Proof of State was something that people at Mina and Ethereum were looking for at the time. Around the beginning of 2021, when we were developing the necessary state proofs for the database management system, people from Mina, Ethereum, and Solana felt that this was “zk Bridging”. Because Justin Drake, Evan Shapiro, and Anatolly all think that we need a more secure Bridge technology, and then they say whatever you call it, it’s zkBridge.

**BlockBeats: Regarding zero-knowledge proofs, the encryption field has been researching and trying for quite a long time, but has not been able to make significant progress. But since the beginning of this year, the development of the ZK field seems to have entered a blowout state. Why? **

Misha: There are actually only two methods that can be applied to the entire zk technology. The first method is obviously used for privacy purposes, and the second method is used for compression, such as the expansion that everyone is talking about, and the emergence of zk -Rollups, zk-Bridges, zk-MLS, zk-Oracles, etc. People “misuse” this stack for compression, and I think it’s the most exciting “misuse” I’ve ever seen. So the question is, why now? We were able to accomplish this a few years ago, and it may be several key technological development milestones that make it usable, feasible, and interesting to use.

The first milestone came in 2016, when the technology became increasingly useful to the crypto industry. At that time, Rank-1 constraint systems (R1CSs) became quite common and different applications started to appear. Fundamentally, when it becomes feasible to preserve privacy, this thing becomes possible. For example, Zcash, Tornado Cash, etc. These projects were born in that era, or the ideas of these projects were born in that era.

The second is between 2019 and 2021, which is the second critical period for this technology. At that time, Bloom filters (Blunt argumentations) became more and more popular. People started building proof systems based on Bloom filters. We also have our own proof system called placeholders. Why is this time period important? Because thanks to these Bloom filter based proof systems, enabling projects to use this stack for compression. It improves compression, making it cheaper and more feasible to do proper Rollups scaling and zkBridge in 2021.

At present, we have made some progress in further developing the proof system, and we have also made certain breakthroughs in our project. Suffice it to say, writing complex mathematical constraints and calculations is also quite challenging in such an environment where information is shared over time. Many people have devoted themselves to this problem, such as the introduction of STARK, the introduction of zkVM to solve this complexity problem, and our introduction of the zkLLVM compiler, which also makes it easier to build applications. From 2019 to 2021, the proof system has been developed, and from late 2020 to early 2021 to late 2022, tool development has also progressed. All of these advances make it efficient enough and economically viable to construct proofs of complex computations.

Of course, the development of proof systems is far from over. In order to realize more application scenarios, there is still a lot of work to be done to prove the system. For example, maybe this year or next year, we will see the development of the proof system, and we are also conducting related research and development here. The development of these proof systems will enable economically viable zkLLVM applications, and we hope to be the first team to do so. But anyway, right now everyone is trying to improve the proof system.

**BlockBeats: You mentioned zkLLVM, which is a compiler built for developers to create their own zk circuits. Where do you think zkLLVM is important and what is the current maturity of the product? **

Misha: zkLLVM may not have been the first, but it was one of the first circuit compilers. I’ve seen some prototypes before, I’ve seen some DSL projects, but with a fully functional circuit compiler instead of a virtual machine, I haven’t seen many before. There are some, but I’m not sure if anyone actually uses them, so that’s why I think it’s important. And quite a few people in this industry are trying to get rid of the dilemma of “I didn’t create it”, which is very energy-consuming. Obviously, people end up creating really good products, but this “I didn’t create it” dilemma makes development time-consuming and expensive.

For example, we are communicating through Zoom now, and almost all the software on our laptops is compiled with LLVM. We just took all of that and made it provable. So I think we’re just bringing the whole ecosystem of compilers into the crypto industry so that these efforts can be reused in the crypto space for efficiency and economic viability. This also brought about widely used programming languages. There is a lot of software in the world written in Rust, C++, Go, TypeScript, etc. that one might want to execute inside Ethereum and in a trustless environment.

My favorite example is when people take the Doom source code (C/C++ source code), they prove it to Ethereum via zkLLVM, and then drag it between each other to show off how long it took them to finish. For example, I completed the Doom speed challenge in 20 minutes, here is the proof and your Ethereum NFT, proving that you completed the Doom speed challenge in 20 minutes.

**BlockBeats: Which user groups are currently using zkLLVM, and what are the products created? **

Misha: Many different types of projects are using these technologies, and some projects may just be building something to try to deploy, or may already be running. The most obvious use case is our compiler-built zkBridge, secured by its proof system. Perhaps this is one of the reasons we recognized the need for a compiler and started building it in the first place. It is also being tried to use it for formal verification of proof statements, in order not to try to put the formal specification of the program with them, but to condense it into the proof by using the zkLLVM compiler that compiles the formal statements. In fact, people do compile compilers.

Take for example zkOracles-like applications, people have built zkOracles to retrieve Ethereum historical data or Lido to secure Ethereum staking issuance. People are addressing issues where there are a lot of trust assumptions, despite having been running for over two years. When we designed Lido in 2020, this was acceptable, but then we wanted to reduce the trust assumption, because we couldn’t risk the user’s TVL, so we decided to protect it with ZK’s proof of work. There are many other projects besides, I could go on forever honestly, I have about 80 projects in CRM at the moment.

**BlockBeats:=nil; Foundation previously received investment from StarkWare, Mina and other L2 teams and other VCs at a valuation of more than 200 million US dollars. Is this money used to build the Proof market, and does the investment from StarkWare and Mina mean that you will be more inclined to cooperate with a specific ecosystem? **

Misha: This is our first and only round of funding in five years, because we didn’t have the need for this before, and now is the time to do it. We’ve done enough prototyping, we’ve backed enough projects, we’ve learned enough that we feel strong and confident enough to launch the product the way we think it should be built.

This funding round closed about a year ago, and we announced it many months after it actually happened. We didn’t announce the funding until we felt comfortable starting to talk about “this is something we built.” Because of raising money, you start promising things to each other, and then they ask you what you raised money for, what are we going to deliver? What is a product? Is someone using your product? So we’ve deliberately postponed any discussion on this topic until we’ve at least done something about it.

We’re really working with the whole ecosystem of Mina and the Starkware team, there’s already a lot of apps from the Mina ecosystem that’s either built on top of us, built with us, or partnered with us of. Recently Mina’s team started researching and developing roll-ups, for which they need a lot of verification capabilities. In addition, we built a compiler-based proof-of-state verification with Mina in 2021, another Mina ecosystem project with which we collaborated.

There’s also a lot going on in working with the Starkware ecosystem. Of course this is the purpose of our collaboration so that we are also useful for provable applications in the Starknet ecosystem. For example there are several bridge projects to Starknet that use our tech stack to be zero-knowledge proof bridges. Several game projects told us that verification capabilities are needed.

There are a few other projects that try to use older bridging technology, leverage proof-of-state verification and build Ethereum applications on top of it. Some people are building L3 on StarkNet, and they said that having verification capabilities would be a good option. Anyway, that’s what we’ve come together with them for. Honestly, I’m happy with the partnership.

Secondary Market for ZK Proofs

Zero-knowledge proof (ZK Proof) is the absolute core of the ZK field in the current encryption market. Its existence provides infinite possibilities for many scenarios such as ZK Rollup and zkEVM. However, generating a ZK proof is also a heavy computational task, and it often takes hours to complete a proof, which is why most current sorters still have not solved the centralization problem. In order to generate ZK proofs reliably and cost-effectively, we not only need to develop and maintain computing infrastructure, but also need to expand it. In Misha’s view, introducing a market mechanism is the optimal solution to this problem.

=nil; The Foundation team believes that generating ZK proofs is a task that should be outsourced to producers who provide such specialized services. Under this premise, we need a Proof market, where everyone can request to generate the required ZK proofs, and then a professional producer network will respond to such requests.

**BlockBeats: Now let’s talk specifically about Proof Marketplace, where did the idea come from, and what’s the story behind it? **

Misha: The idea stems from our extensive participation in protocol applications and various things related to Filecoin from 2020 to the end of 2021. Not only did we witness the madness happening around Filecoin firsthand, but we participated in it from our perspective. That’s when we learned how to get all the proof systems right, how to do proper arguments, etc., and implemented a Filecoin prover that was 10x faster than the public version, allowing miners to fully utilize their hardware. We’re actually a hub that sees all the experiments trying to reduce costs from a miner’s perspective.

During that time, we learned a lot of actual market data like how valuable and how long it would take to generate this particular proof with this hardware; who uses which hardware, which datacenters are built for it, etc. . And then working with the Ethereum Foundation, the Mina Foundation, and many others, we found these proofs of state and proofs of consensus to be very onerous, and we would absolutely not allow anyone to prove these themselves.

Because let’s be honest, no one has this kind of hardware that can be generated quickly because they’re just too massive. For example, like Mina’s consensus, Mina’s state proof is the policy investor curve multiplied by about $35 billion, which is quite a lot. Or the Solana Proof of Consensus, which contains, among other things, about 4000 ECDSA signatures, and it takes a lot of time to generate.

When this was noticed we decided not to do it anymore. We thought, okay, we’re going to outsource this work. We will build a market for this, because we already have a lot of data related to Filecoin, let’s build a market, let’s make it a commodity, let market dynamics apply to this, so that people can go Coordinated by a centralized protocol, they compete with each other so that instead of being the hub, we let the protocol be the hub. It turned out that our thinking was correct. Everyone is building the Proof market right now, and we guessed the direction.

**BlockBeats: When you built the Proof market, did you consider its dynamics with the zkLLVM you’ve already built? **

Misha: At first the two projects were actually separate, they were two separate things. For example, we just need the toolchain to build the circuit, since we won’t be building it manually, it’s too big. Then we found out that other people also needed this toolchain, so we decided to open source it so that everyone can use it.

And the Proof market is also a separate thing, because we think it is just a proof generation market. We didn’t even think about people trying to speculate with proofs. They’re actually trying to buy low and sell high or something, which is pretty ridiculous because it’s not supposed to be like that, but anyway, that’s how it is.

The protocol that supports the Proof market must be a very special protocol, because we need a lot of verification and need to handle a lot of load on this aspect. When people come with data that needs to be verified, we need to deal with a lot of data because they will load the data into the order book of the Proof market, which makes the protocol very data intensive, such as the amount of data describing the average state proof. Once a well-done average state proof description takes up about 2GB of data, try to find a protocol that can handle 2GB of data. It’s almost impossible.

But then, people started proving some really big stuff with zkLLVM, and codebases like Ross and C++ were pretty big compared to what people were doing in Solidity. So we put them together, make them relate to each other, and then make them usable as a service. We still think the compiler does a pretty good job of being efficient and hope to keep it that way.

**BlockBeats: Currently, who are the main user groups and participants in the Proof market? **

Misha: The first type of user is mainly zkBridge, and some consensus proofs and state proofs are quite heavy to generate. If you generate correct and secure verification like the consensus proof of Ethereum, for example, with the complete Ethereum consensus verification, and all 100,000 node signature validator verification, it will take you a while to generate.

The second category is zk oracles, such as those applications that need to access Ethereum historical data, or process Ethereum data in a certain way, and then use it with the EVM. Some applications try to reduce their gas costs in this way, such as lending protocols that try to calculate and load the risk parameters of their collateral assets into the EVM, but they cannot be calculated in the EVM in terms of cost.

They take all the necessary Ethereum data from different exchanges, from different indices, put it into the EVM, and then use it as a set of risk parameters for collateral. This is like another Lido’s oracle, showing how the protocol can improve its security and reduce execution costs by outsourcing a series of calculations (such as the security in Proof market and zkLLVM alone). There is no doubt that zero-knowledge oracles are very important.

The third category is Rollup, which can be used by existing Rollups or new Rollups, and some are even trying to do so. Anyone who intends to become a Rollup validator will come with the desire to implement some kind of proof in the Proof market. Dealing with specialized hardware and running nodes on rented AWS servers is very challenging for validators. The fact that AWS does not currently offer ATX, nor does it offer very powerful GPUs, so basically validators will come with these zkLLVM use cases. Clearly, we already have some use cases for zkLLVM, but I must admit, they are not in production yet.

zkLLVM use cases are also very applicable for large or very complex models, as they need to justify the complexity of the model at hand. This is also something that is currently in progress, but again, it is not in production yet, it is only in the experimental stage. Once in production, we will be able to turn the Proof market into a provable AI computing market, which sounds ridiculous.

**BlockBeats: If I want to become a Proof Generator on the Proof Market, what are the requirements? **

Misha: There are really not many requirements or restrictions to become a proof generator, it all depends on the specific circuit and specific statement you want to prove. We have specially set up something called “Proof Market Toolchain”. When a prover processes various proofs in the market, he only needs to start it as a service, or use it as a tool chain running on your machine. backstage process.

If there isn’t a better hardware supply in the market for a specific statement, a specific circuit, a specific application, a specific proof, then you can take an order and generate a proof. If you have the best hardware, if you can make a promise to generate proofs the fastest, and there is no other better competitor, you can take orders, generate proofs, and get rewarded.

**BlockBeats: All users using =nil; Foundation need to register an account. If the generated proof itself or its transaction and ownership information are stored on a private server, will it introduce some centralization problems? **

Misha: This is exactly what we plan to address by the end of the year. Yes, the current market proof is not that decentralized, we have not released a protocol node to support it, and have not talked about this protocol in public. Here’s how it currently works: With a couple of people who are also participating in Lido and acting as validators and validator operators as validators, we can temporarily host it and see how it goes. Then we distributed the source code to them, and actually had six or eight running as a test mode.

Right now, the system is somewhat decentralized, but it’s not public or truly decentralized. Not everyone can join and run their Proof Market node. That’s a question for us as well, we love apps that ask us about security, how decentralized they are, can we rely on it? Is this something we can currently use? I replied, yes you can, but it’s not decentralized enough because we’re running it in test mode. We will work hard to solve this problem, which is our most important task at present.

**BlockBeats: What steps are you taking to address these issues? **

Misha: First, we designed a proof of market based on a decentralized protocol, using a certain decentralized protocol from the beginning. We discussed several options for deployment and operation, we tried to deploy it directly on Ethereum, but when we calculated the economic feasibility, we found that if we did this, we would need to pay about $2.5 billion in Ethereum fees per year. So running a market on Ethereum proved to be financially unfeasible at all.

Then we try to run it on something like Rollup. Yet even though we tried several different Rollups, the cost was still high. When we calculated the cost of running proof of market and doing arbitrage, we found that the annual cost of proof of market alone was 250 million US dollars, which is also a very high cost. So we had to come up with our own protocol which can handle load, cost, data intensive etc.

Our goal is to make this protocol as close to the security of Ethereum as possible, because there is no other way for applications to rely on it. It turns out that this protocol is also very useful for operations like serialization, because when serializing, the load to be processed is basically the same. One would like to reduce the latency between the orderer and the prover so that they can immediately send data to the prover and thus win the block.

How to deploy the sequencer on this protocol is also one of our current main concerns. We hope to build a platform that can be used by third-party developers, so that anyone can start and run a node that supports this protocol. And make sure the proof-of-market application is as secure as Ethereum in terms of code deployment.

**BlockBeats: Can you share more about the incentive mechanism of the protocol? **

Misha: We would of course prefer to use various tokens to pay for proofs, so we can’t force everyone to use a specific token, which means we have to be as token-neutral as possible, as we Be neutral with any product and application. For example, it’s likely to be similar to how Arbitrum works with Ethereum, you can have Ethereum and Arbitrum, why not?

The first step in this direction is definitely the EVM Endpoint Approval Marketplace, which we deployed the other day. This is the payment solution that enables all Ethereum-deployed assets to be used in the Proof Market as an incentive for approvers or for applications that are willing to pay their own tokens in the Proof Market, and this is the first step in this direction. step.

Proof Market Whimsy

Since it is a market, there must be variability and complexity that people cannot predict and control. Whether and how people will speculate on ZK proofs are important data that the team needs to monitor and record. After several months of actual testing, what interesting phenomena have emerged in the Proof market? What plans does the team have for the future?

**BlockBeats: Will introducing a market mechanism prolong the proof generation process? **

Misha: The auction, or finding the best bidder for the job, does take some time, maybe not a few seconds on our side, but a few moments. Typically, this process takes several seconds, in most cases less than a second. It seems to me that supply and demand are quite abundant, so this does introduce some sub-second latency.

Even with sub-second delays, in the worst cases I’ve seen, the app can’t find a provider for three or four seconds. But even then, this delay is not comparable to the proof generation time overall. So, I don’t think it’s a concern compared to the crowd generation advantages that market dynamics afford.

**BlockBeats: If someone wants to speculate with generated proofs, is that a good thing or a bad thing? Will the team intervene in some way? **

Misha: There are a lot of weird things happening on our site, the one just mentioned isn’t the weirdest one, there are even weirder things happening in the Proof market, but let’s talk about that first The question of speculation. We don’t have any control over this because we can’t. Once we push this project out to the public, once we make this protocol available to everyone, let everyone run it once a week, maybe as a rollup, or otherwise, we will no longer be able to control all of this.

We’re trying now not to interfere, not to try to do something, because at some point we won’t be able to do it anymore, so what’s the point? So let’s speculate. One can build a circuit-like application, like a provable application, basically that’s it, so speculation is even possible. No use other than speculation on the Proof market.

One of the weirdest use cases I’ve seen is someone trying to trade futures for computing power and then use those futures to have a speculative discussion. It’s like bitcoin’s hash rate futures, but for zk proofs as well. Have you ever wondered about MEV? What if I tell you that there is actually a Prover Extract Value (PEV)?

It doesn’t work like the application brings some data and then something needs a proof and the provers do it. They bring in the data, start generating proofs, and everything works as expected. But at the same time, if a prover is trying to make more profit on this data or something like that. They will use this data elsewhere, such as on Ethereum or other protocols, or even some Rollups.

They do this to extract as much value as possible from this data, rather than using it to generate proofs. There are other different types of extractable proofs of value, such as people trying to predict when a proof will be generated, and then injecting transactions to buy or sell proofs into the Proof Market protocol, by reverse engineering the API and trying to inject transactions in it. This way the prover can sell, or the buyer can guess the price to extract value from it, just like Lightning miners, or builders and proposers speculate in transactions in Ethereum.

Some people have started experimenting with how to prevent provers from exploiting the data they obtain when generating proofs. In order to do this, the only way is to generate proofs on FHE (homomorphic encryption) data. They try to make something like zkFHE, in order to hide the data needed for proof generation, but FHE is very computationally expensive, so this increases the cost of the proof.

Like sending it into the sky, which doubles, triples, or even tenfolds the cost of proof. But they will say, no one is using my data, no one is extracting anything from my data. So, zkFHE will be born from the Proof market, which is an independent level of complexity, like a high level of complexity.

**BlockBeats: Currently the Proof market is compatible with ZKLLVM and Mina, I would like to know how the Proof market will generate proofs for different circuits in the future? **

Misha: Simply speaking, the process is as follows: an application carries a statement that needs to be proved, and this statement is compiled into bytecode or a virtual machine to power the Proof Market. This virtual machine is EVM. And then they come here with this requirement, saying I need to prove this statement. Proof Market is permissionless, and then a new circuit pair is deployed, which is how a new circuit pair is generated, and each new circuit is a new trading pair.

When the prover sees a need for a particular new claim, that new claim could be a sudden, ongoing need, a large one-off need, or a one-off but still interesting need. The prover can say, ok, I want to add this circuit to the list of circuits I care about, and I want to generate a proof for this circuit. Proof Market then makes the appropriate changes, generates and submits proofs. We’re working hard to make this process as simple as possible.

**BlockBeats: How is it implemented for different proof systems? **

Misha: This is a more interesting story. There is basically only one requirement for different proof systems to connect to the Proof market, which is to compile the verifier of this proof system into EVM bytecode. Since it is the EVM that powers the Proof marketplace, validators are compiled into the EVM. It might be written in Solidity, it might be Rust or C++.

If it’s written in Solidity, just deploy it; and if it’s written in Rust or C++, we’ll leverage zkLLVM to provide a toolchain that compiles verifiers from Rust and C++, so that zkLLVM can be used as a mainline A language-to-EVM compiler that can generate validators from Rust, C++, or other languages and deploy them to the Proof marketplace. Once deployed, the Proof marketplace supports verification of the new proof system. To that extent, it’s permissionless.

**BlockBeats: I remember you once said in a roundtable discussion about the decentralization process of Rollup, =nil; Foundation’s path is the opposite of most Rollups, which is to build a proof generation network first, and then decentralize the sorter change. So now, does the =nil; Foundation’s Proof marketplace have a chance to be a decentralized solution for these Rollup projects? **

Misha: I remember it was in Denver, when we were discussing market strategy from different directions, a lot of people developed a lot of applications that required zero-knowledge proofs, proof systems, and a lot of proofs internally, and then they encountered problems like this : We have developed the product, but it is not perfect, because it is not decentralized, the proof is not decentralized, but we do not have enough proof power, so we are stuck.

People have built products, but they feel like they’re stuck. On our side, we have built a technology stack to solve these problems, we can improve the market service, integrate it into the value chain, achieve decentralization and decentralization of proofs, and provide support for roll-ups. The way it works is that the verifiers for those roll-ups, need to get attestation from somewhere, and they themselves should be the attestors.

In some cases, the verifier may be unwilling, incapable, or otherwise unable to configure their own hardware, GPU, ASIC, etc. When you only have capital but no infrastructure, you need to get proof from somewhere. At this time, Proof Market It’s great, it provides proof for those who have the capital but don’t have the infrastructure or don’t want to own the infrastructure.

The second point is why I mentioned that we started in different directions, we set out to improve them from a decision-making perspective. People like 3rd party teams are trying to add a decentralized sorter on top of us, maybe someone will put a roll-up on top of the whole system, by then the tech stack will be complete and the whole system will be implemented Complete.

**BlockBeats: Finally, can Misha reveal =nil; what are the most important things in the Foundation’s roadmap for this year? **

Misha: We have two main directions. The first direction is verifiable applications. We must make these use cases public and let more people know about them. Some of these are already known, some are not so well known, and some are not even enabled yet, for example our zkLLVM use case requires a frontend built specifically for zkLLVM applications. This will make Drupal and zkLLVM useful for zkLLVM use cases and all those things.

Another example is that we want to help people who develop on top of us complete their projects, which will be some interesting things about zk games. Have you ever thought about playing a 3D third person shooter game on Ethereum, it’s not yet possible, but it will become possible, and this is how new use cases are enabled for the Proof marketplace and zkLLVM. Sometimes it’s quirky, sometimes it’s funny, and sometimes it’s genuinely useful.

The second big direction, we have to make this protocol decentralized and accessible to anyone, which will enable us to implement the decentralized sequencer use case, make the protocol accessible to everyone, try experiments, build on its foundation build something on it. We’ll see how things go, but we hope it works out. Because of the protocol we built for the Proof market, there is nothing like it in the market today.

Perhaps in addition to solving real problems, it will also be interesting because third-party developers can use it, because they can try some features that cannot be implemented elsewhere. So these are our two general directions: ensuring security and realizing decentralization.