Dialogue =nil; Foundation: From MEV to PEV, the market mechanisms bring innovative ideas for ZK proofs

Guest: Mikhail Komarov, co-founder of =nil; Foundation

Interview & Editing: Jack, BlockBeats

Translation: Kaori, 0x26, BlockBeats

Since the Montenegro EDCON in April, "ZK" has become one of the hottest buzzwords this year, expanding the narrative space brought by Ethereum to new heights. Many believe this will be a new market worth hundreds of billions of dollars, creating more opportunities and wealth stories, such as "ZK mining." Of course, ZK, as a new era that has yet to arrive, also means that many opportunities are difficult for us to identify accurately at present.

What the future of ZK will look like still requires more imagination. The Proof market built by =nil; Foundation has sparked my infinite fantasies about this hundred-billion-dollar era. Recently, I had an in-depth conversation with Mikhail Komarov (hereafter referred to as Misha), co-founder of =nil; Foundation, discussing topics related to =nil; Foundation, zkLLVM, and the Proof market.

Interview Summary

1. People using ZK for information compression is the most exciting "misuse" of this tech stack.

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

3. The phenomenon of PEV (Prover Extractable Value) has already emerged in the current Proof market.

4. The Proof market is not yet fully decentralized, which will be the team's focus in the near future.

=nil; Origin

Misha began his journey in the crypto industry in 2013, and the first thing he did after entering the space was to study the C++ implementation of Bitmessage. This was a Bitcoin messaging protocol that, despite being compromised several times later, drove many people wild at the time. Later, Misha began working on BitShares with Dan Larimer (BM, founder of Steemit, Bitshares, and EOS) and encountered Konstantin Lomashuk, who later created Lido. At that time, Konstantin had some Bitshares-related crypto projects and wanted to create a Steemit fork specifically for Russia, called Golos Network.

In 2016, Misha, as the CTO of Golos, embarked on a new journey with Dan and Konstantin. However, two years later, Misha grew tired of Golos, believing that Dan's designed products were unsatisfactory, with inappropriate internal architecture and insufficient quality. Thus, Misha left Golos and related projects like Steemit and co-founded Nil with Konstantin in April 2018.

Misha's initial idea was to prevent people from encountering the instability issues present in Golos and Steemit, such as inadequate data management, architecture, and security guarantees. Therefore, Nil's goal was to bring the achievements of the database management industry into the crypto space, enhancing reliability, security, and scalability in this field. Of course, Misha did not anticipate that his new journey would lead to the very center of the future scalability of the crypto world.

BlockBeats: Please briefly introduce your background, such as how you started your crypto career and why you joined the crypto industry?

Misha: That was a long time ago. I started getting into the crypto industry around 2013 when I was researching the C++ implementation of Bitmessage. You might remember that kind of Bitcoin-like messaging protocol that drove everyone crazy back then, although it was compromised several times later, it was very popular at the time.

Then I began developing everything around BitShares and Dan Larimer (BM, founder of Steemit, Bitshares, and EOS), and later I met Konstantin Lomashuk, whom you might know from Lido. At that time, he had some Bitshares-related crypto projects and wanted to create a Steemit fork specifically for Russia. So we built Golos, and I became the CTO in 2016, and we've been working together since then.

But in April 2018, I grew tired of Golos because Dan's designed products were unsatisfactory; they never ran for long periods. Although they did run, I felt the internal architecture was not suitable for me, and the quality was insufficient, so I left all projects related to Golos and Steemit and co-founded Nil in April 2018.

My initial goal was to prevent people from encountering the issues I faced on Golos and Steemit, such as inadequate data management, architecture, and security guarantees; everything was very unstable. I felt this was not a good solution, so I co-founded Nil with Kosta to bring the achievements of the database management industry into the crypto space, as this meant reliability, security, scalability, and so on. The subsequent story is the development journey of Nil.

BlockBeats: When did =nil; Foundation start focusing on zero-knowledge proofs?

