msfew https://paragraph.com/@msfew @HyperOracle, Prev @ForesightVen, @Google, @UnionPay Recent research is at HyperOracleBlog.eth's Mirror Mon, 06 Apr 2026 10:18:41 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en msfew https://storage.googleapis.com/papyrus_images/42dec7e8566d8fff68668bf4ed1e7fbdf9ceb656b8294ccaf3513070e7438337.jpg https://paragraph.com/@msfew All rights reserved <![CDATA[Bitcoin MEV]]> https://paragraph.com/@msfew/bitcoin-mev NQlAnm6CjcOG5u58tLKW Sat, 06 Jul 2024 14:32:55 GMT

“wen flashbots mev-bitcoin fork?” It’s here.

Explore Bitcoin MEV and @RebarLabs, the project that came out of stealth to build MEV-aware products and infrastructure for Bitcoin.

MEV & Bitcoin?

You might wonder shouldn't MEVs only exist on networks with smart contracts that can run DeFi or DEX?

MEVs have always existed on Bitcoin (like intentional empty blocks by miners), and the emergence of Ordinals and Bitcoin L2 has created new MEVs.

Bitcoin L2 → MEV

Ordinals add programmability to Bitcoin, but this also creates opportunities for MEV, eg. miners front-run transactions to mint BRC-20.

MEVs like these will grow as these ecosystems develop. More research and coordination are needed.

When Flashbots for Bitcoin?

People like @eawosikaa, @Data_Always, and myself (@msfew_eth) have been asking when Flashbots for Bitcoin to handle MEV.

@0xTaker whetted my appetite, and finally, @RebarLabs came out of stealth to be the first to work on it.

@RebarLabs, MEV-aware products and infrastructure for Bitcoin

Rebar Labs is building infrastructure (alt mempool with private tx), products (data and dashboards), and providing research.

These products will ensure Bitcoin's core principles.

Building Infrastructure for Bitcoin * Rebar Labs

Rebar Labs empowers Bitcoin's ecosystem to address MEV, ensuring fair and transparent markets for users and miners.

https://rebarlabs.io

Looking forward to what Rebar has in store for us!

Here are some more Bitcoin MEV stuffs:

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[500k Block Reorg on L3 WTF]]> https://paragraph.com/@msfew/500k-block-reorg-on-l3-wtf HrnaephebwwEdYxd4cK5 Tue, 14 May 2024 04:51:34 GMT

What happened to @degentokenbase's 500,000 Block Reorg on an L3?

Learn more about L3, Rollup Reorg, and RaaS… 👀 ⬇️

Degen Chain 🎩 (@degentokenbase), an L3, experienced a 500k block reorg 🤯.

The issue is due to a custom config change by Conduit, the rollup service provider for Degen chain.

Degen Chain is an L3 built with @arbitrum Orbit, @base for settlement, and AnyTrust for DA.

My favorite mental model (by @hdevalence) for L3 is that they are just "L2 on top of L2".

What is Degen Chain’s Reorg?

This is not a typical L1 blockchain reorg (nodes disagree on the most accurate version of the chain), but forced inclusion is not operated correctly (batches are not posted to base layer, in this case, from Degen to Base).

L3’s Reorg Problem.

So why do L3 reorgs happen (from @donnoh_eth)?

  • L3 posts different batch to L2 from soft confirmation (today’s case)

  • L2 reorgs itself

  • L1 reorgs so L2 reorgs

Besides dunking, this issue points out open problems:

  • Why trusting the managed sequencer to be honest? (from @0xMawuko)

  • How to resolve reorgs when L2s and L3s are actually decentralized?

  • What if RaaS goes wrong?

  • What if L1 or L2 goes wrong?

  • ……

Anyways, luckily users’ funds are safe. Nothing is breaking or missing.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Security Layer / Circuit Breaker for Smart Contracts]]> https://paragraph.com/@msfew/security-layer-circuit-breaker-for-smart-contracts ncbIKS1GGTbwYgbh02iI Sat, 04 May 2024 05:26:57 GMT

The security of smart contracts can be enhanced not just with auditors and bounty platforms, but also by adding ✨ Circuit Breaker as extra security layer ✨.

Find out more about Circuit Breakers and security projects for on-chain smart contracts in the thread below. 🧵⬇️

Why Circuit Breakers for Smart Contracts?

Hacks in DeFi usually happens immediately (hacker transfer all funds in 1 tx).

When team puts thru recovery plan with governance, it is too late.

“DeFi Protocols won't have ~30% daily TVL drawdowns unless hacked” (by @MeirBank)

Zerem: DeFi Circuit Breaker by @high_byte

Zerem secures protocols by thresholding the transfer of large funds in temporary vault, to secure the protocol if immediate failure happens.

ERC-7265: Circuit Breaker by @MeirBank, @Diyahir, @tcb_00, @real_philogy

ERC-7265 standardizes a circuit breaker protecting onchain protocol, with highly customized rate limit parameters per asset.

Besides the above purely onchain circuit breakers, we also see some novel implementations leveraging the technology of restaking by @EigenLayer or ZKP. 👀

ODIN: Pause dapps before malicious tx is executed by @blocksek, @zk_asv

ODIN is a security service that uses EigenLayer to bond block builders to follow the rules of ODIN.

ODIN Deep Dive

Block Builders Bonded? > Malicious ones will be slashed based on restaking, thus they are economically aligned.

What Rules? > A property of system that should always hold. Eg: sum of lend txs - sum of borrow txs = tokens left in contract

GitHub - anupsv/odin

Contribute to anupsv/odin development by creating an account on GitHub.

https://github.com

HoneyPause: Proactive defense for protocols by @merklejerk

HoneyPause combines onchain bounty with circuit breaker, with the workflow of PROVE an exploit, PAUSE the protocol, Get PAID a bounty.

ODESEC: Onchain Database of Emergency Security Event Contact by @SecurFi

ODESEC takes security layer to another level. ODESEC utilizes zk-proof of exploit for whitehats to blow whistle for alert, and ZK SSL for identifying the hacked project.

That's all for now on the topic of Circuit Breakers in the world of DeFi.

Safeguarding your smart contracts is not just about auditing, but also about having the right security layers in place.

Stay SAFU!

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Parallel EVM, Restaking, zkVM in 1 Day]]> https://paragraph.com/@msfew/parallel-evm-restaking-zkvm-in-1-day iQWDlavREaEv4I39MO3Y Wed, 10 Apr 2024 08:03:54 GMT

/twitter.com/ProofOfTrack/status/1777969638586106163

🤯 In one day, we saw three big announcements.

Parallel EVM: @Monad_xyz Huge Raise Led by @Paradigm

Restaking: @EigenLayer @Eigen_DA Mainnet (also @Karak_Network)

zkVM: @a16z Released Jolt

Let's explain 1 by 1 ⬇️

[Parallel EVM] 🏎️

@Monad_xyz has been active in the Parallel EVM space.

It’s about scaling to 10,000 TPS (⚡️) by breaking the execution bottleneck of EVM.

The team announced $225M fundraise, led by @Paradigm.

[Parallel EVM] 🏎️

@Paradigm has been bullish about Parallel EVM.

Now they found the team to execute on this idea.

[Parallel EVM] 🏎️

What else is interesting about this?

Haseeb posted something controversy and considered “shilling bags on ct”.

Here’s a response by @jtriley_eth on pointing out some of the “offs”.

[Parallel EVM] 🏎️

A misconception about Monad is that: @Monad_xyz is all about “parallel execution”.

But Monad is more than that, see explanation by @kenoeHD. 🫡

[Restaking] 🏦

@EigenLayer announced mainnet of @Eigen_DA.

Now restakers can “really restake” into actual running AVS of EigenDA.

[Restaking] 🏦

However, it’s just mainnet, no token.

The most important question for @EigenLayer: Wen Token? 🥺

[Restaking] 🏦

A competitor to @EigenLayer, @Karak_Network raised 48M at 1B valuation.

Difference is Karak can enable restaking for every chain every asset.

On Karak, @chainyoda posted a lot of hot takes 🔥, pointing out some weakness in its design.

[Restaking] 🏦

It all comes down to one question that 5 months ago @smyyguy asked.

Q: Why @EigenLayer only takes ETH for restaking, not all assets?

A: It’s about the convergence and same stake asset for pooled security. 🙏

[zkVM] 🧮

@a16z open-sourced Jolt: outperforms @RISCZero by ~6x and @SuccinctLabs SP1 by up to 2x.

TL;DR: a16z overtakes the zkVM industry as a VC. 👀

[zkVM] 🧮

Kinda in response to this, @RISCZero posted a feature comparison of zkVM, revealing that R0 is the most production-ready one.

[zkVM] 🧮

On this, the fast-forwarded development on zkVM is crazy.

Let’s focus on adoption more, than competition.

Anyway, this is just another day in Crypto. It’s just has more exciting news.

Follow me here, and subscribe the newsletter at proofoftrack[dot]xyz.

Stay hydrated! 😇

Proof Of Track | msfew | Substack

web3, zk, blockchain, ai... msfew's weekly notes. Click to read Proof Of Track, by msfew, a Substack publication with hundreds of subscribers.

