Since the Black Mountain EDCON in April, "ZK" has become the hottest word of the year, expanding the narrative space brought by Ethereum to new heights. Many people believe that this will be a new market worth 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 present. What ZK will be like in the future still requires more imagination. The Proof market built by the =nil; Foundation has sparked my infinite imagination for this billion-dollar era.

Recently, I had a deep conversation with Mikhail Komarov (referred to as Misha), co-founder of the =nil; Foundation, discussing topics related to the =nil; Foundation, zkLLVM, and the Proof market.

Interview Summary

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

2. The generation of ZK proofs should be outsourced to manufacturers who provide such professional services, and a professional manufacturer network should be established to respond to market demands.

3. In the current Proof market, the phenomenon of PEV (Proof Extractable Value) has emerged.

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

=nil; Origin

Misha has been involved in the cryptocurrency industry since 2013. The first thing he did after entering the industry was to study the C++ implementation of Bitmessage. This is a Bitcoin messaging protocol that was very popular at the time, despite being hacked several times later on. Later, Misha started working on development projects around BitShares with Dan Larimer (also known as BM, the founder of Steemit, Bitshares, and EOS), and in the process, he met Konstantin Lomashuk, who later created Lido. At that time, Konstantin had some cryptocurrency projects related to Bitshares and wanted to create a fork of Steemit specifically for Russia, called Golos Network.

This was in 2016 when Misha, as the Golos CTO, embarked on a new journey with Dan and Konstantin. However, two years later, Misha became tired of Golos. He believed that the product designed by Dan was unsatisfactory, with an inappropriate internal architecture and insufficient quality. As a result, Misha left Golos and related projects such as Steemit, and founded Nil with Konstantin in April 2018.

Misha's initial idea was to solve the instability issues that exist on Golos and Steemit, such as inadequate data management, architecture, and security. Therefore, the goal of Nil is to introduce the achievements of the database management industry into the encryption industry, bringing more reliability, security, scalability, and other benefits to this field. Of course, what Misha did not anticipate was that his new journey would lead him to the very center of the future expansion of the encryption world.

BlockBeats: Please briefly introduce your background, such as how you started in the encryption industry, and why you decided to join the industry?

Misha: That was a long time ago. I started getting involved in the encryption industry around 2013, when I was researching the C++ implementation of Bitmessage. You may remember that at the time, everyone was crazy about that kind of messaging protocol similar to Bitcoin, although it was later hacked several times, it was still very popular at the time.

Then I started developing around everything BitShares and Dan Larimer (aka BM, founder of Steemit, Bitshares, and EOS), and later I met Konstantin Lomashuk, who you may now know because of Lido. At that time, he had some crypto projects related to Bitshares and wanted to create a Steemit fork specifically for Russia. So we created Golos, and I became the CTO in 2016. Since then, we have been working together.

However, in April 2018, I became tired of Golos because I was dissatisfied with the product designed by Dan. His products had never run for a long time, although they were indeed running. I thought the internal architecture was not suitable for me and the quality was not good enough. Therefore, I left all projects such as Golos and Steemit and founded Nil in April 2018.

My initial goal was to prevent people from encountering the same issues I faced on Golos and Steemit, such as inadequate data management, architecture, and security, all of which were very unstable. I didn't think this was a good solution, so Kosta and I founded Nil with the aim of bringing the achievements of the database management industry into the encryption industry, because this means reliability, security, scalability, and so on. The rest of the story is the development process of Nil.

BlockBeats:=nil; Foundation started paying attention to zero-knowledge proofs at what time?

Misha: Looking back, we realized some issues when we completed the first prototype of a DBMS (database management system) around 2020. To be honest, before we attempted to combine a database management system with the encryption industry, no one had really tried to do so. When we completed this project, we realized that the trust assumption was not what we wanted.

