Four expansion teams talk about the Ethereum frontier: decentralized Sequencer, EOF, 4844, and modularity

原文标题：《 四个扩容团队聊以太坊前沿技术：去中心化 Sequencer、EOF、4844 和模块化 》

Original author: Zhixiong Pan

At the Ethereum Shanghai Upgrade Summit, we invited four different expansion teams from the Ethereum ecosystem to talk about the leading edge of Ethereum technology.

In particular, EOF and EIP-4844 are likely to be included in the next upgrade (Cancun). In addition, the narrative of decentralized Sequencer and modular blockchain is also a new direction that researchers pay more attention to.

These four teams have distinct characteristics, such as a focus on zero-knowledge proof (especially zkEVM), a focus on WASM and dynamic expansion, a focus on Move languages and modularity, and a focus on generic storage. In addition, they also have a lot of differences in other technical details.

The participants in this discussion are:

Dorothy Liu from AltLayer

Jolestar from Rooch Network

Qi Zhou from EthStorage

Ye Zhang from Scroll

TLDR

The EOF upgrade has less impact on application developers, but has some impact on Rollup and zkEVM. There may still be some debate as to whether the EOF will proceed to the next stage of upgrading.

Several schemes of decentralized Sequencer: Byzantine fault-tolerant (BFT), MEV auction, shared Sequencer (Flashbots), VDF, etc. In addition, fair ranking may not be fair and requires different strategies for the application.

The purpose of the IP-4844 is not to expand capacity, but more to implement a whole set of concepts needed for future Danksharding, including blobs and their Data hashes. Implement these concepts ahead of time so that Danksharding does not require contract upgrades. Ip-4844 is not a significant improvement over current Ethereum data linking methods, and the bandwidth they provide is in the same order of magnitude.

There are completely different perspectives on the modular blockchain: Some people think that in the era of heavy applications, more choices need to be provided; Some people think we should borrow from mature computer systems, but others think we should not be too modular, Ethereum is the most important data layer.

The following is the full text of the discussion, which has been translated by OpenAI Whisper and formed by GPT-4 processing, with some adjustments and deletions.

Topic 1: EOF (Ethereum Object Format)

Zhixiong Pan:

The Ethereum Object Format (EOF) was originally scheduled to be implemented in the Shanghai upgrade, but has now been delayed. The essence of EOF is to provide a pre-data structure for the self-bytecode of Ethereum, which is conducive to the future upgrade of the bytecode feature and smart contract of EVM.

Will this upgrade have more impact on the overall Layer 2 or Rollup ecosystem? In particular, Rollup Ecosystem will essentially deploy some smart contracts to Ethereum Layer 1, so will this upgrade affect the technology choices and paths associated with Layer 2?

Dorothy Liu:

EOF is not a very important innovation in the eyes of the AltLayer team. Although it has important improvements to the EVM entry mode of packing, but it has no direct influence the writing of the language of Solidity. Therefore, from the perspective of application development and common development, the change of their impact is not big, many developers may not even know this thing, also won't cause problems.

However, for Rollup, the impact is huge, because Rollup is essentially Ethereum's executive layer. When changes are made to Ethereum, Rollup needs to adjust accordingly. This EOF change is likely to have a greater impact on zkEVM because zkEVM is relatively more technically difficult. They are Type-3 in the EVM compatibility classification, so they need to work harder in the pursuit of higher compatibility. It may even require rewriting or making very big changes.

However, for those of us who do Optimistic Rollup projects, whether written in WASM or EVM, we are Type-1 compatible, that is, fully compatible with EVM. So, for us, the difficulty is very low. Although we had to make some changes, it was fairly easy. In addition, our own production certificates are in WASM, so for us, the practical impact is not very big.

Ye Zhang:

First of all, I think EOF is really an important technological development. There was an argument that because the EVM core was upgraded less, zkEVM didn't need to be changed as often. However, with the recent EOF, there may be other updates later that change the core logic of EVM, which does affect zkEVM. However, for now, because EOF is forward compatible, there is still some compatibility with previous contracts. At least for our existing contracts and for the developers, the direct impact will be small. There may be some caveats later, but at least for our Layer 1 contracts, the impact will not be significant. At Layer 2, the impact depends on how much we support EOF. We will definitely lag a bit, because if we want to be completely consistent with EVM at Layer 1, we need to support EOF.

In fact, when we were developing zkEVM, we were already focused on the core upgrade of EOF, which was a little easier than expected. Because we built the entire zkEVM with a modular design, we could easily update Opcode. For EOF, the main change is the addition of some version control and Opcode, we just need to implement the new Opcode and do a good job of version control, such as adding some tags and variables to the circuit. These changes were made at the Opcode level, requiring the addition of some circuitry. In addition, EOF does some checks on bytecode deployment, which affects a subcircuit of zkEVM, the bytecode circuit. In this circuit, we need to check the input hash and then output the corresponding bytecode. If we need to check at this stage, we may need to add some constraints to the circuit.

Overall, I think changes are necessary, but not to the extent that a complete refactoring is required. Ethereum is now taking zkEVM to a very important position, and they are leading some key technological developments themselves. I know that Vitalik and some members of the core EIP team are also following the progress of the zkEVM team, including communicating with us about the impact of this upgrade on zkEVM. Because every upgrade of Layer 1 brings certain risks, it was previously believed that every upgrade may be irreversible. Therefore, we want Layer 1 to be as stable as possible, and the settlement layer to be as stable as possible, so that there is less impact on the application and existing technology. At Layer 2, we can make all kinds of innovations. However, if Layer 1 does need to be changed, I think Layer 2 can be changed as well, and not too much. But I'm sure there will be some delay as we need to implement these changes and possibly audit them. The audit process may take additional time to complete, so we generally want changes to be as minimal as possible. However, I don't think these changes will have a fatal impact on the system as a whole and cause serious problems.

Qi Zhou:

Regarding EVM Object Format (EOF), I've noticed that the Ethereum community has touched on a number of related topics in previous discussions. Especially during the Shanghai upgrade, we can see that Ethereum has a somewhat different attitude towards the whole upgrade process. For example, people like Danksharding founder Dankrad have some doubts about EOF. They argue that while EOF doesn't change much for developers, it mainly improves contract security. In this regard, they do not feel that this is the most important stage in the expansion of Ethereum. In fact, EOF is only a very small part of the overall expansion plan, so there is a lot of controversy in this area.

However, why would you want to include EOF in your upgrade plan now? This is because the EOF has been proposed for a very long time, maybe four or five years, and it could have been even longer in previous internal discussions. After analyzing the EOF, we do agree very much with some of Dankrad's points. While EOF provides some security to the entire Ethereum contract, such as the relatively dangerous operation of eliminating dynamic jumps, the compiler actually avoids the underlying error prone issues in the extensive practice and contract writing of Ethereum. As a result, we have not experienced such abnormal contract execution caused by jumps in recent years.

I personally think there may be some debate as to whether EOF will go to the next stage of upgrades, such as Cancun, given the impact it may have on Ethereum's Layer 2 computing layer. There are still many differences of opinion about EOF compared to what we will discuss next, EIP-4844.

Jolestar:

Regarding EVM Object Format (EOF), there are two main optimizations. First, it front-loads the validation of the smart contract code to be validated at deployment time. This is very effective for improving performance. Today, many projects have adopted this approach through code validation during deployment. Second, EOF provides a scalability capability. Although this update may not be a major change, once this extension mechanism is provided, there may be a lot of extension requirements in the future. At this point, you may be faced with a choice between innovative extension and compatibility. This has always been a dilemma for virtually all software systems.