https://www.proofoftrack.xyz
]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[EigenLayer Native Staking TVL]]> https://paragraph.com/@msfew/eigenlayer-native-staking-tvl Xp6NaFERH3IMl4Xc8EcK Mon, 01 Apr 2024 17:19:07 GMT

👀 @EigenLayer mainnet soon.

🤯 Heard rumor that “ETH staked on EigenLayer are not really staked on EigenLayer”.

🤨 Is that true? Spoiler: It’s kinda true, but kinda false.

⬇️ 🧵

✌🏿 Two types of restaking on EigenLayer

Liquid restaking with LSD is, no doubt, staking on EigenLayer cuz you go to their frontend to restake into their smart contract.

What about Native Restaking?

https://docs.eigenlayer.xyz/eigenlayer/restaking-guides/restaking-user-guide/

Native Restaking is with native ETH and your validator with 32 ETH in the Ethereum consensus layer.

It is more complicated than pressing the buttons on EigenLayer frontend.

You need to…

You need to:

  • create your EigenPod contract

  • grant some power to AVS over this EigenPod

  • set your withdrawal address from the CL to this EigenPod

And

  • slashing only happens when you exit your validator from CL

😇 This makes it feel like:

  • Your restaked is not really in EigenLayer like restaked LSD, because it’s on EigenPod (actually still with EigenLayer)

  • Calculating those TVL is kinda hard, because you need to calculate TVL on EigenPod with CL withdraw address, then minus the “slashed” TVL

🫡 Check @jordanmmck’s thread on understanding EigenLayer if you are still confused.

One of the best explainer.

✨ Also, check out this dashboard for data by @ratednetwork on TVL of Native Restaking.

Always fun to see those rare data point!

https://explorer.rated.network/restaking?network=mainnet&timeWindow=7d

🧵 For more on EigenLayer, check out their post of threads.

🤭 I really wanna write up some spicy stuff on EigenLayer & Restaking on its security or future slashing events.

But I’m reaching the tweet word limit, so will do it in the future..

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[L2Beat for Bitcoin L2]]> https://paragraph.com/@msfew/l2beat-for-bitcoin-l2 9ymhGlPKdzIiSJXuQCqz Sat, 23 Mar 2024 07:35:15 GMT

👀 Since Inscription and Ordinal, Bitcoin L2 is proliferating, even more so than Ethereum L2.

🥺 We need a neutral and reasonable mechanism to analyze these Bitcoin L2s.

✨ Fortunately these "@l2beat for Bitcoin L2" are emerging. 🧵

🫡 The security analysis and decentralization evaluation of Ethereum L2 has been led by @L2beat, and recently @growthepie.

These guys are doing legendary work on publicizing informations on Ethereum L2 for anyone.

🧠 Bitcoin L2 enters the realm of L2 as a brand new species.

🤯 The paradigm of Bitcoin L2 is completely different from Ethereum L2, so we need a new way of analyzing it.

  • Bridge Security

  • Degree of decentralization

  • Execution / DA Layer Difference

  • ……

👀 Today, we see the following projects focused on analyzing the progress of the Bitcoin L2 ecosystem:

  • @BitcoinRollups

  • @BitcoinLayers

  • @Blockchair’s L2 Watch

  1. @BitcoinRollups is an educational resource covering Bitcoin rollups.

You can find educational materials here. This can help you get the general ideas and concepts of Bitcoin Rollup and L2.

https://www.bitcoinrollups.io/

  1. @BitcoinLayers further explores the different layers (or protocols) of Bitcoin L2.

You can know more about the L2 paradigms and designs of Bitcoin L2.

Bitcoin Layers

Documenting Bitcoin Layers

https://www.bitcoinlayers.org

  1. @Blockchair’s L2 Watch tracks the booming L2 Bitcoin ecosystem.

You can find almost all the Bitcoin L2 projects and their basic intro here. This is a super helpful landscape view for Bitcoin L2.

https://l2.watch/

👀 Additionally, there are some public views and opinions on categorizing Bitcoin L2:

  • @BitcoinMagazine’s Editorial Policy

  • @hosseeb’s discussion

  • @januszg_’s view

  1. @BitcoinMagazine published editorial policy on Bitcoin L2 coverage.

@BobBodily’s TLDR, and he also listed a few evaluations on Ethereum L2 perspective for implementing them on Bitcoin:

  1. L2 cannot have its own token

  2. Must be able to bridge back to L1

  3. Cannot function without Bitcoin

  4. Meta-protocols are ok (Ordinals, BRC-20)

  1. @hosseeb raised the question “What are your feelings on Bitcoin L2s?”

@BobBodily in the discussion gave a clear picture on what we can build for Bitcoin L2, and what’s not possible right now.

  1. @januszg_ pointed out the cool stuff happening in the Bitcoin scaling space, along with scams and noises.

🥺 Go back to @L2Beat. They extends to spaces outside L2 (the rollup layer) itself, such as L2’s Bridge, and probably Validium (https://twitter.com/bkiepuszewski/status/1768362982457639031).

Wen L2Beat for Bitcoin L2s by L2Beat?

🫡 All in all, we definitely need more public resources and education in any space in Crypto, especially L2!

🔥 Bitcoin L2 is going great!

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[zkOracle and zkCoprocessor]]> https://paragraph.com/@msfew/zkoracle-and-zkcoprocessor FrLHWa5IFItGrwZf07pT Wed, 29 Nov 2023 16:35:37 GMT I've been talking to Hill about the differences between HyperOracle zkOracle and zkCoprocessor.

Finally we have a detailed definition and comparison!

TLDR: zkOracle = zkCoprocessor (historical data access type) + zkCoprocessor (zkVM compute type).

https://mirror.xyz/sevenxventures.eth/_JMWKYVob9x3COlO7V2k71pN_pZORc4DVcByhfU0ZaQ

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

The equation will be changing. Stay tuned!

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[People's Views on Uniswap Swap Fee]]> https://paragraph.com/@msfew/people-s-views-on-uniswap-swap-fee aS4bDq5QzHILaUGN14cx Tue, 17 Oct 2023 18:50:09 GMT Background

On a limited set of token pairs, Uniswap Labs starts to charge a flat fee of 0.15% to sustainably fund Uniswap’s operations.

This is separate from the Uniswap Protocol fee switch, which is voted on by Uniswap governance (proposals, working groups, temperature checks, signal polls, temporary trial periods for thee).

Hayden said “users have countless choices of ways to use it, through aggregators, other UIs, or by interacting directly with the smart contracts. Imo our interface remains the best”.

There are many different perspectives on this event. I will start from different perspectives, collect other people's thoughts, and then express my own.

Opinion on Governance & Decentralization

At the governance level, much of the discussion centered on the fact that Uniswap has a set of governance tools in place to make changes to the protocol, and that this incident was unique in that it was a change to the front-end, and therefore did not go through the governance process.

$UNI is useless

  • @fishkiller pointed out the governance token is still kinda useless.

  • @tmel0211 summarized that Uniswap's Governance Token may be isolated indefinitely.

  • @twobitidiot said “The Uniswap proposal sucks, and benefits VCs and insiders over holders.”

  • @FreddieRaynolds said “they enabled the wrong fee switch. 0.15% to Uniswap labs equity owners not $UNI token holders.”

  • @spreekaway implied that UF will dump on $UNI holders when they get the fee.

  • @0xSisyphus thought that “all Uniswap would have to do is direct the tiny revenue stream to the token and everything would be fine” and we “can safely assume everyone working at uniswap has sold all of their tokens by now”

Not going through governance is fine

Not going through governance is bad

  • @0xmillie_eth mocked that “this is not a proposal, it's a decree, taking effect right away”, and “haha the fee turns on tomorrow for me”.

  • @AntonioMJuliano from dYdX said “some of the OG major DeFi players (Uniswap, 0x) that started more decentralized are becoming relatively more centralized”.

Opinion on Fork & Frontend

Uniswap Interface will still be used

  • @cronokirby thought people will still use the Uniswap interface, and “just pay the fee cause they're sort of lazy”.

  • @Mudit__Gupta asked “Ser do you know how many people use fox wallet swap?”, and implies that Uniswap Interface will still be used just like the “expensive” Metamask Swap.

  • @0xdoug said the Uniswap Interface is high quality, reliable and worth the fee.

Forks will be different

  • @chainyoda said “you can just fork the front end and cut the fee in half” without forking the contract.

  • @hasufl was confused “why several Uniswap competitors claim to have no fees when they do”, and this shows the heated competition between “forks”.

  • @rsarrow said “you’re going to choose your front end the way you choose the charity you donate to”.

  • @0xmons proposed another form of fork “forked uni frontend with a fee except this time he fee goes to token holders“.

Opinion on Strategy

At first glance, it may seem like charging for Uniswap is going to make Uniswap's usage go down, but in essence, for Uniswap as a whole, that's not necessarily a bad thing.

Continue to be dominant

  • @shier_nftscan thinks this make Uniswap enters the ideal scenario: Uniswap stays #1 in DEX, third-party apps cash in on traffic by accessing Uniswap on Consumer products, earn service fees.

  • @tmel0211 predicts that “Uniswap's launch of the protocol and product segmentation strategy is clearly intended to pave the way for the commercialization and expansion of the subsequent product matrix, strategically covering a larger and broader ecological niche”.

Different models brought by Uniswap

  • @0xTaker brought the fact that Uniswap Labs doesn’t own the liquidity, and fee from interface will come from branding and UX.

  • @keoneHD said this event showed “frontends are valuable and it's worth putting effort into better UX”.

  • @tmel0211 summarized that this act is about “Uniswap is trying to tell the Uni community that only the Uniswap protocol is decentralized, and that the web and mobile are owned by Uniswap.”

  • @jolestar brainstormed about a reference field reserved in the protocol and populated by the front-end. Finally, the protocol shares the profit with front-ends.

  • @0xkydo saw this as “a crucial step forward for DeFi … to establish an open financial system that operates in a permissionless and non-custodial way.”

  • @KamesGeraghty thought “payment will be for curation not for execution” after v4 Hooks makes complexity grow exponentially.

  • @smsunarto said that “represents a shift away from this monolith app/service + protocol companies”.

Trolls

My Predicts

Everyone's views have been very comprehensive . I'll summarize and make some predictions, which do not constitute investment advice:

Read Also

The Interface Dilemma

Uniswap's new 0.15% interface fee marks a shift in DeFi monetization. Explore what it means for users, liquidity, and the future of protocol-based platforms.

https://www.decentralised.co
]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Discussion on A Very Cool Price Oracle]]> https://paragraph.com/@msfew/discussion-on-a-very-cool-price-oracle 3p7Gnuar4SU8rftoV2ix Sat, 23 Sep 2023 18:36:53 GMT