Misha: Looking back, we realized some issues around 2020 when we completed the first DBMS (Database Management System) prototype. Honestly, before we tried to combine the database management system with the crypto industry, no one had really attempted to do this. When we completed this project, we realized that the trust assumptions were not what we wanted.

To make it work, everyone had to trust us, whether using our data or otherwise. We thought about how to reduce this distrust assumption and how to make it as trustless as possible. That was when we realized we might need some technology; we needed a cryptographic tool to achieve this goal, so we built a cryptographic suite for this purpose.

At that time, the industry was still in its early stages, without development environments like Arc Works, and we thought since there were theoretical concepts and some experiments, we had to give it a try. We built a suite and established our proof system. Then we collaborated with people from the Ethereum Foundation and the Mina Foundation to build a circuit compiler. To avoid generating proofs ourselves, we established a Proof market to introduce market dynamics into proof generation.

During the process of building the compiler with the Mina Foundation, we also collaborated with people from the Solana Foundation. In that process, we realized we needed state proofs, which were also something the Mina and Ethereum teams were seeking at that time. Around early 2021, while developing the necessary state proofs for the database management system, people from Mina, Ethereum, and Solana felt this was "zk Bridging." Because Justin Drake, Evan Shapiro, and Anatoly all believed we needed a more secure bridge technology, they said no matter what you call it, it is zkBridge.

BlockBeats: The crypto field has been researching and experimenting with zero-knowledge proofs for quite some time without significant progress. However, the development of the ZK field seems to have entered a boom this year. Why is that?

Misha: There are actually only two ways to apply zk technology. The first is obviously for privacy purposes, and the second is for compression, such as the scaling discussions everyone is having, with zk-Rollups, zk-Bridges, zk-MLS, zk-Oracles, etc. People are "misusing" this tech stack for compression, and I think this is the most exciting "misuse" I've seen. So the question is, why now? We could have accomplished this task years ago, and it might be due to several key technological milestones that made it usable, feasible, and interesting.

The first milestone was in 2016 when this technology became increasingly practical for the crypto industry. At that time, Rank-1 Constraint Systems (R1CSs) became quite common, and different applications began to emerge. Fundamentally, when it became feasible to protect privacy, this opened up possibilities. Projects like Zcash and Tornado Cash were born in that era, or at least the ideas for these projects were conceived during that time.

The second key period was between 2019 and 2021 when the technology underwent its second critical phase. During that time, Bloom filters became increasingly popular. People began building proof systems based on Bloom filters. We also had our proof system called Placeholder. Why was this period important? Because thanks to these Bloom filter-based proof systems, projects could utilize this tech stack for compression. It enhanced compression capabilities, making proper rollups scaling and achieving zkBridge in 2021 cheaper and more feasible.

Currently, we have made some progress in further developing proof systems and have achieved some breakthroughs in our projects. It can be said that writing complex mathematical constraints and computations in such a long-term shared information environment is quite challenging. Many people are tackling this issue, such as introducing STARKs and launching zkVM to address this complexity. We launched the zkLLVM compiler, which also simplifies application building. From 2019 to 2021, proof systems have been evolving, and there has been progress in tool development from late 2020 to early 2021 and then to late 2022. All these advancements have made constructing complex computational proofs efficient enough and economically viable.

Of course, the development of proof systems is far from over. To enable more application scenarios, there is still much work to be done in proof systems. For instance, perhaps this year or next, we will see the development of proof systems, and we are conducting related research and development. The evolution of these proof systems will make economically viable zkLLVM applications possible, and we hope to be the first team to achieve this goal. But in any case, everyone is currently working hard to enhance proof systems.

BlockBeats: You just mentioned zkLLVM, which is a compiler built for developers to create their own zk circuits. What do you think is the importance of zkLLVM, and how mature is the current product?