If we want to make it work, whether using our own data or other aspects, everyone must trust us. We are thinking about how to reduce this assumption of distrust and make it as trustless as possible. Then we realized that we might need to use some kind of technology, and we need 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 of development, and there were no development environments like Arc Works. We thought that since there were theoretical concepts and some experiments, we had to give it a try. We built a suite and established our own proof system. Then we collaborated with people from the Ethereum Foundation and Mina Foundation to build a circuit compiler. In order to avoid generating proofs ourselves, we established a Proof market to introduce market dynamics into proof generation.

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

BlockBeats: In the field of cryptography, zero-knowledge proofs have been studied and attempted for quite some time without significant progress. However, this year, the development of the ZK field seems to have entered a state of explosive growth. Why is this?

Misha: There are actually only two ways to apply the entire zk technology. The first method is obviously for privacy purposes, and the second method is for compression, such as the scalability issue that everyone is talking about. This has led to the emergence of zk-Rollups, zk-Bridges, zk-MLS, zk-Oracles, etc. People have "misused" this technology stack for compression, which I think is the most exciting "misuse" I have ever seen. So the question is, why now? We could have completed this task several years ago, but it may be several key technological milestones that have made it a viable, feasible, and interesting use case. The first milestone was in 2016, when this technology became increasingly practical for the encryption industry. At that time, the Rank-1 Constraint System (R1CSs) became quite common, and different applications began to emerge.

Fundamentally, this became possible when it became feasible to protect privacy. For example, projects like Zcash and Tornado Cash were born in that era, or rather, the ideas for these projects were born in that era. The second key period for this technology was between 2019 and 2021. At that time, blunt argumentations became increasingly popular. People began building proof systems based on Bloom filters. We also have our own proof system called Placeholder. Why is this period important? Because thanks to these Bloom filter-based proof systems, the project was able to use this technology stack for compression. It improved compression functionality, making it cheaper and more feasible to perform appropriate Rollups expansion and implement zkBridge in 2021.

Currently, we have made some progress in further developing proof systems, and have also made some breakthroughs in our projects. It can be said that writing complex mathematical constraints and calculations in such a long-term shared information environment is quite challenging. Many people are working on this issue, such as the introduction of STARK and the zkVM, which was launched to solve this complexity problem. We have also introduced the zkLLVM compiler, which makes building applications easier. From 2019 to 2021, the proof system has been developing, and from the end of 2020 to early 2021 and until the end of 2022, tool development has also progressed. All of these developments have made building complex computing proofs efficient and economically feasible. Of course, the development of proof systems is far from over. To achieve more application scenarios, there is still much work to be done. For example, perhaps this year or next year, we will see the development of proof systems, and we are also conducting related research and development. These developments in proof systems will make economically feasible zkLLVM applications possible, and we hope to be the first team to achieve this goal. However, everyone is currently working hard to improve the proof system.

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 certainly one of the earliest circuit compilers. I have seen some prototypes and DSL projects before, but I haven't seen many complete circuit compilers with full functionality instead of virtual machines. There are some, but I'm not sure if anyone is really using them, so that's why I think this is important. And many people in this industry are working hard to get rid of the "not invented here" dilemma, which is very energy-consuming. Obviously, people will eventually create very good products, but this "not invented here" dilemma makes development time-consuming and expensive.

For example, we are currently communicating through Zoom, and almost all of the software on our laptops is compiled using LLVM. We just took all of this and made it provable. So I think we just brought the entire compiler ecosystem into the encryption industry, allowing these achievements to be reused for efficiency and economic viability in the encryption field. This also brings about the widespread use of programming languages. There are many software programs written in Rust, C++, Go, TypeScript, and other languages that people may want to execute within Ethereum and in trustless environments. My favorite example is when people obtain the Doom source code (C/C++ source code), prove it to Ethereum through zkLLVM, and then drag it between each other to show off the time they completed it in. For example, I completed the Doom speed challenge in 20 minutes, and here is the evidence and your Ethereum NFT to prove that you completed the Doom speed challenge in 20 minutes.