I'm too lazy to write a traditional formatted blog post, so I'll just post our discussion on the subject here. You can read the content directly…

Discussion

10:42 pm - me

This is an interesting, completely third-party-free price oracle (UTXOracle.py). The idea is to statistically analyze the transactions in each block of Bitcoin (eg. Users usually send BTC transfers totaling a rounded number like $100), and predict the BTC price for that day.

10:56 pm - Fren

What’s the accuracy? It may be easy to manipulate, but it's really fun.

10:59 pm - me

The creator said “it's very accurate. It's not clear which exchange price is the "right" price. But it's right in the middle of all of them. Feel free to check yourself”.. Limitations: 1. you have to set a min and max first, so you can't predict prices until 2020; 2. you need a large sample of tx, so currently it can only generate daily prices.

11:00 pm - Fren

This could be a price feed, which would need to be calculated for the cost of manipulation though.

11:02 pm - me

In fact, on Ethereum, using Uniswap price directly is much better... But this is for a pure Bitcoin node, so this is why they use this approach.

Related Links

UTXOracle.py: https://twitter.com/SteveSimple/status/1704864674431332503

GitHub Repo: https://github.com/Unbesteveable/UTXOracle

Replicated Heatmap for Ether: https://twitter.com/bantg/status/1705260495920341052

Other Discussions:

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Wait it’s all PoW]]> https://paragraph.com/@msfew/wait-it-s-all-pow 4qVyaS7t7ms12n2ACTzW Sun, 20 Aug 2023 05:12:52 GMT 0. Intro to PoW

Proof of Work (PoW, “one CPU one vote”) is a sexy mechanism.

It implements many features and solves many problems, including:

  • Decentralized and permissionless system (Bitcoin)

  • High security when total computing power is large

  • Truly clean and private money (clean ETH)

  • Relatively fair launch (Bitcoin again)

The only downsides might be "potential monopolization" and "energy consumption".

But in my opinion (I took a class on waste and energy last year as a sophomore, and did research on Bitcoin and Waste), it is acceptable to support a decentralized global financial system with some energy.

Overall, PoW is a good mechanism. Although Ethereum has struggled over the years to convert from PoW to PoS, PoW is still dominant in Ethereum's overall system and network or application layers.

PoWs are everywhere, and they are all PoWs.

1. PoW in Address

EOA & Contract

The address string (EOA address or contract address) is generated completely randomly, so in order to generate good looking address (like 0xdef1…) or more efficient address (like address with more 0s), numerous random computation need to be done, just like PoW.

Some tools for mining address:

Function Selector

Another kind of “address” is EVM function selector. Usually developers (especially MEV bot) mine for an efficient one with more 0s in it to save gas. There is also a database for function selectors (4byte.directory and samczsun’s eth sig).

Some tools for mining function selector:

Uniswap v4 Hooks

A newer one of “address” requires PoW is the Uniswap v4 hooks. “The hook permissions are determined by the hook address so you have to grind one with the desired permissions”. It is very dirty and clever.

2. PoW in DDoS

In an ideal world, the highest transaction quality means: anyone can send a transaction (no censorship); no spam; low fees.

However, we cannot achieve the perfect network. PoW is a simple and elegant approach to prevent spam by adding an extra layer of computing.

Testnet Faucet

I use Goerli PoW Faucet a lot in my daily development and testing.

While the usual testnet faucet is to sign up with an account and receive a fixed amount of testnet ETH, the PoW testnet faucet allows you to receive more testnet ETH depending on the amount of power you consume. More flexible.

PoW NFT Contract

At the beginning of the popular NFT project mint, the gas cost usually shoots up to a very high level, because a lot of people are doing the same mint operations, making the overall usage of the network very high.

This NFT contract does something like "PoW" within the contract, which increases the gas usage and mint cost on the validator side. This prevents DDoS and allows more suitable people to get the NFT.

Arbitrum Sequencer PoW Connection

The single sequencer model of rollup always faces the problem reliability and spam. There are multiple cases where rollup sequencer is down: Arbitrum Token Launch, and Optimism Delay.

Arbitrum had a proposal to score connections by PoW to disincentivize massive sybil attacks by MEV searchers on the Arbitrum sequencer.

3. Outro

In the finance world, winning requires you to be first, be smarter, or cheat.

PoW only requires you to be first. Maybe it’s fairer.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Thoughts on graph-ts (Subgraph Library)]]> https://paragraph.com/@msfew/thoughts-on-graph-ts-subgraph-library KpXgAD1kaWvvkM7wS6rF Sun, 30 Jul 2023 09:20:35 GMT Introduction

We at Hyper Oracle have recently been building a Subgraph-like zkGraph for developers to write data mapping that can be converted into ZK circuits.

In developing zkGraph, I've drawn inspiration and experience from a number of components in The Graph, as well as attempting to make it backward-compatible to Subgraph.

I've taken a closer look at graph-ts, a library developed for Subgraph, and have some thoughts on it.

1. Usage

If you follow the documentation in their repo to download the npm library and use it in an AssemblyScript project, you'll find that there's no way to use it directly without the other graph cli.

This is related to the following point. There is no way to use this library on its own, which is confusing.

2. Implementation Language

Most of graph-ts is implemented in AssemblyScript, but there are a lot of functions that are just defined in AssemblyScript and not implemented. The implementation is in the Graph Node, which is in Rust.

The main reason for this may be performance, or problems with the AssemblyScript language in early days. See discussion here. Side note: AssemblyScript is sponsored by Near, The Graph, and Shopify, so they are basically the early and the only adopters lol.

As a result of having more than one implementation language, you can't compile the whole graph-ts individually. Also for developers like me who want to achieve Subgraph compatibility, it's very difficult to guess all the functionality and behavior.

3. Naming of Math Operators

People are saying BigInt api is not cool. BigInt's math operations are called plus, minus, times, not add, sub, mul as is the normal JS convention. It's possible to use operators like "+, -, *" directly, but the IDE tends to complain.

In the zkGraph implementation, we support both plus and add operators for Math, so both can be used.

4. Endian

little-endian is the default in graph-ts. But in reality, all of Ethereum's scenarios use big-endian. I think The Graph may have adopted little-endian, which is more common in all scenarios, for the sake of generality.

In zkGraph, we have implemented a similar little-endian function and an additional big-endian version.

5. Conversions

Some conversion functions are weird. For example, toHex and toHexString behave the same, which is redundant. It’s probably, again, the legacy of AssemblyScript.

I submitted a pr, but it’s still pending. In zkGraph, toHexString can take a prefix as input, or if there’s no input, then it’s the same as toHex.

6. Documentation

Overall, the documentation is very good, but it always feels like it was good in the first version and has not been updated accordingly.

For example, there are many functions that are in the implementation, but not in the documentation.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Posts under Hyper Oracle]]> https://paragraph.com/@msfew/posts-under-hyper-oracle KCvysYusIxW7XSbabc0O Sun, 23 Jul 2023 07:01:08 GMT Realized I haven't posted any new Mirror content to this account since May.

The main reason for this is that I'm building Hyper Oracle, and I'm also going more vertical with my research, focusing more on ZK.

In the future (after my summer term is over aka. my official graduation of bachelor), I'll be posting more generic blog posts on any fun topic. Trust me, and verify later…

Below is a list of recent content and research I've posted under Hyper Oracle, feel free to check it out:

https://mirror.xyz/hyperoracleblog.eth/uaygRzKoWIx4qrB97MLRMHVbuLYqH4Qj_Dcl94GxoZY

https://mirror.xyz/hyperoracleblog.eth/n3c8QsNLCAPFqc5jisYV9zEtTCrxV3gjDFglNhiee94

https://mirror.xyz/hyperoracleblog.eth/R65-EL4k_BMWl_c1JO8Kgfk1P6jQhMkFsTEXjZuqXnU

https://mirror.xyz/hyperoracleblog.eth/AvBEIgiYGOXWN-64PjWHRSq-iOFvm266KFQzQpDnwvA