In this way, the EOF actually opens the door for future changes. For example, to implement a Layer 2 feature, you can add a new version and add some new functionality to the smart contract code. At this point, compatibility with Layer 1 May be affected. The change is likely to be highly controversial indeed. However, from my perspective, I believe that innovation and evolution should still be prioritized at this stage, and it is not yet a complete freeze. Of course, for Layer 1, this is another dimension, and Layer 1 and Layer 2 May be judged differently.

Topic Two: Decentralized Sequencer

Zhixiong Pan:

At present, the Sequencer of most Layer 2 networks is still at an earlier stage, and most are single Sequencer. Some projects plan to be upgraded to decentralized Sequencer in the future.

Is there a rational design scheme of decentralized Sequencer at present?

Layer 2 的原生Token是否可能成为实现去中心化 Sequencer 的必要条件？如 Optimism/Arbitrum，虽然有自己的 Token ，但仅可用来作为治理 Token 。所以还有哪些前沿或早期的去中心化 Sequencer 方案值得关注？

Qi Zhou:

Recently we have studied some related topics, such as Arbitrum's Sequencer. The Arbitrum community is faced with a big problem, that is, a large number of nodes (such as 10,000 connections) connect to Sequencer to acquire the latest transaction information and arbitrage it. We often joke internally about whether this Sequencer is similar to the New York Stock Exchange platform, because there are many quantitative robots around the New York Stock Exchange platform to quickly acquire trading data through optical fiber and conduct quantitative operation. Does this Sequencer model cause us to degenerate into a very centralized system?

我认为如何实现 Sequencer 的去中心化是一个非常重要的问题。我能想到的一些解决方案是借鉴权益证明（POS）机制，并将 Layer 2 的原生 Token 用作权益证明。通过这种方式，我们可以实现 Sequencer 的轮换，类似于以太坊最近正在进行的安全领导人选举（secure leader election）。结合这些技术，我认为我们可以找到一些成熟的方式来解决这个问题。

Dorothy Liu:

For this question, I can share some of my personal observations on the history of Arbitrum and Optimism. Early last year, I went to a Chainlink event on Rollup in Amsterdam and had Arbitrum, Optimism, zkSync and Metis. Their discussions focused on capacity expansion and performance. I asked them privately what they thought about the consensus layer and whether Rollup needed to add a consensus layer. They say they are only considering expansion. Optimism is not what optimism optimism was initially considered, and that optimism is often what optimism optimism is.

From our point of view, we designed the decentralized Sequencer from the beginning of the project. We've done two Dark Forest games and two NFT Minting events that took place directly on the Ethereum mainnet, using decentralized Sequencer. In our view, this is not a technical problem, but a legacy of historical development. How they're going to change engines in a running system is going to be more difficult than having a full plan at the beginning of a new project.

关于 Token 问题，Arbitrum 和 Optimism 已经证明，可以不需要自己的 Token 就可以运行。如果想要有 Token ，可能需要一些设计，例如 Slashing 等。我们将在下个月发布去中心化 Sequencer 网络，这将是市场上第一个去中心化 Sequencer 网络。届时，我们会有一些包括 Staking 和 Slashing 在内的设计。

Finally, regarding MEV, although it and Sequencer are two issues, there is a relationship between them. The decentralized Sequencer network may solve the MEV problem to some extent. However, the problem may never be completely solved. At present, the Arbitrum team has adopted some methods, such as increasing randomness to improve, but they can not completely solve these problems. We may also propose some MEV solutions in terms of hardware or other aspects, which will be announced in the future.

Ye Zhang:

我们已经对 Sequencer 进行了大量研究，尽管目前尚未公布具体方案，但我们确实在努力设计。目前有两种主要方向。第一种是基于拜占庭容错（BFT）的方案，例如利用 Tendermint 等选择一个 leader 来代替之前的中心化 Sequencer。这种方法需要 staking 和 slash，可能需要发行自己的 Token 来实现 PoS，或者与其他重押或类似机制结合。BFT 的优势在于可以提供非常快的预确认，保持良好的用户体验。

