Forthcoming mainnet upgrades suggest a future of incentivized data preservation and a shared responsibility to encode the past

Ethereum’s core devs are already approaching another major upgrade to mainnet. This upgrade will center on Ethereum Improvement Proposal #4844 (EIP-4844). They’ve designated a new portmanteau, “Dencun,” to refer to this upgrade (combining “Deneb” and “Cancun,” for updates to the consensus and execution layers, respectively).

EIP-4844 may bring down transaction costs on mainnet, but its focus is on reducing fees for Ethereum’s second layers (see my post here about L2s). To accomplish this, this EIP's approach is all about data. The EIP will improve the way in which L2s encode data on mainnet. L2s currently devote much of their fees to writing to Ethereum mainnet for validating their ledgers (using transaction calldata). This also increases fees on mainnet. You can see this on Etherscan’s “gas guzzler” list here. 5%–10% of mainnet fees are often related to L2s, such as zkSync and Arbitrum.

EIP-4844 is therefore significant. In this upgrade, users of Ethereum (such as L2s) will be able to encode so-called blobs of data. As part of a new transaction type, these blobs will be cheaper because the data will only persist for 30 days. There will be a second fee market on mainnet for the cost of committing blobs on the Beacon chain (the consensus layer). Blob fees will have a dynamic similar to how EIP-1559 governs supply and demand (see here for a great summary). All this complexity (including fascinating details about the blob data itself) are by design; they are meant to bring Ethereum closer to future scaling upgrades. And L2s can use these cheaper blobs to validate their ledgers.

https://twitter.com/VitalikButerin/status/1489768250619559941

But EIP-4844 introduces for the first time a big idea in Ethereum’s future updates: transient data.¹ This upgrade got me thinking about its implications. Other planned protocol changes also have this property of temporary data on chain. A bird’s-eye view over the planned upgrades reveals that data is an important part of Ethereum’s future. Or, put differently, the absence of data is an important part of that future.

Let’s consider some other examples. I’ll focus on NFTs to illustrate what data temporariness means for the future. Despite concerns with transience, this series of upgrades represents a growing data economy for Ethereum.

Pruning Historical Data: EIP-4444

I’m especially curious about implications for applications that make use of on-chain data. In particular, there is a growing landscape of NFTs that use on-chain data storage. On-chain NFTs store their data on chain because the asset (artwork, PFP, etc.) is purportedly forever — you can always retrieve it on chain.

But these upgrades and the temporariness of chain data raise important questions. There are legitimate concerns about how the data will be stored and made available.

Consider another major improvement proposal: EIP-4444. This EIP may be implemented in the coming year or two. The idea of this proposal is pretty simple: Ethereum nodes will no longer be required to hold onto historical records of transactions beyond one year. This will include block headers, calldata, and so on. This can impact applications that make use of historical data, such as market analysis or economic research. It can also impact some NFT projects. For example, some prominent NFT projects store their code or data in calldata. You can see this on Etherscan too. Here’s the C code to generate one of 0xDEAFBEEF’s archetypal projects, Synth Poems*. *It is in the calldata used for this transaction (its hash is recoverable from contract functions here):

This code would be needed to rebuild the hypnotizing audiovisual experiences of 0xDEAFBEEF’s pieces. EIP-4444 would prompt nodes to delete this calldata because it is from over 2 years ago. (And that means that even if you spun up a node yourself in the future, you’d not have access to this data.)

An important distinction here is between memory and storage. Because 0xDEAFBEEF’s code is in calldata, it is at risk in the EIP-4444 upgrade — it is not accessible in the EVM, and calldata is only in memory in the moment of the transaction. So calldata is a historical transaction record, accessible to a full node that syncs the chain (but not in the EVM itself). EIP-4444 would mean this is pruned after a year.

By contrast, projects that use storage preserve data in their contract, accessible to the EVM. On-chain NFTs store data inside contract storage itself. These are part of Ethereum’s state, and so aren’t at risk by EIP-4444. This storage pattern is exemplified by Avastars and CyberBrokers. These NFT projects have a beautiful and complexly layered set of functions to assemble SVG artwork. These functions use contract storage (see my blog post here for detail). You can see the beautiful layers encoded on Avastars years ago by calling its contract storage on Etherscan.

Other planned upgrades imply that contract storage is not entirely safe either. It may succumb to a later upgrade of Ethereum that involves state expiry.

Purge of the State

At this point, you may ask why the absence of data is so important to Ethereum’s future. A compelling case is made in a Bankless episode with Vitalik. The interview is somewhat dated, but the content has aged extremely well, and remains a crystal clear discussion of many roadmap features.

At about 40:00 in this interview, Vitalik summarizes the challenges that data will pose for those who wish to participate in Ethereum’s security — such as by running a node. When Ethereum scales, it would produce petabytes of data per year under the current data model. This is far too prohibitive for most participants because they would be expected to completely sync up with this growing blockchain data.

The concern about data also applies to the very state of the Ethereum blockchain itself — to storage, mentioned earlier. The possibility of state expiry is also encouraged by the fact that historical data has a simpler trust model (the past is “easier to prove”). So why not prune the state itself?

This EIP proposes just this (it is currently an early “proto-EIP,” which you can read here). After a period of time, nodes could prune states too. The effects of this are non-trivial. For example, such states store balances for all ERC-20 contracts. And this would impact all NFT projects. The state also stores URI pointers to every NFT asset, and for on-chain NFTs it is arguably worse: All the metadata and the piece itself are evanescent under state expiry. (That means that, after state expiry, if you spun up a node, states of your projects beyond particular time points may not even be accessible either.)

The New Data Economy

The blobs of EIP-4844 are temporary. This bridge between L1 mainnet and L2s lasts for about a month, after which validators on the Beacon chain need not hold onto them. Where will blobs go? Will they be needed, in audits or analysis? In EIP-4444, historical data is pruned after a year, and state expiry will involve some similar timeline for state pruning. A future of “temporary data.”

To observers, this may seem concerning, especially if you’re into projects that make great use of historical data or contract storage (which is, arguably, everything; perhaps most starkly with on-chain NFTs).