https://mirror.xyz/hyperoracleblog.eth/FKvpIGI7fiuNr5rnTlFWAdxk4QCNFIR9rmqDPxWLc2w

https://mirror.xyz/hyperoracleblog.eth/vPwYqWWmsWW5JPqlOjk9fMo7Ba72D40Ph9SyjthEZDE

https://mirror.xyz/hyperoracleblog.eth/Tik3nBI9mw05Ql_aHKZqm4hNxfxaEQdDAKn7JKcx0xQ

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

https://mirror.xyz/hyperoracleblog.eth/pOjaFIfCVrzvUTaeM9HVi7wFY2tQgZVQUDk7dMtNMtM

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

nft://undefined/undefined/undefined?showBuying=true&showMeta=true

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Risks of Rollup (aka. Comparing Rollup with World Supercomputer)]]> https://paragraph.com/@msfew/risks-of-rollup-aka-comparing-rollup-with-world-supercomputer eCpRya2Y5s9qmFPRb8k9 Wed, 10 May 2023 03:29:00 GMT

https://ethresear.ch/t/towards-world-supercomputer/15487/2

0. Collective Definition of L2

After years of research and development, L2 Rollup has emerged as the most widely adopted scaling solution for enhancing the performance of Ethereum's world computer. As an additional layer built on top of Ethereum, L2 Rollup offers significant benefits and has been embraced by the community.

L2 (Secured/Smart Contract) Rollup can be explained in various ways:

  • From the perspective of Validating Bridge: An L2 Rollup’s core is an optimistic or pessimistic validating bridge that bridges assets from Ethereum L1 to off-Ethereum L2 for faster transaction processing. The bridge is secured by fault/fraud or validity proof.

  • From the perspective of Rollup itself: An L2 rollup is simply about performing state transitions on inputted transactions with data availability on L1 to generate outputs with compression by sequencer. The system requires some forms of proofs (authority, fault/validity proof) to convince the base layer Ethereum blockchain or other networks.

  • From the perspective of Verifier (my version, more on L2 only): An L2 is based on the verifier contract for proofs on Ethereum. Any off-chain computation with all composable innovations can be settled on Ethereum, as long as the final proof passes.

In my version, L2 Rollup is a network that has:

  • On-chain data availability and settlement: public accessibility of historical state or input transactions data, and verification of commitment on Ethereum.

  • Off-chain execution: single state transition of transaction on L2 layer itself.

However, the off-chain execution actually involves not only single transaction state transitions, but also the sorting of transactions. In most cases, L2 sequencers do the sorting, while L2 validators compute for the new state.

1. Centralization Risk of L2 Sequencer

Firstly, it can be argued that L2 Rollups do, in fact, enhance the performance of computers worldwide. However, a key issue with L2 Rollups lies in their current level of decentralization, which is not quite sufficient.

The transactions within L2 Rollups actually take the form of a unique different type of L1 transaction, albeit executed, bundled, compressed, and amortized in a manner that bolsters throughput. Nonetheless, the sequencer responsible for aggregating and sorting these L2 Rollup transactions typically plays a centralized role.

A centralized sequencer may have negative implications for the following centralization properties.

  • Weak censorship-resistance: Unlike the near infinite number of distributed nodes on L1, a centralized sequencer may not ensure that your transactions will be included on the chain. A centralized sequencer under the control of a legal entity may be subject to regulatory resistance to culling specific transactions. Although there are additional mechanisms available to address the weak censorship-resistance problem of L2’s centralization failure problem (such as force exit, escape hatch, inclusion lists, or adding threshold encryption), we still need to accept the assumption that centralized sequencers are more likely to have weaker censorship-resistance.

  • Weak liveness: The design of a centralized sequencer may not be able to handle the computational processing and proof generation required to keep a system running at all times. RPC or sequencer downtime due to hardware failure, excessive spam (eg. Arbitrum Token Launch, Optimism Delay), or operational failure (eg. Arbitrum Sequencer Out-of-gas and its own explanation) from validators or bots can lead to weak liveness of L2 Rollup.

  • MEV capture: The current centralized sequencer of L2 Rollup usually follows the first-come-first-serve rule for transaction sequencing. Additional trust is required to ensure that they will not extract MEV from user transactions through node privileges, or that the third-party sequencing services they adopt (like Chainlink FSS) will not be malicious.

It may be suggested that shared, outsourced, or based sequencer solutions could address these issues with tradeoffs, but it is still too early for such solutions. Additionally, many decentralized sequencer solutions (such as PoA, PoS leader selection, MEV auctions, and PoE) are still in the conceptual design stage.

Currently, the decentralized sequencer is not a priority of most L2 Rollups. Arbitrum has suggested that decentralized sequencer may become an optional feature.

2. Other Centralization Risks: Node Requirement, Governance, App-Rollup Trend…

In addition to the centralized sequencer issue, L2 Rollup may the centralization problems from high node hardware requirements, governance risks, and the app-rollup trend.

Running a full L2 Rollup node requires running an L1 node as well. This means that the hardware requirements for L2 nodes are even greater than those for L1 Ethereum, which could lead to further centralization issues. This is not yet a concern, as most L2 Rollups are not fully permissionless.

L2 Rollup is similar to a specialized on-chain protocol. Unlike traditional protocols such as DeFi and NFT, L2 lacks a mature management mechanism and established model DAO. Governance for L2, Optimism, and Arbitrum has been difficult due to the centralized nature (even sometimes similar to a centralized exchange) of most L2 Rollups. This makes it challenging to govern L2 Rollup in the absence of prior successful decentralization cases.

There has been discussion about deploying Uniswap as an App-chain or App-rollup. There are many tools available for Rollup, including Rollup frameworks (OP Stack, Rollkit, Sovereign SDK) and RaaS (Caldera, Eclipse, Opside, AltLayer). The proliferation of these underlying tools is promising for the future, with a multitude of new Rollups on the horizon. Each of these Rollups will need to address the aforementioned centralization issues. Among these new Rollups, the Sovereign Rollup is particularly challenging to decentralize. It is essentially a different lens for interpreting the same L1, or a velvet fork, or almost a separate L1 with hard-fork as a feature. Additionally, we have L3, an L2 Rollup on L2 Rollup.

The daily transaction count in L2 now surpasses that of L1 Ethereum. However, due to a centralized sequencer and other concerns, if we view L2 Rollup as a crucial aspect of the world computer, we may not attain the ideal balance of performance and decentralization.

3. L2 or Modular Blockchain Are Not Enough

To create a world computer, we require more than just L2 or modular blockchain. We need performance scaling with decentralization, as opposed to incremental decentralization with performance scaling.

The main difference between modular blockchain (including L2 Rollup) and world computer architecture lies in their purpose:

  • Modular Blockchain: Designed for creating a new blockchain by selecting modules (consensus, DA, settlement, and execution) to put together into a modular blockchain.

  • World Computer: Designed to establish a global decentralized computer/network by combining networks (base layer blockchain, storage network, computation network) into a world computer.

L2 Rollup effectively achieves the following:

  • Modularization of World Computer (more experimentation of consensus layer with some external trust on centralized sequencer)

  • Throughput Enhancement of World Computer (though it is not strictly "scaling")

  • Open Innovation of World Computer

However, L2 Rollup is not sufficient in the following areas:

While the world computer architecture can have L2 and modular blockchain, it does not address the fundamental issue. L2 can solve the blockchain trilemma, but not the trilemma of the world computer itself.

We need a network that solves truly general-purpose intensive computing (especially machine learning and oracle), while preserving the full decentralization of the base layer blockchain.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Criticism on ZK]]> https://paragraph.com/@msfew/criticism-on-zk 0aBakEdmV1EW3YYFuZk3 Thu, 20 Apr 2023 00:38:01 GMT

First of all, this is a sketch written in one hour. At this point it's just to gather information quickly, so there may be very many potential errors and incomplete information.

The main criticisms against ZK would include two, one being the long proof time, (hence the various benchmarks, various new ZK protocols, and various hardware optimizations), and one being that system and application security still needs to be tested.

0. Proof Generation Performance

Zero-knowledge proof is a very popular technology in the blockchain space. Due to the scarce and expensive on-chain computational resources, zero-knowledge proofs allow these computations to be performed off-chain, and while the total time consumption for proof generation off-chain is very high, it still compresses the final proof and the associated computational verification, thus allowing the computation to be "on-chain".

The problem of extremely long proof generation times for ZK is often overlooked by researchers and developers, because it is essentially a trade-off that ZK needs to make.

Although they do not directly criticize this drawback of ZK, they have many approaches and discussions to address this drawback from the opposite side. That is, they implicitly talk about the extremely long proof time of ZK by proposing various solutions and performing a lot of benchmarking.

a) Benchmark