A second, more promising option is the MEV Auction. Optimism was the first optimism associated with MEV auctions, in which the person who offers the highest price wins a block. The downside, however, is that users could be marked up wildly by MEV bots.

Similar schemes include Base Rollup, previously proposed by Justin Drake, whose core idea is to reuse Layer 1's validators to generate Layer 2's blocks. In this way, the verifier building the blocks of Layer 1 and Layer 2 can put the validation transaction of Layer 2 into the block of Layer 1 when building the block of Layer 1, so that the overall bid is larger and the block of Layer 1 is included first. The advantage of this scheme is that it is highly consistent with Layer 1's incentive mechanism, but the disadvantage is that it does not have the pre-validation that BFT does, and the user experience may become poor.

Therefore, the most promising direction for now is based on reusing Layer 1 validators, as well as BFT-based solutions. We are working on issues in these directions, such as providing pre-validation while reusing Layer 1 validators.

There is also some Optimism about the direction of decentralized Sequencer. For example, Flashbots put forward a plan named Shared Sequencer. Similar design is also found in Superchain. The core idea of shared Sequencer is to use fixed Sequencer set to process transactions on multiple chains, realize cross-chain MEV and improve the experience of cross-chain UI. However, this design is still in its early stages and has not yet solved some key issues, such as the stress of Sequencer nodes and the atomicity of cross-chain transactions.

Shared Sequencer may be of value in the future for many specific applications (such as small real-time asset applications) that may not have the capacity to run a decentralized network. However, convincing large real-time asset applications to use shared Sequencer can be a challenge.

Flashbots is trying to build a privacy decentralized network to realize shared Sequencer, so as to solve the essential MEV problem brought by information acquisition and bring a certain degree of value to users. However, as the programme is not yet fully public, it is difficult to assess whether it will overcome the problems mentioned earlier. As highly legitimate MEV players, we will evaluate Flashbots in detail after they make their proposal public.

In terms of whether or not tokens are required, I think it mainly depends on the consensus algorithm used. If the BFT algorithm is used, tokens are likely to be required, but if the approach is based on an existing Layer 1 validator, tokens may not be necessary because someone else's resources can be reused. That way, the source of value becomes who's mortgaging you, and the MEV goes straight to the network validator. Thus, how Layer 2 views the value addition of MEVs is the determining factor.

Regarding MEV handling, there is an argument that fair sorting can solve the MEV problem to some extent, but in fact it may just alleviate the MEV problem. Because there could still be various robots competing for priority, the situation is similar to traditional trading firms. Although some randomness has been introduced, the problem has not been completely solved yet. In fact, a study of MEVs suggests that fair ranking is not fair. By constructing an attack model, the researchers prove that the user experience is likely to be worse in the case of fair ranking. Therefore, in order to achieve true fairness, different sorting strategies may be required for different applications.

And there are a lot of interesting attempts. For example, a transaction is encrypted by encryption technology, such as VDF, and decrypted when the transaction is confirmed. This makes it impossible to predict in advance what will be traded. In addition, there are methods such as time locking. In short, we are also looking at and improving these programs. Although we have some general directions, there are problems in each direction. Therefore, we would like to conduct a rigorous analysis to ensure the stability of the programme before it is confirmed. Sequencer involves many issues such as the flow of value, so we believe that there is no perfect solution at present. That's why we put the Sequencer study behind it.

It is now generally felt that decentralised Sequencer might be in favour of anti-censorship. But as I mentioned in my discussion today, it is actually possible to ensure that transactions are enforced at the second level by bridging. More importantly, most bridge designs will stipulate that if you don't include a transaction, there may be some kind of impact within a day. However, most decentralized finance (DeFi) will probably liquidate you the next minute and then reject your transaction outright, potentially giving users a bad experience. Therefore, real-time anti-censorship is very important for users and DEFIs.