But this transient data approach is a necessary one. The chain is getting too heavy. It is the “deadweight of history,” as Vitalik has described it. But this presents new challenges of data preservation, recovery, analysis and so on. And challenges present opportunities. With EIP-4844, we get a new fee market baked into the blob transaction type. EIP-4444 and state expiry present new opportunities for other markets, too. Here are a few ideas.

Centralized services

The obvious choice for maintaining both historical data and state data is centralized services. Vitalik mentions Etherscan and other approaches in his interview, too (including Beaconscan). There is incentive to maintain these data sources because they are monetized as a service. This will become more important for Ethereum beyond the so-called “Purge,” with EIP-4444 and state expiry. Tools like Etherscan are already routinely mentioned as critical infrastructure. In the future era of transient data, their importance will grow.

Incentivizing distributed data preservation

Another approach to storing historical and state data is to create a distributed system (akin to IPFS) that is built on top of Ethereum. The Portal Network is aiming to create a peer-to-peer system that permits light clients that distribute the data load so that history is still accessible in a similar way to current APIs. The Graph is a prominent data infrastructure that many are hoping will approximate a fully decentralized preservation system that can be incentivized by participation in governance and paid data usage.

State maintenance services

These next two present more interesting possibilities and pertain to state expiry. In state expiry, it is possible to keep a storage slot active on your contract in order to maintain its presence in the chain. One could imagine new contract functionalities that routinely “ping” another contract in order to maintain certain states. A customer could register with a state-maintenance server which uses an emerging standard to “ping” all contracts created by a given wallet. For a small fee, this could be “loaded” with a subscription that lasts decades into the future (akin to ENS registry). It could also be decentralized too, using a system of contracts, and customers could routinely check to ensure the system is working. If it is not, they could seek another service or setup a scheduled system themselves to call a “maintenance” contract.

State maintenance monetizes the “state tree” more fully. Some may be concerned that it’s an additional fee for users, like the lamentable “Apple peripherals” that can proliferate into higher distributed cost. But the argument against this is that data preservation is expensive, especially if it is in some tension with securing the blockchain. For this reason, data maintenance services let users pay for the privilege of such data preservation, and let validators and other participants focus on consensus and security.

State recovery services

In that Bankless discussion with Vitalik, he emphasized that history is unlikely to be lost. With the services described above, we could expect multiple more or less centralized tools for robustness to preserve historical and state data. But even without these tools, assuming you have information about the storage in your contracts, you can still recover them. State recovery could be a service too. It could provide point-and-click tools and some standards and practices for preserving history of importance to you. You can then bring that personally held data to a service, upload it and establish a proof that recovers these states.

In a summary of this state expiry, Vitalik shares a wonderful thought experiment of Alice whose work with a smart contract is one of her passions (see “Epoch 13” section). She travels and has some other events in her life that keep her from the contract for some time. Its storage is pruned from the tree. Vitalik describes how she hunts for witnesses with sufficient information to facilitate recovery of her beloved contract.

Conclusion

Ethereum has to accommodate security and efficiency of its consensus mechanism amidst what we hope to be mass scale increase in future use. This goal is in tension with the wonderful yet plentiful data that blockchain creates. Forthcoming upgrades will bring a new era of “temporary data,” but it will also introduce new and interesting economic possibilities for the maintenance, recovery and curation of blockchain data.

Here’s the rendering code for the Art Blocks project Symbol 1 by Emily Weil. A beautiful quinean project; the code is the work. That code sits in storage. But in the coming years, it may not. The future data economy may help to preserve and recover it.

Endnotes

1. Dencun will also likely include EIP-1153, which proposes new transient storage opcodes which have very interesting computational implications — another transient data ingredient.

Further Materials

1. Anthony Sassano just discussed EIP-4844 again on a Daily Gwei, including an update to devnet.

2. Recently updated article on statelessness on ethereum.org.

3. Great recent summary of EIP-4844 by Christine Kim @ Galaxy, including interesting detail about the life of a blob.

About

I am on Twitter. I spend a lot of my time on creative data visualization projects, including several fully on-chain works like the_coin, one of the first NFT projects that lets owners update contract storage to modify the NFTs (hence an interest in state expiry).

Disclosures: I own and create NFTs and sometimes hold the projects that I mention. For example, I own some Avastars. I love them. I was not paid for this post. I wrote it for fun. I hope it was interesting.

For a brief period during May 11th & 12th, transactions on Ethereum were not finalizing. More than 60% of validators went offline, and transactions were not finalized despite being successful. The offline validators had to come back online quickly to avoid being caught in an inactivity leak.

Fortunately, Ethereum is designed to handle these situations and eventually recover without intervention. If you’re not familiar with what we’re referring to, don’t worry, we’ll discuss the intricacies of Ethereum’s finality, the implications of the inactivity leak, and delve into the liveness and safety debate for Ethereum in this article.

Understanding Transaction Finality

The inactivity leak on the Ethereum mainnet was a first-time occurrence. To fully understand it, we need to grasp the concept of transaction finality on Ethereum. In Ethereum’s Proof-of-Stake (PoS) model, transaction finality is achieved through a process similar to a democratic election. Once transactions are finalized, they are permanently recorded on the blockchain and cannot be changed. Validators review and approve each block, casting their votes to determine finality and immutability. A block achieves finality when it gathers over two-thirds of the total validator pool’s votes.

It’s important to note that anyone who wants to validate transactions on Ethereum must stake 32 Ether, and if they act dishonestly, their stake can be slashed, and they can eventually be ejected from the validator pool when their balance drops to 16 ETH. If you want to learn more, you can refer to our short thread on finality a few days before the incident.

https://twitter.com/etherscan/status/1656296375041269761

But let’s take a step back and understand the term finality and what it means. In settlement systems outside of Ethereum, finality refers to the moment when an obligation or asset transfer becomes unconditional and irrevocable. This ensures that all involved parties have fulfilled their obligations, even in cases of insolvency or bankruptcy, as outlined in international standards and domestic laws governing financial market infrastructures.

In other words, once an entity or person makes a payment to a counterparty, the transaction should not be reversible. This is particularly crucial for large-value payment systems that settle significant amounts of money daily. Transactions must be irreversible; otherwise, businesses wouldn’t be able to move forward.