BlockBeats: What are the user groups currently using zkLLVM, and what are the products created roughly?

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 zkBridge, which we built using a compiler to protect the proof system. Perhaps this is also one of the reasons why we recognized the necessity of a compiler and started building it. Some people are also trying to use it to prove the form verification of statements, compressing them into proofs by using the zkLLVM compiler instead of trying to put the formal specification of programs together with them. In fact, people are indeed compiling compilers. For example, in the zkOracles application, people have built zkOracle to retrieve historical data from Ethereum or Lido to ensure the security of Ethereum's staking issuance. People are solving the problem of many trust assumptions, even though it has been running for more than two years. When we designed Lido in 2020, this was acceptable, but later we wanted to reduce trust assumptions because we couldn't risk users' TVL being at risk, so we decided to use ZK's work proof to protect it. In addition, there are many other projects, to be honest, I can go on forever. Currently, I have about 80 projects in CRM.

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

Misha: This is our first and only round of financing in the past five years, as we did not have this need before, but now it is time to do so. We have done enough prototype designs, supported enough projects, learned a lot, and we feel strong and confident enough to launch the product in the way we believe it should be established.

This round of financing was completed about a year ago, and we announced the news several months later than the actual occurrence time. We didn't release the financing news until we felt comfortable talking about "what we developed". Because when you raise funds, you will start to promise each other things, and then they will ask you what is the purpose of raising funds, what do we need to deliver? What is the product? Is anyone using your product? So we deliberately postponed any discussion on this topic until we had done something at least. We are indeed collaborating with the entire ecosystem of Mina and Starkware teams, and there are currently many applications from the Mina ecosystem, either built on our foundation, built with us, or built in collaboration with us. Recently, Mina's team started researching and developing roll-ups, for which they need a lot of verification capabilities. In addition, in 2021, we worked with Mina to build state proof verification based on compilers, which is another Mina ecosystem project we worked on together.

There have been many things happening in our collaboration with the Starkware ecosystem. Of course, this is the purpose of our partnership, so that we can also be useful for the provable applications in the Starknet ecosystem. For example, several bridging projects connected to Starknet use our technology stack to become zero-knowledge proof bridges. Several gaming projects have told us about their need for verification capabilities.

There are other projects that attempt to use old bridging technologies, utilizing state proofs for verification and building Ethereum applications on top of them. Some are building L3 on StarkNet, and they say having verification capabilities would be a good choice. In any case, this is the purpose of us coming together with them. To be honest, I am satisfied with this partnership.

ZK Proof Secondary Market

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

=nil; The Foundation team believes that generating ZK proofs should be outsourced to manufacturers who specialize in providing such services. In this context, we need a Proof market where anyone can request the generation of the required ZK proof, and a professional manufacturer network 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: This idea originated from our extensive participation in protocol applications and various Filecoin-related matters from 2020 to the end of 2021. At that time, we not only witnessed the frenzy surrounding Filecoin, but also participated in it from our perspective. We learned how to properly handle all proof systems, how to make appropriate arguments, and implemented a Filecoin prover that was 10 times faster than the public version, allowing miners to fully utilize their hardware. We were actually a hub that witnessed all experiments attempting to reduce costs from the perspective of miners. During that time, we learned a lot of practical market data, such as the value of generating a specific proof with this hardware and how long it takes; which people use which hardware, which data centers are built for this purpose, and so on. When working with the Ethereum Foundation, Mina Foundation, and many other foundations, we found that these state proofs and consensus proofs are very heavy, and we will never let anyone prove these proofs themselves.

To be honest, no one has this kind of hardware that can quickly generate it because they are too large. 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 Solana's consensus proof, in addition to other content, it also contains about 4,000 ECDSA signatures, which takes a lot of time to generate.

When we noticed this, we decided to stop doing it. We thought, okay, we'll outsource this work. We'll create a market for it, because we already have a lot of data related to Filecoin. Let's turn it into a commodity and apply market dynamics to it, so that people can compete with each other under the coordination of a decentralized protocol. This way, we won't be the hub anymore, but the protocol will be. The results proved that our idea was correct. Now everyone is building Proof markets, and we guessed the right direction.

BlockBeats: Have you considered the dynamic relationship between Proof market and zkLLVM that you have already built when constructing the Proof market?

