ex.rs

Stars Are Hard, Comparisons Are Easy

Wed, 08 Jul 2026 00:00:00 +0000

my work, AI-generated overview

Somewhere around 2015 I admitted to myself that my IMDB ratings were garbage: the numbers meant nothing. Asked to give a movie 7 or 8 stars, I produce noise: it depends on my mood, on the last thing I rated, on whether I’m anchoring against masterpieces or against the mediocre thing I watched on a plane. A 7 from 2013-me and a 7 from 2015-me are not the same 7. What I wanted was for my ratings to be calibrated: an 8 should be a statement with content, comparable across years and genres.

But here’s the thing: while I can’t rate a movie in isolation to save my life, ask me which of two movies is better and I usually answer quickly, and consistently. This is an old observation — psychophysicists have known for a century that absolute judgments drift and paired comparisons are stable. So the plan wrote itself: stop rating. Compare, and let the machine infer the numbers.

The machine works like this. Every item gets a hidden score, and a comparison is a noisy coin flip whose bias depends on the score difference — the same family of models behind Elo in chess. The twist is to be properly Bayesian about it: instead of a single number per movie, keep a full posterior distribution over every score, so the system knows not only the ranking but how sure it is of each part of it. That uncertainty then gets put to work: the system picks the next question to ask — which two movies to show me — to learn as much as possible from each answer. And at the very end, stars fall out for free: map the posterior scores through their quantiles and an 8 finally means “better than this fraction of everything you’ve compared,” calibrated by construction.

In 2022 I finally sat down to build it. The reason it turned into a project rather than an afternoon is a single integral. The Bayesian fit needs the expected value of a certain smooth loss under a Gaussian, and that integral has no closed form — the standard move is to approximate it numerically, everywhere, millions of times. But it turns out the logistic curve is almost an error-function curve, and error functions have a lovely property: the approximation commutes with the expectation. Approximate first or average first, you get the same expression. Add a small correction — a handful of Gaussian bumps, fitted once — and the approximation error drops to three parts in ten million while every quantity you need for optimization stays in closed form. The whole posterior fits with textbook Newton iterations, no sampling, no quadrature. As I wrote in the paper, the closed form has no business working out as cleanly as it does. But it does, and chasing that kind of unreasonable tidiness is most of why the project is fun.

The empirical side had its own surprise. Of the strategies for picking the next comparison, the greedy one — directly minimize the expected number of ranking mistakes, the very metric being scored — turns out to be the worst, losing even to picking pairs at random. It keeps probing the current photo-finishes instead of spreading its questions around. The strategies that target uncertainty itself, like expected information gain, win comfortably. Optimizing your objective one step at a time is not the same as optimizing it.

The project then sat mostly dormant for a few years, the way side projects do. This year I picked it back up — coding agents have lowered the activation energy of “finally do it right” to roughly zero — and finished the job: a proper write-up of the math, a test suite, and support for ties, because not every comparison has a winner. Ties brought one more pleasant surprise: a 1970 model by Davidson slots into the same closed-form machinery exactly, down to the integrals, with the tie-proneness of the domain (rare for movies, common for chess, unknown a priori) learned from the data alongside everything else.

The code (a reference Python implementation and a fast C++ one) is at github.com/murbard/ranker, and the full write-up is in the paper (PDF). As for the original itch: a decade later I still haven’t re-rated my movies. But the difference between “my ratings are garbage” and “my ratings are garbage, and I have a machine that fixes this” matters to me, and the second one is now true.

Even a Bag of Words Has a World Model

Wed, 08 Jul 2026 00:00:00 +0000

my work, AI-generated overview

In October 2023, Gurnee and Tegmark published Language Models Represent Space and Time: linear probes on Llama activations recover, among other things, the latitude and longitude of places the model has read about. The paper was received as ammunition in the “do LLMs have world models?” debate, and the skeptics’ rebuttal was predictable: recovering coordinates with a linear probe is mere statistics, correlations between surface features, not a model of the world.

I always found that rebuttal strange, because it gets the burden of proof backwards. Of course LLMs have world models. Modeling the world is not an exotic capability that emerges at some parameter count; it is what learning from data about the world does by default. Compression is the discovery of structure. The interesting questions are about how rich and how faithful the model is, not whether one exists.

Back then I started a small experiment to make the point by reductio, and, in the age of coding agents, finally finished it. Strip everything away — no transformer, no embeddings, no attention, no pretraining. Take the English Wikipedia article of every country and territory, compute tf-idf, and fit a linear ridge regression from word frequencies to the country’s location. If a linear readout of geography counts as evidence of a world model, then a bag of words has one too.

To keep it honest: 238 of the 249 articles literally contain the country’s coordinates (Wikipedia footers), so coordinate strings are stripped and tokens containing digits are excluded from the vocabulary. And rather than regressing latitude and longitude directly — which punishes predictions near the antimeridian with an absurd squared loss — the model predicts a point in 3D that gets projected back onto the sphere. Everything is evaluated with 10-fold cross-validation, vectorizer refit on the training folds.

The result: a median error of about 1,050 km across 248 countries and territories.

The mistakes are the best part, because they have geographic semantics rather than the flavor of noise. Réunion is pulled toward France and Timor-Leste toward Portugal; Kiribati, which straddles the antimeridian, lands on the wrong side of the Pacific; Canada and Chile get dragged toward their population centers. The regression is wrong the way you would be wrong if everything you knew about the world came from reading about it.

Two details surprised me. In 2023, my quick attempts had gradient boosting comfortably ahead of linear regression; once the target lives on the sphere, the linear model wins (1,058 km vs 1,344 km median). And cross-validation selects the smallest ridge penalty on the grid in every single fold: with ~30,000 features and ~220 training examples, the best regime is near-interpolation. The geographic signal isn’t concentrated in a handful of gazetteer tokens that regularization would preserve; it is smeared diffusely across the entire vocabulary.

If a linear map from word counts recovers the shape of the globe, then “the probe is just statistics” fails as a rebuttal — not because the probe is more than statistics, but because there is no distinction to draw. Statistics about the world, compressed, is a model of the world. The bag of words has a crude one. LLMs have vastly better ones. The claim that they have none was always outlandish.

Code, data, and the experiment log: github.com/murbard/tfidflatlong.

The Frayed Edge of Bespoke Software in the Age of Agents

Thu, 16 Apr 2026 00:00:00 +0000

In 2021, I purchased a property in Tuscany, sight unseen. This was in the midst of COVID restrictions, and UK residents were not allowed to travel outside of the country. The realtor did a tour of the place with a phone camera, and the deal was struck. The property had been renovated completely in the early 2000s, but was mostly left abandoned. With just a bit of work, it would be ready next year. Oh, sweet summer child.

Renovation in Italy is not for the faint of heart. The pristine scenery of Tuscany, its authenticity, comes at a cost. Permitting is … difficult. I am now five years into this renovation project, and I think I see light at the end of the tunnel. This post is not about my woes as the owner of international real estate; it’s about using coding agents, like Claude code, for project management, so bear with me.

The renovation work turned complex for a few reasons. The design was outdated and needed a refresh, but design plans (including interior design) must be filed with the municipality as part of an overall renovation plan. The pool turned out never to have been filled, and if it had, it would have slid down the hill, which is largely made of clay. This meant it had to be re-permitted and reinforced with dozens of deep concrete pillars. All in all, the work involves architects, contractors, lawyers, surveyors, banks, permits, land purchases, and a steady stream of email in English and Italian. For years, the actual state of the renovation ended up scattered across Gmail, attachments, shared folders, some calendar reminders, and whatever I happened to remember.