Misha: zkLLVM may not be the first, but it is indeed one of the earliest circuit compilers. I have seen some prototypes and some DSL projects before, but I haven't seen many fully functional circuit compilers that are not virtual machines. There are indeed some, but I'm not sure if anyone is really using them, which is why I think this is important. A considerable number of people in this industry are trying to escape the "not invented here" dilemma, which is very resource-intensive. It's clear that people will eventually create very good products, but this "not invented here" dilemma makes development time-consuming and costly.

For example, we are communicating via Zoom now, and almost all the software on our laptops is compiled with LLVM. We are just bringing all of this over and making it provable. So I think we are simply bringing the entire compiler ecosystem into the crypto industry, allowing these achievements to be reused in the crypto space for efficiency and economic viability. This also brings widely used programming languages. There are many software applications written in Rust, C++, Go, TypeScript, etc., and people may want to execute this software within Ethereum and in trustless environments.

One of my favorite examples is people obtaining the Doom source code (C/C++ source code), proving it to Ethereum via zkLLVM, and then showcasing it to each other to brag about their completion time. For instance, I completed the Doom speedrun challenge in 20 minutes, and here is the evidence along with your Ethereum NFT, proving you completed the Doom speedrun challenge in 20 minutes.

BlockBeats: What user groups are currently using zkLLVM, and what products have been created?

Misha: Many different types of projects are using these technologies. Some projects may just be building something in an attempt to deploy it, or they may already be running. The most obvious use case is zkBridge, which we built using the compiler, protected by its proof system. Perhaps this is also one of the reasons we recognized the necessity of the compiler and started building it. Others are trying to use it for formal verification of statements, not attempting to put the formal specifications of programs together, but compressing them into proofs by using the zkLLVM compiler for formal statements. In fact, people are indeed compiling compilers.

For example, in zkOracles applications, people have already established zkOracles to retrieve Ethereum historical data or Lido to ensure the security of Ethereum staking issuance. People are addressing the many trust assumptions that exist, even though it has been running for over two years. When we designed Lido in 2020, it was acceptable, but later we wanted to reduce trust assumptions because we couldn't risk exposing users' TVL to risk, so we decided to use ZK's proof of work to protect it. There are many other projects as well; to be honest, I could go on forever. Currently, I have about 80 projects in my CRM.

BlockBeats: =nil; Foundation previously received investments from L2 teams like StarkWare and Mina, as well as other VCs, with a valuation of over $200 million. Is this money used to establish the Proof market, and does the investment from StarkWare and Mina mean you will be more inclined to collaborate with specific ecosystems?

Misha: This is our first and only round of financing in five years because we didn't have this need before, and now it's time to do this. We have done enough prototyping, supported enough projects, and learned a lot. We feel strong and confident enough to launch products in the way we believe they should be built.

This round of financing was completed about a year ago, and we announced the news several months later than it actually happened. We only released the financing news when we felt comfortable discussing "this is what we are developing." Because once you raise funds, you start making commitments to each other, and then they will ask you what the purpose of the fundraising is, what you will deliver, what the product is, and whether anyone is using your product. So we deliberately delayed any discussions on this topic until we had at least done something.

We are indeed collaborating with the entire ecosystem of Mina and Starkware, and there are already many applications from the Mina ecosystem that are either built on our foundation, built with us, or collaboratively developed with us. Recently, the Mina team has started researching and developing roll-ups, for which they need a lot of validation capacity. Additionally, in 2021, we built state proof validation with Mina based on the compiler, which is another Mina ecosystem project we are collaborating on.

A lot has also happened in our collaboration with the Starkware ecosystem. Of course, this is the purpose of our collaboration, so that we can also be useful for provable applications in the Starknet ecosystem. For example, several bridging projects connected to Starknet are using our tech stack to become zero-knowledge proof bridges. Several gaming projects have told us they need validation capacity.

There are also some other projects trying to use old bridging technologies, leveraging state proof validation and building Ethereum applications on top of that. Some people are building L3 on StarkNet, and they say having validation capacity would be a good option. In short, this is why we are coming together with them. Honestly, I am satisfied with this partnership.