Before The Merge, Ethereum ran on a Proof-of-Work consensus mechanism similar to Bitcoin, providing probabilistic finality. There was an economic guarantee that as more blocks were added to the canonical chain, it would become increasingly expensive for attackers to reorganize the blocks. However, the move to the PoS model using the Casper protocol for finality aimed to provide stronger guarantees than PoW.

Non-finalization Event Breakdown

The non-finalization event occurred twice on May 11th & 12th, lasting for 3 and 8 epochs, respectively. On May 11th (Thursday), during epoch 200551, network participation dropped to 40%. Missed slots increased to 18 out of 32, a significant deviation from the typical range of 1 or 2, causing blocks to not finalize. Each block carries attestations, and the reduced number of blocks leads to fewer attestations available for finalization.

On May 12th (Friday), the non-finalization event occurred between 17:20:23 to 18:24:23 UTC. Transaction times were over a minute slower compared to the usual average block time of 12 seconds. Interestingly, despite the reduced block space, gas fees did not exceed the highest daily average. Users transacting on Ethereum during the incident likely wouldn’t have noticed anything significantly wrong.

The fact that more than 60% of blocks were missing indicated that more than one consensus client were experiencing issues. The cofounders from Prysmatic Labs noted that the incident was due to unexpected behavior that client teams Prysm and Teku didn’t handle well. These clients were receiving old attestations, causing Prysm to replay a large number of states to verify the chain’s validity. The clients were overwhelmed with these computations, leaving them with limited bandwidth to respond to block production and attestation.

Additionally, the increased number of validators post-Shapella and maximum deposits from the activation queue caused increased hashing and latency, leading to a rapid decline in network performance. It’s worth mentioning that there are currently over 590,000 validators on the mainnet (at time of writing), compared to the testnet with only 400,000 validators during client team testing.

Since the Shapella upgrade allowed withdrawals, there have been many more deposits to the mainnet. Initially, partial and full withdrawals outweighed deposits, but within a few weeks, the trend reversed due to increased validator rewards and lower staking risk. If someone wants to join Ethereum as a validator now, they would have to wait in a queue for more than 30 days, as only nine validators are currently allowed to join the network per epoch, totaling 2,025 per day.

The Inactivity Leak Takes Effect

So, what actually happened during this incident? In the first non-finalization event, the network was able to recover without any penalties. However, the second occurrence lasted for a full hour, triggering the inactivity leak. When a network partition occurs, and validators cannot communicate with each other, one side will start leaking balance at an exponential rate.

This causes the offline validators to have a diminished stake, while the online validators slowly gain a larger percentage of stake and gain control over the network to achieve over two-thirds of attesting validators needed for transaction finalization. For offline validators, after approximately 3 weeks, they will lose 16 ETH and be ejected from the validating pool.

The inactivity leak resulted in the burning of 28 ETH, which amounts to less than 0.0006 ETH per offline validator or 0.002% of a validator’s 32 ETH deposit. During this time, approximately 50 ETH in revenue was lost due to missing attestations. Regular Ethereum transactions, such as Dex swaps, NFT minting, and yield farming, continued to be executed on the mainnet, meaning end users likely didn’t notice anything out of the ordinary. This showcases Ethereum’s immutability.

Even in highly challenging situations, such as a large-scale crisis or emergency, as long as validators worldwide have internet access, they can help keep Ethereum running. This is all part of the liveness vs. safety debate, which we’ll discuss further.

Reasons Ethereum Kept Running

It’s important to note that while Prysm and Teku clients went down during both non-finalization incidents, Lighthouse clients remained operational, processing transactions on Ethereum as usual. The affected client teams quickly released hot fixes inspired by how Lighthouse handled the situation effectively. Each consensus client has different implementations. The diverse range of clients played a crucial role in keeping Ethereum running, even when more than 60% of clients were offline.

Compare this to two years ago, when Prysm nodes made up approximately 65% of the network. If Prysm nodes had gone offline along with other nodes, we would have faced a more significant problem, rendering Ethereum almost unusable. Today, Ethereum is not a monolithic system but a composition of diverse and distributed components. Thanks to the open-source ethos, anyone can create their own consensus node to validate Ethereum, further increasing client diversity and resilience.

Another factor that contributed to keeping Ethereum running during the non-finalization events was the LMD-GHOST protocol. LMD-GHOST ensures liveness by providing a fork-choice rule that helps maintain the continuity of the blockchain. Validators are able to choose which blocks to support and build upon, even if some validators are inactive or not participating.

This means that as long as there are active validators, the blockchain can continue to grow, and new blocks can be added to it. LMD-GHOST achieves this by using the weights of subtrees created by forks as a heuristic and assuming that the subtree with the heaviest weight is the “correct” one. This ensures that validators will always end up at a leaf block, which defines a canonical chain.

Liveness vs Safety Tradeoffs

The challenge of achieving both liveness and safety in open-source distributed ledger networks like Ethereum stems from the CAP theorem, which states that it is impossible for a distributed system to guarantee consistency, availability, and partition tolerance simultaneously. In the event that validator nodes are unable to communicate with each other, they must prioritize either consistency or availability.

For a general-purpose blockchain like Ethereum, it is important to prioritize liveness. If Ethereum were to prioritize safety over liveness, in the event of a network partition, the network would halt and no transactions would be able to go through. LMD-GHOST provides some measure of ‘safety’ in this scenario while the network is unable to achieve full safety or finality. However, applications built on top of Ethereum as a base layer can prioritize safety as needed. For example, during the non-finalization event, dYdX paused deposits to ensure the safety of its users’ transactions.

But what would happen if the inactivity leak persisted indefinitely? Applications that relies on Ethereum’s finality would be affected, such as optimistic rollups with a 7-day fraud proof window, as their finality is tied to Ethereum’s finality. An optimistic outcome would be for the inactivity leak to eventually recover Ethereum’s finality, and any offline validators coming online could resume attesting to the latest block they perceive as the canonical chain.

In the case of forks on Ethereum, the community can apply common sense to determine which fork represents the result of the originally agreed-upon transactions, although it should only be considered as a nuclear option.

Closing Thoughts

The recent non-finalization events on Ethereum serve as a stark reminder of the complex challenges inherent in maintaining an open blockchain network. Ethereum is not a finished product but an ever-evolving network undergoing constant heavy research and development.