The amount of communication itself was quite manageable: on average, over the past five years, it’s amounted to about an email a day, with long periods of quiet and sudden bursts when permits, contracts, or financing were moving. The management challenge lay in how the project spanned years and involved many parties who were waiting on one another. A surveyor would promise something in October that became relevant again in February. A number buried in a PDF attachment would resurface months later in a discussion with a bank. A planning question that seemed settled would quietly reopen because nobody had a clean record of what had already been agreed.

When I figured out something was blocked, I could look things up in Gmail if I roughly remembered the date or the sender, or had a decent guess at the right keyword. Most of the time, the problem was broader than that. I needed to recover the current state of the project: what had happened, what was still open, who owed what, what had slipped, and which loose ends were likely to matter later. Reconstructing that by reopening threads and attachments each time was slow, and the result was never very satisfying because the useful context lived across too many places.

I have been an early adopter of AI for coding. I started using GitHub Copilot in 2021, invested in magic.dev’s pre-seed round… I was blown away by the step change when OpenAI’s o1 first came on the scene. This was the first model to pass my favorite interview questions, a disarmingly simple question that many CS graduates shockingly fail because they are trained to answer these questions with pattern recognition instead of reasoning. I first used Claude Code around May 2025.

My first reaction was that the interface was finally right, a CLI blends the conversational aspect of AI with the natural workflows of building software, and that the model was finally decent at planning. Tool use had been around for a while – the toolformer paper came in February 2023 – but this was the first time I was really interacting with models that had significant RL training in tool use. I immediately cranked up the difficulty of what I was trying to accomplish with it and quickly noted limitations; the model would simply cheat… replace the unit test it had written with one it could pass, change the winning condition. It couldn’t admit defeat, didn’t know how to ask for help, and didn’t understand how to conduct experiments to root out bugs. Those are still issues today, but to a lesser extent. I didn’t play with coding agents until later that year, when I caught word that they had finally gotten to the point where they were getting useful. I started completing a host of small personal projects I had needed, and launched experiments to generalize their use across the software companies I founded. Towards the end of 2025, I started hearing about people using coding agents to manage their emails, and it got me curious. I didn’t want to give Claude Code unfettered access to my email, but the idea that the model’s planning and tool-use abilities could extend to tasks beyond programming felt intriguing.

In February 2026, I set out to use Claude Code to build a system to help me manage the renovation. The privacy concerns were modest; all the emails involved are banal and do not contain particularly sensitive information, so I could easily filter them out. The scope of the project was also small, and it would help me build up the experience to scale this approach to much larger project management tasks.

A mistake would have been to connect Claude or OpenAI by MCP to my inbox and ask it to “manage” the project or to suggest what to do. The models are not good enough for that. In many ways, they optimize to give you a satisfying-seeming answer right away, not to do the right thing. Ask an MCP connected model for “what’s urgent right now,” and it will do something like search for the keywords urgent | time sensitive | important in your inbox, look at a few messages, and hurry back with a polished but superficial answer.

I had to build a “harness”. Noam Brown, a researcher at OpenAI and an expert on planning, holds the view that all custom-built harnesses will become irrelevant and be replaced by better reinforcement learning training. He’s probably right, but that is at least months from now! This is the harness I had Claude Code build first:

The system starts by syncing project email from Gmail into a local archive of raw messages and attachments. Local files are easier to grep, cache, inspect, and process repeatedly than a live inbox reached through an API. It also means the agent doesn’t have unfettered access to the inbox, only what the script, which is run externally, is programmed to download. The pipeline then walks those emails for shared links and downloads the corresponding files from Google Drive, Dropbox, and WeTransfer, because a large share of the actual project lives in drawings, contracts, invoices, surveys, permits, and estimates rather than in the message body. It also extracts text from documents and useful descriptions from images, so information does not get trapped in attachments.

Once that corpus is assembled, batches of email and attachment text are processed through Claude’s API to extract structured events: commitments, decisions, issues, financial facts, deliverables, deadlines, milestone changes, and anything else that deserves to be a first-class item in the record. This is appended as JSON lines to a log file. Why use the API when the agent environment uses the same models and offers cheaper tokens? Because long repetitive runs need software around the model, the program handles batching, retries, checkpointing, deduplication, validation, and recovery from malformed output. Claude provides the judgment inside a narrow task; the surrounding code keeps the process stable over thousands of messages. You could try asking your coding agent to go over 5 years of emails one by one and build a coherent timeline, but it will most likely veer off track, change its approach midway through, or delete the data. There’s still untapped potential in putting AI models in a well-controlled for-loop.

Those events feed a multi-scale timeline. At the bottom, there is the append-only event log. Above that sit monthly summaries and a current project context that can be queried or rendered into a readable timeline. A reminder layer compares open commitments against Google Calendar and proposes follow-ups.

So far, it has processed about 2,000 emails spanning 2021 to 2026, extracted 1,338 structured events, identified 102 people, and organized the work across 10 workstreams over 62 months. The number of decisions and resolutions since February is five times the previous rate, indicating that the system has been quite effective at getting things moving. I attribute a big part of it to tracking small commitments, those little promises that go unfulfilled and later pile up as delays: revised drawings next week, a document to be sent tomorrow, a correction to a deed, a cost figure to be confirmed, a map someone is still waiting on. They rarely look important in isolation, but they add up and become blockers when nobody records them.

A key design choice was to represent the work as events on a timeline rather than ask a model to rummage through an inbox whenever I had a question. In a multi-year project, the email is usually the wrong unit of thought. What matters operationally is that a contractor promised revised drawings by Friday, a lawyer said a deed amendment was required, a bank requested supporting documentation, or a permit moved from draft to filing. Once those facts exist as dated records with people, workstreams, and links back to source material, the project becomes much easier to reason about.

Search still plays an important role; I regularly search the timeline and the underlying archive. But the search now runs over a representation that already carries context. Gmail search can retrieve fragments if I remember enough to ask the right question. A timeline preserves the dependencies and unresolved issues that give those fragments meaning.

Claude Code was valuable because it gave me a working environment rather than a chat window. It could read and write files, run commands, inspect failures, patch code, rerun jobs, and keep iterating until the workflow behaved properly. That made it cheap to develop and iteratively test tooling around the project. The first version came together in just a few hours, but over the next two months, it steadily improved with use: better recovery from malformed model output, improved file handling, headless authentication for remote runs, a unified CLI, and prompts and schemas that more closely matched the project – normal product work, but in a much tighter loop than would have been practical before.

Humans use tools because they take away physical or cognitive load and provide a repeatable way to perform a task. It is natural for agents to use tools and even build them for their own purposes. So why not connect the agent to a project management tool, and have it file Jira tickets or track progress in Asana? Partly because the project was small enough, I did not want the added complexity of interacting with a project management tool. But more interestingly, the structure that worked well here looked slightly different from that of ordinary project-management software. Existing tools are built for people who stare at dashboards, drag cards across boards, and update fields by hand. The agent could work better with something plainer: files, markdown, JSON, directories, scripts, and a timeline with stable links back to source material. I suspect a lot of software built primarily for agents will end up looking like that. It may be less polished to the eye and more useful in practice. It’s also clear to me that the future of much enterprise software is to build software for agents, at least in the short run, before they just write what they need on the fly.

Today, I mostly “use” the system by talking to Claude Code, but a lot of the value now lives in code written earlier, in scripts that call the API, and in workflows that began as conversations and later hardened into commands. The boundary between software, agent behavior, and conversation has become fairly porous, and that has proven helpful. Useful workflows often begin as one-off interactions; once they prove valuable, I pin them down in code. When the project shifts, I can loosen part of the workflow again or add another layer around it. A packaged product would have forced more structure up front than this project wanted. I call this software with a “frayed edge”: a tightly woven core that, after a while, doesn’t change much; an interface at the periphery that gets rewritten as the workflow evolves; and a chat interface that can handle the unexpected. Packaging “project management with an AI agent” as a product would miss much of the point. Software crystallizes workflows into a polished but inflexible interface, whereas much of the value I’m getting comes from the system’s overall fluidity.