The Secondary Market for ZK Proofs

Zero-knowledge proofs (ZK Proofs) are the absolute core of the current ZK field in the crypto market, providing infinite possibilities for many scenarios like ZK Rollup and zkEVM. However, generating a ZK proof is also a heavy computational task, often taking hours to complete a single proof, which is why most sorters still have not solved the centralization issue. To generate ZK proofs reliably and cost-effectively, we not only need to develop and maintain computational infrastructure but also need to scale it. In Misha's view, introducing market mechanisms is the optimal solution to this problem.

The =nil; 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 the generation of the required ZK proofs, and a professional network of producers will respond to such requests.

BlockBeats: Now let's talk specifically about the Proof market. Where did the idea come from, and what is the story behind it?

Misha: The idea originated from our extensive involvement in various protocol applications and Filecoin-related matters from 2020 to the end of 2021. At that time, we not only witnessed the crazy phenomena surrounding Filecoin but also participated from our perspective. We learned how to handle all proof systems correctly, how to conduct proper arguments, etc., and implemented a Filecoin prover that was ten times faster than the public version, allowing miners to fully utilize their hardware. We were essentially a hub witnessing all the experiments attempting to reduce costs from the miners' perspective.

During that time, we learned a lot of practical market data, such as how valuable it is to generate this specific proof with this hardware and how long it takes; who uses what hardware, which data centers are built for this, and so on. Then, when collaborating with the Ethereum Foundation, Mina Foundation, and many other foundations, we found that these state proofs and consensus proofs were very burdensome, and we absolutely would not let anyone prove these evidences themselves.

Because, to be honest, no one has the hardware to generate them quickly because they are too massive. For example, with Mina's consensus, Mina's state proof is the policy investor curve multiplied by about $35 billion, which is quite a lot. Or Solana's consensus proof, which, among other things, contains about 4,000 ECDSA signatures, and generating it takes a lot of time.

When we noticed this, we decided not to do it anymore. We thought, okay, we will outsource this work. We will build a market for it because we already had a lot of data related to Filecoin, so let's build a market, commoditize it, apply market dynamics to it, and allow people to compete with each other under the coordination of decentralized protocols, so we no longer become this hub but let the protocol be the hub. It turned out that our idea was correct. Now everyone is building Proof markets, and we guessed the direction right.

BlockBeats: When building the Proof market, did you consider its dynamic relationship with zkLLVM, which you have already built?

Misha: Initially, these two projects were actually separate; they were two independent things. For example, we just needed to build a toolchain for circuits because we wouldn't manually build them; that was too large. Then we found that others also needed this toolchain, so we decided to open-source it for everyone to use.

The Proof market was also a separate thing because we thought it was just a proof generation market. We didn't even think about people trying to speculate with proofs. They were actually trying to do things like buy low and sell high, which is quite absurd because it shouldn't be like that, but anyway, that is the reality.

The protocol supporting the Proof market must be a very special protocol because we need a lot of validation and need to handle a significant load regarding this aspect. When people come with data that needs validation, we need to process a lot of data because they will load the data into the orders of the Proof market, making the protocol very data-intensive, such as the amount of data describing the average state proof. Once, a carefully completed average state proof description required about 2GB of data; try to find a protocol that can handle 2GB of data. It's almost impossible.

But later, people began using zkLLVM to prove some very large things, which, compared to what people do in Solidity, like Ross and C++ codebases, is quite large. So we put them together, made them interrelated, and then offered them as a usable service. We still believe that the compiler performs quite well in terms of efficiency and hope to maintain that.

BlockBeats: What are the main user groups and participants in the Proof market currently?

Misha: The first type of users is mainly zkBridge, where some consensus proofs and state proofs are quite burdensome to generate. If you generate a correct and secure validation like building Ethereum's consensus proof, for example, using complete Ethereum consensus validation and validating all 100,000 node signatures, it will take you some time to generate.

