@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
msfewzk, zkVM, zkEVM and their Future
TL; DRZero-knowledge proof, which can guarantee computational integrity, correctness and privacy, has a lot of use cases in blockchain scaling and privacy.zk-SNARK and zk-STARK have their own advantages, and the combination of these two has more potential.zkVM empowers applications with zero-knowledge proofs, and zkVM can be categorized by instruction sets in mainstream, EVM, or newly-built ones.EVM compatibility includes EVM compatibility, equivalence, and specification-level compatibility.z...
msfew(Almost) Everything about Rollup
This post focuses on the Layer2 Rollup universe of Ethereum (only including Secured Rollup), and will explore the good and bad of the current Rollups from the core concepts and mechanism design in an easy-to-understand way, and think about the potential routes and advantages and disadvantages of each of their future solutions in terms of decentralization, further scaling, composability, and additional features such as privacy. A Secured Rollup is a Rollup model like Arbitrum or Optimism, wher...
msfew「Unified to Divided」Modular Blockchain and Data Availability Layer
0. Rollup’s BottleneckIf you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup. The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:Different types of Secured Rollups have different bottlenecks at different stages, ...
@HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror
Subscribe to msfew
Subscribe to msfew
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
As the Rollup narrative is gaining attention and the industry as a whole is demanding better performance, more sovereignty, and easier deployment from App-chains. StarkEx’s App-rollup service, Celestia’s reusable Layer1 security layer, and other high-performance DA solutions have become the mainstream choices in building App-chains.
In the past, App-chain = App as an L1: Before, an application had to make a chain entirely by itself, which cost a lot in development. If it was a PoS mechanism, then there was an additional capital expenditure to start the initial nodes. Despite the existence of various SDKs and consensus engines, building a blockchain is still a huge hassle.
Now and then, App-chain = App as an L1 + App as a Rollup + App as a Validium…: There are 25 Layer2 based on Ethereum alone. These include half of the App-chains (or App-rollups, like the former dYdX) and generic Layer2 Rollups (like Arbitrum). As projects like Celestia production-ready, I think many times more new rollups will be built in the future.
In addition, App-L1 on Cosmos and Subnet on Avalanche will also come up.
Whether existing application protocols are turned into App-chains (like Uniswap can be turned directly into Unichain), or applications are started directly as App-chains (dYdX started as App-rollup, turned into App-L1), it eventually means that there could be dozens of new chains (L1, App-chain, App-rollup, Subnet) in the next year or two.
Recently, Dan Elitzer analyzed why Uniswap must turn into a separate application chain.
The seven-day average fee charged by the Uniswap protocol is second only to the Ethereum mainnet, and is the sum of BSC, Aave, Bitcoin, and GMX. As such a stable, well-run AMM protocol that is used by everyone, why might Uniswap go from an on-chain protocol to an App-chain?
There are four main benefits for Uniswap:
The UNI token is essentially a Meme Coin, which can currently only be used for governance purposes. For UNI holders, this largely prevents the value of UNI from directly capturing the growth and benefits of the Uniswap protocol and ecosystem. The root cause I believe is primarily a regulatory issue. Due to the sensitive nature of the product itself, Uniswap’s organizational structure is unique for compliance purposes.
Uniswap V2 and V3 both have the concept of a Protocol Fee, but for now this fee switch is not flipped on by governance. If it were, then intuitively, it could directly generate hundreds of millions of dollars a year for UNI holders (not considering the side effects on LP revenue and liquidity). This is a huge bonus to the value of UNI tokens.
Also, if Uniswap becomes a PoS chain, then UNI tokens can be used as network staking tokens and gas tokens, which can have a very positive effect on the value capture of UNI.
For a Uniswap Pool, the two most intuitive participants are the user and the LP, but for the use of the entire protocol, the participants also include the network nodes and the MEV Bots.
For a user, there are many transparent and opaque fees for making a swap:
Swap Fee: Paid to Liquidity Provider. ~0.171%.
Gas Fee: Paid to the Ethereum network nodes. ~0.235%.
MEV Tax: Paid to MEV Bots and Ethereum nodes (more than 50% of the volume in the above chart is MEV Bot, who secretly raid users’ revenue). ~0.254%.
Together, these fees are very high compared to centralized exchanges.
For all three fees, Uniswap currently has no way to directly regulate them.
However, if Uniswap is converted to an App-chain, then the Gas Fee and MEV Tax can be optimized directly:
Gas Fee: Paid to UNI network nodes. < 0.235%
MEV Tax: Paid to MEV Bots and UNI network nodes. Also the sum of MEV Tax can be reduced by a new mechanism. < 0.254%
In this way, Uniswap can take the initiative over the fees and the economic mechanism of the agreement, and proactively regulate the economic mechanism through governance and other means.
As a stand-alone App-chain, Uniswap can be built entirely with new technologies, regardless of the technical dimensions of EVM compatibility, smart contract deployment, etc. All on-chain experiences are directly empowered by the protocol’s functionality and the construction of the protocol’s ecosystem.
For the users, they can experience:
Higher TPS: The chain can be optimized specifically for transactions and other operations.
Lower fees: lower MEV Tax + lower or even 0 Gas Fee like the future version of dYdX.
Better overall system: the ecosystem will be built more vertically, all for the chain and Uniswap itself.
Just like dYdX fleeing from StarkEx, Uniswap, if it becomes an App-chain, can gather the above advantages and take more initiative over its own tokens, the functionality and upgrades of the entire protocol, the governance of the entire network and protocol, and the construction and infrastructure of the entire ecosystem.
If Uniswap becomes an Ethereum-based App-rollup, there are more advantages, such as greater performance improvement, faster and lighter construction of the whole blockchain, and not too distant from the Ethereum ecosystem.
However, the other advantages may be weakened, such as the need to return most of the value (~60% of the total L2 cost) to Layer1 as DA fee, the gas dee expenses could not be reduced more significantly, and in the case of a single sequencer, this would mean that most of the MEV Tax is captured by it.
Despite all the advantages of the application chain form, there are several minor disadvantages compared to the on-chain application form, which leads to the interoperability issue we will discuss in the next section:
A blockchain must have social consensus. In the current situation, if an application comes out of nowhere and goes live as a blockchain, it is difficult to have consensus. That’s why many applications are coming to the Ethereum network in the form of protocols or rollups, taking advantage of the security and social consensus that Ethereum already has.
Take Uniswap for example, as an application named by Vitalik, it is very deeply tied to Ethereum, and if it “escapes” from the main Ethereum network, it will be met with a lot of resistance from Ethereum and users.
At the same time, the strength of Uniswap is the permissionless issuance of assets (ERC-20) on the largest global unlicensed decentralized network (Ethereum), which would be slightly less attractive if it became an issuance of assets on its own chain. In contrast, a dedicated trading platform like dYdX makes more sense as an application chain.
Going back to the point we made at the beginning, there will be dozens of new App-L1s, App-rollups, App-subnets. If they all become blockchains and form their own network, then the difference of Web3 world with the Web2 network will be even smaller…
I also think that many of these App-rollups in the App-chain will become Sovereign Rollups. Then they don’t have their own trust-minimized bridges (or) rooted from the same Layer1, and thus use Layer1 as an interoperability layer. They need an architecture like Cevmos to interoperate with other clusters or networks with IBCs via the trusted bridge, which is less architecturally simple and a newer concept.
I think this looks really good, but it’s a lot of work to actually implement. The Secured Rollup on Ethereum only needs to build its own L1-L2 bridge, but now it needs the Evmos Settlement Layer to build a bridge with other networks (or between several Evmos).
For the interoperability problem, take Uniswap as an example, in extreme case, if its main protocol becomes an App-chain, people may have to bridge tokens to it first, then swap, and then bridge back again when they want to get the best offer.
For the solution of interoperability in the era of App-chain + Multi-chain, I can think of the most effective solutions:
1. Actively fork protocols onto each chain
This is a continuation of the current Uniswap scheme, where a new Uniswap protocol is still deployed on each chain. The App-chain is then used as a dedicated add-on for trading. This is actually similar to what USDT, USDC and other assets do.
This approach doesn’t solve the problem. It doesn’t solve interoperability. It just clones itself several times, each protocol has fragmented liquidity and trading activity. They all just run under the name Uniswap.
However, I am actually in favor of this solution, and not against it. Because liquidity is just as fragmented in the Web2 system. Or McDonald has forks in every city (though it certainly doesn’t need to make its own “App-chain”).
1. Connect IBC for each chain
Every application chain (and chain) is connected to IBC is a very simple and brute-force solution that solves the interoperability problem directly.
The disadvantage of this solution is that:
Existing chains may not be directly connected (e.g. Ethereum requires ZK if it wants to connect to IBC). Cosmos chains may not have enough performance (so we need App-rollup)
The user experience is actually not as good as the previous solution (although IBC is fast, it still takes more than 10 seconds to come and go, so the two methods may need to be combined)
2. Trust-minimized bridge for each chain
Let’s just ignore the interworking solutions that are not trust-minimized bridge. To make blockchains interoperable and secure, we need light client bridge (essentially the same principle as IBC), or trustless bridge between L3s.
The difficulty with this solution is that the overhead of various validations (Validator, Signatures) is too high to be executing on-chain (EVM). But validating ZKP is much less expensive, so recently there are many working on ZK Light Client.
I strongly agree with this direction, but it is more difficult to implement than the last one, which is a very long-term solution.
There is a definite trend for on-chain applications to become application chains, leading to better sovereignty, token value capture, and on-chain experience enhancement.
However, the addition of dozens of chains creates liquidity fragmentation and interoperability issues. This problem can be solved either through fork infrastructure to different chains, or by using trustless interoperability solutions.
The boom in App-chains represents a closer move to the Web2 era of “self-governed” applications, but it still does not change the general direction of decentralization and open transparency.
0:
Track total value secured across Ethereum scaling solutions.
1:
Uniswap presents a compelling case study to help builders who aren't yet thinking about appchains understand why they'll eventually have to consider them
https://docs.uniswap.org/protocol/concepts/V3-overview/fees#protocol-fees
2:
Introduction A monolithic chain where everyone executes every transaction is inherently not scalable. Indeed, this is why almost every major ecosystem is
3:
Authors: Garvit Goel, Jinank Jain (Electron Labs) This is an article on how to bring IBC to Ethereum. The goal of the article is to provide an overview of the technical details of this project and gather support from the Ethereum community. Let's dive into it.
https://geometryresearch.xyz/notebook/the-road-to-slush
As the Rollup narrative is gaining attention and the industry as a whole is demanding better performance, more sovereignty, and easier deployment from App-chains. StarkEx’s App-rollup service, Celestia’s reusable Layer1 security layer, and other high-performance DA solutions have become the mainstream choices in building App-chains.
In the past, App-chain = App as an L1: Before, an application had to make a chain entirely by itself, which cost a lot in development. If it was a PoS mechanism, then there was an additional capital expenditure to start the initial nodes. Despite the existence of various SDKs and consensus engines, building a blockchain is still a huge hassle.
Now and then, App-chain = App as an L1 + App as a Rollup + App as a Validium…: There are 25 Layer2 based on Ethereum alone. These include half of the App-chains (or App-rollups, like the former dYdX) and generic Layer2 Rollups (like Arbitrum). As projects like Celestia production-ready, I think many times more new rollups will be built in the future.
In addition, App-L1 on Cosmos and Subnet on Avalanche will also come up.
Whether existing application protocols are turned into App-chains (like Uniswap can be turned directly into Unichain), or applications are started directly as App-chains (dYdX started as App-rollup, turned into App-L1), it eventually means that there could be dozens of new chains (L1, App-chain, App-rollup, Subnet) in the next year or two.
Recently, Dan Elitzer analyzed why Uniswap must turn into a separate application chain.
The seven-day average fee charged by the Uniswap protocol is second only to the Ethereum mainnet, and is the sum of BSC, Aave, Bitcoin, and GMX. As such a stable, well-run AMM protocol that is used by everyone, why might Uniswap go from an on-chain protocol to an App-chain?
There are four main benefits for Uniswap:
The UNI token is essentially a Meme Coin, which can currently only be used for governance purposes. For UNI holders, this largely prevents the value of UNI from directly capturing the growth and benefits of the Uniswap protocol and ecosystem. The root cause I believe is primarily a regulatory issue. Due to the sensitive nature of the product itself, Uniswap’s organizational structure is unique for compliance purposes.
Uniswap V2 and V3 both have the concept of a Protocol Fee, but for now this fee switch is not flipped on by governance. If it were, then intuitively, it could directly generate hundreds of millions of dollars a year for UNI holders (not considering the side effects on LP revenue and liquidity). This is a huge bonus to the value of UNI tokens.
Also, if Uniswap becomes a PoS chain, then UNI tokens can be used as network staking tokens and gas tokens, which can have a very positive effect on the value capture of UNI.
For a Uniswap Pool, the two most intuitive participants are the user and the LP, but for the use of the entire protocol, the participants also include the network nodes and the MEV Bots.
For a user, there are many transparent and opaque fees for making a swap:
Swap Fee: Paid to Liquidity Provider. ~0.171%.
Gas Fee: Paid to the Ethereum network nodes. ~0.235%.
MEV Tax: Paid to MEV Bots and Ethereum nodes (more than 50% of the volume in the above chart is MEV Bot, who secretly raid users’ revenue). ~0.254%.
Together, these fees are very high compared to centralized exchanges.
For all three fees, Uniswap currently has no way to directly regulate them.
However, if Uniswap is converted to an App-chain, then the Gas Fee and MEV Tax can be optimized directly:
Gas Fee: Paid to UNI network nodes. < 0.235%
MEV Tax: Paid to MEV Bots and UNI network nodes. Also the sum of MEV Tax can be reduced by a new mechanism. < 0.254%
In this way, Uniswap can take the initiative over the fees and the economic mechanism of the agreement, and proactively regulate the economic mechanism through governance and other means.
As a stand-alone App-chain, Uniswap can be built entirely with new technologies, regardless of the technical dimensions of EVM compatibility, smart contract deployment, etc. All on-chain experiences are directly empowered by the protocol’s functionality and the construction of the protocol’s ecosystem.
For the users, they can experience:
Higher TPS: The chain can be optimized specifically for transactions and other operations.
Lower fees: lower MEV Tax + lower or even 0 Gas Fee like the future version of dYdX.
Better overall system: the ecosystem will be built more vertically, all for the chain and Uniswap itself.
Just like dYdX fleeing from StarkEx, Uniswap, if it becomes an App-chain, can gather the above advantages and take more initiative over its own tokens, the functionality and upgrades of the entire protocol, the governance of the entire network and protocol, and the construction and infrastructure of the entire ecosystem.
If Uniswap becomes an Ethereum-based App-rollup, there are more advantages, such as greater performance improvement, faster and lighter construction of the whole blockchain, and not too distant from the Ethereum ecosystem.
However, the other advantages may be weakened, such as the need to return most of the value (~60% of the total L2 cost) to Layer1 as DA fee, the gas dee expenses could not be reduced more significantly, and in the case of a single sequencer, this would mean that most of the MEV Tax is captured by it.
Despite all the advantages of the application chain form, there are several minor disadvantages compared to the on-chain application form, which leads to the interoperability issue we will discuss in the next section:
A blockchain must have social consensus. In the current situation, if an application comes out of nowhere and goes live as a blockchain, it is difficult to have consensus. That’s why many applications are coming to the Ethereum network in the form of protocols or rollups, taking advantage of the security and social consensus that Ethereum already has.
Take Uniswap for example, as an application named by Vitalik, it is very deeply tied to Ethereum, and if it “escapes” from the main Ethereum network, it will be met with a lot of resistance from Ethereum and users.
At the same time, the strength of Uniswap is the permissionless issuance of assets (ERC-20) on the largest global unlicensed decentralized network (Ethereum), which would be slightly less attractive if it became an issuance of assets on its own chain. In contrast, a dedicated trading platform like dYdX makes more sense as an application chain.
Going back to the point we made at the beginning, there will be dozens of new App-L1s, App-rollups, App-subnets. If they all become blockchains and form their own network, then the difference of Web3 world with the Web2 network will be even smaller…
I also think that many of these App-rollups in the App-chain will become Sovereign Rollups. Then they don’t have their own trust-minimized bridges (or) rooted from the same Layer1, and thus use Layer1 as an interoperability layer. They need an architecture like Cevmos to interoperate with other clusters or networks with IBCs via the trusted bridge, which is less architecturally simple and a newer concept.
I think this looks really good, but it’s a lot of work to actually implement. The Secured Rollup on Ethereum only needs to build its own L1-L2 bridge, but now it needs the Evmos Settlement Layer to build a bridge with other networks (or between several Evmos).
For the interoperability problem, take Uniswap as an example, in extreme case, if its main protocol becomes an App-chain, people may have to bridge tokens to it first, then swap, and then bridge back again when they want to get the best offer.
For the solution of interoperability in the era of App-chain + Multi-chain, I can think of the most effective solutions:
1. Actively fork protocols onto each chain
This is a continuation of the current Uniswap scheme, where a new Uniswap protocol is still deployed on each chain. The App-chain is then used as a dedicated add-on for trading. This is actually similar to what USDT, USDC and other assets do.
This approach doesn’t solve the problem. It doesn’t solve interoperability. It just clones itself several times, each protocol has fragmented liquidity and trading activity. They all just run under the name Uniswap.
However, I am actually in favor of this solution, and not against it. Because liquidity is just as fragmented in the Web2 system. Or McDonald has forks in every city (though it certainly doesn’t need to make its own “App-chain”).
1. Connect IBC for each chain
Every application chain (and chain) is connected to IBC is a very simple and brute-force solution that solves the interoperability problem directly.
The disadvantage of this solution is that:
Existing chains may not be directly connected (e.g. Ethereum requires ZK if it wants to connect to IBC). Cosmos chains may not have enough performance (so we need App-rollup)
The user experience is actually not as good as the previous solution (although IBC is fast, it still takes more than 10 seconds to come and go, so the two methods may need to be combined)
2. Trust-minimized bridge for each chain
Let’s just ignore the interworking solutions that are not trust-minimized bridge. To make blockchains interoperable and secure, we need light client bridge (essentially the same principle as IBC), or trustless bridge between L3s.
The difficulty with this solution is that the overhead of various validations (Validator, Signatures) is too high to be executing on-chain (EVM). But validating ZKP is much less expensive, so recently there are many working on ZK Light Client.
I strongly agree with this direction, but it is more difficult to implement than the last one, which is a very long-term solution.
There is a definite trend for on-chain applications to become application chains, leading to better sovereignty, token value capture, and on-chain experience enhancement.
However, the addition of dozens of chains creates liquidity fragmentation and interoperability issues. This problem can be solved either through fork infrastructure to different chains, or by using trustless interoperability solutions.
The boom in App-chains represents a closer move to the Web2 era of “self-governed” applications, but it still does not change the general direction of decentralization and open transparency.
0:
Track total value secured across Ethereum scaling solutions.
1:
Uniswap presents a compelling case study to help builders who aren't yet thinking about appchains understand why they'll eventually have to consider them
https://docs.uniswap.org/protocol/concepts/V3-overview/fees#protocol-fees
2:
Introduction A monolithic chain where everyone executes every transaction is inherently not scalable. Indeed, this is why almost every major ecosystem is
3:
Authors: Garvit Goel, Jinank Jain (Electron Labs) This is an article on how to bring IBC to Ethereum. The goal of the article is to provide an overview of the technical details of this project and gather support from the Ethereum community. Let's dive into it.
https://geometryresearch.xyz/notebook/the-road-to-slush
New Blogpost
medium.com/@ingonyama/bri… 
to @kobigurk, @jtguibas, @pumatheuma, @garvitgoel03 for discussion & comments
New Blogpostmedium.com/@ingonyama/bri… to @kobigurk, @jtguibas, @pumatheuma, @garvitgoel03 for discussion & comments
No activity yet