Misha: Initially, these two projects were actually separate and independent entities. For example, we just needed a toolchain to build circuits because we couldn't build it manually, it was too big. Then we found out that other people also needed this toolchain, so we decided to open source it so that everyone could use it.

And the Proof market is also a separate entity, as we believe it is only a proof generation market. We never even thought people would try to speculate with proofs. They are actually trying to buy low and sell high, which is quite absurd because it shouldn't be like this, but anyway, that's the fact. The protocol that supports the Proof market must be a very special protocol because we need a lot of verification and need to deal with a lot of load about 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 orders of the Proof market, which makes the protocol very data-intensive, such as the amount of data describing the average state proof. Once a carefully crafted average state proof description required about 2GB of data, try to find a protocol that can handle 2GB of data. This is almost impossible.

However, later on, people started using zkLLVM to prove some very large things, which are considered much larger than what people do in Solidity, such as Ross and C++ code libraries. So we put them together, let them relate to each other, and then use them as a usable service. We still believe that the compiler performs quite well in terms of efficiency and hope to maintain this situation.

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

Misha: The first type of users are mainly zkBridge, some consensus proof, state proof generation is quite heavy. If you generate correct and secure verification like building Ethereum consensus proof, for example, using complete Ethereum consensus verification and all 100,000 node signature verifier verification, it will take you some time to generate.

The second type is zk oracle, such as applications that require access to Ethereum historical data or process Ethereum data in a specific way and use it with EVM. Some applications attempt to reduce their gas costs in this way, such as lending protocols attempting to calculate and load their collateral asset risk parameters into the EVM, but they cannot calculate it in the EVM in terms of cost.

They obtain all necessary Ethereum data from different trading platforms and indices, and put it into the EVM as a set of risk parameters for collateral. This is like another type of Lido oracle, demonstrating how the protocol improves its security and reduces execution costs by outsourcing a series of calculations (such as security in Proof markets and zkLLVM). There is no doubt that zero-knowledge oracles are very important.

The third type is Rollup. Existing Rollups or newly created Rollups can use this technology, and some are already trying to do so. Anyone planning to become a Rollup validator will come with a desire to prove something in the Proof market. For validators, dealing with specialized hardware and running nodes on leased AWS servers is very challenging. In fact, AWS currently does not provide ATX or very powerful GPUs, so validators will basically come with these zkLLVM use cases. It is clear that we already have some zkLLVM use cases, but I must admit that they have not yet been put into production.

For large or very complex models, zkLLVM use cases are also very suitable because they need to prove the complexity of their models. This is also what is currently being done, but it is emphasized again that it has not yet been put into production and is only in the experimental stage. Once put into production, we will be able to turn the Proof market into a provable AI computing market, which sounds absurd.

BlockBeats: What are the requirements for me to become a proof generator in the Proof market?

Misha: Becoming a proof generator doesn't actually have many requirements or limitations, it all depends on the specific circuit and statement you want to prove. We have specifically created something called the "Proof Market Toolchain" for proof generators to use when dealing with various proofs in the market. All you need to do is start it as a service or run it as a background process on your machine.

If there is no better hardware supply for specific statements, specific circuits, specific applications, and specific proofs in the market, you can take the order and generate the proof. If you have the best hardware, if you can make the promise of the fastest proof generation, and there are no better competitors, you can take the order, generate the proof, and get the reward.

BlockBeats: Do users of =nil; Foundation need to register an account? If the generated proof or its transaction and ownership information are stored on a private server, will it introduce some centralization issues?

Misha: This is exactly the problem we plan to solve by the end of the year. Yes, the current market has not proven to be as decentralized as we thought. We have not yet released protocol nodes that support it, nor have we publicly discussed this protocol. Currently, several people who are also involved in Lido and serve as validators and validator operators act as validators. We can temporarily host it and see how it goes. Then we distribute the source code to them, and in fact, six to eight are 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 node. This is also a problem for us. We like those who ask us about the security and decentralization of the application, and they ask us if they can rely on it. Can we use it now? I answered, 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 currently our most important task.

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