The second type is zk oracles, such as applications that need to access Ethereum historical data or process Ethereum data in a specific way and then use it with EVM. Some applications are trying to reduce their gas costs this way, like lending protocols trying to calculate and load the risk parameters of their collateral assets into EVM, but they cannot compute it cost-effectively in EVM.

They obtain all necessary Ethereum data from different trading platforms and indices, put it into EVM, and then use it as a set of risk parameters for collateral. This is like another oracle for Lido, demonstrating how protocols can enhance their security and reduce execution costs by outsourcing a series of computations (like just the security in the Proof market and zkLLVM). Undoubtedly, zero-knowledge oracles are very important.

The third type is Rollups, which can use this technology, whether existing Rollups or newly created ones, and some are already trying to do so. All those intending to become Rollup validators will come with a desire to implement some proof in the Proof market. For validators, handling specialized hardware and running nodes on rented AWS servers is very challenging. In fact, AWS currently does not provide ATX or very powerful GPUs, so basically, validators will come with these zkLLVM use cases. It's clear that we already have some zkLLVM use cases, but I must admit they are not yet in production.

For large models or very complex models, zkLLVM use cases are also very applicable because they need to prove the complexity of the models they have on hand. This is also something currently in progress, but again, I emphasize that it is not yet in production; it is still in the experimental stage. Once in production, we will be able to turn the Proof market into a provable AI computing market, which sounds absurd.

BlockBeats: If I want to become a proof generator in the Proof market, what qualifications do I need?

Misha: There aren't too many requirements or restrictions to become a proof generator; it entirely depends on the specific circuit and statement you want to prove. We have specifically set up something called the "Proof Market Toolchain," where proof generators only need to start it as a service when handling various proofs in the market or run it as a background process on their machines.

If there is no better hardware supply for specific statements, specific circuits, specific applications, and specific proofs in the market, then you can take orders and generate proofs. If you have the best hardware and can make the fastest proof generation commitment without better competitors, you can take orders, generate proofs, and earn rewards.

BlockBeats: All users using =nil; Foundation need to register an account. If the generated proofs themselves or their transaction and ownership information are stored on private servers, will this introduce some centralization issues?

Misha: This is precisely the problem we plan to solve by the end of the year. Yes, currently the market proofs are not that decentralized; we have not yet released the protocol nodes that support it, nor have we publicly discussed this protocol. The current operation is as follows: there are a few validators who also participate in Lido and serve as validator operators, and we can temporarily host it to see how it goes. Then we will distribute the source code to them, and there are actually six to eight running in test mode.

Currently, the system is somewhat decentralized, but it is not public and has not truly achieved decentralization. Not everyone can join and run their Proof Market nodes. This is also a problem for us; we like those applications that ask us about security and the degree of decentralization. They ask us if they can rely on it? Is this something we can use right now? I answer yes, you can, but it is not decentralized enough because we are running it in test mode. We will work hard to solve this problem, which is also our most important task at the moment.

BlockBeats: What measures have you taken to address these issues?

Misha: First, we designed a market proof based on decentralized protocols, using a certain decentralized protocol from the start. We discussed several deployment and operation schemes, and we tried to deploy it directly on Ethereum, but when calculating the economic feasibility of computation, we found that doing so would require about $2.5 billion in Ethereum fees annually. Therefore, running market proof on Ethereum is financially infeasible.

Next, we tried to run it on technologies like Rollup. However, despite trying several different Rollups, the costs remained high. When we calculated the costs required to run market proof and conduct arbitrage, we found that just for market proof, it would cost $250 million annually, which is quite a high cost. Therefore, we had to propose our own protocol that can handle load, cost, data density, and other issues.

Our goal is to make this protocol as close to Ethereum's security 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 the load to be handled during serialization is fundamentally the same. People want to reduce the latency between sorters and proof generators so that they can immediately send data to proof generators to win blocks.

How to deploy sorters on top of this protocol is also one of our current main focuses. We hope to establish a platform that third-party developers can use, allowing anyone to start and run nodes that support this protocol. And ensure that market proof applications are as secure in code deployment as Ethereum.

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

