Ed Felten

@econcallum @alexcdot I responded to clarify because the original tweet said "vulnerability" and "at-risk" which reads as less neutral.

@alexcdot @EdFelten Yes I am careful to say “exposure” rather than eg “replaced” or whatever

Shortly after ChatGPT was released, a paper came out which estimated the vulnerability of different occupations to AI disruption. Since then, the MOST at-risk occupations have grown by the MOST. The LEAST at risk-occupations have grown by the LEAST. 🤪

@econcallum See the top of section 2. "The term 'exposure' is used so as to be agnostic as to the effects of AI on the occupation, which could involve substitution or augmentation depending on various factors associated with the occupation itself."

@econcallum This point is often misunderstood, unfortunately. Our paper's metric relates to the *magnitude* of impact on a job, but not the *direction*. Direction is much harder to predict.

@EdFelten @Offchain Enterprise adoption of rollup tech is the signal that matters. When F500 companies trust the security model enough to deploy, it validates years of R&D. The next challenge: making the security guarantees legible to traditional risk teams.

This is a very cool moment. Seeing the technology we at @Offchain Labs have been building for the past 8 years adopted by a Fortune 500 company is incredible. The best part about deciding what features to ship for the Arbitrum stack (Stylus, Timeboost, the new pricing algorithm, etc.) is that we can now do so with multiple environments in mind that all have different target use cases, who may or may not want to adopt specific features: @Arbitrum One for general finance and settlement @RobinhoodApp as rails for their app and DeFi for Stock Tokens @edgeX_exchange for pure execution on their perps exchange Just to name a few! While this is only a testnet, I’m very excited to see what developers will be able to build with Stock Tokens as assets with Arbitrum powering all of it.

Deeply saddened to hear of the passing of Dave Farber. He was a true pioneer who had major influence on the architecture of the Internet and tech policy. Rest in peace to one of the most "Interesting People" our field has ever known. mailarchive.ietf.org/arch/msg/ietf/…

Day 1 at @DAF_Global 📌 🇬🇧 Who owns the rails of tokenized finance? 🧐 That question matters more than which asset gets tokenized first. Ed Felten (@EdFelten), Co-Founder & Chief Scientist at Offchain Labs (@Offchain), put it plainly 👇 “Because of the optionality that comes from having been here early, if this technology does end up becoming the main rails, you’re in a position, first of all, to profit from it, but second, to have some influence, more influence over how it develops. I’m a big believer that these rails are superior in the long run as we continue to build them out.” No one knows exactly where this technology is heading 🤔 That is exactly why early exposure matters. This is not just about upside 📈 It is about influence, standards, compliance, and interoperability as the next financial rails take shape. #Tokenization #DigitalAssets #FinancialInfrastructure #Compliance #Regulation #Interoperability #Blockchain #TradFi

Arbitrum One soars past 1100 TPS and sustains 150 mgas/second. Arbitrum’s new gas pricing algorithm is being battle tested today and the network is rising to the moment, with record throughput and low gas prices as activity on the network surges.

How and why Arbitrum is the home of DeFi, more now than ever.

The chain with the highest net inflows in 2025 tells a clear story: capital is consolidating around scalable, liquid, and production-ready infrastructure and @arbitrum is leading that shift. Arbitrum Everywhere

When building Arbitrum, protecting users against front-running was always a top level design principle, right next to security. Over the years, I’d very often get asked why this was so important and the answer was always twofold 1. I view it as part of our basic duty to protect users. 2. In traditional markets, front-running is illegal. Regulators might not have caught up to crypto yet, but they will and the same principles would and should apply.

Debate on Ethereum’s L1 design is healthy and necessary. For a thoughtful, research-driven take on instruction set choices, I recommend: “Why RISC-V Is Not a Good Choice for an L1 Delivery ISA, and Why WASM Is a Better One” by @EdFelten 🔗 ethresear.ch/t/why-risc-v-i…

1/10 New blog post: a control-theoretic view of Arbitrum’s constraint ladder gas pricer, why current rules overreact to harmless bursts and how a “constraint ladder” may fix it. One price, multiple time horizons, stable behavior.

Crypto-means-cryptography literature gives huge importance to saving communication rounds, making protocols non-interactive. This typically comes at the cost of making protocols computationally expensive. FHE and (non-interactive) publicly verifiable secret sharing are good examples of this phenomenon. Some in the crypto-means-cryptocurrency space have also taken up that model: make the protocol non-interactive and go for beefy machines. [I agree non-interactive protocols also look easy to understand/cool to propose. I have done so myself. say eprint.iacr.org/2023/451] However, in experiments/practice, I am regularly finding that interactive protocols are regularly beating non-interactive protocols. Logarithmic-round protocols are regularly beating constant-round protocols with the same communication overhead. Modern networks have much improved communication bandwidth and low latency, and we should not disregard their capabilities.