Misha: First of all, we designed a proof of market based on a decentralized protocol, and we used a certain decentralized protocol from the beginning. We discussed several deployment and operation plans, and we tried to deploy it directly on Ethereum. However, when calculating the economic feasibility, we found that it would cost about $2.5 billion in Ethereum fees annually, which is financially unfeasible to run proof of market on Ethereum. Then, we tried to run it on technologies like Rollup. However, despite trying several different Rollups, the cost is still high. When we calculated the cost required to run proof of market and arbitrage, we found that it would cost $250 million annually just for proof of market, which is also a considerable cost. Therefore, we had to propose our own protocol that can handle issues such as load, cost, and data intensity.

Our goal is to make this protocol as secure as Ethereum, as there is no other way for applications to rely on it. This protocol has also proven to be very useful for operations such as serialization, as the payload to be processed is basically the same. People hope to reduce the delay between sorters and verifiers so that they can immediately send data to verifiers and win blocks.

How to deploy the sorter on top of this protocol is also one of our main focuses at the moment. We hope to establish a platform that can be used by third-party developers, allowing anyone to launch and run nodes that support this protocol. And ensure that the market-proven application is as secure as Ethereum in terms of code deployment.

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

Misha: Of course, we are more inclined to use various tokens to pay for proof, so we cannot force everyone to use a specific token. This means that we must remain neutral towards tokens as we do with any product or application. For example, it is likely to operate similar to Arbitrum and Ethereum, where you can have both Ethereum and Arbitrum, so why not?

The first step towards this direction is undoubtedly the EVM endpoint approval market, which we deployed a few days ago. This is a payment solution that allows all assets deployed on Ethereum to be used as incentives for approvers in the Proof market or for applications willing to pay their own tokens on the Proof market. This is the first step towards this direction.

Proof Market's Wonderful Ideas

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

BlockBeats: Will introducing market mechanisms prolong the proof generation process?

Misha: Auctioning or finding the most suitable bidder for this job does require some time, which may not be just a few seconds on our end, but rather a few moments. Typically, this process takes a few moments, usually less than a second. In my opinion, the supply and demand relationship is quite abundant, so this does introduce some delay of less than a second.

Even a delay of less than one second, in the worst case scenario that I have seen, the application was unable to find a supplier within three to four seconds. But even so, this delay cannot be compared to the overall proof generation time. Therefore, I believe that compared to the collective generation advantage brought by market dynamics, this is not a problem worth worrying about.

BlockBeats: Is it a good thing or a bad thing if someone wants to speculate through generated proofs? Will the team intervene in this?

Misha: A lot of strange things have happened on our website, and the one mentioned earlier is not the strangest. Even stranger things have happened in the Proof market, but let's talk about speculation first. We have no control over 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 once a week, perhaps as a rollup or in other ways, we will no longer be able to control everything.

We are now working hard not to interfere, not to try to do something, because at some point we will no longer be able to do so, so what's the point? So let's speculate. People can build an application similar to a circuit, like a provable application, basically that's it, so speculation is even feasible. There is no other use except for speculation in the Proof market.

One of the strangest use cases I've seen is someone attempting to trade futures for computing power and then discussing speculation with those futures. It's like hash rate futures for Bitcoin, but the same goes for zk proofs. Have you ever thought about MEV? And if I told you that there's actually another way for a prover to extract value (PEV)?

Its working principle is not like an application that brings some data and then something needs proof, and the proofers come to complete it. They bring data, start generating proofs, and everything goes as expected. But at the same time, if a proofer tries to earn more profit or similar behavior on these data. They will use this data elsewhere, such as on Ethereum or other protocols, or even on some Rollups.

Their goal is to extract value from this data as much as possible, rather than using it to generate proofs. There are other 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 APIs. This allows proof makers to sell, or buyers to speculate on prices to extract value, just like lightning miners, or builders and proposers trading in Ethereum. Some people have started trying to prevent proof makers from using the data they have obtained when generating proofs. The only way to do this is to generate proofs on FHE (homomorphic encryption) data. They are trying to create something like zkFHE to hide the data needed to generate proofs, but FHE is very computationally expensive, so this increases the cost of proofs.