Another issue is the extractable value of miners (MEV). For example, Arbitrum now implements a first-come, first-served strategy, which uses a centralized sequencer. The previous view was that if you found out I was being used in MEVs, I would probably leave the network, causing people to distrust the legitimacy of the network. But a huge problem is that when you get your network off the ground and network effects, like single sequencer, kick in, once the ecosystem gets to a certain size and you start charging or thinking about MEVs, users actually become so dependent on you that it's hard for them to move to another platform. So I think this threat could come up in a few years and they suddenly start implementing MEVs and it's a potential threat.

此外，还有合规问题。如果你的 Token 和权益证明（PoS）有关联，你可能会面临一定的合规风险。例如，如果你实行中心化，某个国家要求你关闭序列器或解决某些问题，去中心化可能会带来一定的好处。

So we've done a very detailed analysis and put a lot of effort into this direction. If anyone in the audience is interested in protocol research, please join us. We are looking to hire people in this area, and we will have a more detailed analysis in the future.

Jolestar:

On the introduction of BFT as a Sequencer, everyone has reached a consensus. In fact, we need to introduce a BFT consensus in Layer 2. We focus on the contents of this consensus decision. If it directly determines the outcome, then we can let it directly determine the outcome. We hope to provide extensibility Layer 2, so we consider Sequencer from another Angle. What is our main purpose? One is for safety. In Layer 2 schemes, Sequencer and other schemes such as Proposer or similar Prover or zk are different roles. Sequencer and Proposer are separate in the operational case and must cheat jointly if they are to cheat. For example, the Sequencer hides the trade and the Proposer makes a false root. Security is guaranteed if their roles are separated and assumed by different organizations.

Before Sequencer commits to Layer 1, the order of transactions can be adjusted by Sequencer, where there may be room for cheating. To eliminate this problem, let's ask Sequencer to provide a proof similar to a fraud proof, called a Sequence Prove. You justify putting a deal in place, giving a promise. The Sequencer can be challenged and punished if the final order of the chain is not consistent with the promise.

Finally, if we are really going to introduce BFT voting, we should decide the order of transactions, not the outcome of transactions. The existing consensus mechanism determines the final execution of the result vote, and does not determine the order of transactions in the blockchain. So, in this case, we might need to introduce a consensus sensitive to order or fairness, and let people vote on the order of transactions. This is a direction we are currently exploring and a plan for the decentralization of Sequencer.

Topic 3: IP-4844 (Proto-Danksharding)

Zhixiong Pan:

In addition to EOF, another important implementation of protocol layer upgrades and expansions is EIP-4844, particularly related to the Layer2 team. At the beginning of this year, the KZG Ceremony has been started, but it may take some time to add the protocol layer. For Rollup, ZK Rollup, or capacity expansion directions, how long do you think it might take the Layer2 team to integrate the EIP-4844?

What difficulties do you think might be encountered with the integration of IP-4844? In addition, has any estimate been made of the impact of using EIP-4844 on GAS or overall capacity expansion?

Jolestar:

In my understanding, integrating the IP-4844 with the original Rollup scenario doesn't change much. We have been looking for a solution with higher TPS and lower processing fees, but relying on EIP-4844 alone will not solve this problem. In fact, it just adds one transaction type, the Blob type, and the overall block size limit is still limited to the base layer. If we want to achieve the ideal Layer 2 with TPS of hundreds of thousands or close to hundreds of thousands, the first layer transactions still cannot be placed directly on a block.

Our goal now, therefore, is to achieve a model in which different schemes can be combined in order to choose between schemes with lower cost, ease of use, and greater throughput.

Dorothy Liu:

First of all, the IP-4844 upgrade is relatively easy to integrate for our OP, while it may be more difficult for zkEVM. About this upgrade professional answer, Zhang Ye can provide for you. In addition, I want to share a protocol called Monad by Keone, who you can follow on Twitter. Keone, a former developer at Jump, is a math whiz who is good at calculations. He posted a forecast on Twitter about the IP-4844 protocol when it goes live, predicting that Arbitrum's TPS will be able to improve to about 160, but whether that number is significant is a matter of opinion. It is also debatable whether there is room for improvement in his calculation method, but we believe that IP-4844 can only improve the performance to a certain extent, and ultimately it still depends on the combination of IP-4844 and Rollup, which may require multiple Rollup to improve the performance. Ip-4844 won't solve much on its own.

For us, the Service we provide is called "Rollup as a Service". As mentioned by Zhang Ye, many applications (such as games and DeFi protocol) require high throughput and they can run on a Rollup when there is no high requirement for composability. These rollups will share a decentralized Sequencer network, and the Prover and Validator networks will also be decentralized. This is our current vision for the service, and we will provide more details next month. Therefore, we believe that the existing IP-4844 or a single Rollup solution cannot solve all the problems, and relying on a large number of Rollup services for different projects and application scenarios is the key.

Ye Zhang:

As for IP-4844, we are studying. Ip-4844 will certainly reduce some data costs. There was a recent discussion on Twitter about the cost of Polygon and zkSync data. Both we and Polygon are now linking directly with raw data from transactions. Optimism and Arbitrum are then chaining with some compression, while zkSync and StarkWare use the more space-efficient State Diff mode. State Diff may save a lot of space for high-frequency operations on the same account. Someone analyzed zkSync's data after using State Diff and found that it did save some money. However, if the data cost is further reduced after IP-4844 or sharding, we still prefer to trade raw data directly on the link, because it allows others to see your data and execute the transaction faster, with stronger guarantees.

We hope that after the data cost is reduced, some compression algorithms will be added, which may achieve a similar effect to the State Diff. But at the moment we prefer to use raw transaction data. As for the impact of IP-4844 on us, it will affect two parts: One is our Bridge, we have started to explore the new bridge design under IP-4844, there will be some impact, need to write a new specification. The other part is in our Circuit, because under the new format, we can not directly access the previous data, only access a small Commitment, so we need to prove the openness of this commitment in the circuit. There's definitely an overhead to the circuit, but we think it's doable.

Implementing EIP-4844 involves a domain issue because the data is on a different curve and may not be quite the same as the native data format. A long time ago, Vitalik came up with a concept of proving equivalence, but later found that there were still problems if the fields were different. Dankrad and Vitalik propose a sophisticated way to incorporate the promised openness into the circuit. We think this change is deterministic and will take time, but it is not particularly complicated and feasible. We need to coordinate at Layer 1 when to implement this change, and then we can adjust accordingly. Until then, we will continue to focus on the current system.

Qi Zhou:

We've done a lot of research on IP-4844. In fact, the purpose of IP-4844 is not to expand capacity, but more to implement a whole set of concepts needed for future Danksharding, including Binary Large objects (bloBs) and their Data hashes. Data hashes can be accessed in the contract to implement these concepts in advance so that Danksharding can be implemented without contract upgrades. The IP-4844 will not be a significant improvement over current Ethereum data linking methods, and our initial estimates suggest that they are in the same order of bandwidth.

However, according to Danksharding specifications, the throughput level is about 20 times. Therefore, assuming we achieve a speed of 100 TPS on IP-4844, Danksharding could theoretically achieve 2000 TPS, or even higher. The Ethereum community, including the Vitalik Buterin and Danksharding teams, is very concerned about the IP-4844 upgrade, because once upgraded, the next major Ethereum upgrade will not require an upgrade to the entire contract system.

Our storage contract is designed directly for the IP-4844 and may actually be simpler in terms of development implementation and storage proof. Using the Danksharding provided by IP-4844, the system is actually pre-calculated and is a very friendly way for us to store.

