All articles

Recently, there was a dustup on Crypto Twitter (started here, carries on here) about Ethereum’s money supply. The claim was made that Ethereum’s money supply was not easily available, nor was it widely agreed upon.

News flash: Both of these claims are right.

At one point, our project, TrueBlocks, was mentioned, so I thought I’d write an article (which has grown into two articles and a code base) exploring the issue.

While the work we present here doesn’t necessarily make the numbers easier to get (fix the node!), the numbers are accurate to 18-decimal places and verified to the on-chain account balances at every block. We used TrueBlocks to do that.

This article is incomplete in the extreme.

[Jan 20, 2021: Since writing this article, we’ve come upon a project called TurboGeth. It reduces the size of the hard drive needed for an archive node from 6TB to around 1.5TB. Significant difference. Same data. Less costs.]

In the first part, we simply present pictures and prices for the components we used to build the two Ethereum archive nodes we run in house. This list is outdated. About eight months ago we were forced to add a second 4TB hard drive to each machine, as the Ethereum archive node we were running (Parity) was getting close to filling up our single 4TB drive.

Why build an 18-decimal place accurate ledger if it doesn’t balance?

[Accompanying Video]

I had a call this morning with a cryptocurrency accountant. He’s a wonderful fellow. One of those people who can happily wade through thousands of rows of a spreadsheet trying to get the digits to behave themselves. He’s a man after my own heart.

This accountant — call him Mr. Green — makes a good living helping people do their crypto-taxes. He’s busier than ever. He tells me, and here I quote, “Nothing ever balances.”

• The Liberal Radicalism Mechanism for Producing Public Goods [Tabarrok]
• Experiments With Liberal Radicalism [Singh]
• Liberal Radicalism: Breaking down Buterin, Hitzig and Weyl
• Some Gentle Criticisms on Vitalik/Gitcoin CLR [van Ness]
• A Simple Way to Fund Public Goods [van Ness]
• Radical Market, ZK, Privacy and More [Buterin]
• Wikipedia: Quadratic Voting

Eth Research

• A Proposal to Improve Pairwise Coordination Subsidies
• Pairwise Coordination Subsidies: A New Quadratic Funding Design [Buterin]
• A Strange Kind of Pairwise-Bounded Quadratic Funding
• Negative Votes in Quadratic Funding [Buterin]
• On Collusion [Buterin]

Round 2

• Gitcoin Grants: $50K Open Source Fund

Round 3

• Gitcoin’s Q3 Match: $100K+ to OSS projects
• CitCoin’s $4.6m in Results
• Review of Gitcoin Quadratic Funding Round 3
• Gitcoin’s Q3 Match: The Radical Results

Round 4

• Review of GitCoin Quadratic Funding Round 4 [Buterin]

Round 5

• Gitcoin Grants Round 5 Retrospective
• Top Gitcoin Grants For $250k Matching Round 5

News

• Vitalik Buterin Lauds Public Participation in Gitcoin Grants CLR Round 3
• Vitalik Buterin on Effective Altruism [and] Public Goods
• Vitalik Buterin Highlights Grants for Open Source

Tweets

• Vitalik Tweet: Link to Round 3 Analysis
• Gitcoin Tweet about Offering Private Goods

Other

• Grants Round 3 CLR — Data Analysis Bounty

This is short update on what we’ve been doing since receiving so many wonderful grants during the GitCoin CLR matching fandango. This money goes a long way. It allows one of us (Rush) to make a trip to EthDenver, where he will be judging some hacks. It has also paid for some much needed help developing the React frontend. If you donated (or even if you didn’t), and you’re in Denver this week, seek me out. I’ll be happy to share our latest work.

One of the reasons I fell in love with blockchain tech way back in 2013 was because I felt that for the first time in history, engineers had created a system that could produced undeniable data. Undeniable access — yes, but more importantly, undeniably high-quality data. That was a paradigm shift.

While, technically, the data on a blockchain may be untrue, what is mathematically undeniable is that at least 51% of the participants have agreed that the data is consistent — maybe that’s as close as we can get to data being ‘true’.

There is no more angst-ridden profession than being a member of a bomb squad. You’ll know what I’m talking about if you’ve ever seen the movie The Hurt Locker. In a recent Gitter post in the All Core Devs channel, Alexey Akhunov says of the difficulty bomb that it, “…forces people to make rushed decisions and be reckless, without real emergency…” This is true currently, but we can do better.

In a previous article, I mentioned two questions that arise each time we discuss the Ethereum difficulty bomb: “How soon will the block times become intolerable?” and “For how many blocks should we reset the bomb?” I presented in that article a simple method to decide the second of these two questions. In this article, I extend that argument and run through an example. I then try to show why, if we adopted the method I’m proposing, we could answer the first question more predictably, removing some the ‘angst’ or ‘emergency’. Later this week, I will write an article analyzing the current situation and making a prediction of when the block times will become intolerable.

All about the Ethereum Difficulty Calculation

Special thanks to a first-rate Tuftian and data scientist, Ed Mazurek, for early versions of the R code used in this article.

Each time the Ethereum time bomb goes off, two related questions arise. The first question (and arguably the more important) is, “When will blocks get so slow, they will be intolerable”. The second question is, “How long should we delay the bomb this time?”

Did you ever notice that the only way to get the history of an Ethereum account is to visit a fully-centralized, database-driven, old-fashioned web-2.0 website?

Every time I use one of those sites (and I use them all the time), I think to myself: They’re watching me. They’ve attached my IP address to my address and in the future, they will wildly invading my privacy…but I need them…

Recently we demoed a fully decentralized blockchain explorer built on TrueBlocks. (Check it out here.) At the core of our explorer (which runs on commercial-grade hardware) is an index of Ethrerum addresses. This article discusses how we built the index, the difficulties we ran into, and why it’s way more complicated than you may think to share it — especially if you want to avoid becoming an old-fashioned, outdated, web site destined to invade people’s privacy.

Given a blockchain, our goal was to create a list of every appearance of every address in any block on that chain. We define an “appearance” as either the use of the address in one of the common ‘address’ fields of a transaction (such as to, from, or contractAddress) or its use as data in one of the data fields in a transaction. We do not check numeric fields such as value or gasUsed.