Misha: We certainly prefer to use various tokens to pay for proofs, so we cannot force everyone to use a specific token, which means we must remain as neutral as possible regarding tokens, just as we remain neutral regarding any products and applications. For example, it is likely to operate similarly to how Arbitrum operates with Ethereum; you can have both Ethereum and Arbitrum, so why not?

The first step in this direction is undoubtedly the approval market for EVM endpoints, which we deployed a few days ago. This is a payment solution that allows all Ethereum-deployed assets to serve as incentives for approvers in the Proof market or for applications willing to pay with their tokens in the Proof market. This is the first step toward this direction.

The Whims of the Proof Market

Since it is a market, there will inevitably be variability and complexity that cannot be predicted or controlled. Whether people will speculate on ZK proofs and how they will do so are important data that the team needs to monitor and record. After several months of practical testing, what interesting phenomena have emerged in the Proof market? What are the team's future plans?

BlockBeats: Will introducing market mechanisms extend the proof generation process time?

Misha: Auctions or finding the best bidder for the job do take some time; it may not be a few seconds on our side but rather a few moments. Generally speaking, this process takes a few moments, most of the time less than a second. In my view, the supply-demand relationship is quite rich, so this will indeed introduce some delays of less than a second.

Even a delay of less than a second, in the worst-case scenario, I have seen the worst case where an application could not find a supplier within three to four seconds. But even so, this delay is not comparable to the overall proof generation time. So I think this is not a concern compared to the collective generation advantages brought by market dynamics.

BlockBeats: If someone wants to speculate on the generated proofs, is that a good thing or a bad thing? Will the team intervene in this?

Misha: A lot of strange things have happened on our site; the thing I just mentioned is not the strangest one. Even stranger things have happened in the Proof market, but let's first talk about the speculation issue. We have not controlled this because we cannot control it. Once we push this project to the public, once we make this protocol available to everyone, allowing everyone to run it weekly, perhaps as a rollup or in other ways, we will no longer be able to control everything.

We are currently trying not to interfere or attempt to do anything because at some point we will no longer be able to do so, so what is the point? So let’s speculate. People can build applications similar to circuits, like provable applications, and that’s basically it, so speculation is even feasible. Besides speculating in the Proof market, there are no other uses.

One of the strangest use cases I have seen is someone trying to trade futures for computational power and then discussing speculation with those futures. It's like Bitcoin's hash rate futures, but the same goes for zk proofs. Have you ever thought about MEV? What if I told you there is actually a Prover Extractable Value (PEV)?

It works in a way where applications bring some data, and then something needs a proof, and the provers come to complete it. They bring data and start generating proofs, and everything goes as expected. But at the same time, if a prover tries to earn more profit or similar behavior on this data, they will use this data elsewhere, such as on Ethereum or other protocols, or even on some Rollup.

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 value proofs, such as people trying to predict when proofs 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 into it. This way, the prover can sell, or the buyer can guess the price to extract value, just like flash miners or builders and proposers speculating on transactions in Ethereum.

Some people have already started trying to prevent provers from exploiting the data they obtain when generating proofs. To do this, the only way is to generate proofs on FHE (Fully Homomorphic Encryption) data. They are trying to create something like zkFHE to hide the data required for proof generation, but FHE is very computationally intensive, so this increases the cost of proofs.

It's like sending it to the sky, which can double, triple, or even increase the proof cost tenfold. But they would say, no one is exploiting my data, and no one is extracting anything from my data. So zkFHE will emerge from the Proof market, which is an independent layer of complexity, like a high-level complexity.

BlockBeats: Currently, the Proof market is compatible with zkLLVM and Mina. I wonder how this Proof market will generate proofs for different circuits in the future?

Misha: Simply put, the process is as follows: an application comes with a statement that needs proof, and this statement is compiled into bytecode or a virtual machine that powers the Proof Market, which is the EVM. Then they come here with this demand, saying they need to prove this statement. The Proof Market is permissionless, and then a new circuit pair will be deployed; this is how a new circuit pair is generated, with each new circuit being a new trading pair.