These incidents have demonstrated that Ethereum’s inactivity leak mechanism functions as intended, and no catastrophic events occurred that could have had a significant impact on the network’s operation. Weaknesses in client implementations were also identified and addressed. It currently takes an average of 2.5 epochs for transactions to finalize, but future developments such as single-slot finality, which allows for finalization within the same slot a proposal is made, will be interesting to watch.

The Beacon chain, the backbone of Ethereum’s move to proof of stake, went live in late 2020. Interested participants could deposit ETH into the Eth2 deposit contract, enabling them to participate as validators in the Beacon chain, which fused with mainnet in the celebrated Merge in late 2022.

A few weeks ago, the newest hard fork was activated: The Shapella upgrade now allows validators to withdraw their ETH back into regular mainnet circulation. Full withdrawals — through which validators exit Beacon — are significantly rate-limited. Partial withdrawals (such as staking rewards) are also limited but have higher bandwidth: 16 per block. At the time of writing, there have been over 2,500,000 withdrawals from Beacon, amounting to over 2,000,000 in ETH.

Since Shapella, there have also been plenty of fresh depositors. Last month saw the highest concentration of Beacon deposits so far. So even with millions of withdrawals, staking on Ethereum is an order of magnitude larger than current or pending withdrawals, at least for now (see a helpful survey of this in the Coin Metrics State of the Network #203).

From Etherscan’s deposits dashboard

It was widely discussed that initial deposits into Beacon were highly concentrated, including after The Merge (see prior post here). A few parties or pools control the vast majority of the deposited ETH, raising concerns that the network is insufficiently decentralized. Only a few parties could control the majority of block production.

We can measure this concentration with the Gini coefficient. It is a measurement of how unequally distributed a good is. A Gini of 0 means that there is no concentration, indicating equal distribution. A Gini of 1 means that a single entity has all the resources in a given distribution. We can show this by plotting the rank of depositors by their relative dominance in a cumulative distribution (from 0% to 100%, adding them up).

As you can see below, this is not a flat distribution. It shows that the first 500 depositors (in either regular or internal transactions) are responsible for over 80% Beacon inputs.

This distribution of depositors has a Gini coefficient greater than 0.85. This concentration is due in part to staking services such as Lido and Coinbase. An important note by Kyle Waters of Coin Metrics and others is that these staking services involve many participants who, in theory, represent a more decentralized potential as there are many hundreds or thousands of these depositors. So the debate is nuanced (including debate about metrics like the Gini), and also involves other aspects of the proof of stake consensus framework.

How about withdrawals? Have they been concentrated?

It appears they have been intensely concentrated, perhaps more so, with a Gini coefficient of about 0.98. This is likely due in part to the exit of Kraken, as just one of the withdrawing wallets, responsible for over 600,000 ETH, flows directly into a Kraken address. But it could also be due to the relative rewards accrued by these entities. Smaller validators may have to wait longer to justify withdrawal; larger validators may exit with a very regular stream of withdrawals as they receive more rewards. Indeed, wallet 0xB9D79 shows frequent, daily withdrawals. It has received withdrawals from Beacon over 1,000,000 times alone with an average of about 0.25 ETH. It seems to belong to Lido.

- Lido withdrawal manager

Concentration like this is very common across many networks, both in the digital world and in physical and biological systems. The tendency for resources to become concentrated has been argued to be an inevitable fact of reality — the vagaries of uneven distribution, preferential attachment, thermodynamics and more (hypotheses vary). Readers may recognize this as the famous “80/20” principle — 20% of the entities control 80% of the resources, work, etc. It’s a rough heuristic, a rule of thumb. But it expresses this concentration in a familiar way (though in the cases above, it is closer to “95/5”).

For Ethereum, this has been long under discussion. Vitalik addressed this concentration years ago, shortly after Beacon went live. He argued that focusing too much on the Gini coefficient and related measures of unequal distribution may oversimplify our understanding of important underlying relationships in a social or economic system. Such relationships may better express the nature of such “inequality,” its origins, architectural implications and risks. This seems reasonable, but one could argue that (i) other possible measures of underlying relationships may still yield strong indications of concentration and (ii) there’s simply obvious concentration at a glance. In any case, Ethereum is not the sole project subject to such discussion. Many, perhaps most, are. Even Bitcoiners debate mining concentration, too.

-Bitcoin pool ranking; https://mempool.space/graphs/mining/pools

In the design of protocols that decentralize responsibility, to ensure robustness to attack or manipulation, it is an uphill battle if this distribution is indeed an inevitability of nature’s principles. But we can try to vary the slope of this concentration to make sure that it doesn’t become too skewed.

There are movements afoot to promote this in Ethereum, such as facilitating a broader base of participants in block validation and block building. For example, Flashbots, despite fears of its dominance, has nobly taken on the challenge to open-source its tools and expand participation. Alongside these advances on Ethereum, developments such as EigenLayer allow depositors to restake their ETH into other services, such as to help secure an emerging project or protocol. This expands the potential utility of staked ETH, and could alter incentives around deposits and withdrawals in the future.

I wrote this for fun for Etherscan. I was not paid by anyone. I own various cryptocurrency things, sometimes ones that I mention in my writing. You can follow me on Twitter here.

A few weeks ago, three crypto-serving banks faced major liquidity crises amidst a bank run. These banks were shuttered, and some rather scandalous hypotheses swirl around these events. Something else interesting happened on chain, too: This fiasco impacted the peg of both USDC and DAI. Because USDC was significantly banked at the now-defunct Silicon Valley Bank, and DAI collateralized substantially with USDC, both experienced their own little “run.” As Coin Metrics reports in a great survey of this run that happened around March 11th, 2023, users seemed to move their USDC and DAI into USDT and BUSD. (They may have perceived them as safer given the potential impact on USDC’s Circle, or have been seeking arbitrage, etc.)

Figure from Coin Metrics State of the Network #198

As you can see in the plot from Coin Metrics, this was a temporary effect. Unlike other notorious “stable”coins of recent history, both USDC and DAI returned to peg after a couple of days.

The term “run” conjures a mental image of individual customers rushing to the bank to withdraw their cash. The term implies a singular desire to escape a particular asset or custodial situation. While this simple description captures an underlying motivation, it is actually enacted in many different ways. A “run” manifests in ways that can be complex: The simple desire among holders actually yields distinctive patterns of decisions and actions.

Indeed, with Etherscan data and USDC alone, you can see this complexity on chain. In this brief post, I summarize some underlying on-chain patterns between March 9th and March 12th. The message here is simple: The visualization and analysis suggests runs have complex on-chain dynamics. They involve a mix of on-chain activity, shifts in value-sent distributions, and more.

Below I illustrate this in two ways. (1) First with direct transfers of USDC across various wallets. And second, (2) with individual token swaps between USDC and other assets.

(1) Direct USDC Sends

To explore patterns underneath this run, I extracted transaction data from Etherscan, starting with direct ERC-20 transfers of USDC. These were transactions that included only a single transfer event. Between March 9th and March 12th, I extracted about 200,000 of these.

I built a “stackplot” of these 200,000 transactions. To understand what a stackplot is, consider this key I shared in an introductory article to this visualization:

When we do this for all addresses across the 200,000 transactions, you get the following full stackplot:

Here, each “stacked” row is an address, each column (line) is a transfer. As addresses enter the data, and transact on USDC’s contract, rows rise in number quickly between 3/9 and 3/12. You can see a “glow” in the middle of the stackplot, indicating a collective, momentary “run,” USDC being sent across wallets. I highlighted some exchange addresses (Binance 14, Coinbase 10) with color. There seems to be a rise in exchange wallet activity visible even in this granular visualization.

You can also see very large transactions. The largest, in the top right quadrant (in white) is a $500,000,000 transaction between two Binance wallets. As Coin Metrics reported, many larger transactions took place during this time, and there were unusually more $1,000,000 or greater USDC transfers. This distribution seems visible in the stackplot above, with higher and large density along the steep “sigmoid” rise of the wallet rows and their transfers.

We can examine how these transactions cluster in blocks. On the x-axis we plot time (in block height) and y-axis the number of unique USDC senders and receivers within that block. By plotting each block this way, we can examine this local distribution of on-chain activity. Departures from this distribution represent an important pattern: They could be exchange consolidations taking place in one or a few blocks at a given time.

Near the end of this date interval, curiously, HitBTC seems to show some consolidation in wallets that were once funded by their deposit wallet. Bittrex sends a large number of USDC transactions to separate wallets far exceeding the statistical trend among unique receivers.

We can visualize these trends with network diagrams, illustrated below. Lines are ERC-20 transfers and dots are wallets. USDC flows into a wallet that seems to be associated with HitBTC here. Over a range of about 40 blocks,* *just 8 minutes, there are hundreds of these consolidations (as suggested to me by someone: this could also be recovery of sybil wallets).

Direct USDC transfers from blocks 16815288 to 16815328; 0xbfcd8 = HitBTC affiliated?

(2) USDC Swaps

Let’s consider transactions that involve two ERC-20 transfers, one of which is USDC. These usually involve a swap (from or to USDC). In that date range, I extracted about 80,000 of these (amounting to 160,000 transfers, two per transaction). Interestingly, the distribution of senders and receivers by block seems more orderly in DEX swaps, which may indicate a more collective phenomenon of individual wallets transacting to move USDC around.

However you can detect significant shifts in the distribution of USDC swaps. As Coin Metrics also reported, users seemed to swap into USDT or (W)ETH, and below you can see the rapid rise of USDT swaps near the run.

One way to summarize the swap patterns is to calculate an entropy score over the distribution of unique tokens in 100-block windows. Entropy is generally interpreted as “disorder,” but here higher entropy reflects a more complex mix of tokens in a period of time. Conversely, if entropy drops, it means that DEX “behavior” with USDC is getting simpler, focusing on a smaller number of tokens. Indeed entropy drops by about 25% or more at the start of the run. To put it in very playful terms: Runs alter the thermodynamic structure of block space.

Finally, USDT and WETH showed different patterns too. On March 11th, the distribution of swaps involving these tokens were distinct, with USDT having the higher average swap value, but WETH having a handful of extremely large swaps (owing to an MEV bot).

Summary

I focused on USDC, and peeled back hundreds of thousands of transactions to take a quick glimpse into the composition of a run.

The view of a “run” as being a collective clamor among individual wallets is partly right. There seems to be lots of that.

But there is also significant and easily identifiable heterogeneity of activity: (i) individual users send into exchanges, (ii) whales become more active, (iii) blocks exhibit statistical trends of coordinated consolidation, (iv) CEX and DEX behavior are distinct, and (v) swap distributions shift. In a helpful thread about these events, Delphi Digital referred to this as an “on-chain frenzy.” It had impacts on issuance too: Kyle Waters of Coin Metrics reported thousands of burnt ETH around this time, taking the cumulative burn to over 3 million ETH since The Merge!

This post dipped a bit more into this underlying complexity to share some other on-chain details. Understanding these details may be helpful for responding to future runs of this sort.

…

I’m a creator and writer and such and you can follow me on Twitter. I was not paid for this post. I sometimes own the assets I mention.

Contract verification allows smart contract developers to prove and publish the source code of the contracts deployed on-chain.

As your smart contracts for your NFT marketplace or governance token grows in size, so would the number of parameters and files you have to include in your verification process.

Plugins help automate this as much as possible; detecting compiler settings, metadata, libraries, and imported files to be submitted to Etherscan. They’re usually also baked-in to IDEs and developer tooling that you’re already using.

Here are 4 plugins built by the community that makes contract verification feel like writing “Hello World”!

1. Hardhat Verify

Uses Solidity Json Input format ✅ Custom constructor arguments ✅ Custom library address inputs ✅ Built-in support for most networks plus custom explorer option ✅

Hardhat is running as one of the most popular Ethereum development environments out there, with features such as compilers, node simulation, tests, and much more.

Once you’ve deployed your contract, simply install the Hardhat Etherscan plugin via npm and run npx hardhat verify to automatically submit contracts to Etherscan and any similar “scan” explorers your project is supported on.

Hardhat also has a tasks feature, which you can automate and repeat this verification process as needed across multiple chains.

https://hardhat.org/hardhat-runner/plugins/nomiclabs-hardhat-etherscan

2. Foundry

Uses Solidity Json Input or Single File format ✅ Custom constructor arguments ✅ Custom library address inputs ❌ Built-in support for most networks plus custom explorer option ✅

Foundry is a rising development toolkit, focused on the speed and performance of Rust that it’s written in.

A verification module is baked into it, which supports submitting this as a multifile contract or flattening it into a single file using the --flatten flag.

This plugin goes well with those already within the Rust ecosystem, and can be easily installed with Cargo!

https://book.getfoundry.sh/forge/deploying

3. Truffle Plugin Verify

Uses Solidity Json Input format ✅ Custom constructor arguments ✅ Custom library address inputs ❌ Built-in support for most networks plus custom explorer option ✅

One of the earliest Solidity development tools, devs will remember and still go on to love developing with Truffle.

Truffle users can and have always been able to use the verification plugin developed by @rkalis to submit verifications, easily integrated into your project via an npm package.

Once you have it added, simply run truffle run verify YourContractName --network mainnet or to any chain you need this on!

https://github.com/rkalis/truffle-plugin-verify

4. Remix

Uses Solidity Json Input format ✅ Custom constructor arguments ✅ Custom library address inputs ❌ Only Ethereum mainnet and testnets supported ❌

Not leaving out web devs, Remix is an online, no-install web IDE that you can whip up and deploy contracts within your own browser.

The verification plugin comes from activating the Etherscan - Contract Verification module from plugin manager.

One thing to note is while Remix can be used with any EVM network, the verification module only supports the Ethereum network at the moment.

They do however have a Flattener plugin which you can manually compile and submit source code to other explorers.

https://remix-etherscan-plugin.readthedocs.io/en/latest/

This list isn’t exhaustive

Share your new plugins, thoughts, or issues with us through a contact or via Blockscan Chat to nicholaschin.eth💡

Open source the world, verifyooors!

Code on distributed systems may live long into the future, etchings on a ledger, similarly revealing our human tendencies

Intrigue of the Ancients

The earliest contracts in human history may be from thousands of years ago, in ancient Mesopotamia. Here’s an example of a real-estate transaction containing many familiar ideas:

Sini-Ishtar, the son of Ilu-eribu, and Apil-Ili, his brother, have bought one third Shar of land with a house constructed, next the house of Sini-Ishtar, and next the house of Minani; one third Shar of arable land next the house of Sini-Ishtar, which fronts on the street; the property of Minani, the son of Migrat-Sin, from Minani, the son of Migrat-Sin. They have paid four and a half shekels of silver, the price agreed. Never shall further claim be made, on account of the house of Minani…

An interesting feature of such written artifacts is their recapitulation of the mundane. Ancient Egyptian recordings, legible after epic endeavors to decode them, express a unique and alluring culture but in ways that are familiar: contracts, teaching, poetry, private letters, graffiti, and so on.

It’s intriguing to draw comparisons to modern blockchain systems. Code on distributed systems may live long into the future, etchings on a ledger, similarly revealing our human tendencies.

But blockchain is not yet two decades old. Nevertheless, many blockchain enthusiasts derive the same “intrigue of the ancients” from decoding and examining samples of code from just a few years ago¹. On Ethereum, there’s now a sizable “historical NFT” community that pores over old projects, often with an eye to rejuvenating, appreciating and speculating on them.

Verified Contracts

One way to peruse this little history is to explore early verified contracts on Etherscan. Verifying a contract lets us read its pre-compiled code. Tracing a history of verified contracts shows this new medium quickly encoding familiar concepts of human experience, ones that probably occupied the minds of Sumerians and Egyptians, from greetings and messages to real-estate systems and games of fortune.

But a new medium can be a new message. Novelty offers fresh opportunities for a culture that is distinct. In blockchain, this distinct culture might be the way that contracts build composable functionality that is only possible in a public computational system.

Here’s a chain of early contract deployments illustrating this.

August 7, 2015: “Hello Ethereum!”

The earliest verified contract on Etherscan was deployed by wallet 0x3d076. It’s a simple contract that creates a read function called go() that prints “Hello Ethereum!”

Coincidentally, this wallet 0x3d076 is a known contributor to early Ethereum named “Linagee,” now famous for the global registrar contract that implements a lookup table for human readable strings. The idea, like the now widely used Ethereum Name Service, is that you can register and use a much simpler alphanumeric sequence like “takenstheorem.” The contract can use this string to point to a harder-to-remember address. Historical NFT enthusiasts recently implemented a wrapper function around this old contract and the registrar is now widely traded on OpenSea. (Note that this global registrar contract may have originally been written by Gavin Wood, as part of the early Ethereum codebase.)

August 7, 2015: Terra Nullius

“Terra Nullius” was touted on Reddit to be an opportunity for users to claim their spot in Ethereum history. The contract allows transactions to “claim” a message on chain. These messages are not transferrable, so they resemble a “soul-bound token” to the claimant.

You can still peruse the messages that were created from those who interacted with the contract. Linagee also created their own little message on Terra Nullius. Some in the NFT community created a V2 version of Terra Nullius in Sep. 2021 and this distinctly non-historical redeployment somehow garnered over 600 ETH in volume on OpenSea.

August 7, 2015: Gambling, Ponzis & More

Early verified contracts are filled with gambling, ponzis and related projects. The contract “MySchema” might be the first verified contract of this sort. It implements 1 ETH Ponzi scheme, as discussed here on Reddit back in 2016:

Provably fair, uncensorable and permanent. The first financial contracts of their kind. Quite an achievement…for a Ponzi scheme. And they are still out there accumulating and distributing…

Interestingly, this old contract now holds over 9 ETH. This early engagement surely indicative of ETH at $3.

There are tons of these: SimpleLotto, LittleCactus, Goodfellas, ZeroPonzi, The10ETHPyramid, NoFeePonzi, CrazyEarning. It marks the association our industry has with speculation and financial play that is both tempting and unfortunate (games of fortune are likely older than recorded history).

October 6, 2015: A Public Good!

Wallet 0xd3cda created a contract called “DateTime” that implements a set of useful timestamp functions, shown below. The contract will help you convert from a Unix timestamp like 1669601568 (the timestamp of my writing here) to a human-readable date. It can also generate a timestamp from a readable date. The deployer spent 0.03 ETH in gas to create this public resource that all can use. At the time of deployment, this was about $0.02 USD.

October 9, 2015: “Grove”

Grove by Piper Merriam was a public good that offered publicly stored and accessible structured data. An interesting data experiment in the days when gas was priced according to $1 ether, but the contract was not widely used.

October 19, 2015: A Virtual World

The culmination of this vector of complexity at that time was Etheria. Etheria is probably the first true NFT on Ethereum², and was deployed in October 2015, well before the hallowed ERC-721 standard. A wrapper contract allows it to be traded on OpenSea here. Etheria’s original vision was “a virtual world in which players can own tiles, farm them for blocks, and build things. The entire state of the world is held in and all player actions are made through the decentralized, trustless Ethereum blockchain.”

Conclusion

I began this little post describing how contract history recapitulates common human experience, connecting us to the “ancients.” There are many more examples of this in verified contracts relatively early in Ethereum. For example, a couple decided to use an on-chain voting contract to choose their child’s name. A software developer created a codebase for representing prenuptial arrangements on chain. Even proposals in the famed DAO contain echoes of human curiosity, from basic governance decisions to what appears to be playful on-chain graffiti.

These practices are still sometimes the subject of jokes. “Put it on the blockchain” is both a common refrain of new enthusiasts and an ironic lament of OGs. But it’s not at all surprising on the backdrop of human history. We want to encode these things. Hieroglyphs are a striking example of human willingness to invest considerable time and effort learning to encode a wide variety of human messages, even platitudes.

On Ethereum, as the years have passed, composability practices have yielded massively complex financial systems. This is true in DeFi as well as NFTs. For example, I once observed how the Avastars NFT might be telling of their time:

Avastars are “heavy” NFTs, their contract loaded up with elaborate artwork on a network that was once more permissive in fees and ether price. It has that austere weightiness of artifacts from the past, lasting forever into the future, to inspire awe in those who float down the chain and inspect the contract’s details.

That thought is fun, cheesy — and human.

Notes

1. Nick Szabo first proposed the idea of a “smart contract” almost three decades ago, and Bitcoin itself can now implement many kinds of smart contract. Bitcoin has a limited smart-contract language, Script*. *Maybe the most famous Bitcoin contracts are the ones supporting the Lightning Network. Bitcoin surely offers its own intriguing history.

2. What is the “first NFT” is obviously a fraught question of debatable value. If forced to vote though, I might go for Etheria, because its contract is really quite elaborate, implementing many of the ingredients we think of as NFTs and NFT trading tools.

This blog was also posted on our Medium page.

Devcon finally returned after a 3-year enforced absence in October. The event was bigger than ever, with more than 300 talks. We summarize some of the topics covered, including:

1. Growth by Subtraction

2. Ultrasound Money

3. Social Slashing

4. MEV

5. Proposer-Builder Separation

6. Account Abstraction

7. Scaling Ethereum

8. Future of Staking

Growth by Subtraction

Aya from the Ethereum Foundation (EF) opened with a talk on the philosophy of Growth by Subtraction. While the predominant approach to growth for companies is to expand and acquire, the EF understood its role in the infinite game that is Ethereum and chose to subtract — empowering others and providing opportunities for more people to get involved in the process.

“Ethereum is too great for one entity to control.”

Subtraction is not easy. It may not be in the best interests of the individual and they may not be recognized. The philosophy refers to subtraction of power, not work, so it involves even more effort for the organization in educating, coordinating and communicating.

In the words of the Nomics Labs team (behind Hardhat), what subtraction does allow for is the feeling of working with others to achieve the same common goal.

A question for us all: how can each of us Subtract?

Ultrasound Money

The only talk out of 330 in Devcon about ETH the asset rather than Ethereum the protocol was by none other than Justin Drake. He equates ETH with water and uses temperature as a mental model to examine it.

ETH is cold when staked as the assets are not fluid or flowing, and hot when it is being transacted for dapp interactions.

ETH can also be programmed to contribute to the network in four ways:

1. towards security when it’s staked

2. towards sustainability when it’s spent as base fees

3. towards economic bandwidth when it’s used in DeFi

4. towards activity as it’s used for transactions

The incentives for users to stake are in issuance of new ETH and in appreciation of ETH price. Given that issuance has diminishing growth as stake grows, and that the network has been designed for minimum viable issuance, this means that for Etherum’s security to be upheld, ETH price needs to go up.

In short:

A way to measure the sustainability of Ethereum is by treating it with the Price-Earnings (P/E) ratio model. Treating ETH burnt (from base fees) as revenue and issuance as expenses, we can model ETH to have a P/E ratio better than that of Google.

Justin emphasizes ETH as an ideal collateral for DeFi services due to it having no contract, custodial, oracle, bridge, or governance risk on the Ethereum network. Due to its ETH’s volatility, stablecoins will always be used on the network, and here again ETH is ideal as collateral.

With rollups, sharding, and assuming Nielsen’s law, Justin predicts that Ethereum will be able to handle 10 million transactions per second leading to transaction fees of 3 gwei per transaction. Even with an ETH price of $1 million, that amount equals $0.003!

Social Slashing

The Ethereum community has never been one to shy away from discussing controversial ideas, and Social Slashing is right up there in the list, especially in light of OFAC censorship.

With potential centralization of validators challenging Ethereum’s neutrality, Eric Wall cited an old article on Vitalik’s blog discussing how harder-to-detect attacks like coalition censoring can be tackled through a minority User Activated Soft Fork (UASF). A UASF can selectively target and slash misbehaving validators and can be done without compromising the entire protocol, which isn’t possible with Proof-of-Work.

A fear of censorship might prompt us to slash all validators using OFAC-compliant relays such as MEV Boost, but it is not that simple. The existence of these relays preserves the decentralization on the validator level — they may choose to use other relays. The alternative would be worse — only a few validators having a majority of the access to order and censor transactions.

This brings us to a more dystopian view of system-wide censoring. Instead of censoring happening in the block building process, it would happen at the validator level through refusal to attest non-OFAC compliant blocks.

A growing body of research is being built to tackle this pertinent issue, and it is our collective responsibility to be involved in the push for a credibly neutral Ethereum.

MEV

The topic of MEV has been a confusing one ever since it was first introduced to the community. Not only is the term ill-defined, even what it stands for hasn’t been consistent. Initially standing for Miner Extractable Value, it became switched (rather unsuccessfully) to Maximal Extractable Value.

At Devcon Sxsyun entered the scene with a clearer distinction of 3EV — the three types of MEV: Mafia, Moloch, and Monarch.

Mafia EV refers to the scenario where one or more agents have knowledge not known to other agents in the system. This upper hand allows them to conduct sandwich attacks or frontrun others’ attempted transactions.

Moloch EV is value that is surrendered to Moloch, the mythical god of discoordination. In this scenario, a lot of value is wasted due to the lack of coordination between all agents. An example of this was the Priority Gas Auction (PGA) wars that frequently drove up gas prices prior to the launch of Flashbots.

Monarch EV arises as a central coordinator gains power to decide on the ordering or allocation of transactions. A sequencer of transactions in a layer 2 network, for example, can extract value from all transactions occurring there.

Ideally, we want the relationship between them to be 0% Mafia EV, 0% Moloch EV, and 100% distributed Monarch EV. This is difficult to achieve in real life but isn’t impossible.

0% Mafia EV can be achieved with programmable privacy. By increasing efficiency in MEV or specialization of labor, Moloch EV can be reduced. As for Monarch EV, focusing reinvestments into wallets or ideas such as retroactive public goods funding helps to ensure the MEV is distributed.

Proposer-Builder Separation

The idea of PBS is closely related to MEV, as it aims to separate the powers of proposers from that of MEV builders. In the current post-Merge Ethereum, the building of blocks (fitting and ordering transactions that make up a block) is done by external parties using a third party system called MEV-Boost. Searchers find opportunities for arbitrage and other MEV-transactions from users’ transactions and share them with a builder. The builder submits their block of transactions to relays who pass these on to MEV-Boost. On the other side, a block proposer (i.e. validator) selects a suggested block and adds it to the blockchain.

This currently happens outside of the Ethereum protocol itself, relying on relays that could fail to submit blocks, pay proposers less than promised, or even not deliver payment at all.

PBS aims to make this “in-protocol”, removing the reliance on a third party. However, research for it and its consequences are still in an early stage. Some directions in the research are to explore:

• “Two-slot” PBS: where the bidding and payment between proposer and builder are done over two consecutive blocks

• Inclusion lists: where block builders are forced to include a list of transactions as long as the block size isn’t at 100% (extremely expensive to maintain with EIP-1559)

• Partial PBS: where proposer can sell off rights to form only part of a block to a builder

• Slot auction: where the builder can ‘book’ the rights to a particular block ahead of time

More research is needed, and the Robust Incentives Group of the EF welcomes mechanism design researchers to apply to join the team!

Account Abstraction

Another big topic in Devcon was account abstraction, which aims to make smart contract wallets a first-class citizen compared to its current status as subordinate to Externally Owned Accounts (EOAs).

Wallets would not need to sign transactions with their private keys by default. Instead, they could leverage smart contract capabilities to do all kinds of powerful actions such as paying gas for other wallets, using social recovery if access to wallets are lost, and sign batched transactions.

Because there is so much at stake on Ethereum’s layer 1, the current roadmap for implementing it is to push it live on layer 2s with a non-consensus affecting change such as ERC-4337. Once it has proven itself there, the changes could then be implemented to layer 1.

To support the movement, layer 2 developers are encouraged to implement account abstraction on their networks while dapp developers are encouraged to support existing related standards such as ERC-1271 (a standard way to verify signatures for smart contract wallets). Developers in general are also encouraged to join #AllWalletDev calls organized by Sam Wilson to discuss related topics.

Scaling Ethereum

Scaling Ethereum involves not only upgrades to the layer 1 network but also research and breakthroughs in layer 2 technology.

A significant future upgrade is the change to Ethereum’s data structure from a Merkle Patricia Tree to a Verkle Tree structure. This talk by Guillaume Ballet from Geth explains how moving to a Verkle Tree structure will pave the way to a stateless Ethereum and other future applications such as state expiry. A few advantages of Verkle Trees include faster and selective node syncs, making blocks as self-contained execution packages and a (somewhat) smaller state.

Layer 2s are key in Ethereum’s rollup-centric roadmap and a plethora of sessions about it were held in Devcon. A talk by Daniel Goldman from Arbitrum highlights the current and future role of sequencers. As sequencers are currently centralized, a few possible futures were laid out on how to reduce this power. One way is through cryptoeconomic penalties by enforcing slashable bonds from the sequencer. Next is managing MEV extraction through encrypting transactions or having an MEV auction for ordering rights. Finally is “Fair Ordering” through sequencer committee consensus or a hybrid ordering algorithm paired with priorities fees.

Future of Staking

With Ethereum now running on Proof-of-Stake, nowhere is the battle for a secure and decentralized network fiercer than in the staking space. From hobbyist stakers to institutional staking services, Devcon was the perfect place to catch up on this ever evolving front.

For solo stakers, a session led by Pok Lanski from DAppNode provides useful insights. First is the acceptance of MEV as a centralized force and mitigation (for now) by participating in extracting its opportunities. Next is related to proto-danksharding, specifically EIP-4844. Once this is implemented, expect your consensus layer node to become bigger as a new type of data or ‘blob’ is created for Rollups. Statelessness and PBS were also covered. Once this is achieved, validators won’t need to store the full state of Ethereum to validate a block. Hard-drive requirements will lessen for validators, but more work for builders will be needed to provide pieces of state affected in a block.

A panel titled The Staking Economy: From Monolith to Modularity invited us to have a glimpse of the staking future, made possible by tech stack modularization and innovations in middleware solutions. Key highlights include:

• Distributed Validator Technology (DVT) services that can allow distribution of an encrypted single validator key, allowing for distribution of staking pools

• EigenLayer which plans to allow ETH stakers to leverage their ETH stake as a commitment to provide services for blockchains

• An interesting question on whether middleware providers should implement their own governance mechanisms, to ensure adopted innovations are properly maintained and are not just passed over to Ethereum’s core developers

***

The talks and panels above are only a small portion of the knowledge shared at Devcon. For those interested in consuming all its content, head over to the EF’s YouTube channel to explore the various tracks covered. Until the next Devcon!

Thanks to Harith, Azfar and Faiz.