This post introduces some new concepts in L2 pricing, which we at @Offchain Labs are proposing for adoption to the @Arbitrum DAO. This cross-posted at the Arbitrum Research Forum, research.arbitrum.io/t/multi-constr… I’ll start by reviewing how L2 pricing works on Arbitrum today. This is fairly typical of how blockchains price their gas. 🧵 Then I’ll move on to the new ideas. This post will only cover the pricing of L2 gas, and won’t address the data posting fees that get charged to cover data posting on L1. I’ll also set aside questions of multi-dimensional pricing–those can be combined with ideas from this post, but trying to cover that would make the post longer than it already is. L2 gas pricing on Arbitrum today Why does the chain limit gas usage? Ultimately, we need to limit gas usage to make sure that the chain’s infrastructure doesn’t get overwhelmed and run out of a resource. In practice, execution nodes are the limiting factor, so we’ll focus on them. There are three main things we need to protect: Execution: make sure that a node that is executing the tip of the chain can keep up with the blocks being issued by the sequencer Sync speed: make sure that a node that is behind the tip and synching can catch up quickly enough State growth: make sure that the state of the chain doesn’t exceed the size of practical, affordable storage devices on a node Each one of these implies an upper bound on the gas used by the chain, averaged over some period. But the periods are very different! For execution we care about a period of seconds; for sync speed a period of hours to days; and for state growth a period of weeks to months. These are effectively three different constraints on gas usage, which operate over different periods of time. The current pricer essentially mashes these together into a single constraint which is supposed to protect all three resources, at different levels over different periods of time. As an example, suppose that for execution we need to limit usage to 50 Mgas/sec over an adjustment time of 102 seconds, and that to control state growth, we need to limit usage to 25 Mgas/sec over an adjustment time of one day. If we insist on using a single constraint to protect both resources, as the current pricer requires, we’ll probably be stuck with a target of 25 Mgas/sec and adjustment time of 102 seconds, because safety seems to require us to use the minimum of the two gas targets with the minimum of the two adjustment times. (We can be a little more aggressive than that, but not much.) Multi-constraint pricing If we know the gas target and adjustment time we want for each resource, we can build a pricer that tracks all of our constraints, and raises the price only in response to the actual constraints (if any) that are being exceeded. This approach allows each constraint to have its own target and adjustment time. Where the current approach has a single backlog with its coefficient in the exponent, the multi-constraint one has a linear combination of the per-constraint backlogs. To see why this is good, consider the example from above. With 30 Mgas/sec used over 10 minutes, the execution constraint will keep its backlog at zero, and the state growth constraint will build up a backlog of 5 Mgas/sec times 600 seconds = 3000 Mgas. The price will multiply by a factor of exp(3000/(25*86400)) ≈ 1.001, which is much better. If the usage persists at the 30 Mgas/second rate, the gas price will eventually rise more, but with a one-day adjustment window the pricer can afford to be very patient. That said, if usage goes above 50 Mgas/sec, the execution constraint will kick in, and it is much less patient–which makes sense because if a node falls behind the tip of the chain, we don’t want to wait hours before it can catch up. In that case the price would increase with more urgency, allowing the node to catch up quickly. This is the beauty of multi-constraint pricing. The pricer can be patient when addressing longer-term needs, and more aggressive when protecting shorter-term requirements. Constraint ladders Multi-constraints are an improvement, but simulations suggest that we can make one more improvement. When two constraints are farther apart, like our (25Mgas/sec, 1 day) and (50 Mgas/sec, 102 sec) constraints, it seems to be beneficial to introduce a set of intermediate constraints between the two. We call this a constraint ladder. The effect of this is to create a more evenly spaced set of constraints, causing the pricer to more gradually lose patience, and increase urgency, as the usage gets farther from the long-term constraint and closer to the short-term one. I’m planning to write more about constraint ladders in a later post.

Research post by @EdFelten on multi-constraint pricing, research.arbitrum.io/t/multi-constr…, which is a step towards full-fledged multi-dimensional pricing. The post explains current L2 execution pricing of Arbitrum chain, and proposes adding constraints for better resource allocation.

Our paper on Economic Censorship Games in Fraud Proofs (arxiv.org/abs/2502.20334) co-authored with @BenBerg07141321 and @EdFelten from @offchain and Benny Sudakov from @ETH_en was accepted at ACM EC 2025. Check out the list of accepted papers here: ec25.sigecom.org/program/accept…

@dmihal @_weidai @0xiamnico Stylus injects code into the app WASM to do gas metering. This is safe to do because of WASM's type-safety. And because WASM is structured, you only need to inject one gas adjustment per basic block, not per instruction. (Both would very difficult to do w/ RiscV.)

@EdFelten @_weidai @0xiamnico What did Stylus do different than other WASM implementations in relation to metering?

Why risc-v over wasm for Ethereum contracts? If the argument is that there is more risc-v zkVMs than wasm ones, then that's the wrong way to look at it. WASM actually has a lot of nice properties that EOF is trying to add, which risc-v doesn't have (e.g. it doesn't have jumps and is easier to analyze statically). The ability to prove properties about contract code and lower to machine code while preserving gas accounting are the key properties. This actually has been done in wasm by ewasm couple of years ago (surprised that VB didn't mention this in the post). ZK-friendliness between risc-v and wasm shouldn't be the deciding factor (and it is a toss-up based on what I found when I deep dived this ~2years ago).

@_weidai @0xiamnico Yes, Arbitrum Stylus does proper gas metering for WASM code, integrated into an EVM stack.

@0xiamnico Didn't Arbitrum Stylus solve this? cc @EdFelten

Ethereum-aligned