Since the 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 an upcoming new era, ZK also means that there are many opportunities that we cannot accurately identify at present.
What will ZK 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, co-founder of the =nil; Foundation (referred to as Misha), discussing three related topics: =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. Generating 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.
- Analyst Five Catalysts May Awaken the Cryptocurrency Market
- Reflecting on the Crypto Market Returning to Common Sense and Rationally Examining Market Chaos
- Analysis of 6 projects that have recently experienced a counter-trend rally Can this speculative frenzy in the blockchain sector continue into a bull market?
3. In the current Proof market, the phenomenon of Prover Extractable Value (PEV) has emerged.
4. The Proof market is not completely decentralized at present, which will be the focus of the team’s work in the future.
=nil; Origin
Misha has been involved in the encryption industry since 2013. The first thing he did after entering the circle was to study the C++ implementation of Bitmessage. This was a Bitcoin messaging protocol that many people were crazy about at the time, despite being hacked several times later. Later, Misha started working on a series of development projects around BitShares with Dan Larimer (aka BM, founder of Steemit, Bitshares, and EOS), and during this process, he met Konstantin Lomashuk, who later created Lido. At that time, Konstantin had some encryption projects related to Bitshares and wanted to create a Steemit fork specifically for Russia, called Golos Network.
It was in 2016 that Misha, as 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 inappropriate internal architecture and insufficient quality. Therefore, Misha left Golos and related projects such as Steemit and co-founded Nil with Konstantin in April 2018.
Misha’s initial idea was to prevent people from encountering the instability issues that existed on Golos and Steemit, such as lack of proper data management, architecture, and security. Therefore, Nil aims to bring the achievements of the database management industry into the encryption industry, bringing more reliability, security, scalability, and other aspects to this field. Of course, what Misha didn’t expect was that his new journey would lead to the heart of the future scalability of the crypto world.
BlockBeats: Please briefly introduce your background, such as how you started your encryption business and why you joined the encryption industry.
Misha: That was a long time ago. I started getting involved in the cryptocurrency industry around 2013 when I was researching the C++ implementation of Bitmessage. You may remember that at that time, there was a frenzy around a Bitcoin-like messaging protocol called Bitmessage, although it was later compromised a few times, it was still popular at that time.
Then I started developing around BitShares and everything Dan Larimer (aka BM, founder of Steemit, Bitshares, and EOS) was doing. Later, I met Konstantin Lomashuk, who you may now know because of Lido. 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.
But in April 2018, I became disillusioned with Golos because the products designed by Dan were not satisfactory. His products never ran for a long time, although they did run, I felt that the internal architecture was not suitable for me and the quality was not good enough. So I left Golos and all other projects like Steemit and founded Nil in April 2018.
My initial goal was to prevent people from encountering the same problems I encountered on Golos and Steemit, such as lack of proper data management, architecture, security, etc. Everything was very unstable. I thought it was not a good solution, so Kosta and I founded Nil, with the aim of bringing the achievements of the database management industry into the crypto industry, because it means reliability, security, scalability, etc. The rest is the development history of Nil.
BlockBeats: When did the =nil; Foundation start paying attention to zero-knowledge proofs?
Misha: Looking back, we realized some problems when we completed the first prototype of the Database Management System (DBMS) around 2020. Honestly, before we tried to combine the database management system with the crypto industry, no one had really tried to do this. When we completed this project, we realized that the trust assumption was not what we wanted.
If we wanted to make it work, whether using our data or in other aspects, everyone had to trust us. We thought about how to reduce this distrust assumption, how to make it as trustless as possible, and that’s when we realized that we might need to use some kind of technology. We needed a cryptographic tool to achieve this goal, so we built a cryptographic suite for that 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 try it out. We built a suite and created our own proof system. Then we collaborated with people from the Ethereum Foundation and the Mina Foundation to build a circuit compiler. In order to not generate 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 that we needed state proofs, which were also something that Mina and Ethereum 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 thought of it as “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’s zkBridge.
BlockBeats: Regarding zero-knowledge proofs, the field of encryption has been researching and experimenting for quite a long time, but significant progress has not been made. However, this year, the development in the ZK field seems to have entered a state of rapid growth. Why is that?
Misha: In fact, there are only two ways to apply zk technology. The first obvious method is for privacy purposes, and the second method is for compression, such as the scalability solutions everyone is talking about, including zk-Rollups, zk-Bridges, zk-MLS, and zk-Oracles. People have “misused” this technology stack for compression, and I think this is the most exciting “misuse” I have ever seen. So, why now? We could have completed this task several years ago, or it may be due to several key technological milestones that have made it usable, feasible, and interesting.
The first milestone was in 2016 when this technology became increasingly practical for the encryption industry. At that time, the Rank-1 Constraint Systems (R1CSs) became quite common, and different applications began to emerge. Fundamentally, when it became feasible to protect privacy, this became possible. For example, projects like Zcash and Tornado Cash were born during that era, or the ideas for these projects were born during that era.
The second milestone was between 2019 and 2021, which was the second crucial period for this technology. During that time, the use of bloom filters in arguments became increasingly popular. People started building proof systems based on bloom filters. We also have our own proof system called “placeholder.” Why was this period important? Because thanks to these bloom filter-based proof systems, projects were able to use this technology stack for compression. It improved the compression capability, making it cheaper and feasible to perform proper Rollups scalability and achieve zkBridge in 2021.
Currently, we have made some progress in further developing the proof system and have also made breakthroughs in our project. It can be said that writing complex mathematical constraints and computations in such an environment where information is shared for a long time is quite challenging. Many people are devoted to this problem, such as the introduction of STARK and zkVM, which was introduced to solve this complexity problem. We have launched the zkLLVM compiler, which also makes application development simpler. From 2019 to 2021, the proof system has been continuously developing, and from the end of 2020 to the beginning of 2022, tool development has also made progress. All these developments have made it efficient enough to construct complex computation proofs and economically feasible.
Of course, the development of the proof system is far from over. There is still much work to be done to achieve more application scenarios. For example, perhaps this year or next year, we will see further development of the proof system, and we are also conducting related research and development. The development of these proof systems will make economically feasible zkLLVM applications possible, and we hope to be the first team to achieve this goal. However, regardless, everyone is currently working hard to improve the proof system.
BlockBeats: You mentioned zkLLVM earlier, 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 early circuit compilers. I have seen some prototypes and DSL projects before, but I haven’t seen many complete functional circuit compilers that are not virtual machines. There are indeed some, but I am not sure if anyone is really using them, so that’s why I think it is important. And quite a few people in this industry are working hard to get rid of the “not invented here” dilemma, which is very time-consuming. Obviously, people will eventually create very good products, but this “not invented here” dilemma makes development time-consuming and costly.
For example, we are currently communicating via Zoom, and almost all the software on our laptops is compiled using LLVM. We just bring all of these over and make them provable. So I think we are just bringing the entire compiler ecosystem into the crypto industry, allowing these achievements to be reused for efficiency and economic feasibility in the crypto field. This also brings about widely used programming languages. There are many software written in Rust, C++, Go, TypeScript, and so on in the world, and people may want to execute these software within Ethereum and in trustless environments.
One of my favorite examples is people getting the source code of Doom (C/C++ source code), proving it to Ethereum through zkLLVM, and then showing off the time it took them to complete it to each other. For example, I completed the Doom speed challenge in 20 minutes, and here is the evidence and your Ethereum NFT, proving 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?
Misha: Many different types of projects are using these technologies. Some projects may just be building something to try to deploy, or they may already be running. The most obvious use case is zkBridge, which we built using the compiler to provide protection through its proving system. Perhaps this is also one of the reasons why we realized the need for a compiler and started building it. There are also people trying to use it for formal verification of statements, compressing them into proofs by using the zkLLVM compiler instead of trying to put the formal specifications of programs together with them. In fact, people are compiling compilers.
Take the zkOracles-like applications as an example, people have built zkOracles to retrieve Ethereum historical data or Lido to ensure the security of Ethereum staking issuance. People are solving the problem of many trust assumptions, 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 the trust assumptions because we couldn’t risk users’ TVL being at risk, so we decided to protect it with ZK proof of work. Besides, there are many other projects, to be honest, I can go on forever. Currently, I have about 80 projects on hand in the CRM.
BlockBeats: = nil; Foundation, previously valued at over $200 million, has received investments from L2 teams such as StarkWare and Mina, as well as other VCs. Is this money being used to build a proof market? Does the investment from StarkWare and Mina mean that you will be more inclined to cooperate with specific ecosystems?
Misha: This is our first and only round of financing in the past five years because we didn’t have the need for it before, but now it’s time to do it. We have done enough prototyping, supported enough projects, and learned a lot. We feel strong and confident enough to launch the product in the way we think it should be built.
This round of financing was completed about a year ago, and we announced the news several months later than the actual time it happened. We didn’t start discussing “this is what we developed” until we felt comfortable. Because when you raise funds, you start making commitments to each other, and then they 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 about this topic until we had done something.
We are indeed collaborating with the entire ecosystem of Mina and StarkWare. Currently, there are 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, which requires a lot of verification capabilities. In addition, in 2021, we worked with Mina to build state proof verification based on compilers, which is another project in collaboration with the Mina ecosystem.
A lot has happened in our collaboration with the StarkWare ecosystem. Of course, this is the purpose of our collaboration so that we can also be useful to 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 that they need verification capabilities.
There are also other projects trying to use old bridging technologies and build Ethereum applications based on state proof verification. Some people are building L3 on StarkNet and they say having verification capabilities would be a good choice. In short, this is the purpose of us coming together with them. Honestly, I am satisfied with this collaborative relationship.
Secondary Market for ZK Proofs
Zero-knowledge proofs (ZK Proofs) are the absolute core in the ZK domain of the current crypto market, and their existence provides 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 haven’t 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 scale it. In Misha’s view, introducing a market mechanism is the optimal solution to this problem.
=nil; Foundation believes that the generation of ZK proofs should be outsourced to manufacturers who provide such professional services. In this regard, we need a Proof marketplace where anyone can request the generation of the required ZK proofs, and a network of professional manufacturers will respond to such requests.
BlockBeats: Now let’s talk specifically about the Proof marketplace. Where did the idea come from and what is the story behind it?
Misha: This idea came from our extensive involvement in protocol applications and Filecoin-related matters from 2020 to the end of 2021. During 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 the proof systems, how to conduct proper reasoning, and even developed a Filecoin prover that was 10 times faster than the public version, allowing miners to fully utilize their hardware. We were essentially a hub that witnessed all the experiments aimed at reducing costs from the perspective of miners.
During that time, we learned a lot of practical market data, such as the value and time required to generate a specific proof using this hardware; who uses which hardware, which data centers are built for this purpose, and so on. Then, when collaborating with the Ethereum Foundation, Mina Foundation, and many other foundations, we realized that these state proofs and consensus proofs were very burdensome, and we would never allow anyone to prove these evidence on their own.
To be honest, no one has the hardware to generate them quickly because they are too large. For example, just like Mina’s consensus, Mina’s state proof is a polynomial commitment curve multiplied by about $35 billion, which is quite significant. Or Solana’s consensus proof, in addition to other content, it also includes about 4,000 ECDSA signatures, which takes a lot of time to generate.
When we realized this, we decided not to do it anymore. We thought, well, we will outsource this work. We will establish a marketplace for this 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 decentralized protocols. We no longer want to be the hub, but let the protocols become the hub. It turned out that our idea was correct. Now everyone is building Proof marketplaces, and we guessed the direction correctly.
BlockBeats: When building the Proof marketplace, did you consider the dynamic relationship between it and zkLLVM that you have already built?
Misha: Initially, these two projects were actually separate, and they were two independent things. For example, we just needed to build a toolchain for circuits because we wouldn’t build it manually, as it’s too large. Then we found that others also needed this toolchain, so we decided to open source it for everyone to use.
And the Proof market is also a separate thing, because we think it’s just a market for proof generation. We never even thought that people would try to speculate with proofs. They are actually trying to do things like buying low and selling high, which is quite absurd because it shouldn’t be like that, but anyway, that’s the fact.
The protocol supporting 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 orders in the Proof market, which makes the protocol very data-intensive, such as the amount of data describing an average state proof. Once a carefully completed average state proof description needs to occupy about 2GB of data, try to find a protocol that can handle 2GB of data. It’s almost impossible.
But later on, people started using zkLLVM to prove some very large things, which are quite large compared to what people do in Solidity, like code libraries such as Ross and C++. So we put them together, let them relate to each other, and then use them as a usable service. We still think 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 category of users is mainly zkBridge, where some consensus proofs and state proofs are quite heavy to generate. If you want to generate correct and secure verification like building Ethereum consensus proof, for example, using the complete Ethereum consensus verification, and all 100,000 node signature validators, it will take you some time to generate.
The second category is zk oracle, such as those applications that need access to Ethereum historical data or process Ethereum data in a specific way and then use it with EVM. Some applications try to reduce their gas costs in this way, such as lending protocols trying to calculate and load their collateral asset risk parameters into EVM, but they cannot calculate them in EVM in terms of cost.
They obtain all the necessary Ethereum data from different trading platforms and indexes, put them into EVM, and then use them as a set of risk parameters for collateral. It’s like another kind of Lido oracle, showing how the protocol improves its security and reduces execution costs by outsourcing a series of calculations (such as only security in the Proof market and zkLLVM). There is no doubt that zero-knowledge oracles are very important.
The third category is Rollup, existing Rollups or new Rollups can use this technology, and some are already trying this. Anyone who intends to become a Rollup verifier will come with a desire to implement some kind of proof in the Proof market. For verifiers, it is very challenging to deal with specialized hardware and run nodes on rented AWS servers. In fact, AWS currently does not provide ATX or very powerful GPUs, so basically verifiers will come with these zkLLVM use cases. Obviously, we already have some zkLLVM use cases, but I must admit that they have not been put into production yet.
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 again, it is emphasized that it has not yet been put into production and 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: What are the requirements to become a proof generator in the Proof market?
Misha: There are actually not many requirements or restrictions to become a proof generator, it depends entirely on the specific circuit and specific statements 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 or run it as a background process on your machine when dealing with various proofs in the market.
If there is no better hardware supply for specific statements, specific circuits, specific applications, and specific proofs in the market, then you can receive orders and generate proofs. If you have the best hardware, if you can make the fastest promise to generate proofs, and if there are no better competitors, you can accept orders, generate proofs, and receive rewards.
BlockBeats: All users of =nil; Foundation need to register an account. If the generated proofs themselves or their transaction and ownership information are stored on private servers, will it introduce some centralization issues?
Misha: This is exactly the issue we plan to address by the end of the year. Yes, currently the market proofs are not so decentralized, we have not released protocol nodes that support it, nor have we discussed this protocol in public. The current operation mode is as follows: a few people who are also involved in Lido and serve as validators and validator operators serve as validators, and we can temporarily host it to see how it goes. Then we distribute the source code to them, and in fact, there are six to eight running in test mode.
Currently, the system is decentralized to a certain extent, but it is not open and not truly decentralized. 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 decentralization and whether we can rely on them. Can we use them now? I say, 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 proof of market based on a decentralized protocol, and we used a certain decentralized protocol from the beginning. We discussed several deployment and operation scenarios, and we tried to deploy it directly on Ethereum. However, when considering the economic feasibility, we found that if we do this, we would need to pay about $2.5 billion in Ethereum fees annually, which is financially impractical to run the market proof on Ethereum.
Next, we tried to run it on technologies like Rollups. However, despite trying several different Rollups, the cost remained high. When we calculated the cost of running market proof and arbitrage, we found that it would cost $250 million per year for just the market proof, which is quite high. Therefore, we had to come up with our own protocol that can handle issues such as scalability, cost, and data-intensive tasks.
Our goal is to make this protocol as secure as Ethereum, as 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 payload to be processed is essentially the same. People want to reduce the delay between the sorter and the prover so that they can immediately send data to the prover and win the block.
One of our current main focuses is how to deploy the sorter on top of this protocol. We hope to build 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 code deployment for market proof applications is as secure as Ethereum.
BlockBeats: Can you share more about the incentive mechanism of the protocol?
Misha: We certainly prefer to pay proofs with various tokens, so we cannot force everyone to use a specific token. This means we must remain neutral towards tokens, just like we do with any product and application. For example, it is likely to work similar to how Arbitrum and Ethereum operate. Why not have both Ethereum and Arbitrum?
The first step in this direction is undoubtedly the EVM endpoint approval market, which we deployed a few days ago. This is a payment solution for using all Ethereum-deployed assets in the Proof market as incentives for approvers or for applications willing to pay their own tokens on the Proof market. This is the first step in this direction.
The Wonders of the Proof Market
Since it is a market, there will certainly be unpredictability and complexity that cannot be controlled. Will people speculate on ZK proofs? How will they speculate? These are important data that the team needs to monitor and record. After several months of testing, what interesting phenomena have occurred in the Proof market? What are the team’s future plans?
BlockBeats: Will the introduction of market mechanisms lengthen the time it takes to generate proofs?
Misha: Auctions or finding the bidder most suitable for the job do take some time, perhaps not a few seconds from our side, but 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 a delay of less than a second.
Even with a delay of less than a second, the worst case scenario I’ve seen is that the application couldn’t find a supplier within three to four seconds. But even so, this delay is incomparable to the overall proof generation time. So, I don’t think it’s a worrisome issue compared to the collective generation advantage brought by market dynamics.
BlockBeats: Is it a good thing or a bad thing if someone wants to speculate with the generated proof? Will the team intervene in any way?
Misha: Strange things have happened on our website, and the one mentioned earlier is not the strangest one. Even stranger things have happened in the Proof market. But let’s talk about speculation first. We have no control over it 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, maybe as a rollup or in some other way, we will no longer be able to control everything.
We are now trying 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 an application that can be proved, that’s basically it, so speculation is even possible. There is no other purpose except for speculation in the Proof market.
One of the strangest use cases I’ve seen is someone trying to futures trade computational power and then discussing speculation with those futures. It’s like hash rate futures for Bitcoin, but it’s the same for zk proofs. Have you ever thought about MEV? What if I told you there’s actually a Prover Extract Value (PEV)?
It doesn’t work like an application bringing in some data and then something needs a proof and the provers come in to do it. They bring in the data, start generating the proof, and everything goes as expected. But at the same time, if a prover tries to profit more from this data or similar behavior. They will use this data elsewhere, like on Ethereum or other protocols, even some rollups.
Their purpose in doing this is to extract as much value as possible from this data rather than using it to generate proofs. There are also different types of extractable value proofs, such as people trying to predict when a proof will be generated and then injecting buy or sell proof transactions into the Proof market protocol, reverse engineering the API and trying to inject transactions into it. This way, the provers can sell, or buyers can speculate on the price to extract value from it, just like flash miners, or builders and proposers trading speculation in Ethereum.
Some people have started to try to prevent provers from using the data they obtain 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 for proof generation, but FHE is very computationally expensive, so it increases the cost of proofs.
Just like sending it to the sky, this will double, triple, or even increase the cost of proof by ten times. But they will say that no one is using my data and no one is extracting anything from my data. So, zkFHE will emerge from the Proof Market, which is an independent complex hierarchy, just like complexity high up in the sky.
BlockBeats: Currently, the Proof Market is compatible with ZKLLVM and Mina. I want to know how this Proof Market will generate proofs for different circuits in the future?
Misha: In simple terms, the process is as follows: an application comes with a statement that needs to be proven, and this statement is compiled into bytecode or a virtual machine, which provides power for the Proof Market, and this virtual machine is the EVM. Then they come here with this demand and say that I 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, and each new circuit is a new trading pair.
When a prover sees a specific new statement in demand, this new statement may appear suddenly, or it may be persistent demand, or it may be 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 to watch, and I want to generate a proof for this circuit. Then the Proof Market will make the corresponding changes, generate and submit the proof. We are working hard to improve and make this process as concise as possible.
BlockBeats: So how is this achieved 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 this proof system into EVM bytecode. Because the EVM provides power for the Proof Market, the verifier needs to be compiled into EVM. It may be written in Solidity, or it may be written in Rust or C++.
If it is written in Solidity, it just needs to be deployed; if it is written in Rust or C++, we will use zkLLVM to provide a toolchain for compiling verifiers from Rust and C++, so that zkLLVM can be used as a compiler from mainstream languages to EVM. This can generate verifiers from Rust, C++, or other languages and deploy them to the Proof Market. Once deployed, the Proof Market supports validation of new proof systems. To this extent, it is permissionless.
BlockBeats: I remember you mentioned at a roundtable discussion about the decentralized process of Rollup. The path of =nil; Foundation is the opposite of most Rollup projects, where the proof generation network is built first and then the sequencer is decentralized. 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, and at that time, we discussed market strategies from different directions. Many people have developed many applications that require 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 is not decentralized, and the proofs are not decentralized either, but we don’t have enough proofing capabilities, so we are in a dilemma.
People have developed products, but they feel trapped. On our side, we have built a set of technology stacks to solve these problems. We can improve market services, integrate them into the value chain, achieve decentralization and decentralized proof, and provide support for roll-ups. The way it works is that the validators of those roll-ups need to obtain proof from somewhere, and they themselves should also be provers.
In some cases, validators may be unwilling, unable, or unable to configure their own hardware, GPUs, ASICs, etc. When you have capital but no infrastructure, you need to obtain proof from somewhere. At this time, 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 I mentioned that we approach from different directions. We start improving them from a decision-making perspective. People like third-party teams are trying to add decentralized sorters on top of our foundation, and maybe someone will add a roll-up on top of the entire system. By then, the technology stack will be complete and the whole system will be perfected.
BlockBeats: Finally, can Misha reveal the most important thing in the roadmap of=nil; Foundation 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 them are already known, some are not well known yet, and some are not even enabled, such as our zkLLVM use case, which requires a frontend specifically built for zkLLVM applications. This will make DruLianGuail and zkLLVM useful for zkLLVM use cases and all these things.
Another example is that we want to help those who develop on top of our foundation to complete their projects. There will be interesting things about zk games. Have you ever thought about playing a 3D third-person shooter game on Ethereum? Currently, it is not feasible, but it will become feasible, and this is how we enable new use cases for the Proof Market and zkLLVM. Sometimes it’s strange, sometimes it’s interesting, sometimes it’s really useful.
The second major direction is to decentralize this protocol and make it accessible to anyone. This will allow us to achieve decentralized sorter use cases and allow everyone to access the protocol, try experiments, and build something on top of it. We will see how it develops, but we hope it will be successful. Because the protocol we built for the Proof Market currently has no equivalent in the market.
Perhaps besides solving practical problems, it will also become interesting because third-party developers can use it to try out functionalities that cannot be achieved elsewhere. So these are our two main directions: ensuring security and achieving decentralization.
Like what you're reading? Subscribe to our top stories.
We will continue to update Gambling Chain; if you have any questions or suggestions, please contact us!