There can be challenges with techniques such as ZK and Optimism, especially about how to convey data. The etheric fang now there are some tools, including random evaluation way, can the Blob data retransmission in CoreData. There are challenges to prove whether these deals are right.

We plan to provide some common libraries, similar to the OpenZeppelin library, to facilitate various operations on the data blob on the IP-4844. This will bring security and efficiency advantages in terms of audit and Gas consumption.

In short, IP-4844 is innovative and has great potential for the operation of the entire data layer of Ethereum. For those interested in IP-4844, it is recommended to study the Ethereum code and parametric design to better understand how to use this technology.

Topic four: Modular blockchain

Zhixiong Pan:

The last topic is to discuss modular blockchain, which is a hot topic and closely related to the public chain itself. It is a new trend. Although it has been over a year since the beginning of last year, one of the big ideas is that blockchain could gradually be layered, with layers of consensus, execution, DA or settlement. Under such a background, whether the protocol of Layer 2 will face greater challenges and competition, and whether the competition pattern of the whole industry will change greatly.

Jolestar:

I think the modular blockchain is an evolution of Layer 2 thinking. Since at Layer 2 we are moving the execution from Layer 1 to Layer 2, why can't we split up the different modules and let different systems take care of it? This leads to another perspective, which is to take a traditional distributed system, where we have a consensus Layer called Zookeeper and Raft, which is the blockchain equivalent of Layer 1. But unlike the traditional consensus Layer, blockchain Layer 1 can run programs. So now we have our application running in Zookeeper, but we found that the global consensus was that the implementation was too slow, and we needed to move it out and scale it up.

Another perspective is from an application perspective, where we build applications by selecting different system components to perform application functions, such as Zookeeper or MySQL. In fact, we're building the application, not MySQL scaling Zookeeper. This modular blockchain approach can lead to a new perspective on how we can leverage existing Layer 1 resources, together with storage and execution capabilities, to build a basic DApp.

This new perspective does not conflict with existing public chains and components of the production system. We believe that developers first need to choose a suitable language to build applications in, ensuring certainty and verifiability. We chose the Move language for better extensibility. Developers build applications in this language and then figure out how to decentralize. It may not be completely decentralized at first, but you need to be able to decentralize. For example, transactions can be made public so that anyone can verify them. It's still centralized, but it's at least verifiable. A protocol can then be plugged in to guarantee security as a commitment. This step-by-step mechanism provides a new development path for centralized applications.

Dorothy Liu:

I can't agree more with Jolestar. Since last year, we have realized that the industry has evolved from fat application and thin application to fat application and thin protocol. The focus is now shifting from the pursuit of decentralized utopias and technological advances to practical application scenarios. As more and more new applications emerge for gaming, social, etc., people are more focused on what blockchain applications can achieve, rather than just expanding Ethereum or advancing a particular technological direction. While Ethereum is an important L1, as different L1s emerge, people are willing to accept the trade-offs of the multi-chain era.

As a Rollup oriented company or team, we're not just serving the Ethereum community. We want to build a Lego-like technology solution that can be dismantled and assembled to meet the needs of different applications. Some apps may require larger block limits, some game companies may want a Solana VM compatible L2, and someone may want to put DA on Celestia or compatible with EigenLayer. We want to provide a combinable solution that can be tailored to the needs of different applications. We can put L1 on Ethereum, BNB Chain or even Solana, or our own Beacon Layer. Having the proof on Ethereum is important from a security perspective, but the transaction body doesn't necessarily need to be on Ethereum. Moving away from Ethereum's transaction body would significantly reduce costs.

In the fat era, we focus on how to give each application is most suited to its expansion plans, rather than simply optimizing direction. For argument between zkEVM and OP, we can support both sides. We are concerned about the cost of prover for zkEVM, for example Scroll might cost $10,000 a month to run a prover, which might be too expensive for a game vendor. They need more cheap prover scheme, we can provide the use of computers for prover solutions, provide technical solution proposal to the different according to different needs. This is our solution.