Just like sending it to the sky, this will increase the cost of proof by two, three, or even ten times. But they will say that no one is using my data, and no one is extracting anything from my data. Therefore, zkFHE will emerge from the Proof market, which is an independent and complex level, just like the complexity that is high up.

BlockBeats: Currently, the Proof market is compatible with ZKLLVM and Mina. I would like to know 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 to be proven, which is compiled into bytecode or a virtual machine, providing power to Proof Market. This virtual machine is the EVM. Then they come here with this demand, saying that they need to prove this statement. Proof Market is permissionless, and a new circuit pair will be deployed, which is how a new circuit pair is generated, and each new circuit is a new trading pair. When a prover sees a specific new statement in demand, it may be sudden, continuous, or a one-time large demand, or a one-time but still interesting demand. The prover can say, "Okay, I want to add this circuit to my list of circuits of interest, and I want to generate a proof for this circuit." Then Proof Market will make the corresponding changes, generate and submit the proof. We are working hard to improve the process to make it as concise as possible.

BlockBeats: How is it implemented for different proof systems?

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

If it is written in Solidity, just deploy it; but if it is written in Rust or C++, we will use zkLLVM to provide a toolchain for compiling verifiers from Rust and C++ to EVM, which will enable the generation of verifiers from Rust, C++, or other languages and deploy them to the Proof market. Once deployed, the Proof market supports verification of new proof systems. To this extent, it is permissionless.

BlockBeats: I remember you mentioned in a roundtable discussion about the decentralized process of Rollup. The path of =nil; Foundation is different from most Rollups, as it first builds a proof generation network and then decentralizes the sorter. So, 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. At that time, we discussed market strategies from different directions. Many people developed applications that required zero-knowledge proofs, proof systems, and a large number of proofs internally. Then they encountered this problem: we have developed the product, but it is not perfect because it has not achieved decentralization, and the proof has not achieved decentralization either. However, we do not have enough proof capabilities, so we are in a dilemma.

People have developed products, but they feel trapped. On our end, we have built a technology stack to address these issues. We can improve market services, integrate them into the value chain, and achieve decentralization and proof of decentralization to support roll-ups. The way it works is that the validators of these roll-ups need to obtain proof from somewhere, and they themselves should also be proof providers.

There are situations where validators may not be willing, able, or for other reasons unable to configure their own hardware, GPU, ASIC, etc. When you have capital but no infrastructure, you need to obtain proof from somewhere. This is where Proof Market comes in handy, providing proof for those who have capital but no infrastructure or do not want to own infrastructure. The second point is the reason why we approach things from different directions. We improve them from a decision-making perspective. People like third-party teams are trying to add decentralized sorters on top of our system, and perhaps someone will add a roll-up to the top of the entire system. When that happens, the technology stack will be complete, and the entire system will be perfected.

BlockBeats: Finally, can Misha reveal what is the most important thing on the=nil; Foundation's roadmap for this year?

Misha: We have two main directions. The first direction is verifiable applications, and we need to make these use cases public so that more people know about them. Some of them are already known, some are not yet well known, and some are not even enabled, such as our zkLLVM use cases that require a frontend specifically built 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 who are developing on top of us to complete their projects. This will be about some interesting things about the zk game. Have you ever thought about playing a 3D third-person shooter game on Ethereum? It is currently not feasible, but it will become feasible. This is the way to enable new use cases for the Proof market and zkLLVM. Sometimes it's quirky, sometimes it's fun, and sometimes it's really useful. This is the first major direction. The second major direction is that we must decentralize this protocol and make it accessible to anyone. This 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 be successful. Because there is currently nothing similar to the protocol we are building for the Proof market.

Perhaps in addition to solving practical problems, it may also become interesting because third-party developers can use it to try out some functions that cannot be implemented elsewhere. So these are our two main directions: ensuring security and achieving decentralization.

欢迎加入律动 BlockBeats 官方社群：

Telegram 订阅群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方账号：https://twitter.com/BlockBeatsAsia