Whilst the agent conveniently did all the coding, I still had to understand what I was building from an architectural perspective. No, this doesn’t point to some long-arching synergy between human and AI; the centaur era (where man + machine is greater than man or machine alone) will not last long, but we are in it, and it’s thus relevant to talk about it. Among the decisions I had to make were whether the timeline should be append-only, what belonged in the schema, how large a batch should be, which data should be cached locally, which tasks belong in deterministic code, and which ones benefit from model judgment. Those questions do not disappear because a model writes the code.

That should still be encouraging for non-programmers. The bar is no longer “can you implement the whole thing by hand?” It is closer to “do you understand the workflow well enough to shape the system, inspect its outputs, and notice when it is going wrong?” You still have to get your hands dirty, but you do not need to be a professional developer to build something useful.

Seen from a distance, a fair amount of middle management consists of maintaining institutional memory and doing follow-up. Who promised what and when is it due? What does it depend on, and who needs reminding? Which disagreement is being reopened because nobody remembers how it was settled? Strategy, judgment, negotiation, hiring, politics, and taste remain human problems for the foreseeable future. But the connective tissue of coordination is much more legible to software than many organizations admit.

The cost of bespoke internal software has now dropped sharply. Someone who understands a workflow well, working in an agentic coding environment and with a short iteration cycle, can assemble something that previously would have required a small internal tools team. This will also reduce the importance of middle management, as more leverage can be gained when information is surfaced and managed easily. This is not the first time this has happened; computers and IT have delivered on some of that promise and extended the scale at which individuals could operate, but this stretches it even further.

A new type of software is emerging, one that exists on a continuum between robust, repeatable tooling code, high turnover features rewritten by an agent, and an agent orchestrating their use. The agent becomes useful not just as a developer but also as a somewhat competent planner, capable of using tools and making sense of structured information collated from disparate sources.

P.S. We should bear in mind AI will likely make the vast majority of intellectual labor obsolete in the coming years, then recursively self-improve at an increasing pace. This will not stop at the digital world; molecular nanotechnology, as envisioned by Drexler, offers the prospect of doubling the stock of productive capital every hour; the surface of the earth will be covered with solar panels, and planets will be disassembled to surround the sun with a Dyson sphere. The odds are stacked against humanity’s survival in this process, without a collective realization of what’s happening. Even if humans do survive, the world will be largely unrecognizable. In this context, the future of middle management and custom software is quaint, and the wisdom of pouring time and energy into a renovation project in its fifth year is questionable. But there is little sense in living our lives as if we were right on the cusp of the singularity, and at least we can finally enjoy getting a handle on things for a brief moment.

Consumption inequality

Tue, 30 Dec 2025 19:38:00 +0000

Economic inequality lies less in wealth than in consumption, at least for billionaires, and at least in the sense that consumption is what actually commands real resources. A pile of stock in productive companies, or even a pile of cash that never becomes spending, doesn’t directly divert today’s output away from anyone else.

And it isn’t inert. Being willing to sit on long-duration equity at a low required return bids up valuations and, at the margin, lowers the cost of capital. Likewise, keeping cash as a bid for liquidity means some money is being held instead of spent, so there is less immediate pressure on prices, and interest rates can be lower than they otherwise would be, even if that cash is literally just stashed under a mattress. Arguments about the assets being productive are a red herring.

What bites is spending that actually pulls on scalable capacity and scarce inputs. When billionaire wealth is spent on resource-intensive goods and services, productive capacity and bottlenecked inputs get pulled toward satisfying that demand, leaving less capacity for other uses. If big chunks of capacity are going into making yachts, they’re not going into healthcare.

Billionaires do obviously consume far more than most people, but they consume a much smaller fraction of their wealth, because there’s only so much you can buy. And even that spending is often positional and doesn’t translate cleanly into a large diversion of real resources. Buying a very expensive Renaissance painting doesn’t cause the economy to allocate more labor and materials to producing Renaissance paintings. It mostly reallocates ownership, with the real resource burn concentrated in intermediation, promotion, authentication, auctions, lawyers, security, and there are diminishing returns there. Same story with beachfront property and trophy assets, you’re bidding up scarce slots, not placing a production order.

Once you put those two facts together, low consumption relative to wealth, and a big chunk of that consumption being positional, the conclusion is pretty stark. If you look at the actual flow of goods and services the economy produces, very little of it ends up going to billionaires. Their lifestyle footprint can be loud and visible, but it’s a microscopic layer on top of a massive base of production that overwhelmingly serves everyone else.

People often get this exactly backwards and praise billionaire spending because “it creates jobs” or “stimulates the economy.” That’s the wrong frame in a mostly capacity-constrained economy, demand gets accommodated by reallocating resources and by prices moving. It’s also why trickle-down economics, in its popular form, is nonsense. The idea that letting the rich keep more money helps because they will spend it and “create jobs” is backwards, they don’t spend much relative to their wealth, and a lot of what they do spend is positional.

When the rich raise everyone’s standard of living, it is mostly through the opposite channel, saving and investment. A higher propensity to save lowers the economy’s cost of capital, and that makes it easier to fund new capacity, new technology, and new firms. Over time, that raises productivity, and in competitive markets the gains show up as better goods, lower quality-adjusted prices, and higher real wages.

The first implication is that there isn’t much to be gained by “grabbing the pot of money,” if what you do with it is just spend it. If that wealth wasn’t being turned into consumption, it wasn’t directly diverting real resources. Convert it into pure spending and you don’t magically increase the economy’s productive capacity, you mostly just push more demand through the same bottlenecks.

The second implication is that the recent obsession around the tax strategy of borrowing against appreciated assets is mostly a nothing-burger as a lifestyle-finance story. There isn’t that much billionaire consumption to finance relative to billionaire wealth to begin with. And if borrowing were treated as a realization, taxable event, I’d expect many to scale back consumption sharply. For people who’ve worked hard to build wealth, there’s something uniquely offensive about pissing it out to the government, plenty would rather cut down already-discretionary spending than hand it to the bastards.

Thoughts on inscriptions

Sun, 07 Jan 2024 13:54:00 +0000

“Inscriptions” became a popular way to create NFTs on Bitcoin earlier in 2023 and have picked up significantly in the past month. However, they are, in many ways, a step backward.

To understand inscriptions, we must first understand some technical limitations of the Bitcoin blockchain and the historical emergence of solutions around it.

Data-availability and sovereign rollup

Bitcoin generally lacks support for the statefulness and logic required to deploy all but the most basic smart contracts. It is, however, possible to write arbitrary data to the Bitcoin blockchain. As such, Bitcoin can serve as a “data-availability layer” for a chain following arbitrary logic. You can create arbitrarily complex blockchain logic that takes as input data from the Bitcoin blocks and maintains the state of a ledger. This is the approach taken by systems like Mastercoin, Counterparty, etc. The logic can be arbitrarily complex and include smart contracts. If you are so inclined, think of the chain as a linked list and of the logic as a “fold” operation where the accumulator is the ledger state. This approach has recently been rebranded as “sovereign rollups.” There are several issues with it.

First, Bitcoin data-availability is fairly limited and expensive. Transactions can only use a small fraction of their content as a data payload, and the data itself is limited to 1MB - 4MB per 10 minutes. There isn’t much capacity to go by. While this can price out small transactions, it’s silly to try and police how a permissionless network will be used. Moreover, the Bitcoin network’s security is meant to be subsidized by fees, not inflation. As scaling solutions build up, Bitcoin purists should welcome, not rail against, any fee they can get, however, it’s far from certain that they can contribute meaningfully to the budget in the long run. Bitcoin has one thing to offer to these applications: its brand and luster¹. The market for collectibles, and frankly, memecoins, is driven by many intangible factors, not necessarily cost-efficiency. Nonetheless, the cost does create a strong current to swim against, and applications will tend to migrate where fees are cheaper. Part of the problem is that Bitcoin only has its brand to offer; these systems do not meaningfully interact with bitcoin, the asset. This gets us to our second point.

Second, these systems cannot securely share their state with other systems, including the base chain they are built upon. In the case of a so-called “sovereign rollup” on top of Bitcoin, this means, ironically, that they cannot use bitcoin as a native asset. It’s perfectly possible to deposit bitcoin into such a rollup — the nodes computing the state of the rollup can take note of such deposits — but it’s not possible to take it out. This is because the Bitcoin chain itself is unaware of the state of the rollup; it does not and cannot know whether or not a valid withdrawal is taking place. Relatedly, Bitcoin light clients do not and cannot provide information about the state of the rollup. The same goes in general for so-called “sovereign rollups”; they cannot prove their state to any other rollup, meaning they are condemned to interact with other rollups via trusted bridges.

To conclude this section, I’ll add a note on colored coins, which are in some way a lighter version of the above. They typically do not implement extraneous logic but use data to “tag” certain transaction outputs (UTXO) with nominal value as representing assets. With careful wallet implementations, it’s possible to segregate these outputs from regular coins and treat them as special.

Ordinals and inscriptions

“Ordinals” for digital collectibles became popular in the middle of 2023, somewhat went away, and are now making a comeback. They do not implement complex logic as outlined above. As such, it’s not really possible to implement decentralized exchanges for ordinals, nor is it possible to implement auction contracts or a host of other important primitives for collectible ecosystems.

They differ from what has been typically seen in the NFT space in two particular ways:

They are issued on the Bitcoin chain.
The media content of the collectible is written in the transactions themselves.

Those two aspects are completely independent. It would be possible for ordinals to be issued on Bitcoin without inscribing the entire media content in transactions (by inscribing instead an IPFS link for instance), and of course, people have taken to inscribe collectibles on other chains.

On the first aspect, as discussed above, Bitcoin is not fit for purpose as most interesting primitives for a collectible ecosystem cannot be implemented. However, it does lend its brand, which has been enough to create an interest in the phenomenon.

The second aspect is weird, and a proper discussion involves dispelling technological misconceptions while reflecting on… reflexivity. Let’s start with the strict technical requirements for storing NFT media content.

Storing NFT media content

An NFT represents a title, a digital right to a piece of media. Those rights can vary. In many cases, the NFT only represents a right to hold the NFT, and nothing else. The fact that a piece of media was attached to it is meaningful to collectors, regardless of them holding any rights. Collecting is not about obtaining some IP right to display a piece, otherwise, no one would collect old masters; it can be about bragging rights, it can be about supporting artists (yes, collecting dead artists is a way to retrocausally support them, as the expectation of future collection is what enables speculators to support them during their lifetime). It can also be about explicit IP-related rights, but I think people who focus on some concrete form of utility, be it real-world utility or IP rights, are somewhat missing the point.

Hashes and IPFS

So what it is to be done about the piece of media? A simple hash of the content is sufficient in my opinion, it indicates without ambiguity that the piece was attached to the NFT, and that is all that matters. But what about the media itself? The collector can right-click and save it if they care to. This is a function that ought to be automated by most wallets.

IPFS represents a fairly good solution to the problem. It is as lightweight as a hash, but also specifies a fairly general way to retrieve the media if someone cares to make it available. The “natural” solution to the matter is wallets saving the content, running IPFS nodes and pinning it there. This can introduce practical problems, of course, marketplaces need to access the data, and it may be inconvenient to corral it from a bunch of sometimes offline nodes, but this is something that can be solved by caching. Sellers are incentivized to make the content broadly accessible.

Ledger state

It’s been proposed to store data in the state of the ledger. Smart contracts can hold data, which they rely on for business logic, and that data can represent various pieces of media. The advantage of this approach is that the validators of the chain typically have to store that data because they need to assess the validity of any incoming transaction, and a transaction could in theory depend on that data. The initial design of Ethereum does not price state storage correctly; it tries to limit the amount of data stored on-chain via gas fees. This has the unfortunate consequence that, when demand for transactions and thus gas fees are low, it can be cheap to permanently expand the size of that state. The huge size of the Ethereum state tree has been one of its major impediments to scaling, as most of the time spent by validators is waiting for IO in that large tree. Predictably, allowing stateless validation, or introducing state rent has been a major area of R&D in the Ethereum community. Tezos, in contrast, uses a simple but fairly robust approach to managing state size by charging a fixed burn cost for every byte added to the storage. This means that the cost of increasing the state tree size does not depend on gas costs. This offers much simpler UX and implementation than state rent but has worked well in practice.

What am I getting at with all this? I’m getting at the fact that it’s important for the state tree to remain somewhat light, and increasing it should be priced accordingly. This state will have to be replicated across all the validators and all the nodes, with economic incentives. This makes it extremely overkill and also particularly expensive. The convenience factor is high, any chain RPC will reply with the data, but at what cost?

Block history

A third approach, the one taken by inscriptions/ordinals, is not to store the data in the ledger state, but in the blocks themselves.

Blocks provide “data availability” guarantees, although, as Dankrad Feist points out, “data-availability” is a terrible name that obscures what is going on. He proposes the much better term “proof of publication.” Including data in blocks is a way to prove that the data was, at one point, made public. This means that anyone who cared to pay attention at that time, and run a node, was able to download that piece of data. Proof of publication is critical to ensure that all the participants wishing to maintain the state of the ledger, ascertain its validity, or even produce blocks can do so.

Proof-of-publication by itself does not guarantee that the data can be retrieved at a later time. There is no incentive in the Bitcoin protocol, the Tezos protocol, Ethereum, or others to store blocks for longer than the length of a typical chain reorganization. Fortunately, as long as there is at all times at least one altruistic, honest archivist online, then in practice the chain will be saved. Typically, I don’t think it’s worth really sweating incentives when you only need a single honest, altruistic participant, but that depends on the cost of this altruism. If the cost is on the order of thousands of dollars a year, this will just happen; if the cost is on the order of millions, you need incentives, funding mechanisms, etc.

There is no “crypto-economic” mechanism that makes inscriptions in blocks stored more safely and reliably than IPFS pins; in both cases, you are dependent on honest, altruistic participants storing the data. The only mechanism at play is bitcoin miners and node operators not really caring about optimizing their operations enough to prune old blocks. Note that it’s also possible for these miners to selectively prune inscriptions from old blocks with no adverse consequence, as blocks pruned of inscriptions can be used by new participants to validate the chain and recreate the ledger from genesis.

To be completely fair, I have zero concerns about Bitcoin archives becoming unavailable. The cost of storage is minimal, and Bitcoin is a huge social movement. In other words, Bitcoin’s block history isn’t going anywhere. But likewise, when the creator of Hic & Nunc, a leading NFT marketplace on Tezos suddenly pulled the plug on his site, a mirror was up within hours, and all the content on IPFS was repinned. Nothing was lost. IPFS can be brittle if not enough people care about the content. The benefit Bitcoin blocks is that someone is realistically always care about the content enough to save it.

Storing in blocks offers some convenience, but it’s just another form of storage, with a different social dynamic, there is no “crypto-economic” incentive at play. Sadly, there is more to it.

Reflexivity