Before measuring the ZK application, we first had to test the performance of the underlying commitment of the ZK protocol (https://2π.com/23/pc-bench/index.html). For example, FRI leads to STARK, KZG leads to regular SNARK, and IPA leads to Bulletproof (https://blockdoc.substack.com/p/an-introduction-to-commitment-schemes). The performance testing of the underlying commitment is not intuitive to the performance of the ZK application, but it is useful for understanding the long proof time of ZK.

As we can see from the above links, these underlying commitment protocols are not only computationally complex (which may lead to long proof times), but also have the problem of consuming very large amounts of memory. Of course, memory consumption is actually more related to hardware configuration requirements, which is different from the topic we are discussing today.

For specific SNARK performance tests, a16z crypto divides them into front-end and back-end (https://a16zcrypto.com/content/article/measuring-snark-performance-frontends-backends-and-the- future/). The front-end is usually the Cairo language/zkVM high level language etc. that ZK application developers are exposed to, while the back-end is the underlying cryptographic operations such as commitment that are closer to the SNARK proof generation time. Among them, the authors mention that SNARK proof generation has about 100 times more computational overhead, and each ZK protocol has additional overhead, e.g. "In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups In Groth16, P must work over a pairing-friendly group, whose operations are typically at least 2x slower than groups that aren't pairing friendly. , this results in at least an additional factor-6 slow down relative to the 100-|C| estimate above.". Overall, the additional performance overhead of zk-SNARK is in the range of 200 - 1000 times. In addition, the article also mentions other limitations of zk-SNARK, such as trusted setup and memory usage.

The Modulus Labs article (https://medium.com/@ModulusLabs/chapter-5-the-cost-of-intelligence-da26dbf93307) measures the actual performance of some ZK protocols. Some of the benchmarks are for the number of parameters, which is not very intuitive for us. However, in the application, the article mentions that in the Worldcoin use case, even with the "fastest" Plonky2, it still requires several minutes of proof generation time and tens of gigabytes of memory consumption, which cannot be run on a personal computer.

b) Recursion and Batching

To reduce the proof generation time, we can prove multiple proofs in parallel. Usually, there are two ways to do this, one is batching and the other is recursion. In simple terms, batching is proving a batch of proofs simultaneously and finally aggregating them together, while recursion is verifying other proofs in one proof. In general, the recursion approach has the additional advantage of smaller proof size (https://twitter.com/bobbinth/status/1608690628652838915).

Some of the more common aggregation methods include Halo2, Plonky2 (https://www.youtube.com/watch?v=HE06BAsoWjw&list=PLlcfbEGVTa-gfVw5oz6a3BxAaUvstvxzf), Nova. Each of them performs batching and recursion in different ways, thus reducing the proof time. (https://kb.delendum.xyz/zk-knowledge#proof-aggregation)

In addition to the protocol level of ZK, the application level (https://www.youtube.com/watch?v=VmYpbFxBdtM) of ZK can also be optimized specifically. For example, multiple ZK protocols can be used simultaneously (STARK + SNARK (https://www.youtube.com/watch?v=ZwG3UI_iDAs)), or application-specific tuning on macroscopic recursive strategies (https://ethresear.ch/t/proving-a-chain-of-hashes-using-plonky2/15246, https://www.youtube.com/watch?v=t34Pt40COKg).

In general, this actually reduces the proof generation time in terms of protocol and proof allocation. In the exploration of new ZK protocols, reducing the proof time is the most important consideration.

c) Hardware Acceleration

In addition, many efforts have been made to further reduce the proof time at the physical and node levels for ZK applications from the hardware perspective.

First, like the new protocols mentioned before, the ZK protocol is designed to be as hardware friendly as possible, for example HyperPlonk (https://hackmd.io/@omershlo/rJhgKJPtj).

Paradigm mentions (https://www.paradigm.xyz/2022/04/zk-hardware) that the slow proof generation for ZK is mainly due to the large number of MSMs and FFTs involved which are not hardware friendly, resulting in slow final proof generation due to random memory access and other issues. With respect to these underlying cryptographic computations, the ZK protocol requires some trade-offs in their composition and scale (https://www.youtube.com/watch?v=5hO9NbtFc0g&t=3882s) to make it more hardware friendly.

Several ZK hardware acceleration manufacturers (https://www.youtube.com/watch?v=3wLYtzHuu5U&list=PLlcfbEGVTa-gfVw5oz6a3BxAaUvstvxzf) and researchers (https://trapdoortech.medium.com/zero-knowledge-proof-fpga-or-gpu-97b96ffbf0f) have said that GPUs are actually the most economical and configurable hardware option right now, and that we will have FPGAs to transition to the ASIC stage eventually. According to the zk hardware companies, the first version of their ASIC can reduce the ZK proof generation time by at least 30% directly.

In addition, running different cloud servers as nodes may involve different hardware-specific optimizations due to different server configurations (https://twitter.com/ingo_zk/status/1597963357772214272).

1. Security

Another criticize ZK has right now is the code of circuit still need to be right (no bug). If a ZK protocol is attacked from the Soundness, Completeness, Zero-knowledge perspective, we will no longer have a valid ZK system. We can see examples of attacks from various perspectives at this link (https://kb.delendum.xyz/zk-knowledge#vulnerabilities).

Although a ZK application can be called trustless, we still need to ensure that the project's ZK protocol and the application's code and architecture are correct. There are many kinds of ZK bugs in the blockchain space (https://www.youtube.com/watch?v=FMXTvxo3NsI). For example, Vitalik talks about the need for multi-prover of ZK applications, due to the problem of huge codebase of ZK circuit of zkEVM (https://youtu.be/6hfVzCWT6YI?t=164).

So a ZK system may need to be paired with security tools like Formal Verification (https://medium.com/delendum/formal-verification-of-zk-constraint-systems-ab22f17b0525), or other security related tools like Ecne (https://github.com/franklynwang/EcneProject). Application level, it needs more auditing especially for big projects like zkEVM (https://www.youtube.com/watch?v=WJewE8fdlmU).

In practice (https://mirror.xyz/privacy-scaling-explorations.eth/BaqGMfBhEZR1cvTJlA9E3Xu5ZhD7IthLiUK-Q75rQMM), Ethereum PSE maintains zk bug tracker repo (https://github.com/0xPARC/zk-bug-tracker), which tracks bugs to help auditors quickly find common vulnerability in zk applications. Veridise has done a lot of research and development on formal verification of zk circuits (zk circuits natively can be easily expressed with mathematical formulas, which lend themselves well to formal verification), as well as universal tools for static analysis of zk.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[AI Rollup, replacing fault/validity proof with AI oracle proof]]> https://paragraph.com/@msfew/ai-rollup-replacing-fault-validity-proof-with-ai-oracle-proof dSe6ifFr62pXDwBKYJWf Sun, 16 Apr 2023 19:04:05 GMT

AI Rollup, replacing fault/validity proof with AI oracle proof

First of all, this is just a wild idea. Please don't really use it or consider using it in practice except hackathon. Proof in Rollup For proving that "Rollup's program" is executing correctly, we need to provide some commitments. These commitments can be Fault Proof and Validity Proof in Optimistic and ZK Rollup.

https://ethresear.ch

First of all, this is just a wild idea. Please don't really use it or consider using it in practice except hackathon.

Proof in Rollup

For proving that “Rollup's program” is executing correctly, we need to provide some commitments. These commitments can be Fault Proof and Validity Proof in Optimistic and ZK Rollup.

In order to prove and convince, we have several ways other than Fault proof and validity proof:

  • Authority (eg. Coinbase)

  • Multi-sig (or multi-authority)

  • Light Client

AI as Proof in Rollup

Current AI models, such as GPT-4, are very much like a Hypercomputation or super-Turing computation model. More specifically, they are like an Oracle machine that can solve certain complex problems in a single operation, like a black box.

Thus, we can use the AI as something like an Authority, and let it reveal whether the Rollup program was executed correctly.

Rollup: 
Here's pre_state...
Here's rollup programs...
Here's transactions...
Here's my output...
Evaluate whether it's correct.

ChatGPT:
.......

Different Styles of AI Oracle Proof

Besides the commitments should be proving that rollup program is executing correctly, we may still need to show that the commitment is generated correctly.

Optimistic Style

When challenge is submitted on the claim, we play interactive game and figure out who's correct.

Interactive game would be executed on the chain with approximately ten back-and-forth steps (something like five questions, five ChatGPT answers).

ZK Style

We need to make the entire AI model ZK, so that the commitment itself can be executed correctly and the model can be guaranteed.

Limitations

  • Accuracy of AI itself: It is difficult to test the accuracy of a generative model like ChatGPT. If we can't guarantee the accuracy of the AI itself or go further and make the accuracy 100%, then we can't never really use a similar solution in practice. Or we can include AI Oracle Proof into multi-prover rollup architecture, so we can have a 3/4 multi-sig…

  • Development of On-chain AI and zkML: zkML and on-chain AI can be combined together, and there is already zkML that can do GPT-2. In the future, if GPT-5 zkML can be implemented with a similar high-performance solution, then different styles of AI Oracle Proof will be possible.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Notes on Hyper Oracle Whitepaper]]> https://paragraph.com/@msfew/notes-on-hyper-oracle-whitepaper eYppaZN3gxXQHsDpDcrd Sat, 25 Mar 2023 15:05:00 GMT It's been ten days since the Hyper Oracle whitepaper was released, and this article will explain and add to some of the content of the Hyper Oracle whitepaper. The original content was taken from my twitter.

Naming of I/O Oracle

The I/O Oracle data flow is actually Output Oracle, then Input Oracle. It is not called O/I, because O/I is less common than I/O. Also, there is no real combination of Input Oracle and then Output Oracle. It's more like two separate Oracles.

ZK and Receipt example

ZK just proves the validity of the computation, so the "price of the item purchased" is secured by the data source, not directly by zk. In Hyper Oracle, the security and validity of the data source is guaranteed by the on-chain data (the actual source) and zkPoS (the source fetching).

Another advantage of using zkIndexing

On The Graph's Indexer Explorer, indexers earn less than $1 per day in indexing rewards...... So, due to the lack of incentive, it is still essentially forcing developers to "run their own nodes". zkIndexing provides a solution with a trustless and decentralized hosted service.

Existing tools and ecosystem for zkGraph

All Subgraph tools can be used seamlessly with zkGraph. So everything from The Graph (such as their grant project) can be powering zkGraph.

Proof Queues

The network itself is decomposed into separate jobs (zkPoS, zkGraph_N...) . If a node generates proofs for a job and collects rewards. Others will spontaneously make other proofs to get incentives. This allows >= 1 node to claim all proofs and execute them. Magic tricks like recursion, aggregation and parallelization are not considered here.

The Need for Automation

We have 14 ways to transfer, but the essence is that someone (human or robot or whatever) must trigger the on-chain signature. To keep the protocol running, developers need to automate the process of triggering some smart contract calls.

Price Feeds are always Input Oracle

Even if the data source is about the assets on the chain, the price still comes from something like CEX. It still meets the definition of Input Oracle, having data feeds from off-chain (even if they are about on-chain data).

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Diffs between OP and ZK System]]> https://paragraph.com/@msfew/diffs-between-op-and-zk-system Akd5kOHETxxOHRzj3Rk4 Fri, 13 Jan 2023 10:11:55 GMT

Written on the train from Venice to Rome, 2023.01.12.

0. "Performance"

The real "finality" of the two is different, similarly to the "real performance". (Of course the definition of finality is also a matter of opinion, a matter of wisdom....)

  • OP systems (mostly) have a (human-adjustable) challenge period of about 7 days (aka. delay?) . This is like the long delay in Nakamoto consensus (which actually has no finality).

  • ZK system is fully confirmed once the proof is generated and verified. Also, with hardware acceleration, the proof generation speed and overhead can be infinitely close to zero (theoretically). It can be compared to the Tendermint consensus Single-slot Finality.

Of course, after all this about finality, you can actually see by comparing it with the consensus mechanism that this finality does not represent what is commonly referred to as "performance". Although Tendermint has Single-slot finality, it is not necessarily faster than Nakamoto. For the real performance measurement, we can write a seperate article (scalability, throughput, real tps, performance)...

Other than that, there is a difference in verification.

  • OP systems are more like verify after post. First post compute, then verify, so the latency is high.

  • The ZK system is more like verify before post. Although the proof needs to be verified after it is generated, the process of generating the proof actually puts a proof of validity on the computation process and the result before being posted.

If you want to compare it to a Math exam, OP is like a teacher following and redoing each step of your proof, while ZK is like a teacher looking directly at the scoring points in your proof after having all those scoring metrics.

1. Trust Basis

The two trust bases are slightly different, resulting in different security of the system.

  • OP seems to be based on an economic mechanism, similar to following the "innocent until proven guilty".

  • ZK seems to be based on a purely mathematical mechanism, like following the "presumption of guilt".

In contrast, the purely cryptographic assumptions of ZK are definitely more rigid.

However, these are theoretical security. Mechanically secure ! = implementation-secure, mechanism-insecure ! = implementation insecure. In practice, as software, they all have bugs, and therefore they all have risks. Code security requires additional mechanisms to ensure it (picus, ecne...) .

Depending on the security assumptions, ZK can be considered as a more secure system than smart contracts (based on networks, which are actually based on consensus and mathematics), and can be used as an extension of smart contract functionality (zkExtension). For example, Scroll makes smart contracts more scalable in terms of scalability, Hyper Oracle makes smart contracts more capable in terms of indexing and automation...

So, to take it a step further, if you've ever pushed EIP, then you know that setting up a standard alone is a very long and complex (and random) process, and it's even harder to develop the development ecosystem around it. It is even more difficult to update the network level (EIP-1559, merge...). Therefore, the ZK system can be used as an extension for experimental innovations (the main reason is that ZK is secure enough and pluggable) without breaking Layer1's own features and mechanisms.

2. System Complexity

Another point that no one has mentioned, but which I think is worth mentioning, is the complexity of the system.

ZK can outsource a large amount of computation to a single node for proof generation, making it very efficient in a distributed consensus system like a blockchain network.

This also has the advantage that the overall architecture is very simple (who generates the proof, who sequences it, and who verifies it).

The complexity of the ZK system is shifted from the surface and macro level, to the micro and code level.

If you want to compare, the OP and ZK systems look like this:

  • OP's mechanism is particularly complex and different at the same time, and the token economy involves a myriad of curves and troublesome settlement mechanisms. In short, it is beyond the reach of normal people, and probably only we researchers and the project itself understand what is going on.

  • ZK's mechanism is extremely Succinct (good word!) . Prover, User, Verifier, can be fully expressed in one sentence/diagram. There may be subtle differences between each system, but the real differences and hard work are transferred to the system developers and architects.

I think this is the biggest advantage of ZK. The nature of software is to be easy to use for the masses (and for developers to lose their hair), especially in an already complex Web3/Crypto system.

3. Which one to use?

Conclusion: Both, depending on the scenario.

I read an opinion the other day, written by Haseeb. Web3 is the left wing of freedom and openness, Crypto is the right wing of sovereign individuals. It is perfectly applicable to our topic.

  • OP gives more resemblance to the existing system of Web3. Systems like banks have been using OP-like mechanisms for a long time (credit cards), and for compliance etc., I think they will still use OP. Specific applications might be various Web2.5 "DeFi", cross-chains (like interbank transfers, but of course ZK does a good job too).

  • ZK gives a more pure and Crypto-Native Crypto. Because of the cryptography gene, ZK is very suitable for power applications such as Privacy Coin/True DeFi.

In my case, I'd go with Crypto's ZK.

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[Crypto-Native Indexing Protocol and Keeper Protocol]]> https://paragraph.com/@msfew/crypto-native-indexing-protocol-and-keeper-protocol PtZ4sgIp9MWnxwMRwn70 Wed, 26 Oct 2022 03:48:01 GMT 0. Middleware Security Issues

Existing Indexing protocols and Keeper networks are not completely trustless, but trusted, or seemingly trustless. Developers and users need to trust that these products are not evil in a “Trust, Not Verify” way.

They are last generation infrastructures, and there may not have been a good solution at the time, so Fisherman mechanisms or DAO governance (Social Consensus…) were used to ensure trustworthy data and secure operation of the protocol.

At the moment, the zk solutions are in the final stage of performance optimization, so the mechanism of the previous generations can no longer be used to tackle the issues of the current one. With zk, all the innovations of Web3 middleware can be achieved, ensuring that security, decentralization, and performance are met at the same time, just as Optimistic Rollup is likely to give Layer2 dominance to zk Rollup in the future.

1. Web3 Indexing

a) Web3 Indexing

We first need to understand why the Web3-specific indexing protocol is needed:

  • Web3 is an address model where smart contract data exists in transactional form and needs to be indexed to make the data structure easier to use; Web2’s data structure is handled by the developers themselves.

  • Much of Web3’s data is transaction-related; a large portion of Web2’s indexed data is web page or image data indexed by search engines.

  • Web3 needs a common indexing protocol to be composable; Web2 developers build their own indexing services based on their own centralized applications.

For these points, if you’re developing a DApp and you’re forced to do the indexing yourself, it takes a lot of front-end code to extract specific data from a contract, and here’s an example of the countless different functions that would be required to build a service:

So in our previous DApp architecture diagram, a common Indexing protocol is required as an intermediate layer for the front-end to use and access the data of smart contracts, so that the data of smart contracts can be easily used by the front-end.

b) GraphQL Indexing

We need an Indexing protocol as an intermediate layer, so how do we choose this protocol (The Graph ’19 talked about why Web3 uses GraphQL, but it didn’t feel very clear)? We have four potential choices:

First, exclude SOAP. Because its adoption rate is very low, and the learning curve is very steep. Some even say “REST is king, and SOAP is trash”.

Second, exclude RPC. RPC is a common specification for client-to-blockchain, or Web2 service-to-service calls, with operations (verbs) as the core, and the interface is a bit more cumbersome to update, suitable for client-to-blockchain network communication. But for our smart contract development scenario, it is too heavy, not the most suitable, and performance is not good due to the number of requests and the need to rely on the running application.

Next, REST is ruled out. The REST style is considered a resource (noun) centric specification. But in a Web3 application, any update to a resource needs to be triggered by user or other authorization, and all our requests in the indexing protocol are GET requests, so there is no need for REST.

Finally, GraphQL was chosen:

  • The GraphQL protocol itself requires less effort to build than other standards, requires less changes, and is easier to build a common protocol.

  • The interaction format of GraphQL gives more freedom to the front-end to define the result, which is in line with the back-end-less idea of DApp architecture.

  • GraphQL is very suitable for blockchain smart contract scenarios that are completely open and immutable, and have a lot of tree-structured data, and therefore better performance.

  • GraphQL is already a mature standard in blockchains with The Graph for indexing individual smart contracts, and there are already GraphQL interfaces for entire chains (ethql, Clear), with a high degree of maturity and a well-developed developer ecosystem.

Beyond that, I don’t think we need to spend a lot of time developing new GraphQL and Query protocols for storage networks (although it makes sense to aggregate these indexes):

  • Most of the storage networks come with available indexing protocols, such as Arweave’s GraphQL service, and developing new protocols would be rebuilding the wheel.

  • The amount of data on the storage network is very small compared to contract data or Web2 data, and the value it carries is also relatively small.

  • Web2 already has more mature protocols and solutions for indexing this data, and developing new protocols is still like reinventing the wheel.

When we talk about indexing protocols, the default is to get the blockchain smart contract data directly from the front-end, because as we explained in the previous article, it makes sense to eliminate the back-end server for the Web3 Crypto-native trusted DApp.

Adding a backend for smart contract chains would add architectural complexity and expose more untrustworthiness (there are projects like zk-sql that focus on this problem, but can’t fully solve it; there is also Sqlidity, interesting on-chain SQLite solution), but of course for DApps based on storage protocols, SQLized statements are necessary for development familiarity and flow.

The structure to focus on for the indexing protocol should be a GraphQL structure that the front-end can use directly.

c) Existing Web3 GraphQL Indexing Protocol Issues

The leaders of the existing Indexing Protocols are necessarily the decentralized The Graph and Pocket Network and the centralized Alchemy. Both centralized and decentralized have their own problems:

— The problem of centralized Indexing Protocols:

  • Inability to resist censorship

  • Inability to guarantee high availability of services

— Problems with existing decentralized Indexing Protocols:

  • Trust model and security remain poor (the cost of attacking Subgraph is very low, as with Chainlink 2.0, which relies on “more trusted” Fisherman to report)

  • Performance does not meet demand

For security, the Fisherman mechanism in Optimistic Rollup is different from Indexing Protocol in that Optimistic Rollup’s data is up-chain and can be easily verified by a larger group of people through execution, whereas Indexing’s process is down-chain, if not If the indexer is not a Subgraph indexer, it is difficult to challenge the wrong data. This makes the trust model even less robust.

The combination of these shortcomings has led to a huge gap in the market for large DeFi applications that rarely use these indexing protocols because of performance and security.

d) ZK Solving Problems

ZK is actually a very good solution, and any problem with Optimistic mechanisms can be solved by switching to ZK, such as Rollup, which is the most prominent area.

The ZK-ized indexing protocol combines all the advantages of both centralized and decentralized protocols, including high availability and censorship resistance (multiple nodes guarantee uptime), excellent performance (centralized high-performance nodes can be chosen because of ZK), and security (ZK’s mathematical cryptography ensures good security).

For an indexing protocol, ZK’s solution:

  • EVM compatibility is not required.

  • Focus on overall performance, need to guarantee the rate of verifiable query.

The Graph itself is aware of the lack of security in its own mechanism and is working on Shellproof.

But I think The Graph is still slow in research and development, and I don’t know if Shellproofs can support all subgraphs. Also, The Graph has spent so much work on the existing mechanism that it would be more difficult to replace it than to build a new one.

A truly zk-enabled application of The Graph can build a new application and development paradigm:

  • Any DeFi application can trust data from this indexing protocol, greatly simplifying the development process.

  • Multi-chain applications can trust data from multiple chains and protocols at the same time, resulting in a huge improvement in user experience (+ Standardized Subgraph).

In this way, we can understand that the zk-ized The Graph is actually a decentralized RPC, which is far more ambitious than The Graph’s narrative, and truly achieves the decentralization that Infura is aiming for.

2. Web3 Keeper Network

In our previous article on Crypto-Native application architecture, we mentioned the Keeper.

It is essentially, an off-chain timer that triggers a function of a smart contract at a certain time, similar to:

  • CronJob in Linux

  • Web API (not JS) setTimeout and setInterval

It is used for the following purposes:

  • On-chain prophecy machine price updates (previously mentioned Uniswap V2 TWAP)

  • Trading, voting, clearing bots

  • automated mining and selling

However, similar to The Graph we mentioned before, its security mechanism is very outdated, not even on-chain governance like The Graph, but off-chain manual reporting of illegal nodes through DAO and Social Consensus. For example, in the diagram below, Gelato’s architecture is clear in its overall functionality, but each component does not show any security guarantee.

Take two typical Keeper Networks as an example, their security mechanisms are:

  • Gelato: The current Keeper service execution nodes are not permissionless, but only whitelisted nodes can participate. Gelato expects to secure the network in the future after decentralization through Stake and Slash mechanism and DAO. However, the slow decision to punish an illegal node for a week through DAO is not acceptable for a service that needs to run at a high frequency. I think it is completely unacceptable for a service that needs to operate at high frequencies.

  • Keep3r Network: Similar to Gelato, the Watcher monitors and reports illegal behavior to the DAO, requiring communication and lengthy steps.

Like the Indexing protocol we just mentioned, Keeper can be completely zk-ified to solve the security problem, and even Gelato’s off-chain resolver is a subgraph defined in GraphQL, but has no security guarantees with The Graph. These two problems can be solved together.

This way a zk-ified Keeper with a trusted off-chain resolver can unlock a myriad of new application scenarios:

  • Transaction bots with complex strategies

  • Cross-Cluster/Cross-Chain/Cross-Block/Cross-DEX arbitrage/market-making bots

  • Programmable Liquidity (Adjust interval, JIT, reinvestment, Rebalance)

3. Crypto-Native ZK Infra

As the underlying infra of zkEVM and generic zkVM mature, we can already try to build infra based on them and use them to build infra that developers can use directly, including the zkified middleware we are envisioning.

ZK, as a typical solution, is an important innovation driver like AMM. ZK and AMM unlock more automated and trusted applications than Optimistic and Order Book mechanisms, respectively, making security fully transparent and publicly verifiable on the chain, as well as unlocking the additional tracks of proof outsourcing and Swap aggregators, respectively, unlocking countless new applications.

In addition to scaling/cross-chain light nodes/privacy/machine learning, ZK is a cryptographic solution perfectly suited to the blockchain scenario (network-wide verification, extremely automated, and even more secure than network consensus), and has great potential in the middleware tracks of Indexing protocols and Keeper networks. We will continue to monitor the application of ZK in more areas.

Related Links

1a:

GitHub - nulltea/zk-SQL: ZK-based engine for self-sovereign SQL queries

ZK-based engine for self-sovereign SQL queries. Contribute to nulltea/zk-SQL development by creating an account on GitHub.

https://github.com

1b:

Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC

Comparing API Architectural Styles: SOAP vs REST vs GraphQL vs RPC Two separate applications need an intermediary to talk to each other. So, developers often build bridges - Application Programming ...

https://levelup.gitconnected.com

GraphQL Will Power the Decentralized Web

GraphQL Will Power the Decentralized Web Leveraging blockchains and storage networks as a data interoperability layer For decades, the only widely used database in town was the SQL database, and it ...

https://medium.com

GitHub - Consensys/ethql: A GraphQL interface to Ethereum :fire:

A GraphQL interface to Ethereum :fire:. Contribute to Consensys/ethql development by creating an account on GitHub.

https://github.com

Ethereum, meet GraphQL ⛓

Ethereum, meet GraphQL ⛓ Explore the Ethereum blockchain using a rich GraphQL API. Try it in your browser! " Users want consistent application experiences across platforms, but delivering this can ...

https://medium.com

GitHub - hananbeer/sqlidity: SQL on chain

SQL on chain. Contribute to hananbeer/sqlidity development by creating an account on GitHub.

https://github.com

1c:

What's Wrong With the Chainlink 2.0 Whitepaper? (For Simpletons)

Why Chainlink's "Explicit Staking" is One of the Most Half-Baked Ideas in the History of Cryptoeconomic Design

https://ercwl.medium.com

1d:

]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[The Second-Generation Optimistic Rollups]]> https://paragraph.com/@msfew/the-second-generation-optimistic-rollups c2HnpPyxgauiKg4V8OZy Tue, 18 Oct 2022 03:17:46 GMT 0. Why Still Pay Attention to Optimistic Rollup?

a) OP or ZK?