Qi Zhou:

From a historical point of view, I agree with the direction of modularity. This includes the OSI hierarchy in the network and computer architecture. By thinking of Ethereum or blockchain as a world computer, we can learn from existing computer systems to better play that role. Because each component has significant market value, Ethereum's Layer 1, for example, can be likened to early cpus, with basic computing power and limited storage capacity. DA, on the other hand, is more like memory.

Between memory and CPU, we need data hashing and precompilation to transfer data. Coredata is similar to a register, and we also need modular plug-ins such as Gpus and other high performance computing devices. In the blockchain network, communication of computational data is realized through DA and zero-knowledge proof. In addition, we need mass storage, copying data from memory to hard disk. Finally, we need a mouse, keyboard, and monitor, similar to the MetaMask and Web3 protocols we use today.

Drawing on the mature computer system and learning from the experience, we can imagine the future computer world system. Of course, we can also connect the hard drive to other computers, such as other Layer 1 devices. However, if a Layer 1 does not have a good DA layer and memory, the speed and bandwidth of data transfer and storage will be greatly limited.

A computer without CPU and memory will not boot, this is a very critical part. With these basic components in place, we can put together devices like Gpus, displays, and hard drives. When developing the EthStorage and Web3 protocols, we support multi-link and modular access to other networks. As long as the network basic execution Layer and Layer DA, they can be other Layer 1 or Layer 2. In the access Layer 2, EthStorage actually to some extent become the Layer 3. This is our vision of the future world of computing or blockchain architecture as a whole.

Ye Zhang:

I think the modular blockchain is really a very important narrative right now, which is the separation of execution and data. However, at least for us, we still view Ethereum as the most important data layer right now. There are various interpretations of the definition of Rollup, as various rollups are appearing. Right now, one definition that most of the community accepts is that you need to publish data to Layer 1 at least, and even if you don't publish proof, you need to publish data to Ethereum in order to inherit Ethereum security. Because most people think that once the data is linked, whether through other nodes, full nodes or light nodes, at least one deterministic result can be obtained, it must be final.

The idea with rollups is that whether you believe the result depends on your choice, your choice of full node or light node. For example, Optimistic Rollup would say "I challenge you", while zkRollup would say "I've always proved you right". Actually, all of this Rollup is just to make a point, to decide whether I trust your data, and whether I trust your money to be bridged from you.

So, at least for us, we want our platform to always trust Ethereum's data layer and stick to doing a Rollup. We will also strive to promote Data Sharding. I think the only thing to focus on is the timing of when it will happen and how long it will take. Until then, do we need to take transitional measures? This depends on our estimation of the timeline of the data shard. If we estimate that it will take five years to achieve, then we may take some intermediate measures. But if we think it's going to happen in a reasonable timeframe, we're still going to stick to that direction.

Over-modularity may not be a good thing. When we observed the situation of Layer 2 before, there might be only nine Layer 2, each of which has its own security attributes, such as whether the contract is upgradable, whether Sequencer is decentralized, whether it is open source and whether it has been audited. At Layer 2, these security attributes are tricky. For example, in the case of scalable contracts, if a less compliant Rollup does something bad, it may be discovered in an instant. If the public does not understand the properties of different rollups and the trade-offs between them, and there are already 100 rollups to choose from, some security issues may arise. So, I think you'll probably end up with a few major rollups that have absolute security, some assurance about their properties, and good composability. On this basis, it is possible to relieve the pressure of Layer 2 either by developing Layer 2 of some application layers in parallel or deploying Layer 3 on it. At this point, they can choose to use other data layers or other methods, and as long as the community has a consensus, they can innovate as they want.

However, we want to be the Layer 2 that best meets the needs of the community and help with some research and some engineering. We want our platform to be absolutely secure, absolutely decentralized, and on top of that we can do all kinds of innovation, crazier innovation or whatever.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia