How Not To Critique Ethereum
A Handy Guide For Bitcoiners
Tensions between the Bitcoin and Ethereum communities have steadily risen over the years. I’m not entirely sure why this is, but my pet theory is that it has something to with the confluence of bear-market-blues, impatience with technical progress, and unusual weather patterns.
For the dwindling number of us who attempt to maintain some semblance of dual loyalty between these rivalrous tribes, the inter-crypto hostility can grow quite frustrating and tiresome. Not that there’s anything inherently wrong with heated argumentation, of course; it’s the concomitance of strongly held opinions and ignorance of one’s opponent’s position that wears the patience thin. All too often, the Bitcoiner’s argumentative missteps go beyond simply misrepresenting reality and cross over into them shooting themselves in the foot.
So, as a free public service to the Bitcoin community¹, in an initiative intended to improve the quality of the discourse and minimize the self-inflicted pedal-appendage wounds, I offer this guide of argumentative tactics to avoid when verbally sparring with Ethereans. You can thank me later:
Argument #1: “Smart contracts require oracles, and are therefore useless.”
Why You Should Stop Saying This:
The so-called “oracle problem” — much discussed, perhaps best articulated here — is real. Simply put, data concerning external reality can’t be validated by cryptography alone, and granting a party the authority to publish assertions about external reality creates a concentrated point of trust and failure, a threat that any neighboring smart contract logic is implicitly powerless against.
There are some quibbles to be had around the edges here: various mechanisms exist to enable open, permissionless oracles with cryptoeconmic incentives to converge on the truth. Furthermore, a system that uses oracles needn’t necessarily strictly depend on them; oracle failure is almost certainly bad, but it may not render the whole application moot. Still, the core point remains: relying on oracles in non-ideal.
Okay. But the bigger problem with this argument is the frequently held assumption that “smart contract” necessarily implies “oracle-reliance”; what this ignores are the plethora of smart contract applications being researched and implemented in Ethereum circles that don’t involve oracles at all, applications which actually make up a sizable chunk of the r&d in the Ethereum ecosystem. This includes, but is not limited to, layer 2 payment protocols, privacy preserving apps , DEXes, smart contract wallets, interoperability bridges, and even the trustless creation of synthetic assets (including Bitcoin! Really!)
…In fact, given that the term “smart contract” essentially describes any blockchain-enforced transaction logic with more intricate conditions than simple Alice-to-Bob payments, “use cases for smart contracts” would include the Lightning Network itself.
So if you keep saying that smart contracts are inherently useless, people may start thinking that you’re anti-Lightning Network, which, as a Bitcoiner, I assume you don’t want.
Argument #2: “We can and should keep layer 1 as simple as possible; anything complex can be implemented on second layers.”
Why You Should Stop Saying This:
For starters, this claim seems to presuppose that there are useful things to do with smart contracts, which flies in the face of argument #1. So first things first, you should decide on one or the other (although of course my whole point is that I’m advising you to go with neither).
If you do settle on argument #2, we need to unpack what exactly is meant by “can be implemented”:
Say, for example, you wish to use your Bitcoin as collateralized debt for a layer 2 ZK-SNARK-enforced plasma-fied bonding curve (or whatever). This, I hope we can agree, will require some application logic too complex to be executed with Bitcoin Script alone.
Now yes, it is indeed the case that this logic could be executed on a federated sidechain. It could also be executed on a Digital Ocean droplet. In fact, give this author enough time (and adequate compensation) and I’ll run the script for you on pen and paper. In a separate environment without any restrictions, we are free to run whatever code we want. This is not untrue.
But surely the whole point — I mean, quite literally, the whole point of all of this — is that there’s utility in giving humanity the ability to carry out digital financial transactions without imposing trust requirements on them. If there’s anything interesting about “second layers,” it’s their ability to derive their security and trust assumptions directly from the blockchain layer beneath them. Whatever security guarantees are provided by a trusted federation (or my pen and paper, etc.) have nothing to do with the security properties of Bitcoin itself (you know, mining, permissionlessness, economic security, all that.)
And while there’s an intuitive appeal to the “simple layer 1, fancy layer 2” mental model, the empirical fact is that the limitations of the base layer directly impose limits on the protocols that can be handled trustlessly on higher layers. Second layer protocols are only as good as their on-chain settlement conditions; your funds are secured by the ability of the base layer to property settle any fraudulent activity, if the need arises. Lightning channels are fine example of such a protocol, but there are entire other areas of this design space — channel constructions beyond the scope of Lightning, and non-custodial sidechain-ish constructions that aren’t even channels, all with their own potentially powerful properties. If you try to implement these things on a base layer that can’t support sufficiently complex settlement conditions, you’ll find yourself needing to trust third parties more than you than they otherwise would. It’s that simple.
To be sure: there are other downsides to adding complexity on the base layer (see argument #5), the trade-offs of which seem to this author to be well worth debating. But unfortunately, the “we can just do that on additional layers” retort not only short-circuits this debate, but makes you appear unaware of and/or unconcerned with the nature and risks of trust assumptions. You don’t want this and neither do I. Step it up.
Argument #3: “Bitcoin Script currently supports the optimal level of smart contract logic; any additional features are unnecessary.”
Why You Should Stop Saying This:
You don’t actually believe this. No seriously, you don’t. Look at yourself: you’re a Bitconer. You love lightning. You yourself have been arguing (to take one example) for adding SIGHASH_NOINPUT for years. It’ll give you Eltoo channels (almost universally agreed to be superior Lightning channel constructions than the currently used Poon-Dryja channels), as well as other potentially fruitful layer 2 / layer 2 adjacent constructs like Channel Factories, Statechains, etc. (Constructs all of which, by the way, have been possible since day 1 on Ethereum.)
Your view that Bitcoin Script’s current state just so happens to be ideally sufficient for all needs — let’s call it “Bitcoin Panglossianism” — is belied by your pushes to change it. You must be confused.
Which leads us to:
Argument #4: “Smart contract features that prove to be useful can be added to Bitcoin via soft forks.”
Why You Should Stop Saying This:
Lot going on here.
For starters, once again, even considering the potential utility of a new feature contradicts argument #1, and acknowledging that we may want/need to update the core protocol to support new features contradicts arguments #2 and #3. So sort of all that out first.
Regarding “can be added to Bitcoin via a soft fork”: a strange but true property of these public blockchains (that’s still yet to sink in for many) is that literally any change — yes, any change, including modifying the inflation schedule, increasing the blocksize, and even switching the mining algorithm — can be implemented via a soft fork.² So to say that something could be added with a soft fork is essentially a tautology. The real question, then, is could it be added to Bitcoin without radically changing the nature of Bitcoin itself, and/or losing some other desirable properties?
There are properties of UTXO chains that are hard to toggle gently. Most fundamentally, state modifications are limited to consuming UTXOs and creating new ones; many protocols naturally want a way to read state and/or mutate it, and recreating this feature on Bitcoin gets weird. You can kinda sorta fake state mutation with covenants, but this unleashes all sorts of other risks you need to squash. You could try to just directly allow some state-reading, but then you’re going to have to rethink the limits of scripting, and probably introduce something more akin to gas, and before you know it, Bitcoin will just de/e-volve into a technological sibling of Ethereum itself (surely you don’t want that, right?)
Of course, the more obvious point to make here is that one of the main purported value propositions of Bitcoin is that changes to the base layer are very rare and very politically difficult to get through. And indeed, credit to Bitcoiners, this has proven to be the case. Remember that cool SIGHASH_NOINPUT mode? The one that many have pushed for, and that many are already building protocols presuming its eventual inclusion? Well, it’s increasingly looking not-unlikely that technical and political concerns ³ may prevent it from ever getting forked in, at least not in its currently understood form. In fact, historically, more Bitcoin upgrades have amounted to removing features than adding them. Can’t have it both ways.
Point being, all things equal, permissionless innovation on the base layer is surely preferable to lobbying for a protocol change whenever a useful construction is discovered. Now listen carefully: all things are not equal, and I’m not suggesting they are. But to simply say “we’ll soft fork in” is a non-retort that implies that there aren’t downsides to requisite social coordination and consensus on which protocol upgrades merit inclusion. Das ist not very Bitcoin-y.⁴
Argument #5: “The requirement for every node to execute smart contract logic renders Ethereum unscalable.”
Why You Should Stop Saying This:
This one gestures towards a valid point: bringing scalability to Ethereum is indeed, in at least one important way, more difficult than bringing scalability to Bitcoin. The generalized data-store of Ethereum’s state has proven far more unwieldy than Bitcoin’s more constrained, implicit UTXO state, as evinced by how much more taxing it is to run an Ethereum full node than a Bitcoin one (despite Ethereum’s Blockchain still being smaller in size).
But with that said, the core, fundamental scaling challenge here — that every state update must be globally executed and shared by all nodes — is shared by Bitcoin and Ethereum alike, and for the exact same reasons.
If it feels like I’m tearing down a strawman here, I include it because oddly, the implication that this is somehow a uniquely Ethereum problem still comes up, even by people who surely have a strong understanding of Bitcoin itself.
In short — if Ethereum is rendered unscalable by this specific property, Bitcoin is too. So I’d tread lightly.
Argument #6: “Nobody uses Ethereum.”
Why You Should Stop Saying This:
This isn’t true.
Now it is indeed the case that Bitcoin has wider adoption than Ethereum, but the strategic problem with this argumentative tactic is that employing it will inevitably force the bigger, underlying issue to the surface: cryptocurrency adoption is still quite limited all around.
Real talk: if you’re one of the people who’s been excited about this space for years, 2012-you most likely would have predicted that more people would be using and caring about cryptocurrency than we in fact see here in 2020. If Bitcoiners and Etherocrats quibble about the sizes of their respective slices of the pie, to outside onlookers, it only really draws attention to how measly the whole pie still is. This helps nobody other than nocoiners, who I assume we can all agree are vile degens who deserve no help from anybody.
So on the issue of adoption, I’d suggest that a détente would suit both sides best.
Argument #7: “Ethereum isn’t and can’t ever be a ‘world computer,’ that’s absurd.”
Why You Should Stop Saying This:
Well actually, you can keep saying this one, because it’s true.
The thing is, I don’t know anyone in anyone in the Ethereum world who doesn’t feel the same way (and I know several who’ve actively pushed back on the use of this term). “World Computer” was pretty clearly meant to be a metaphor to help out non-techies, but it’s ultimately a misguided and misleading meme; if you see someone promoting it, go ahead and chastise them, and I think you’ll find Etherocrats right there beside you. I only ask that you don’t enter a debate with an Etherean expecting them to believe and defend anything about the “world computer” thing; it will ultimately just waste everyone’s time, time which we could all better spend yelling at each other about more substantive things.
Argument #8: “Ether going up in value is bad for Ethereum, since it will mean gas is more expensive.”
Why You Should Stop Saying This
It’s genuinely mystifying that an argument this confused and self-defeating has withstood the test of time. And yet, like (globally distributed) clockwork, it continues to regularly rear its head.
So fees on Ethereum are necessarily a bit more complex than on Bitcoin, due to the need for a standardized cost-per-computation unit. This unit is known as gas, and it determines how much Ether miners get paid for executing operations.
The block gas limit is managed in-protocol, but the gas price emerges directly on the open market from users bidding on miners, just like in Bitcoin*. Thus, as the native asset increases in value (in USD terms), miners can opt to decrease the amount of the native currency that users need to pay for transactions. Just like fees in Bitcoin. This means that transaction fees needn’t necessarily tightly correlate with asset price. Just. Like. Bitcoin.
In every way that’s actually relevant to this argument, fees on Ethereum are equivalent to fees on Bitcoin. So if the economics of fees on Ethereum will pull Ether’s value down, Bitcoin’s value is going down along with it. Luckily for all of us, this isn’t the case. Move on.
Final Thoughts
Observers may find that some of their personal favorite criticisms of Ethereum don’t appear on this list. One possible explanation for this is that the author is unfamiliar with the argument you have in mind.⁵ The more likely explanation is that he himself tends to agree with it. Thus, if your Ethereum critique of choice doesn’t appear here, that’s probably one you ought to keep using. For everything else, I hope this checklist serves as a handy guide.
Good luck out there.
Thanks to Josh Stark and Eric Wall for their feedback.
Daniel Goldman is an independent software engineer, technical consultant, and writer who spends a lot of time thinking about cryptocurrency.
Correction: This had originally incorrectly suggested that miners vote directly on gas price in protocol. Thanks Edmund Edgar.
Notes:
[1]: Yes, I do strongly believe there are such things as crypto communities and will be referring to them as such throughout; you’ll just have to get used to it.
[2]: Intuitively: soft forks restrict the set of blocks that are considered valid. To add some rule (rule X) via soft fork, we make a new restrictive rule of the form “block are considered invalid unless X is true.” The specific case of soft-forking in a new mining algorithm is a bit cuter than the others, but hey, it can be done.
[3]: Tldr: if two UTXOs are locked with SIGHASH_NOINPUT and have the same addresses and Bitcoin values, a transaction spending one could be replayed to steal the other. Which sounds (to me) like a pretty hard thing to simply happen by accident, but this seems sufficient to stir enough debate to slow things down, at least for now. There are several proposed mitigations/solutions, all of which, to my eyes, look rather Byzantine.
[4]: It’s worth adding that the the Ethereum side of the “flexible layer 1 / political ease of upgrading layer 1” equation is ironic in the contrapositive way, but that’s outside of the scope of this; Bitcoiners are the ones in the hot-seat right now. Stay focused.
[5]: Unlikely.
