Today we're launching EthSystems.
We build confidential systems for institutional Ethereum.
Institutions want to use Ethereum, but one of the biggest problems is the lack of built-in, modular privacy tools.
We were the Ethereum Foundation's Institutional Privacy Task Force (IPTF) for the past year. We had hundreds of conversations with central banks, regulators, tier-one banks, and asset managers, shipping open source work the whole time.
Wall Street has found crypto as an asset class, but not yet as commercial infrastructure. Institutions want to run real flows on Ethereum: stablecoins, tokenized assets, settlement. These are businesses with billions of dollars on the line, and no bank will operate in full public view. On a public ledger, confidentiality is the hard part: each party to a transaction should see what it has a right to see, and nothing more.
We have a year of proof of work: private bonds, confidential stablecoin transfers, private settlement across chains, the Ethereum Privacy Map, and more. All with protocol specs and security properties, at our website.
We've spent a decade working on privacy in crypto. We know there's no silver bullet. Different use cases need different systems, each designed, specified, and hardened properly, and someone has to do that work. That's why EthSystems exists.
We're an independent, for-profit company, backed by long-term Ethereum-aligned investors. This is a decade-long transition, and we aren't going anywhere.
If you're an institution that wants to build on Ethereum, talk to us. We're hiring: BD in New York, protocol engineers, ops: [email protected]
Robinhood Chain 上线一周,目前已经全面采用 ETH 作为网络原生 Gas Token。
这意味着,用户在链上的每一笔交易都需要使用 ETH 支付网络费用,而交易对也主要围绕 WETH 构建。
随着更多传统金融应用选择在以太坊生态中落地,ETH 正在从网络原生资产,进一步成为越来越多链上经济活动中的基础结算资产。
It has been a week since the Robinhood Chain has launched, and the momentum has been rapidly increasing. It's been awesome to see.
The early success of the Robinhood Chain is an illustration of my vision for what success looks like for the two foundations it is built on top of: Ethereum and Arbitrum.
Ethereum: Robinhood utilizes $ETH as the native gas token of the chain. In other words, for every transaction to occur someone needs to be holding and spending $ETH. This motion continues to cement $ETH as the native onchain asset across the programmable economy. All the major trading pairs on the chain right now are utilizing WETH on Uniswap. Bringing on 27m users into Ethereum's sphere of influence is a generational and historic moment for Ethereum.
Arbitrum: Robinhood's tokenized equities have been housed on Arbitrum One for the last year, prior to the launch of the Robinhood Chain. The Robinhood Chain is now utilizing the underlying Arbitrum stack to power its experiences. The way the license works, Robinhood shares with the ArbitrumDAO Treasury 10% of its transaction fee profits for utilization of the technology. So, while Arbitrum One remains the core focus and priority for supporting enterprises, startups and protocols, the monetization strategy extends with their growth motions. I look forward to continued and deepened collaboration between Arbitrum and Robinhood across a number of different initiatives.
Building business models that align with the success of the adoption of the underlying technology has always been necessary, but has become absolutely critical as investors are looking more at capture than proliferation today. Both Ethereum and Arbitrum are extremely well set up as the onchain economy increases 100x in the coming years.
Ethereum for settlement and medium of exchange.
Arbitrum for execution, scalability and cusomizations.
Powerful combination with a lot more to come. The playbook is being written as we speak.
Native UTXOs on Ethereum.
Payments should be one-shot objects, not permanent state.
Bitcoin got this right. Ethereum can bring the same idea to payments: prove existence from history, keep only a spent bit in state, and reduce permanent state by ~99.8%.
Check out the blog post for details.
https://t.co/blKMizIHFS
Two weeks ago, Ethereum researchers met in Berlin to continue charting the protocol's long-term trajectory, following along discussions with client teams in Svalbard in April.
The updated strawmap is at https://t.co/9e2AQ6rhz6, and I attached a picture of it to this post.
My own high-level takeaways:
* "Lean Ethereum" is not a single one-shot upgrade, it is a collection of improvements that will come online to the Ethereum network over the course of three or four years. But make no mistake, this IS the third major iteration of Ethereum in the same way that the Merge was the second. Almost every major piece of the protocol will be replaced:
- Verification through recursive STARKs, rather than direct re-execution. Recursive STARKs become an enshrined first-class core component of the protocol
- Replacing everything quantum-vulnerable with quantum-safe alternatives
- Consensus: decoupled available chain and finality, one or two-round finality. Theoretically optimal security properties, simpler than today, and faster than today
- Multidimensional gas
- State: not just tree structure, but what *types* of state are available
- Changes to client architecture
...
At the same time, simplification, cleanup and future-proofing. And this will all be done in a way that minimizes disruption to existing application. We've done this before (the Merge), we can do it again.
* H-star (aka Hegota) is probably Ethereum's last thematically "pre-Lean" fork. Starting from I-star, most of everything we do will have a very strong "Lean" feel to it in one way or another.
* Privacy is no longer an afterthought, it is a first class goal. When designing Frames, the mempool, additions to the state tree, we explicitly ask the question "okay, how do quantum-safe, intermediary-free privacy protocol transactions go through this, and what is the overhead?"
* Formal verification of everything for security.
* FV also makes us much more comfortable with canonicalization (having pieces of the protocol that are directly defined as a piece of bytecode expressed in some language). evm-asm is being written in part to become a canonical proof system for the EVM.
* Quantum safety has shifted up a LOT in priority. This adds a lot of work (eg. finalizing a quantum-safe blobs design has become urgent; this work has already been ongoing for months)
* Probably the single most disruptive part of the plan is the changes to state. There is growing consensus around leaving present-day-style "dynamic state" mostly unchanged, but scaling it only a medium amount, and adding new types of state that are more scalability-friendly (eg. no need for builders to sync/store all of it) but more restrictive, and that will scale a large amount.
eg. possible Ethereum in 2030: 2 TB of present-day-style (dynamic) state, and 100 TB of new-style (scalable but restrictive) state
This "new-style" state would work very well for ERC20s, NFTs, many defi use cases, but not eg. highly "central" objects like Uniswap contracts, or onchain order books, or other complex things (which are crucial for Ethereum but which only take up a small percentage of state)
Hence, it will not be *necessary* to rewrite any apps, but it will be *very cost-effective* to eg. rewrite an ERC20 token into a newer design that uses a new type of UTXO storage that is currently being explored, so that it will have >10x lower txfees.
Design of these new state types (current ideas: keyed nonces, ring buffers, UTXOs, statically accessible state, temp state) is an area where we will need a lot of feedback from application developers (incl. privacy-friendly application developers) and probably several rounds of rethinking and iteration.
* In the context of a much larger total state size, we need to figure out the incentive issues around who stores this state and what motivates them to. Even saying "each node stores 1%" is not good enough - why do they store that 1% and why are they willing to serve it? This is being elevated as a first-class research area.
* Ethereum will need to have a "VM" other than EVM in one form or another - at the very least, we need something like leanISA for recursive STARKs - and the gains are large in exposing it to users so that we support programmable privacy and better scalability. Right now, the most likely contenders are leanISA and RISC-V.
My own ideal is that in this world, we adjust the protocol so that the EVM becomes a high-level-language compiler-level feature, and the protocol only "sees" RISC-V / leanISA directly. But this is still far away.
* Gas limit increases, blob increases and slot time decreases will happen many times over the next ~5 years. We expect a large gas limit increase with Glasterdam. Each step of increased scale or decreased slot time is a matter of getting to the point where it is safe to do it, which comes from a combination of client optimization and protocol changes.
Ethereum is CROPS.
Ethereum is scaling.
Ethereum is reinventing itself.
Onward.
1/ Announcing Ethereum Institutional
An independent non-profit dedicated to accelerating the institutional adoption of Ethereum, its L2s, applications and overall ecosystem.
This year, the EF is decreasing its budget by roughly 40%, which entails some difficult decisions. The goal of the decreases was set out in the Treasury Management Policy last year: the EF is transitioning into being a long-term-oriented endowment-based organization, shifting from its pre-2026 average of spending ~15% of its remaining funds each year, toward a post-2030 target of ~5% per year.
Often, when an organization goes through something like this, people try to pretend that nothing of great value was lost, that it is an efficiency increase, that the only people cut are unproductive dead weight, and everyone else stopped partying, studied the blade, entered cracked S-tier beast mode, and this was sufficient to make up for the downside. I will not try to pretend this. I respect my EF colleagues far too much to pretend that there was not much that is lost. They are brilliant people. They are dedicated engineers of whom some have worked on the Ethereum protocol for nearly a decade. They have brought a bright light to the Ethereum ecosystem with their code, their words, their warmth as human beings and their actions. My dearest hope is that they find a path that brings them fulfillment and happiness whether inside Ethereum or outside. Hopefully many will be able to bring their excellent talents and mindset to the wider Ethereum ecosystem, or the even wider CROPS world.
Instead, I will try to explain what *are* some of the grand sacrifices being made. The Ethereum Strawmap is no small thing. It is an extremely ambitious undertaking seeking to replace and augment almost every part of the protocol - consensus, proofs, privacy, account model, state, and more. This is the third iteration of Ethereum, in the same way that the Merge was the second, even if the shipping style is less Big Bang and more one-piece-at-a-time. On top of this, the EF is increasing its role in the Access Layer. We are not compromising on Ethereum being a Deeply Impressive protocol, something worthy of its place in a world with quantum computing, rockets to Mars and powerful biotech and AI, and capable of meeting the challenges that this era will bring.
Some of the deficit will be recovered through more work happening outside the EF. But not all. So what are the grand sacrifices that will enable a leaner effort to accomplish all of this? I will give a few examples (though far from an exhaustive list):
* The multi-client model will shift in the direction of multiple clients existing less for _redundancy_, and more for _specialization_. Up to this point, redundancy has been the main security strategy: if one client has a bug, if it has less than 33%, the chain keeps going and does not even stop finalizing. We are increasingly exploring moving more pieces of the protocol to a different security strategy: AI-assisted formal verification. Some smaller pieces of Ethereum (eg. BLS libraries) have worked this way already for a long time. But soon many more parts of Ethereum will likely function on this model. This may greatly reduce resource requirements of shipping a large number of EIPs. The resources saved by client teams can ideally instead be used to better serve different specialized user needs, including EF Access Layer goals.
* PSE (Privacy and Scaling Explorations) is winding down as a unit. The number of people working on ZKPs for privacy and scaling is probably as high as ever, but they are working less on "exploration" and more on *implementing* ZKP-based privacy and scaling into the Protocol and Access Layer
* Devcon will likely over time become smaller-scale, somewhat more spartan, much lower-deficit than previous years, in addition to other changes in vision in line with the Mandate.
* Fewer beyond-Ethereum megaprojects coming from EF. As I announced earlier this year, I am taking on some of the responsibility of doing projects in this category that I consider valuable with my personal funds.
* EF institutional work is reducing in scope, specializing more specifically on creating replicable test cases of highly CROPS-friendly deployments, even if at smaller scale.
These do not explain all departures; in some cases they do not explain departures at all and rather explain _reduced need for new spending_. But they are a large part of the strategy at play.
In the longer term, I personally favor a "soft lean-and-done" approach to Ethereum: once the Strawmap is completed, generally stick to security fixes and small high-value changes, and have a much higher bar for considering new feature additions to the protocol. This allows Ethereum to remain capture-resistant without demanding very large budgets. Learn less from multimillion-line-of-code behemoth projects, more from bitcoin.
The past years have been a challenging era for Ethereum. However, the ecosystem is adapting, both inside the EF and outside, and I am confident that Ethereum is very well-positioned to succeed and thrive.
https://t.co/iZiOonRYzR