From a technical perspective, we’ve established there isn’t much of a case for storing media in the ledger state or in the blocks. However, that may not matter. The fact that the data is not stored “on-chain” is unpopular. Maybe this stems from a lack of familiarity with the above arguments, maybe it’s just a coping argument against digital collectibles in general, and maybe it is mere aesthetic preference. No matter, if enough people are convinced that this matters, and if they represent a market of buyers, then the incentive is to cater to that preference. If Elon Musk goes out and complains that “the image isn’t even on-chain,” the merit of technical arguments becomes moot. Reflectively, a Schelling Point can form around the idea that inscriptions are intrinsically more valuable, like a crystal growing around a seed. It does not matter in the least if the seed is a silly misconception, once the crystal is there, it’s there.

To be clear, this is an unfortunate state of affairs. Peacocks got trapped in making huge feathers because of a runaway Fisherian sexual selection phenomenon, making them easier prey, but they can’t escape the circular logic leading to it.

A world where block space is spent on inscriptions because people decided they mattered is slightly worse off than a world in which they recognized it didn’t. But the world is not always as we wish.

I think it’s the brand dilution that fundamentally upsets the Bitcoin purists. ↩

Parallel scans

Sun, 31 Dec 2023 18:26:00 +0000

This post is inspired by the recent paper on Mamba. Mamba introduces a simplified, linear RNN and shows that it can be computed in $\mathcal{O}(\log n)$ time using a parallel scan. It’s not immediately obvious how the parallel scan algorithm can be applied to this recurrence, so I set out to understand the approach and see if it could be generalized.

The parallel scan

We have a sequence $x_0, \ldots, x_{n-1}$ and we want to compute the sequence $y_0, \ldots, y_n$ where $y_0$ is given and for $i > 0$, $y_i = f_i(x_i, y_{i-1})$.

If $y_0 = 0$ and $f_i(x,y) = x + y$, the scan computes the prefix sums, and due to the associativity of addition, it can be computed in parallel. Compute, in parallel, the prefix sums for the first half and for the second half. Then add the last element of the first half (the sum) to each element of the second half, which can be done entirely in parallel. With enough parallel processors, this means the prefix sum can be computed in $\mathcal{O}(\log n)$.

A more complicated example

Let’s consider a more complicated recurrence. We will make the $x_i$ and the $y_i$ vectors, and $f_i(x,y) = A_i x_i + B_i y_i$ for index-dependent matrices $A_i$ and $B_i$.

A priori, this is not an associative operation… But let’s try anyway. We’ll process the first half starting with some $y_0$, and the second half starting with some $y_{n/2-1}$. If we knew the real $y_{n/2-1}$, it would be easy, but we don’t. This doesn’t really help us; if we change $y_{n/2-1}$, we have to recompute the scan for the second half.

The trick is to lift the sequence $y$. Notice that given the $A_i$, $B_i$, and $X_i$, each $y_i$ is a linear function of $y_j$ for $j < i$. But we know how to represent linear functions between vectors: they are matrices. So if, instead of calculating the sequence of $y_i$, we compute the sequence of $Y_i$ which represents the function that gives $y_i$ as a function of $y_0$, then we are getting somewhere!

Indeed, we can compute the second half of the scan as $Y_{n/2}, Y_{n/2+1}, \ldots$ and, when the first half has completed, multiply those matrices by $y_{n/2-1}$, which can be done in parallel.

Generalization

In fact, the transform we have applied applies generically to any function $f_i$! The algorithm is the following:

Compute the first half of the sequence.
For the second half of the sequence, compute $F_i : y \rightarrow f_i(x_i, F_{i-1}(y))$.

In the linear state-space model, the functions collapse and simplify, and we have a neat representation for them. However, in the general case, those functions do not simplify. However, we can perhaps approximate them?

For instance, in the one-dimensional case, we could posit that $F_i$ is well approximated by a Chebyshev polynomial and maintain the $F_i$ as the values taken around the Chebyshev nodes.

The Chebyshev trick can be extended to the multivariate case, but the size of the representation unfortunately blows up with dimensionality $d$ as $\binom{n+d}{d}$ for polynomials of degree $n$.

Alternatively, we could start with a random cloud of points, propagate it using $f_i$, but then assume that $F$ is approximated by a Gaussian process and move the points to somehow provide a better representation of the function, for example by moving them slightly towards zones of higher curvature.

Gradients and conclusion

Another matter is how to deal with gradients. Since the $f_i$ are known, it’s straightforward to compute the gradient with respect of their parameters. However, these are the gradients of the exact scan. Should we use those gradients, or should we use the gradient of our approximation? We know the cloud of points at $i-1$, so we know how a change in our approximation of $y_{i-1}$ and a change in $f_i$ would cause a change in our approximation of $y_{i}$.

Ultimately, this whole fields seems to be more of an experimental science than anything, and mathematics are just here to suggest reasonable things which are worth trying. I believe this is.

It also gives a framework to detect parallel scans… do the functions $F$ belong to some set with a simple parametrization which is stable by composition with $f_i$? Linear functions and simple categorical functions are the only examples I can think of, but there could be more.

Decentralization, what is it good for?

Sun, 22 Oct 2023 21:36:00 +0000

Decentralization is a means to an end. In the case of blockchains, decentralization typically achieves two ends: double spending prevention and censorship resistance — these map, respectively, to the properties of safety and liveness of a consensus algorithm. Consensus algorithms do not require decentralization, but they do require an honest majority. Decentralization helps maintain an honest majority insofar as it forces smaller bad actors to collude with each other or corrupt many honest participants to attack the network.

These are relevant functions of decentralization. The goal is not to create a “participative system” for the sake of it but to create a safe and resilient system. Unfortunately, decentralization is a pretty poor tool for the job:

decentralization implies redundancy and thus higher costs
economic efficiency pushes the system towards centralization, and decentralization generally only survives due to friction
relying on parties not colluding is not great as far as security assumptions go. I trust the difficulty of the discrete logarithm problem in elliptic groups far more than I trust a bunch of random people not to be tricked or coerced into attacking the network

And yet, and yet… decentralization is all we have. It would be fantastic to obtain safety and liveness properties from mere cryptographic assumptions, but that is not the case. Mathematical primitives live in the abstract work of statelessness; ledgers and blockchains live in the concrete world of statefulness, hence the omnipresence of the human element in their security models.

Some good news: double-spending attacks by validators are a limited concern. These attacks must generally target exchanges or bridges because these are fast and automated. It’s tough to commit other types of fraud by corrupting the chain to cause a double spend. Exchanges have means of protecting themselves, especially if the chain offers quick finality, which only leaves cross-chain bridges as sitting ducks.

To be sure, if merchants couldn’t rely on transactions being final, this would render the use of these systems moot, but the vast majority of transactions are too small to be worth launching a double-spend attack on the entire chain. Moreover, in a world where most people are connected most of the time, the presence of forked blocks more than a few hours in the past is confusing to essentially no one. To be clear, double spending attacks are not a major concern, because of the security properties of the protocol. The chain would be useless if double spending were easy, costless, and could happen willy-nilly. In fact, if you do not have a double spending problem, you generally do not need a blockchain at all.

Moreover, these attacks, if and when they happen, can be quickly detected and mitigated. In proof-of-stake systems, the perpetrators can be eliminated from the pool of participants, they can be severely punished, and the entire economy can benefit due to the deflationary pressure of the slashing event. From that standpoint, the security properties of proof-of-stake are far more desirable than those of proof-of-work, despite the popular wish to see tradeoffs in everything.

Realistically, complete liveness attacks that result in halting the chain aren’t a major concern either. They, too, can be remedied with slashing and restarting. The main arguments against this are aesthetic, not pragmatic.