Although Vitalik has identified zkEVM Rollup as the future for several years, and various zkEVMs (Scroll, zkSync, Hermez, Consensys) have sprung up, Optimistic Rollup is still the dominant stack in the Rollup ecosystem, with 80% of the Layer2 market share and half of the top 10 Layer2 solutions.

Will the existence of zkEVM Rollup as the ultimate scaling solution make Optimistic Rollup completely obsolete?

  • Optimistic Rollup and zkEVM Rollup are not incompatible, but will be complementary solutions in the long run (even permanently).

  • For App-rollup, the Optimistic mechanism is still the simplest and easiest solution to develop and deploy.

b) OP and ZK are not ready…

According to Vitalik, the zkEVM circuit of the Ethereum Foundation PSE has 34,469 lines of code. That’s a lot of code to polish in a very long period of development and continuous testing. We won’t be able to fully rely on the security offered by the ZK system for several years.

c) OP + ZK!

Six months ago, Optimism’s Kelvin started tweeting a lot about the feasibility of combining Optimism with zkVM.

He says Optimism’s Bedrock will not be just an Optimistic Rollup client, but a Rollup client. In order to fully guarantee the overall security of Rollup, the client (perhaps related to Arbitrum’s recent acquisition?) and the diversity of proofs (Validity Proof and Fraud Proof) are the real roadmap for Rollup.