When provers see a specific new statement in demand, this new statement may suddenly appear, may be a continuous demand, or may be a one-time large demand, or a one-time but still interesting demand. Provers can say, okay, I want to add this circuit to my watchlist, and I want to generate proofs for this circuit. Then the Proof Market will make corresponding changes to generate and submit proofs. We are working to improve this process to make it as streamlined as possible.

BlockBeats: How is it implemented for different proof systems?

Misha: This is a more interesting story. The requirement for different proof systems to connect to the Proof market is basically just to compile the verifier of this proof system into EVM bytecode. Since EVM powers the Proof market, the verifier must be compiled into EVM. It may be written in Solidity or in Rust or C++.

If it is written in Solidity, you just need to deploy it; if it is written in Rust or C++, we will leverage zkLLVM to provide a toolchain for compiling verifiers from Rust and C++ so that zkLLVM serves as a compiler from mainstream languages to EVM, which can generate verifiers from Rust, C++, or other languages and deploy them to the Proof market. Once deployed, the Proof market supports the new proof system verification. To this extent, it is permissionless.

BlockBeats: I remember you mentioned in a roundtable discussion about the decentralization process of Rollups. The path of =nil; Foundation is the opposite of most Rollups, first building a proof generation network and then decentralizing the sorters. So now, does =nil; Foundation's Proof market have the opportunity to become a decentralized solution for these Rollup projects?

Misha: I remember it was in Denver when we discussed market strategies from different directions. Many people developed many applications that internally required zero-knowledge proofs, proof systems, and a lot of proofs, and then they encountered this problem: we have developed products, but they are not perfect because they have not achieved decentralization, and the proofs have not achieved decentralization, but we do not have enough proof capacity, so they are stuck.

People have developed products, but they feel trapped. On our side, we have built a tech stack to solve these issues; we can improve market services, integrate them into the value chain, achieve decentralization, and decentralize proofs to support roll-ups. It works in such a way that those roll-up validators need to obtain proofs from somewhere, and they themselves should also be provers.

In some cases, validators may be unwilling, unable, or unable to configure their hardware, GPUs, ASICs, etc., due to other reasons. When you only have capital but no infrastructure, you need to obtain proofs from somewhere, and this is where the Proof Market shines, providing proofs for those with capital but no infrastructure or who do not want to own infrastructure.

The second point is the reason I mentioned we approached it from different directions. We are improving them from a decision-making perspective. People like third-party teams are trying to add decentralized sorters on top of our foundation; perhaps someone will add a roll-up on top of the entire system, and by then, the tech stack will be complete, and the whole system will be perfected.

BlockBeats: Finally, Misha, can you reveal what the most important things on =nil; Foundation's roadmap are this year?

Misha: We mainly have two major 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 very well known, and some are not even enabled yet, such as our zkLLVM use cases that need a frontend built specifically for zkLLVM applications. This will make Drupal and zkLLVM useful for zkLLVM use cases and all these things.

Another example is that we hope to help those developing on our foundation complete their projects, which will involve some interesting things about zk games. Have you ever thought about playing a 3D third-person shooter on Ethereum? It is currently not feasible, but it will become feasible, and this is how we enable new use cases for the Proof market and zkLLVM. Sometimes it is quirky, sometimes it is interesting, and sometimes it is genuinely useful.

The second major direction is that we must decentralize this protocol and make it accessible to everyone, which will enable us to achieve decentralized sorter use cases, allowing everyone to access the protocol, experiment, and build something on top of it. We will see how things develop, but we hope it will succeed. Because the protocol we built for the Proof market has nothing like it on the market.

Perhaps, aside from solving practical problems, it will also become interesting because third-party developers can use it to try some functionalities that cannot be achieved elsewhere. So these are our two major directions: ensuring security and achieving decentralization.