The big, thorny issue is the selective censorship of transactions. That’s the one to worry about, the property most crucially dependent on decentralization. More on this in a little bit.

These observations lead to a few conclusions:

Cross-chain bridges are brittle things, even when they use light-client security
It’s best to not depend on decentralization if you can at all avoid it
Not depending on decentralization for censorship resistance would be great
Turning safety attacks and censorship attacks into full-blown liveness faults is a good thing, actually

The first point is an argument for rollups, which offer the possibility for multiple independent ledgers to bridge with each other without any loss of security (no honest majority assumption is required, unlike light-client bridges in, say, Cosmos)

The second point is an argument against depending on decentralization to preserve the ledger’s integrity. Optimistic rollups rely on including challenges in the chain for their security, which means validators can collude to censor those challenges and steal assets from rollups. Fortunately, such a censorship attack can be readily observed. If the finalization period for rollups is long enough, and the rollups are enshrined in the protocol, this gives the possibility to hard fork out of an unlikely concerted attack. Again, arguments against such approaches are primarily aesthetic, not pragmatic. Polkadot parachains, similar to rollup in many ways, can transfer assets to each other very quickly, but this comes at the cost of trusting the validators not to collude to steal assets because there is no period in which censorship can be mitigated.

The third point is an interesting open research problem. Can we stop censorship on a ledger controlled by bad actors? Perhaps. As mentioned above, censorship can be readily observed. A user posting a transaction can make it quite clear to everyone running a node that they have indeed assigned this transaction, and if that transaction fails to be included in a block, they can infer that censorship took place. This is because, in practice, we have synchronous channels for honest actors to coordinate for sufficiently large synchronization times. But is it possible? One scheme to convert a censorship attack into a liveness attack takes the following form:

Assume a transaction is emitted at time $t$, and seen by all nodes at time $t + dt$, where $dt$ is suitably large to not worry about network latency, partitions, etc. Node $i$ sees the transaction at time $t_i \in [t, t + dt]$. If the transaction is not included at time $t_i + T$, for some grace period $T$, then nodes will probabilistically reject blocks that do not contain the censored transaction for each subsequent block. They do so based on a common draw, meaning they will all reject at once or all accept, so long as they agree that time $T$ has passed.

If the probability of rejection is high, there is a risk that nodes will reject a block at a time when there is disagreement on whether $T$ has elapsed. If the probability is low, then the risk of disagreement is lower, but it will take a long time before the chain halts for lack of inclusion. Typically, the probability should be inversely proportional to $dt$. To be sure, this is not a very good solution. It’s slow and cumbersome, and it would likely only make sense to apply it to fraud proofs or similar critical operations. However, it is a nice proof of existence that there indeed are schemes that can turn censorship by block producers into liveness faults.

In summary, despite its cost, decentralization remains an essential tool for blockchains, particularly for ensuring censorship resistance. While maintaining or improving decentralization is a great thing, there are promising research avenues for minimizing the reliance on decentralization, and both should be conducted in parallel.

Crowdsourcing supplements stacks, part 1

Sun, 25 Jun 2023 13:00:00 +0000

Important update

It seems that one of the reason Vick’s First Defence lost popularity is that, in rare cases, the injected zinc can directly reach the olfactory nerve and cause anosmia. This is a good example of why I’m advocating for caution before shooting anything in your nose. At a minimum, removing the Zinc from the recipe could be wise.

Part 1: LLM ideation

This is the first part of a three-part post exploring ideas around quantified self, citizen science, black-box optimization, and graph algorithms for Sybil resistance. If you’re here for Tezos content, this isn’t about that; I recommend you check @tezos for daily news.

No one welcomes the first symptoms of a cold. Still, lately, as I began taking singing lessons, the dread of the upcoming two weeks of sniffling misery has become even more salient to me. And that is assuming it’s not something worse like a bad covid infection!

My teacher suggested I try Vick’s First Defence. It’s a nasal inhaler meant to be taken at the first symptoms of the common cold or after potential exposure. I was (and remain) skeptical of how effective this could be. Surely, if this worked, the product would be far more popular, wouldn’t it? But I did try it when my wife returned from a trip with a cold. Surprisingly, I did not develop symptoms, even though I typically would in such circumstances.

I set out to understand how it worked. And, for fun, I decided to do so using GPT-4. Yes, large language models are prone to confabulation, and I know it would be naive to ask random questions and blindly trust the output. Yet, rejecting the tool for that reason misses the forest for the tree:

The type of questions I’m asking are very likely to be answered correctly because they are specialized and technical, yet not obscure.
Having to double-check the answer does not mean the answer is useless or not a time saver.

Thus I copied the ingredient list and asked GPT-4 what they might all do.

Aqua, Hydroxypropyl Methylcellulose (1%), Succinic Acid (1%), Disodium Succinate (0.44%), PCA (0.35%), Phenethyl Alcohol, Zinc EDTA, Zinc Acetate, Polysorbate 80, Menthol, Camphor, Sodium Saccharin, Eucalyptol.

I learned that some ingredients might provide a physical barrier, some lower the pH, creating a less favorable environment for the virus to replicate, and some have antiviral properties (Zinc, menthol, eucalyptol).

Let me stop at this point to stress that I have no medical or pharmaceutical training whatsoever. Worse, I am using GPT-4 for research. You are bonkers if you take medical advice from this blog post. What is the point, then? Well, people who actually know their stuff might weigh in and say: “yeah, that makes sense,” in which case, this won’t be for naught. Or they will have a good laugh and explain why it doesn’t make sense. In all cases, the rest of us will have learned something. Ready?

Ok, back to Vicks’ First Defence. “Can we do better?” — I wondered. I asked what stronger antivirals could be used. GPT-4 suggested interferon. No surprises here; intranasal interferon is indeed a treatment for viral infections. The top search result for “intranasal interferon” is, in fact: “Intranasal interferon-alpha 2 for prevention of natural rhinovirus colds.”

Nice! But Interferon has many side effects; it’s a serious medication and a prescription drug. What if I could make a DIY defense spray with more commonly available substances with antiviral activity? I asked GPT-4 to come up with a list of candidate compounds. Did a bit of research on them, and they all seemed interesting.

One, in particular, caught my attention, Iota-carrageenan. A Google search for intranasal iota-carrageenan brings up this paper: “Efficacy of a Nasal Spray Containing Iota-Carrageenan in the Postexposure Prophylaxis of COVID-19 in Hospital Personnel Dedicated to Patients Care with COVID-19 Disease”. In this study, medical personnel was given prophylactic intranasal iota-carrageenan and a relative risk reduction of 80%. It’s not a huge sample of people, but… well done, GPT-4.

After talking things through a bit with GPT-4, we devised the following DIY recipe for a prophylactic intranasal spray made of readily available ingredients. While I suspect GPT-4 is likely to choose sensible compounds — which all seemed backed up by at least tentative studies — I have little faith in its ability to pick good concentrations, so please: do not make this as is. If you’re excited about it (as I am!), please wait until people with actual pharmaceutical knowledge take a look.

Start with 100 ml of distilled water or saline solution (0.9% sodium chloride). If using distilled water, add 0.9 grams of non-iodized salt to create a saline solution. Stir until the salt dissolves completely.
Add 1% to 2% of an emulsifier like polysorbate 20 or polysorbate 80 to the saline solution.
In a separate container, mix the following ingredients:

- Tea tree oil: 0.1 ml (0.1% concentration)

- Menthol: 0.1 gram (0.1% concentration)

- Camphor: 0.1 gram (0.1% concentration)

- Eucalyptol: 0.1 gram (0.1% concentration)
Slowly add the oil mixture to the saline solution while stirring to ensure an even distribution of the oils in the solution.
Add the following ingredients to the mixture:

- Iota-carrageenan: 1 gram (1% concentration)

- Elderberry extract: 1 ml (1% concentration)

- Echinacea extract: 1 ml (1% concentration)

- N-acetylcysteine (NAC): 1 gram (1% concentration)

*- Zinc acetate: 0.5 gram (0.5% concentration) or another zinc compound* (see update at the top)

- Succinic acid: 1 gram (1% concentration) or another suitable acidifier

- Hydroxypropyl methylcellulose: 1 gram (1% concentration) as a thickening agent
Add a preservative like grapefruit seed extract or phenoxyethanol at a concentration of 0.5% to 1% or as the manufacturer recommends.
Mix the solution thoroughly to ensure all ingredients are evenly dispersed. You may need to shake or stir the solution occasionally to prevent the ingredients from settling.
Transfer the solution to a clean, sterile nasal spray bottle. You can purchase empty nasal spray bottles online or at a pharmacy.
Before using the nasal spray, shake the bottle to ensure the ingredients are well-mixed.

I am not a trained medical professional (I did mention that, didn’t I?), but I do know that spraying things inside your nose can be dangerous. People have contracted fatal brain amoeba infections using neti pots with unsterilized tap water. Very, very few people, but it still gives you a healthy pause. I do not think doing DIY sprays safely is beyond the reach of laypeople — pharmacies wouldn’t recklessly sell empty nasal spray bottles if that were the case — but please do not blindly trust the above.

Can we do even better? This little experiment with GPT-4 showed that many readily available compounds with antiviral activities could be tried. But can we find the best formula? And can we ensure it actually works? In the next part, we’ll explore large-scale experimentation with Gaussian processes.

Why I am joining the Tezos Foundation council

Wed, 24 Feb 2021 15:00:00 +0000

Seven years ago, I embarked on a mission to bring about a new form of money: bound by algorithmic rules, and yet capable of evolution; decentralized, and yet capable of self-governance. Tezos has always been an ambitious idea.

It has been a while since I worked on this project exclusively during my nights and weekends. Over the last four years, it has been rewarding to watch Tezos grow from an idea to a network used across the world. This outcome could not have been achieved without the dedicated commitment of countless people. Indeed, for a cryptocurrency to succeed, it must be a movement. The focus needs to be on its community, not on its founders, nor on some non-profit entity.

Alas, the Tezos Foundation did historically attract attention to itself, which subtly, but indubitably, negatively affected the culture in the ecosystem — a phenomenon which persists to this day. I think I can help change that, which is why, on February 23rd, 2021, I reluctantly accepted a nomination to join the Tezos Foundation council and set for myself a term limit of one year. This is a decision that came after much deliberation and which I did not take lightly.

Over the last year, a non-managerial executive board has replaced the model stewarded by the first two Foundation presidents. The current council of the Tezos Foundation acts as a responsible governance body for its endowment but takes no role in the day-to-day management of the Foundation. This is the model I believe in, but a model which is not yet fully understood or appreciated by the broader community, I hope to help communicate that more clearly.

I intend to champion a more humble role for this organization, one focused on empowering centers of excellence throughout the ecosystem. I believe my steadfast devotion to Tezos and my intimate understanding of the project qualifies me to take part in this transition, and I look forward to helping the council further the foundation’s mission.

Protocol-level transaction fees?

Fri, 11 Sep 2020 19:00:00 +0000

The following is a collection of thoughts around fee markets in general and mechanism to fold in transaction fees in a protocol, such as the one outlined in EIP 1559. While EIP 1559 is an Ethereum-specific proposal, the fee market in Tezos, Bitcoin, and Ethereum are essentially similar, making the ideas in this proposal broadly applicable to all three.

How a fee market works

Let’s first review how a fee market work, and clear up common misconceptions about fees. Block producers control a scarce resource: block space. Whether this space is expressed in terms of bytes, in terms of gas, or a combination thereof, the general idea is that there is some limit to how many transactions can be put in a block, and the block producer has to decide which transactions to include and which not to include.

The choice to include or not include a transaction is at the discretion of the block producer. To incentivize inclusions, transactions typically authorize the payment of a fee to the block producer. Generally speaking, the default behavior programmed in block producing software is for block producers to maximize the collected fees¹.

This default behavior is often mistakenly assumed to be part of the protocol. It isn’t. There is nothing in Bitcoin, Tezos, or Ethereum’s protocol that requires block producers to select the transactions paying the highest fees. In fact, protocols typically don’t even know what transactions a block producer sees as ascertaining this would require consensus in the first place.

There are many reasons why a block producer could choose to include transactions based on other criteria than the fee attached to it. In particular, they may accept off-band payments to include transactions. This is particularly helpful for users who seek to enter into long term agreements with block producers.

Corollaries

There are a few important corollaries that follow from properly understanding fee markets.

The cost of fees is not pegged to the value of the underlying cryptocurrency. Marginal users who choose whether to transact or not do so based on the benefit they derive from making this transaction. This might be coupled with the value of the cryptocurrency but loosely so. Just because you purchase something in some currency doesn’t mean that thing becomes cheaper or more expensive as the currency depreciates or appreciates.
The “real” fees could be higher than what is observed on-chain. If a user is paying a miner off-band to include transactions, those could appear with 0 fees but that doesn’t mean they were free.
The “real” fees could be lower than what is observed on-chain. Mechanisms that attempt to measure the cost of fees by looking at averages on the chain can be fooled by block producers including transactions with very large fees in their block as it is costless for them to do so.

Fee volatility and inelasticity

Much of the discussion around fee markets comes from the volatility of fees. When the demand for transaction surges and meets an (almost²) perfectly inelastic block space, fees surge.

Historically, “Cryptokitties” has been the canonical example of this phenomenon. A short term spike of interest for a feline phenomenon can render the chain prohibitively expensive for everyone else to use.

The solutions proposed generally involve making the block space more elastic or using a different auction mechanism which might slightly temperate surges. We argue that this approach is at best a band-aid.

Limited elasticity

First, block space is limited for security reasons, so it cannot be arbitrarily increased when demand increases. Conversely, artificially restricting block space during times of lower demand seems like it would only smooth-out the cost of fees by making them more expensive across the board. There simply is a naturally limited amount of slack for elasticity.

Specifically, block space is limited for a few reasons:

The time to download and validate a block must be smaller than the time between blocks for all validators. In fact, in the case of the Nakamoto consensus, it needs to be so small as to be negligible.
Validators who are intermittently offline or online need to be able to catch up with the chain, so the time to validate the average block must be smaller than the time between blocks.
Storing blocks takes disk space, which is why we might want to care about the average block space.

Right off the bat, we can eliminate consideration number three. It’s not that the size of disk space doesn’t matter, it’s just that constraint number 1 is a much stronger constraint. Assume 2MB blocks every 5 seconds, that would come to 1TB a month. A 1TB hard drive comes to less than $30. This doesn’t need to be fast storage either, as the blocks are stored for archival purposes only and are only ever accessed by new peers requesting the chain’s history. The storage cost for old blocks is largely dominated by the cost of the Internet connection or the cost of computing.

Consideration number one places a tight constraint on the maximum block space, so any elasticity we might find would come reducing the block space below this maximum.

This only makes sense if consideration number 2 places a meaningful constraint on block space. If for some reason, we want the average block space to be lower than the worst-case block space, then there is elasticity to be found. If not, the elasticity merely boils down to artificially restricting supply when demand is low.

Does the average block validation time matter?

There are arguments on both sides of that issue.

It must indeed be much faster to synchronize with the chain than it is to merely follow the chain in real-time. Otherwise, validators who periodically go offline would need to wait a very long time before being caught up. If validation time takes, say, 95% of the block time, it would take 20 hours to synchronize with the chain after being offline for only an hour.