Vitalik has refined Kelvin’s solution, suggesting that a 2 + 1 combination of (OP + ZK) + Governance could be used to achieve a reliable Rollup.

Until zkEVM is fully stable and mature, the workflow is as follows:

  1. publish the block

  2. wait 24 hours

  3. a) If there are no fraud challenges during this period, release the ZKP and fully finalize the block. b) If there are challenges, Governance is introduced to adjudicate the final result through the 2 of 3 model.

After zkEVM is stable and mature:

  1. release the block

  2. Publish ZKP periodically.

  3. a) If the ZKP is released properly during the specified period, it will prevail. b) If the ZKP is not released properly during the period (Prover failure or bug), the Optimistic mechanism is introduced first, until the ZK mechanism is restored.

Both options require the existence of the Optimistic mechanism to ensure the liveness and safety of the entire Rollup system.

Therefore, the development of the Optimistic mechanism is still the vital part of the Rollup universe.

1. Second-Generation Optimistic Rollup

The term “Second-Generation Optimistic Rollup” comes from the title of Arbitrum Nitro’s white paper. The Optimism Bedrock, which was released slightly earlier than Nitro, is also considered a Second-Generation Optimistic Rollup.

The overall difference between the two is not really that big (if you read Arbitrum and Optimism blogs, you might even think they are the same), they are essentially a new major release with themselves. The differences between the second generation and the first generation are just the following optimizations:

  • Developer experience: stronger EVM equivalence and compatibility, L1 interoperability…

  • User experience: higher throughput, lower gas…

