🌟A modular and decentralized storage Layer 2 that offers programmable key-value storage 🌟Scaling Storage of the World Computer 🌟Received grants from ESP

bit.ly/EthStorage_Discord
Filter
Exclude
Time range
-
Minimum likes
What happens as more and more ETH gets staked? @drakefjustin (Justin Drake) recently laid out the potential consequences for non-stakers, DeFi, and ETH itself — and why he describes the current dynamic as a “Moloch trap.” We explored the key arguments together with the @Quark_Chain team ↓
1/7 — Ethereum’s Staking Rate: When Does It Become Too Much? At last week’s EF Protocol Reddit AMA, Justin Drake was asked whether the EF sees an uncapped staking ratio as a problem. His response laid out six potential harms—some more directly and comprehensively than we usually see discussed. Here are the key points 🧵
1
3
1,153
Faster Ethereum confirmations could have meaningful implications across bridges, L2s, and exchanges. As part of our ongoing technical research with @Quark_Chain, we took a closer look at FCR — how it works, its security trade-offs, and where it could make the biggest difference. ↓
1/7 Fast Confirmation Rule (FCR): From ~14 Minutes to 12 Seconds Earlier, there was a noteworthy development around FCR (Fast Confirmation Rule): a major cross-chain bridge company is expected to launch FCR within the next few months. This means cross-chain transfers originating from either L1 or L2 could see latency drop from around 14 minutes—the time currently needed to wait for finality—to as little as 12 seconds. Here’s how FCR works and why it matters ↓
3
1,180
Ethereum produces a block every 12 seconds. So why do many applications still wait ~14 minutes? Fast Confirmation Rule (FCR) could change that — enabling secure, single-slot confirmations and dramatically faster interactions across Ethereum. Our team member breaks down how it works, the security trade-offs, and why it could matter for Ethereum’s next wave of adoption ⬇️
上周 FCR(Fast Confirmation Rule)有了一个值得关注的进展:一家主流跨链桥公司将在几个月内上线 FCR。这意味着所有以 L1 或 L2 为起点的跨链转账,延迟会从大约 14 分钟(等待最终性所需的时间)降到最短 12 秒。EF 也已经开始为 FCR 制定 GTM 策略,目标不只是帮这家跨链桥顺利上线,还要把它做成一个案例,推动所有的桥、L2 和交易所采用 FCR。 FCR 是什么 以太坊现在的确认时间是一个尴尬的量级:一个 slot 是 12 秒,但最终性需要两个 epoch,大约 13 分钟。所有需要等确认的应用,都在等这 13 分钟。 FCR 的做法是统计 attestation,在正常网络条件下把确认压缩到单个 slot,约 13 秒,相比最终性缩短了约 98%。它不需要硬分叉,也不需要 devnet,只是共识客户端的一个功能:启动时加一个 flag,然后照常用 eth_getBlockByNumber("safe") 查询即可,safe 标签返回的就是最近一个 fast-confirmed 区块。RPC 提供方基本零改动。 需要说清楚的是它和最终性的关系。最终性由可罚没的质押支撑,回滚一个已最终化的区块至少要烧掉 33% 的全部质押 ETH,是无条件的。FCR 没有经济安全性,它提供的是确定性保证:在网络同步且作恶质押低于 25% 的前提下,被确认的区块一定会被最终化。一旦这两个假设被打破,它会回退到最终性,在极端情况下,已确认的区块可能被重组。 所以 FCR 不是最终性的替代品,而是介于"等 k 个区块"和"等最终性"之间的第三个选项。相比于固定区块数,它至少有形式化的安全论证;相比于最终性,它快了两个数量级。适合 L2 存款、交易所充值、跨链转账这类场景,高价值结算和不可逆操作仍然应该等待最终性。 为什么这件事对桥、L2 和交易所有价值 主流跨链桥从以太坊出发的确认时间大多在 7 到 19 分钟之间,只有少数官方桥能做到 1 分钟左右。 这些等待时间对应的是真实成本。对桥来说,是跨链转账期间被锁住的资金;对交易所来说,是用户盯着屏幕等充值到账的那几分钟,以及资产闲置期间无法进入订单簿的深度;对 L2 来说,是从 L1 接入以太坊流动性的速度。而这些时间里的绝大部分,等的是并不是安全性本身,而是最终性这个默认选项。 FCR 把这些场景的延迟压到十几秒,代价是明确的、可以被评估的:接受同步性和 25% 作恶阈值这两个假设,换取两个数量级的速度提升。对充值和跨链这类场景,这个交换在多数情况下是划算的。
4
1,446
Glamsterdam is nearing completion, while the conversation is already shifting toward what comes next for Ethereum with Hegotá. Censorship resistance, faster confirmations, native account abstraction, and continued L1 performance improvements are all part of the discussion. A useful overview from EthStorage dev on how Ethereum's base layer continues to evolve 👇
上周的以太坊核心开发者会议同步了 Glamsterdam 分叉的进展,九月份的公开测试网预计如期上线,也确定了分叉激活后 gas limit 会提升到 2 亿,较现在提升三倍多。这标志着本次分叉扩容 L1 的目标得到了很好的实现。 Glamsterdam 的开发工作基本结束,客户端开发者的主要精力已经转向确定 Hegotá 的 scope。按照惯例,每个客户端团队都会在这个时候写一篇文章,阐述自己团队对于 Hegotá 应该包含哪些 EIP 的想法,进而从中达成共识、确定 scope。 EthLabs 汇聚了很多从以太坊基金会离开的研究员,研究能力非常强,被一些人称为第二个以太坊基金会。这次他们也第一时间发布了自己的看法,我们可以一起看一下。 抗审查 如果说 Glamsterdam 的主题是 L1 扩容,那么 Hegotá 的一个重要主题就是增强 L1 的抗审查能力。目前 Hegotá 唯一确定下来的头条改进是 EIP-7805(FOCIL),而 EthLabs 团队的三位成员 Francesco、Barnabé 和 Julian 都是它的共同作者。 为什么抗审查这么重要?只有对所有人保持中立的区块链,才能成为所有人的信任根基。这正是以太坊能够扩展成为全球经济的真正结算层的关键所在。 更快的确认时间 12 秒的确认时间非常影响用户体验,用户要等 12 秒交易才能被确认,而最终性的时间与确认时间成正比,所以缩短 slot 也会加快结算。 EthLabs 特别解释了现在就着手缩短 slot 时间的理由:这绝非一劳永逸的事。与扩容一样,真正交付出来的缩短比路线图上的承诺更能为应用提供确定性。要实现 6 秒以下的 slot,首先要让 slot 时间变得可修改,然后迭代式地调整。计划是在 Hegotá 先降到 10 秒,第二年可能进一步降到 10 秒以下。 原生账户抽象 以太坊及其更广泛的生态系统早就应该拥有原生 AA 了,它会带来诸多用户体验方面的好处,例如 passkey 钱包、赞助交易、ERC-20 支付 gas、交易批处理等等。 然而原生 AA 的发展之路异常坎坷,因为 AA 会影响以太坊技术栈的各个层面,包括客户端、L2、钱包、RPC、开发工具等等,因此需要众多利益相关者的支持。 值得注意的是 EthLabs 对 EIP-8141(Frame Transactions)的定位:他们认为它是原生 AA 的最佳候选,技术上完全够得上 S-tier,但仍然只放进了 A-tier,理由不是技术不足,而是落地采用的风险需要大量协调工作才能化解。这个判断在这次的争论里得到了印证,Base 和 Arbitrum 两个核心 L2 都明确反对该提案。可见,想在如此多的参与者中取得共识,是比较难的事情。 L1 的性能提升 性能被视为以太坊首要的研发约束,EthLabs 认为持续扩容仍然十分必要。主网容量距离应对需求高峰仍有相当大的差距:在以太坊诞生十一周年之际,每日基础手续费中位数仅为 0.1 gwei,但一次 NFT 铸造活动就将其推高至 10 gwei 以上,交易成本中位数达到约 1 美元,90 分位的交易成本则超过 5 美元。因此,Glamsterdam 的扩容计划应该延续到 Hegotá。
1
1
3
1,546
The rollup-centric roadmap was never a detour — its ZK proof advances are becoming the very input for native rollup's L1 provability. Native rollup's scaling power is literally built on proof tech that's been battle-tested through years of L2 competition. Nothing here was wasted — every phase of the rollup race quietly became the foundation for the next.
L1 和 L2 的边界正在消失,但方向和直觉相反:不是 L2 越来越像 L1,而是 L1 的执行层自己会变成一个 rollup。 最近以太坊社区讨论的两个方向,单独看都不新,叠加之后才产生了新的东西。 Native rollup 让 L1 直接验证 L2 的状态转移。L2 不再需要维护自己的证明系统和验证合约,代价是执行环境必须与 L1 完全一致,回报是 L1 后续的任何升级都自动继承。 Single slot finality 则把 L1 的 finality 从大约 15 分钟压缩到单个 slot。 两者解决的并非同一个问题。今天的 rollup 名义上已经结算到 L1,但实际被信任的是它自己的验证合约以及背后的升级权限,native rollup 消除的正是这层自定义的信任假设。延迟方面,一笔 L2 交易需要先等待自身的证明生成与批次提交,再等待 L1 的 finality。Native rollup 让验证在 L1 区块内同步完成,直接消除了前一项;SSF 则压缩后一项。缺少任何一个,L2 的结算都会被剩下的那项限制住。 两者同时到位之后, L2 的区块空间与 L1 已经相差无几,若再叠加 based sequencer,则趋于完全一致。 代价同样明确:交出定制执行环境的权利,也就交出了在这个维度上做差异化的空间,L2 的角色从"另一条链"回落为"L1 的扩展"。对已经拥有成熟技术栈的头部 L2 而言,这是一个真实的取舍。 值得注意的是,这套架构里所证明的是 L1 而不是 L2。L1 由区块构建者为整个区块生成证明、节点验证证明,而 L2 的执行本就发生在 L1 区块内部,天然被这个证明覆盖。L2 自始至终不需要生成任何证明,也不需要为 L1 更换证明系统做任何适配。 这也让最后一件事变得清晰。这几年 rollup-centric 的路线与对 ZK 的巨额投入,随着路线图转向 L1 扩容,很容易被解读为走了弯路。事实恰恰相反:native rollup 的扩容能力建立在 L1 的证明化之上,而 L1 的证明化,依赖的正是这几年被 L2 赛道反复验证过的那套证明技术。rollup-centric 并没有被放弃,它的产出成了下一个阶段的输入。
1
1
7
1,898
In his Lean Ethereum update, @VitalikButerin elevated state storage incentives to a first-class research area — as state grows much larger, "who stores it, why they store it, and why they're willing to serve it" becomes a core problem. That's exactly the problem we've been working on. Great thread by EthStorage dev @qzhodl walking through how Lean Ethereum came to be. 👇
聊一下 Lean Ethereum 这两年的演变。 这个概念最早叫 Beam Chain,是 Justin Drake 在 24 年 Devcon(曼谷)上提出的。当时这个 talk 提前很久就在预热,号称是以太坊共识层的下一次重大升级,我正好在现场,可以说是整个 Devcon 最火爆的一场。核心内容是:抗量子 + 更快的 finality + 共识层 SNARK 化(zkVM)。而且因为 Beacon Chain 五年下来积累了不少技术债,方案是不在现有客户端上改,而是从零开发全新的共识客户端。 后来因为 "Beam" 这个名字有商标的争议,项目被迫改名。25 年 7 月,Justin 借着以太坊十周年把它升级成了 "Lean Ethereum":不再只是共识层,而是 lean consensus / lean data / lean execution 三条线,覆盖整个 L1 技术栈。原来的 Beam Chain 变成了其中的 lean consensus。这个方向吸引了一批新客户端团队同步开发,比如 Ream (Rust)、Zeam (Zig)、Qlean (C++)、Lantern (C) 等,并且已经在专门的 pq-devnet 上做了好几轮多客户端 interop 测试。我们也在持续跟进,每周参加 Ethereum PQ 的 weekly meeting 了解进展。 最近一个大变化是 Vitalik 发了这条 post(nitter.net/VitalikButerin/status/…),给 Lean Ethereum 正式定了性: 它是以太坊的第三次重大迭代——The Merge 是第二次,这次几乎所有主要协议组件都会被替换:recursive STARKs 验证取代重放执行、全面抗量子、共识重构、多维 gas、新的 state 类型等等,但它不再是一次性的大升级,而是未来三到四年通过多个 fork,把规划的功能一点一点集成进主网,尽量不打扰现有应用——路径上更像 The Merge 而不是推倒重来。 Vitalik 还专门提到了 client architecture 会有变化。在我看来,既然走的是"主网渐进式 fork"路线,大概率意味着这些升级最终要落在现有主网客户端上,而不是当年设想的"全新客户端整体替换"。 如果这个判断成立,那当初为 Beam Chain 组建的那批新客户端团队,角色可能会从"未来的主网客户端"转变为"探索和研究的先遣队"——他们在 devnet 上验证过的 PQ 签名、聚合方案、SNARK 化状态转换,会以规范和经验的形式反哺现有客户端团队。这不是白干,而是以太坊一贯的做法:用最激进的方式做研究,用最保守的方式上主网。 回头看这两年,Lean Ethereum 的演变其实是一个很典型的样本:一个宏大的"从零重写"叙事,如何在现实的工程约束和生态惯性中,被逐渐改造成一条渐进但可执行的路径。愿景负责定方向,devnet 负责试错,主网 fork 负责收敛。以太坊的升级从来不是靠某一次革命完成的,而是靠这种"激进研究 + 保守交付"的节奏一步步磨出来的。The Merge 是这样,Lean Ethereum 大概率也会是这样。
1
5
1,101
Our team takes a closer look at @Ethereum's latest strawman roadmap. Beyond individual proposals, it highlights the broader direction of Ethereum: scaling execution, rethinking state, strengthening verification, and building infrastructure that can support the next decade of innovation.
Vitalik 把最新的 strawmap 称为以太坊的“第三次技术大迭代”,它是继 PoW 时代、The Merge 之后的第三次。读完最直接的感受是:覆盖之广,几乎重写了协议的每一层。 递归 STARK 的验证与扩容、全面抗量子、共识层把活性与最终性解耦、更短的 slot、多维资源计价、针对状态爆炸的新型 state、把隐私列为一等目标、形式化验证的落地,乃至用 RISC-V 逐步替换 EVM...... 这更像是以太坊研究团队最近几年来对区块链认知的一次集大成,选在中期扩容压力缓解之后(Glamsterdam + Hegota)系统性地兑现。 读这份路线图,能强烈感到以太坊社区里那种技术极客驱动、对进步近乎执拗的追求,也能感到他们的雄心。让我想起 Vitalik 之前的话,大意是:希望以太坊始终是一款令人印象深刻的协议,在量子计算、火星探索、强生物技术与 AI 齐头并进的时代里,依然配得上一席之地。 以太坊走到今天十年了,技术体系仍未定型,还在剧烈迭代。有意思的是,Vitalik 说过 strawmap 完成之后架构大体就能稳定下来,往后只需很小的改动。另外 ,EF 的剩余资金可能也不足以支撑这种规模的长期迭代。但换个角度想:随着研究员对区块链的认知继续演进,strawmap 会不会又"不够"了,还要长出新的分支? 这一点,恰好和比特币的技术理念形成鲜明对比:一个把"不断迭代、永远追新"当作生命力,一个把"尽量不变、极致稳定"当作信仰。
3
4
984
We spent a decade hardening smart contracts. But the frontend users actually interact with is still often served from centralized infrastructure. The Bybit hack showed the risk: secure contracts, compromised frontend. In our latest post, we explore how EthStorage + Colibri enable client-side verification for web3:// frontends. ✅ Frontend hosted on-chain via EthStorage ✅ Gateway responses verified against on-chain commitments ✅ No need to trust the gateway ✅ No full node required Verification runs directly in the browser, turning "trust me" into "verify it yourself." A trustless padlock for on-chain applications. Read more 👇
3
2
9
1,378
Frontend attacks are becoming one of the most critical risks in crypto today — from DNS hijacks to compromised UIs. This is exactly why we proposed ERC-4804 (web3://): to enable direct access to apps from onchain data, without intermediaries. This article does a great job outlining that vision and why it matters now. Full article 👇 bankless.com/read/crypto-fro…
2
3
7
968
Great week at Buidl Asia in Seoul, Korea 🇰🇷 We joined a range of events across the week and had the chance to dive into discussions across infrastructure, applications, and emerging use cases in the ecosystem. On the storage side, it was especially valuable — we explored new ideas, met promising builders, and had meaningful conversations around how programmable onchain storage can support next-generation applications. Excited about what’s ahead! #BuidlAsia
5
426
A missing piece of Ethereum: No simple way to locate or browse on-chain content — even though the data is already there. web3:// (ERC-4804) changes this. Browse on-chain images and content directly — no DNS, no HTTP servers, no trusted intermediaries. Simple as http:// At @EthCC, EthStorage founder @qc_qizhou walked through how it works — from fundamentals to real applications👇
6
414
EthStorage will be at @EthCC 🇫🇷, introducing web3:// — turning the EVM into an unstoppable web server. If the full stack isn’t decentralized, it breaks. web3:// (ERC-4804) decentralizes the access layer — enabling true end-to-end decentralization with no single point of failure. See you in Cannes — come meet the team.
Replying to @EthCC
Learn how to turn the EVM into your own unstoppable web server with Anthurine (@anthurine) presenting web3:// at the Cypherpunk & Privacy track. This could be the missing piece that finally makes decentralized hosting practical for everyone.
2
1
9
813
Excited to share that @anthurine from EthStorage will be speaking at @EthCC in Cannes 🇫🇷 📢Introducing web3:// — a decentralized access protocol that turns the EVM into an unstoppable web server. 🗓 Mar 31, Cypherpunk & Privacy Track web3://(ERC-4804) enables fully decentralized on-chain apps without relying on DNS or centralized hosting. As Ethereum continues scaling computation and storage, decentralizing the frontend access layer becomes equally critical. Adoption is already emerging — including support from @opensea. The decentralized web stack is gradually coming together.
2
1
5
624
Since we are building on top of the Ethereum ecosystem, the security of the base layer is fundamental for all infrastructure and applications built above it. Expanding the EF bug bounty to $1M is a meaningful and positive signal for the broader ecosystem, reinforcing the importance of continuously strengthening the protocol’s security.
The Ethereum Foundation Bug Bounty Program (bounty.ethereum.org) has increased its maximum payout from $250K to $1M.
4
653
If Ethereum is for agents, data matters too. Agents need persistent, verifiable storage for memory, content, and coordination. EthStorage enables permanent, petabyte-scale storage at ~1/1000 the cost. The need for this infrastructure is only becoming clearer.
the synthesis is coming.
1
5
673
🇹🇭 EthChiangmai 2026 EthStorage co-founder @qc_qizhou participated in @ETHChiangmai 2026 as a Hackathon Judge and Summit Panelist. He joined the panel “Cypherpunk as a Survival Skill: What It Takes to Live Permissionlessly”, contributing to discussions with builders and the broader Ethereum community. Thanks to the EthChiangmai team and everyone who made the event possible 🙏
2
5
602
EthStorage 2025 Annual Review 2025 was the year EthStorage moved from long-term research to real-world infrastructure. From Mainnet Alpha on Ethereum, petabyte-scale verifiable storage, and Git-on-Ethereum (GoE), to deep contributions across Ethereum clients, EIPs, and storage architecture — this report captures how decentralized storage became viable at scale. 📘 Read the full EthStorage 2025 Annual Report: 🔗 blog.ethstorage.io/ethstorag…
7
476
Merry Christmas!!🎄 Thank you to all the builders, researchers, and partners who were part of the EthStorage journey in 2025. More building, research, and progress ahead in 2026.✨
1
5
450
Cloudflare-scale outages showed us a hard truth: Web3 breaks anywhere a centralized layer still exists — DNS, routing, storage, and even the frontend. At EthStorage, we focus on the storage layer, and with web3:// (ERC-4804) we extend decentralization all the way to the frontend delivery layer, removing the last major choke point most “Web3 apps” still rely on. End-to-end resilience requires end-to-end decentralization. AItopia is the perfect place to discuss how the stack can finally get there. 👇 Join the space today nitter.net/i/spaces/1jMJgRdpWoYGL
AItopia [EN] No.001 "When the Internet Breaks: Can Web3 Survive a Cloudflare-Scale Outage?" Time: Friday, November 28 · 10:00 PM (GMT+8) Cloudflare’s global outage reminded the industry of an uncomfortable truth: even Web3 still depends on centralized routing, DNS, and edge layers it aims to transcend. AItopia No.001 begins with a simple question — what actually stays online when the backbone of the Internet fails? Hosted by: Vincent — Committee Member, @499_DAO Confirmed Speakers: • Vikas Pandey @buidloor — Head of Protocol, @GoKiteAI • Anthurine @anthurine — Co-Founder, @EthStorage • Kate @ionetkate — Head of Partnerships, @ionet Tune in here: nitter.net/i/spaces/1jMJgRd… X Community: x.com/i/communities/19877699… Telegram Group: t.me/+xMlOO3VQH-piZWNl AItopia will dive into: • How the outage exposed dependency chains across compute, storage, inference, and routing • Which layers of decentralized infra would fail today—and which could stay operational • Whether decentralized networks can offer Cloudflare-grade reliability without recreating central choke points • The system-level design needed for a genuinely outage-tolerant Web3
2
1
6
1,565