A counter-argument is that synchronization can be done in parallel. A node syncing with the chain can download a snapshot of the state of the ledger at present, and a snapshot at the midway point when they were offline, and validate, in parallel, that the chain correctly links the last known state to the midway point, and the midway point to the current state.

The counter-counter-argument is that doing so is somewhat impractical. It involves large fixed costs in downloading the state of the ledger, it likely requires multiple hard drives for the IO to be properly parallelized, etc.

A better argument in favor of limiting the average block validation time below the maximum block validation time is safety. Validation time is estimated based on a gas model but it is only an approximation of the real validation time on a real machine. The consequences of the average validation time exceeding the block time can be extremely serious and split the chain or prevent it from advancing. However, the consequences of some blocks occasionally exceeding the maximum validation time are quite mild. At worst some block producers might miss their chance to create a block.

The existence of a safety margin for the average block validation time which can be set lower than the maximum block validation time opens the room for at least some elasticity.³

Block producer extractable value

Blockchains, and particularly smart-contract platforms, sometimes leave money on the table for block producers to grab. This could be a mistake “anyone can spend” output in Bitcoin, this could be an auction about to expire on Tezos, etc. If or when that happens, fiddling with the amount of block space or the kind of auction involved in the fee market will have little impact on the block content.

Long term service agreements: the correct solution

There is a natural solution to the problem and it doesn’t involve modifying the fee market at all. As we mentioned earlier, users can enter into long term service agreements with block producers. In a proof-of-stake network, the owner of a stake controls a predictable source of block space. The output of a miner in a proof-of-work network is more difficult to predict due to difficulty adjustments but it is still somewhat predictable.

Users who need the guarantee that they can regularly include their transactions at a reasonable price and block producers both benefit from entering into long term service agreements where they are guaranteed a certain number of transactions per month with some maximum latency.

Under this model, bouts of craze for the latest fad do not affect normal users of the chain. Normal users will pay the contractually agreed upon transaction rate, and the very high transaction fees will essentially only affect those jumping on the fad bandwagon.

This is a financial solution to a fundamentally financial problem. Demand and supply of block space are commodities, they can be hedged, traded, and packaged in a way that shifts the risk.

Those who would insist on being independent on any kind of off-chain agreement still have the option of paying the fee market’s spot price or, even better, to run nodes and become block producers themselves.

Protocol-level fees?

Having given a quick lay of the land, let’s look at what EIP-1559 does. When we look at full blocks, we see that, although there are variations in each block, there is an underlying, slowly moving, and persistent fee being paid per gas unit consumed. The fact that we may be able to observe that is purely a consequence of the relative lack of popularity of off-band payment for miners. By and large, transaction fees are paid using the default method, and block producers select transactions the default way. That doesn’t mean we can trust those numbers for anything where security is critical, but they are good enough to give us some idea of what’s going on.

The idea of EIP-1599 is to take out this baseline amount of fee and turn it into a burn. We cannot do that by looking at the fees paid, because this number is not reliable, but we can do it by searching for an equilibrium.

One way to do this is to let block producers choose the block space (within some bounds). As long as it is above average, the burn required per unit of gas consumed keeps increasing. As long as the block space is below average, the burn require keeps decreasing. This control mechanism ensures that the burn is set at the level where the amount of transactions being submitted matches the available block space. Users can still attach a transaction fee (now dubbed “tip”) to their transactions to incentivize inclusion.

Benefits & drawbacks

There are several benefits to this approach, but also some drawbacks.

Deflationary

The first benefit is that this codifies the use of the cryptocurrency in the fees and makes fee payment deflationary. This can matter for proof-of-work networks where the fees would otherwise be spent on hash power. This might seem equivalent to simply reducing the block subsidy, but relying more on fees to secure blocks changes the dynamic as shown in Carlsten et al (2016)⁴.

For proof-of-stake networks, this benefit is somewhat moot as transaction fees naturally accrue to stakeholders anyway, regardless of the way they are being paid. So the benefit that this brings to proof-of-work networks is already present in proof-of-stake networks. However, in some jurisdictions, it could conceivably be more tax-efficient to burn the fees.

Elastic

A second benefit is that this brings some elasticity to the block space. Depending on how steeply the required burn increases with blocks that go beyond the target average size, this can somewhat alleviate congestion. We are however quite skeptical that moderate increases of the block space in short bursts would do much to reduce congestion.

Better UX

A third benefit is in terms of UX. Currently, wallets must evaluate fees by looking at the fees paid over past blocks. However, we know these numbers do not necessarily reflect the reality of the fee market. If the burn cost is built in the protocol, it becomes much easier for wallets to evaluate how much should be paid for inclusion. Users only need to worry about estimating fees when the congestion is so high that the burn cost doesn’t rise fast enough to balance the market.

Meaningful, in protocol, metric

A fourth benefit is that the fees paid to include transactions now become a meaningful number that can be used within the protocol or smart-contracts. This is not the case when fees can be manipulated completely by block producers. Reliable numbers could be used to grant governance rights over smart-contracts to those who use them the most for instance, or it could be used to grant discounts to access contracts that have consumed a lot of gas over their lifetime, etc.

Drawback: potential for oscillations

We might wonder whether we could dispense with the elastic block space altogether and still get the benefit of estimating the appropriate burn cost. This would generally suggest trying to tie very moderate changes in the block space to a very steep rate of increase for burn costs. However, doing so is almost guaranteed to produce see-saw behavior where the cost oscillates wildly. A slow rate of increase would simply lead to the “tips” added to transactions becoming the de facto fee market.

There is a trilemma between inelasticity, stability, and not having tips become a de facto fee market. You can only have two, but it’s not clear just how much elasticity you need to foster stable burn costs that don’t oscillate all over the map and transaction tips that remain marginal.

Drawback: complicates long term service agreements

The main drawback is that it no longer becomes possible to hedge transaction costs by holding a stake, guaranteeing access to a given rate of block space. This means block producers can no longer easily enter into service agreements with users to guarantee them a certain amount of transactions.

There are two possible workarounds:

Shift the burn cost risk to some third party through insurance.
Allow users to prepay for transactions on-chain.

The first approach is straightforward if a bit heavy. A long term service agreement would now involve a user and an insurer who must take on the risk of paying the burn cost. This is not as ideal of a situation as a traditional fee market where the block producer’s risk and the consumer’s risk perfectly offset each other, there is now a cost to insure the risk.

The second approach requires quite a bit more on-chain machinery. It would work like this: for all blocks, a given capacity is reserved, tokenized, and auctioned off a few months before the blocks are created. Those who intend to include transactions in the future can buy those tokenized transaction rights now and use them instead of paying a burn cost when the time comes. However, they would still need to enter into a long term service agreement with a block producer to ensure that they can indeed exercise their right.

Conclusion

There are interesting benefits in moving transaction fees at the protocol level, in particular in terms of UX. However, doing so can jeopardize the most natural and efficient way for regular users to access block space: through long term service agreements. Indeed, these agreements do not seem common today. The benefits of protocol-level fee assessment depend on whether there are fundamental reasons for this, or if this is because the market is still immature.

Solving a knapsack problem ↩
Nitpick: we say “almost” because, technically speaking, in a proof-of-work network, higher fees could lead to more hash power coming online and lowering block time in the short term, until the difficulty adjusts. This is a nitpick, it’s a small effect, your takeaway should be that I want to be precise, not that proof-of-work has great built-in elasticity. ↩
I defended on Twitter the more radical view that only maximum validation time matters, but thoughtful comments from Dankrad Feist led me to reconsider my position. ↩
On the instability of Bitcoin without block reward. (Carlsten et al. 2016) ↩