But there are still trade-offs in design details, and we can see in these differences the refinement of Arbitrum and Optimism in building the next generation of Optimistic Rollup.

2. Second-Generation Optimistic Rollup Design Choice

The developers of Arbitrum and Optimism have compared and contrasted their architectures, and here we will discuss only those points that are relevant to users or dApp developers:

a) block time

There are two main options for block time design: fixed time or variable time. This can be interpreted as the difference between PoS and PoW Ethereum.

  • Optimism: fixed time (2 seconds).

Fixed time ensures the stability of contracts that use block.number to measure the time, such as Sushiswap’s Masterchef contract. These contracts do not use timestamps probably because the miner has control over the timestamp (sort of selfish mining or MEV?).

The first generation of Optimism used a variable time + 1 tx/block design, so there were some problems with Stargate rewards due to its contracts’ time calculation algo.

For the old 1 tx/block design, Optimism considered the overhead of the storage of the blockchain too high due to the block header and the need for frequent updates to the state root too costly.

  • Arbitrum: Variable time.

Variable time is designed to reduce the delay of tx confirmation. Currently, up to 4 blocks can be created per second, and skipped if there is no tx, so it is variable time.

For contracts that are timed with block.number, Arbitrum returns the block.number directly from the Ethereum L1 block, so there are no stability or adaptation issues. In addition, Arbitrum also provides a pre-compile to provide L2 block numbers.

b) Geth

Geth is the execution client of Ethereum, which accounts for about 80% of the total number of nodes.

  • Optimism: As a standalone engine.

Geth is treated as a standalone execution engine, not a library. The advantage is that it can fully reuse the previous infrastructure, while seamlessly switching to other execution clients.

  • Arbitrum: As a library.

Since Arbitrum has more L2-specific features, such as gas pricing for L1 and L2, and retryable tickets, Geth is handled as a library. Arbitrum uses hooks for invocation.

c) L1-L2 message inclusion delay

  • Optimism: ~2 minutes.

Bedrock’s latency is the length of several L1 blocks, with a worst-case latency of ten minutes.

Bedrock’s architecture is more like an L1, which in extreme cases can cope with L1 reorg by reorging itself.

A tx that is not contained by L2 for more than 10 minutes is simply invalidated.

  • Arbitrum: 10 minutes.

Nitro delays processing for 10 minutes, and if it exceeds 10 minutes, it can force tx inclusion via an L1 call.

The goal of Nitro is to make L2 never need to reorg for user experience.

Both are tradeoffs for user experience in different ways.

d) L1-L2 message retry mechanism

The message retry mechanism is designed to solve the problem of “L1 confirmed, L2 failed” in L1-L2 messaging.

  • Optimism: Implemented in the contract.

Developers can refer to the L1 Optimism Portal implementation, or define their own retry mechanism in the contract.

  • Arbitrum: Implemented in the node.

The retry mechanism is implemented in the ArbOS node.

e) L2 fee algo

The gas calculation for L2 is basically L2 execution gas + L1 calldata cost.

  • Optimism: Reuse EIP-1559.

The benefit is that the wallet and other infrastructure can be seamlessly connected.

Optimism’s calculation of L2 gas essentially minimizes the cost of L2 execution gas (99% of it is calldata cost).

  • Arbitrum: Use a custom system.

Due to the variable block time design mentioned earlier, gas pricing is more complex, so EIP-1559 is not used.

f) L1 fee algo

  • Optimism:

The transmission of L1 gas levels to L2 is almost instantaneous. Currently sequencer’s revenue is basically entirely from the multiplier of L1 gas costs. After EIP-4844, their revenue will come from MEV.

In the future, this data will be transmitted via L1-L2 messaging, thus ensuring security (being part of the protocol and subject to fraud challenge).

  • Arbitrum:

Arbitrum’s L1 fee algorithm collects fees by averaging the L1 gas, and uses its own control system to obtain feedback from the actual fees paid, thus ensuring stable L1 gas collection and spending.

The overall strategy also includes, in order to avoid sequencer overcharging, releasing batches when gas prices are low.

In addition, the differences in architecture and technical details are also discussed, but the content is too domain-specific and not relevant to users and application developers, so you can read it on your own.

3. The Future of Rollup is Optimistic

The zkEVM Rollup and the entire ZK ecosystem has been really hot lately (Devcon Bogota is basically ZK + MEV + others), so much so that most Ethereum researchers have more or less overlooked the development of Optimistic Rollup and these interesting design details in the second generation.

Optimistic, the leading force in Rollup, is experimenting with pioneering and groundbreaking innovations on L2 UX and DX. What they are doing could lay the groundwork for the zkEVM Rollup.

Until the zkEVM Rollup is fully available in the next two to three years, or even longer, the dominance of the Rollup will remain with Optimistic, and 80% of the new Rollups (App-rollups) will use the more mature and available Optimistic mechanism.

Even after the long-term zkEVM rollup has matured, Optimistic will remain the cornerstone of the system for the overall liveness and safety of the rollup.

The future of rollup is (still) optimistic.

Links:

0:

https://hackmd.io/@vbuterin/zk_slides_20221010#/1

https://hackmd.io/@vbuterin/zk_slides_20221010#/7

1:

Arbitrum Nitro: one small step for L2, one giant leap for Ethereum.

Arbitrum Nitro: one small step for L2, one giant leap for Ethereum. The time has come Arbinauts. Arbitrum One has now been fully migrated to the Nitro stack! Ahhhhh! Yes, it's true, Arbitrum One is ...

https://medium.com

https://dev.optimism.io/introducing-optimism-bedrock/

2:

Optimism Bedrock vs Arbitrum Nitro

This is a really nerdy breakdown of the differences between Optimism Bedrock 🗿 and Arbitrum Nitro 🚀. This is all sourced from my reading of the Nitro whitepaper, and my intimate sensual knowledge of the Bedrock design. This actually started a Twitter thread, but grew way way too big for that.

https://norswap.com
]]> msfew@newsletter.paragraph.com (msfew) <![CDATA[App-chain > On-chain App?]]> https://paragraph.com/@msfew/app-chain-on-chain-app u3wbb9T2ZtexzZ2nWuCY Wed, 05 Oct 2022 02:16:01 GMT 0. More Rollups. More Blockchains.

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.

1. App-chain > On-chain App

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:

a) Token Value Capture

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.

b) Economic Mechanism

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.

c) Trading Experience

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.

d) App Sovereignty

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.

e) Additional Features of App-Rollup

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.

2. Disadvantages of App-chain

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) Consensus and Ecosystem

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.

b) Interoperability

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).

3. Interoperability Solutions for App-chain and Multi-chain Era

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:

a) Copy & Paste

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”).

b) Link

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.

4. Conclusion

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.

Related Links

0:

Total Value Secured - L2BEAT

Track total value secured across Ethereum scaling solutions.

https://l2beat.com

1:

The Inevitability of UNIchain

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://medium.com

CryptoFees.info

There's tons of crypto projects. Which ones are people actually paying to use?

https://cryptofees.info

https://docs.uniswap.org/protocol/concepts/V3-overview/fees#protocol-fees

2:

https://forum.celestia.org/t/an-open-modular-stack-for-evm-based-applications-using-celestia-evmos-and-cosmos/89

Pay Attention To Celestia - Delphi Digital

Introduction A monolithic chain where everyone executes every transaction is inherently not scalable. Indeed, this is why almost every major ecosystem is

https://members.delphidigital.io

3:

Bringing IBC to Ethereum using ZK-Snarks

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://ethresear.ch

https://geometryresearch.xyz/notebook/the-road-to-slush

]]> msfew@newsletter.paragraph.com (msfew)