What Comprises an Ethereum Fullnode Implementation?

Demystifying Ethereum Fullnodes

Note: This post was originally published May 13, 2019 on the Amentum blog: https://medium.com/amentum/what-comprises-an-ethereum-fullnode-implementation-a9113ce3fe3a

Like clock-work, similar misinterpretations of blockchain-based “fullnodes” gets a bit out of hand. When we see this confusion, we want to do our part in dispelling it so as to push the community forward and educating them, as I did with bitcoin initially.

Since validating transactions on Bitcoin is a bit different from Ethereum due to how they handle, store, and archive state updates for reference and security, given Ethereum’s difference in architecture, we want to dispel any confusion between the two. This post will only discuss fullnodes, to get a full in-depth breakdown of how Ethereum works, check out this article; or to simply understand theETH transaction lifecycle, this post here.

What Is a Fullnode?

On Ethereum, validating the current state of your transactions only requires knowing the current state of the block that your transaction will be in included in, once it is propagated to the network, and accepted by miners.

Because Ethereum takes your smart contract code, compiles it to bytecode, and then submits your transaction to the EVM to update its state, maintaining the older historical state outside of the block with your transaction is not necessary for immediate validation (though some implementations will store the state of the last few hundred blocks, just for additional security against block reorgs, more on that later).

For Ethereum, a “fullnode” is copy of the entire chains’ history of state changes, from one account to another. By default, all intermediary states of contract transactions and contract calls are computed on the fly during your initial sync (unless you adjust this setting specifically before you sync), and what is unneeded (older state transitions) are pruned away (removed to save storage).

This is a feature, not a bug, since Ethereum abstracts state updates into contracts and compiles them via the EVM before they’re eventually saved on-chain and the state root is updated; this architecture gives us greater flexibility in how we can configure your node to be most efficient, depending on your personal use-case.

This guy gets it. Nodes are your economic representation on a blockchain-based network.

Importance of Ethereum Fullnodes

As we stated above, by default all intermediary states of all contracts that interact on chain are computed by default, but not all of them are stored. It is important, however, to note that those intermediate states could be re-computed and that data’s integrity can be check at anytime, since the intermediate states are stored on disk from genesis with a default fullnode.

This process is of course CPU intensive, and can require a lot of data to store all those intermediate state updates on your harddisk (that don’t even belong to you!). So, this is why by default those unnecessary states are “pruned” (periodically removed from the state trie so as to reduce bloat when initially syncing your node).

Not everyone needs to know the state of every contract interaction in the world (unless of course you’re a data analytics firm, like Etherscan, that needs to store all states to provide you a block explorer).

Example of a state update flow, from an externally controlled ETH account, to the transaction with a contract, and the subsequent internal contract calls. This image was taken from Preethi Kasireddy’s “How Does Ethereum Work, Anyways?

In Bitcoin, the transition from one unspent output (UTXO model) to a new input when you send from one address to another, is the state update itself. This is why many in the Bitcoin space will claim a pruned fullnode is not a “fullnode” in the extreme purist sense, because spent TXs are removed from the state when you fully sync a pruned node. Once removed, you cannot re-compute the state, you must re-sync from genesis to get the full snapshot of the blockchain once more.

Here’s two analogies from Twitter we think will help:’

A very simple analogy to compare an Ethereum fullnode, to a traditional bank account from Nick Johnson (ENS).

Re-computing intermediate states just formulates a full index for reference, in Ethereum.

Now that we understand quickly why fullnodes work the way they do on Ethereum, let’s dive into all the types of economic agents (nodes) that are possible on the network.

Types of Ethereum Nodes

Remember, Ethereum fullnodes are flexible by design, but they still need to do a few things. In short, fullnodes have to be able to: validate transactions that are being mined (if mining); apply the block reward (which is now 3 ETH/block at time of this writing based on recent EIPs); and, the most important task for the majority of users, verifying that state and the resulting state changes are applied properly and follow the consensus rules (which are checked against the state trie in each new block header).

However, sometimes your use-case may require a certain type of access to information (or as the least amount of information as possible, due to system restraints). Here’s each of the various types of clients you can configure on Ethereum:

  • Light Clients: Requires no validation, requests the current state from the P2P network to verify current state (fine for processing payments and simple contract calls), but your validation is out-sourced to other fullnodes with the necessary information.

  • Fast Node (Fast Sync/Warp Sync):Will not validate intermediate states during the initial sync, will validate everything else after that, however. This allows older data to be pruned that likely has nothing to do with your transactions

  • Full Node:As described above, validates everything, and will prune old intermediate states from memory, and will keep an archive of future state trie updates.

  • Archive Node (Historical Node):Validates and stores all intermediate states, nothing is pruned, all state transitions for accounts are retrievable. Future state trie updates and full intermediate states are stored.

Here’s some more reactions from the community responding to others with concerns about Ethereum, due to public misunderstanding of how its different economic nodes function (the misinformation is very widespread).

If you’re looking to sync a Geth or Parity node of your own (Ethereum’s two largest implementations), you can follow this guide hereto get up-to-speed on the various modes prior to syncing.

Dispelling Myth and Confusion

We are in the firm belief that Ethereum’s capability to have so much flexibility with how it stores and updates its state root gives it a real strategic advantage to platforms following UTXO models. In Ethereum, there are many types of clients that record state, and in the future, perhaps even clients that don’t require state at all!

But, as Ethereum continues to mature, and is embedded in more devices, its flexibility will begin to shine and continue to improve (with a fresh blank state with the incoming transition to ETH 2.0, making things even more efficient storage-wise).

We see a future of many clients, all acting as independent economic agents, with different data availability requirements. But, regardless, a fullnode on Ethereum is in fact that, a fullnode. And, how one syncs theirs should not be misconstrued with other chains like Bitcoin, as long as you’re using the right type of node for the job.

References and Other Relevant Educational Resources:

Ethereum node configuration modes cheat sheet
This document is a quick cheat sheet of most common geth and parity configurations explained - usually, everything you…dev.to

How does Ethereum work, anyway?
Introductionmedium.com

The Blockchain Stack
Co-authored by Alexis Gaubamedium.com

Synchrony and Timing Assumptions in Consensus Algorithms Used in Proof of Stake Blockchains
Co-authored with Alexis Gauba.medium.com

Cent Network Master Class

Understanding the Incentive Mechanics of Cent

Note: This post was originally published May 13, 2019 on the Amentum blog: https://medium.com/amentum/cent-network-master-class-a9d473cb54a2

If you haven’t heard of the Cent Network, now’s the time to really look in-depth to understand one of the most intriguing and advanced platforms for mainstream adoption for Ethereum, to date.

Built atop Web3, Cent is a social network that abstracts away many of the headaches of Web3 by utilizing state channels to remove the need to pay gas, fees, and provide instant settlement for fund reuse on the platform. Ultimately the Cent team has created a Web2/Web3 hybrid that is easy to sign-up for and get started using quickly, even without ETH.

The incentive primitives that are native to the platform are: Sorting, Tipping, Bounties, and Seeding — each works to create a feedback loop of value exchange to keep users passively earning a income, while incentivizing them to create and support others concurrently while providing an income for themselves.

To help speed up the education process as Cent moves to exit beta (since it formally launched in August of 2017), here’s some insights into how the mechanisms on the network interact as you use the platform proficiently to grow your brand and influence.

Importance of Following

Explanation on why following Channels is useful as a Cent user.

Following Channels is straight-forward and very important, since your personal feed (notated by your custom-user color dot on the home screen) is self-curated; any channels or users you follow will have the content displayed direct into this feed.

Shot of the the main screen when signed into Cent, with all the channels we follow.

Follow the topics you love the most (similar to following hashtags on Instagram, if you’re familiar). This adds you to that community and will put any new content posted there front and center when you sign-in to use Cent, so you can quickly start engaging and earning by interacting with those posts right away.

Ensure you follow the users you come across and enjoy as well, as their latest content will show up in this feed in reverse-chronological order.

Why Use a Bounty?

Explanation of a post lifecycle with a Bounty attached.

When you include a Bounty on a post, you’re not just giving away money. The point of Bounties originally was to incentivize micro-tasks (like photoshopping an image, taking a survey, etc), with the best responses being curated and subsequently rewarded by the community — but that overtime has evolved into something flexible and more generalizable that enables more engagement for any type of content post.

Along with more engagement, Bounty posts have a longer life-cycle. Instead of immediately going to New, and slowly fading from lack of engagement, your posts get more opportunities for interaction through each phase it moves to as notated by the graphic above. This makes it more inviting for Seedersto reward you as they may make a profit if your content gets further traction based on its perceived quality to the community.

In summary: the more times users get an opportunity to read or interact with your post, the more likely it’ll be seeded, engaged with — increasing your overall passive earning potential.

Content Farming with Seeding

Explanation of how seeds enable a passive social income, while curating the site’s content.

Getting passive rewards for every social interaction you do online? Sounds like a crazy idea at first — one rife with technical and regulatory headache using traditional payment rails. Here it isn’t, with every reply capable of being Tipped (via state channel micropayments), and every post capable of being Seeded, earning passive rewards is easy.

Since Seeds go on forever (as the seed channel doesn’t close), whenever a future user discovers one of your posts on Cent, and subsequently seeds it in the future, you’ll still get your passive cut of the reward, proportional to your weighting in the seed in the channel (which depends on how much you seeded compared to others). The more seeds you accrue, and replies you post, the more passive rewards you can garner overtime as the site grows. Your time spent socializing is now money!

Where’s the Money Come From?

A web of the value exchanges in the platform from the various primitives that can be engaged with.

The illustration above shows how new value (in the form of ETH) comes into the network. Built off Ethereum, the state channel wallet holds your value while it remains unspent in your account. New value accrues in the network with the help of Sorting or Tipping for those with no value in their wallets and starting from square 1; this makes the network more inclusive for less wealthy individuals.

Since a user can earn without needing a wallet, only an email, and just for using the platform naturally, the barriers to entry are much lower. That said, the value that accrues also gets re-distributed by those that don’t withdraw.

Sorters make ETH, or can get Tipped directly, and then use those funds for future bounties or seeds. All these interactions are eventually connected, creating a positive feedback loop of earning and social engagement.

Those that include Bounties on posts make additional funds from Seeding, or those seeds end up as direct entries in a user’s wallet from a non-bountied/bounties post, or they accrue when someone who has earned distributes it as a tip directly to a user. Everything is connected.

Social Network Experimentation

As you can tell, a simple system that abstracts away fees and gas, and enables seamless value exchange in novel ways can create sustainable ecosystems. We believe social networks built atop of Ethereum also help strengthen its social moat and network effect, and enables adoptees an easy on-boarding ramp without dealing with the really step learning curve of self-custody or setting up a Coinbase account.

Recently, Cent announced the ability to use its platform without a Web3 wallet by utilizing a mobile pin and authorization to interact with your Cent state channel wallet, As well as the addition of an in-app messenger, enabling you to send money instantly anywhere in the world with no fee, in just a click.

We believe these features, coupled with their teams’ commitment to a seamless product UX, makes Cent the most accessible and powerful social network built on Ethereum to date. We’re excited to see how the platform further evolves, and we’ll discuss any significant changes as they arise here to keep you up-to-date.

Sign-up for Cent today and give it a try.

Amentum GP Video Series

Links to Panels and Lectures of Amentum GPs

We as a firm get invited to speak at many different events and conferences. Since we’re committed to educating the greater community on our perspectives, insights, and strategies for building and maintaining success companies and protocols in our burgeoning industry.

Here are a few of the recordings we’ve managed to get our hands-on, and we hope you find value from them. We’re grateful to all those who help us by allowing us to spread our message to so many bright minds.


Panel discussion on Marketing to Crypto Developers at StarfishHQ in San Francisco:
https://www.youtube.com/watch?v=cOcvK9wIEXM

Amentum lecture about Crypto and Crypto Funds at Howard University:
https://www.pscp.tv/w/bUIKhjE3NzMxMnwxZWFLYnFqZW5EUXhYRcZCCHZSJLTiI997P4hk2okzbXjSiWyxcVfWqH9V3mM=

McKie’s discussion on diversity and decentralization at ETHDenver can be found here (Starts at 2:35:00):
https://www.facebook.com/ETHDenver/videos/165255714125496/

McKie’s presentation at ETHDenver (2018) Hackathon on Power for Amentum, (Starts at 43mins):
https://www.facebook.com/ETHDenver/videos/165524917431909/

What Should Developers Build? (Steven McKie on Dapp University Podcast):
https://www.youtube.com/watch?v=Z8oaDQ2DfrE/

Blockchain Communities and Their Emergent Governance

Thoughts on Legitimacy and Narratives

Note: This post was originally published November 19, 2018 on the Amentum blog: https://medium.com/amentum/blockchain-communities-and-their-emergent-governance-cfe5627dcf52

Blockchain governance is an important topic. In varying contexts, we’ve written about it in the past (here and here). Vlad Zamfir and Fred Ehrsam have also long been making important contributions — and it’s important we continue these discussions accordingly as the ecosystem matures and grows, too.

By: Matthew Prewitt and Steven McKie

As a topic, blockchain governance is incredibly confusing. First, it is not always clear what’s being discussed. And even when it is, the intersecting questions of technology, culture, and political philosophy can get terribly knotted up. Our hope is that this piece will loosen the strands just a bit and help clarify what’s at stake.

First, conversations about blockchain and governance should clarify their scope by clearly answering two questions: (1) What is being governed, and (2) what is doing the governing? In other words, talking about blockchains and governance can refer to at least four things:

  • Governance of blockchains by humans (e.g., EIPs, BIPs, and forks)

  • Governance of humans by blockchains (e.g., via DAOs or bounties)

  • Governance of blockchains by blockchains (e.g., on-chain limitations and permissions)

  • Governance of humans (blockchain users/developers) by other humans (government authorities)

Figure 1: Blockchain Governance Map

There are interesting and important questions present for all four quadrants. But to be clear, this piece is concerned primarily with how humans take decisions that affect blockchains, through mechanisms such as code updates and forks (henceforth referred to as, “blockchain governance”).

Blockchain governance decisions matter, because they influence how blockchains work, how they are used, and what kind of communities spring up around them. These things, in turn, affect the broader society and ultimately matter to everyone.

Legitimacy, or . . .

As a jumping off point, let’s examine what Vlad Zamfir has called “legitimacy”, in one of his more recent posts on governance.

Zamfir defines the issue of blockchain governance in the following way. A number of stakeholders decide what happens with a blockchain: developers writing and updating the blockchain’s software, node operators deciding whether to run said software and implement updates, “trademark” holders (i.e., people or institutions asserting “this blockchain is Ethereum” or “that blockchain is Bitcoin”). In most cases these parties are not appointed by any authority. Yet, their coordination or lack thereof determines how a given blockchain’s software evolves overtime (or at all), and whether its community of developers and users stays together or “forks” to go a different ideological direction.

Legitimacy, in Zamfir’s usage, is a property that these parties’ coordination mechanisms have when their outcomes are likely to be respected:

“I say that a decision, decision-making process or coordination mechanism ‘has legitimacy’ if there is common knowledge that participants in governance will implement the decision, or use the decision-making process or coordination mechanism.” [2]

Further, from Zamfir:

“[I]f a coordination mechanism is legitimate, people will (justifiably) act like it’s a fact that people will use it. When a decision is legitimate, they don’t need to worry about whether other people will also implement it, they can be confident that they will. On the other hand, if it’s illegitimate then they will act like it’s a fact that people won’t use it. I see the establishment of legitimate decisions, decision-making processes and coordination mechanisms as a clear, elegant solution to coordination problems.” [2]

Moreover, Zamfir goes on to observe that such “legitimacy” can have various sources. For example, advocates of autonomous blockchains wish to limit the influence of humans in blockchains’ future governance processes: they want the blockchain itself to be the only source of legitimacy. Alternatively, one can imagine governance processes falling under the sway of various real-world groups, such as corporations, developer groups, or governmental institutions, so that these groups would monopolize the “legitimacy” behind a given blockchain.

All of this raises interesting, knotty questions. But let me pause for a semantic quibble.

. . . Authoritativeness

When Zamfir talks about legitimacy, he’s referring to an important subject in blockchain governance, and his analysis is lucid. But we do not think “legitimacy” is the best word choice. “Authoritativeness” would be more appropriate.

To be clear, this is a purely semantic argument, not a criticism of Zamfir’s logic. But occasionally semantics matter, and we think this is one of those times. Let us explain.

In the literature on political legitimacy, there are two general schools of thought: one descriptive, and the other normative. Descriptive theories of legitimacy take legitimacy to refer to peoples’ beliefs about where authority rests and how it arises. Normative theories of legitimacy, on the other hand, deal with the justification of authority. They distinguish between de facto authority and legitimate or rightful authority (you can learn more about the varying types of “power”, here).

Zamfir’s concept of legitimacy is purely descriptivist. His insights still matter, because it matters how members of blockchain communities locate authority, and what decisions they take to be authoritative. I just think there is a better word for this. Why not call it “authoritativeness?”

Take a look at this key passage from Zamfir, with “authoritativeness” replacing “legitimacy”. To my eyes, its meaning is clarified but unchanged:

“[I]f a coordination mechanism is authoritative, people will (justifiably) act like it’s a fact that people will use it. When a decision is authoritative, they don’t need to worry about whether other people will also implement it, they can be confident that they will. On the other hand, if it’s not authoritative then they will act like it’s a fact that people won’t use it. I see the establishment of authoritative decisions, decision-making processes and coordination mechanisms as a clear, elegant solution to coordination problems.” [2]

But we digress. The importance of the semantic point is simply to highlight the need for conversations about normative legitimacy in blockchain governance.

In blockchain communities, normative legitimacy matters hugely, much as it does in nation states, or other governed entities, like corporations and tribes. To illustrate: Suppose a cigar-chomping Generalissimo appears on state television to announce the success of a violent coup d’etat, declares himself head of state, and then issues credible, threat-backed commands to a fearful populace. Those commands are likely to be followed by all, or most. They are authoritative. But they are not legitimate, because the values of the community are embodied in certain decision procedures[1], which the Generalissimo ignored. The community will not accept the legitimacy of his decisions, because they were not arrived at through proper means (like elections), which reflect the community’s values. The distinction that the community members hold in their minds as they reject the legitimacy of the Generalissimo decisions, even while accepting their authoritativeness, is constitutive of that particular community. It is what makes that community a community, rather than just a bunch of people blindly following orders of its loudest or most referent community leaders.

Hopefully you can see why this is worth thinking about. If legitimacy, for blockchain communities, has no normative content, then blockchain communities don’t really stand for anything. They aren’t really communities.

So What Are Blockchain Communities, Anyway?

Yuval Harari has an interesting and concisetake on what communities are. He says they are collections of people who believe in shared stories. Shared stories allow people to work with people they don’t already know, thus creating a community extending beyond mere family and friends. For example, we wouldn’t ordinarily trust a stranger. But if we learn that he/she believes the same religious/moral (i.e., normatively significant) stories that we believe, everything changes. We can trust him/her. And we can start cooperating accordingly without fear of repercussion or malice.

Blockchains are a technology that enables people to cooperate without trusting each other — without a shared narrative. In other words, they enable cooperation without community. But this is where things get confusing. Because that kind of cooperation — blockchains augmenting trust, and opening up the traditional boundaries of community — belongs in the bottom left quadrant of Fig. 1, above. It’s interesting and important. But it’s unrelated to what we’re calling “blockchain governance”, which concerns the upper right quadrant.

At the end of the day, blockchains are embedded in actual human communities. These communities are far-flung, contentious, and hard to define, but they exist. And they are constituted by shared stories and values that inform the legitimacy of the decisions taken about blockchains’ governance.

Now let’s look at three prominent examples from some of the major public crypto assets.

Comparing Bitcoin, Ethereum, and ZCash

Figure 2: Three major assets, from most conservative, to most progressive.

Bitcoin’s community is highly conservative (Fig. 2), with a starkly limited narrative of the blockchain’s purpose (basically centered on the idea of an alternative to fiat currency). Few parties meaningful have influence in governance. One of Bitcoin’s calling cards is the fact that it has been successfully operating almost autonomously, uninterrupted and at high volume, longer than any other blockchain. Thus, modifications are regarded warily, because they weaken that overall narrative.

Bitcoin’s community has repeatedly shown that they greatly value the conservative nature of technical improvements, and will push diligently if that ethos is challenged for the sake of what the “majority” deems a short term improvement (research Bitcoin’s history of opposing hard forks to learn more).

Ethereum’s community, by contrast, is far more fluid and open. It embraces the idea that its blockchain can and should serve dramatically different purposes for different people — with individual use cases serving as loosely-coupled applications that utilize the main public chain.

Moreover, its narrative centers less on the idea of an alternative currency, and more on the idea of decentralizing institutions. Where the Bitcoin community doesn’t seem to mind so much if it generates some kind of new plutocracy, the Ethereum community is more “big tent”, with room for more egalitarian dreams (as long as you respect the progressive ethos).

Their community was built and predicated on improving and scaling the Ethereum layer 1 codebase, and launched with a very ambitious roadmap in order to reach their end goal of implementing Proof of Stake. The more progressive your community, the wider your eventual funnel of opportunities for your captured community members. (i.e. Ethereum and its massive development community/funnel, which was likely driven from the influx of capital from the ICO boom in late ‘17 — early ‘18).

Figure 3: As communities grow and get more liquid, the importance of having a large funnel to bring in new talent grows in importance.

The more innovative, and “fast-moving” cryptocurrencies will tend to lean more towards the progressive end, which is especially aided by a large market-cap and a highly-liquid asset (which means the community is not stricken by poor capital reallocation/reinvestment into their ecosystem).

ZCash belongs somewhere between these two poles. As a newer asset that only launched in October of 2016, Zcash had a lot of ground to catch up on when compared to Bitcoin and Ethereum.

This also lends credibility to the theory that the newer your major public chain asset is (one that is deemed sensible and worthwhile by the technical community), the greater the need for your community to beslightly more progressive than its most legacy incumbent, in order to “catch-up” in liquidity and be integrated into existing services to gain a proper foothold. Though, still forked from Bitcoin’s original codebase, and utilizing a UTXO set, ZCash must still maintain a level of conservatism compared to the seemingly unmatched pace of technical innovation that persists in Ethereum’s smart contract, account-based, token-focused model.

With the launch of the ZCash Company, and eventually the ZCash Foundation and other for-profit/non-profit entities, ZCash is slowly building a strong foundation by which its community can stand on long-term; while concurrently building an ethos and a narrative around both quality, and security.

The public parameters at the root of ZCash’s zero-knowledge proofs were generated by actual humans at a (maximally transparent) “ceremony.” Thus, non-zero trust in the integrity of that process is required in order to believe in the inviolability of ZCash’s encryption.

Moreover, ZCash’s updates are highly transparent and open to user participation, and each subsequent hard fork increases the number of active participants and further decentralizes improvements with each iteration of the MPC ceremony . These are indicia of “openness”. At the same time, ZCash distinguishes itself from Bitcoin and Ethereum by creating a radically cloaked environment, in which users can participate in good or evil without discovery. In this respect it appeals to radical individualists, with a values-agnostic user base. ZCash continues to navigate an interesting tension between the closed and open aspects of its community.

Their focus is on targeting a more moderate, yet still conservative rate of change, while refusing to add any unnecessary features that are deemed superfluous by its low-level technical community members.

By first developing integrated security practices, a focus on scientific peer review/code review, and slowly adding support for alternative fullnode clients, they can steer the future of the asset in the right direction — while simultaneously distancing and differentiating itself from incumbents like Bitcoin, with its strong focus on privacy and long-term growth.

Their team is even aware of the potential that one day its internal community may opt to hard fork itself, in order to improve its base-layer for a much-needed use case or other major addition that could make the asset’s community even more resilient. Having just completed another planned hardfork with the successful release of Sapling, the ZCash community is already leading the way for further layer 1 improvements with next year’s “Blossom” upgrade.

Ultimately, we believe that fluid and open governance styles are conducive to the growth of blockchain communities. Giving more people a seat at the table — and role in shaping the narrative — “widens the funnel” of community members. For example, both Bitcoin and Ethereum have attracted enormous speculative interest during the past several years. But Ethereum has done much more to translate that speculative energy into a real, thriving community — largely through institutions like the Ethereum Foundation, ConsenSys, and meaningful developer communities like EthMagic — with ZCash on the path to build similarly with its slightly more progressive vision when compared to Bitcoin.

Conclusion

Going forward, we will be looking out for blockchain communities with open, fluid governance, and a proven tendency to translate speculative energy into a concrete developer opportunity. And perhaps most importantly, we will be looking for communities tied together by a compelling, inspiring story.

The low-level technical semantics of each major blockchain-based asset is of course incredibly important — however a common narrative that people can understand and echo is just as important, and crucial for the longevity and growth of a new community.

Subscribe to our Newsletter to get this in your inbox:

Amentum GP Newsletter
Essays and analyses from the Amentum GP team.amentum.substack.com

— — — —

[1] In this passage, I am focusing on “process” legitimacy. But normative criteria for legitimacy can also concern outcomes.

[2] Zamfir, Blockchain Governance 101

More On Governance:

The Crypto Governance Manifesto
Loosely Coupled Governance and Its Effects on Future Economies and Statesmedium.com

The Case for Ethereum Scalability

Understanding What’s Possible & What Comes Next

By Hunter Hillman (Connext), Steven McKie (Amentum), and Eric Olszewski; this post originally appeared on the Connext blog.

Over the past few months, we have noticed a significant number of articles proclaiming the imminent failure and collapse of the Ethereum platform due to its inability to scale and its overall lack of user traction. This is hardly a surprise; with many new emerging technologies, we see a similar hype cycle: the “Peak of Inflated Expectations” is followed rapidly by the “Trough of Disillusionment”. In the case of Ethereum, we have passed the former and are well on our way through the latter.

The concerns raised in these articles are legitimate, but generally ignore the staggering progress being made daily in regards to scalability. No, Ethereum cannot scale to become sort of world computer in its current state. The throughput is low and the cost is exorbitant. However, these issues were anticipated and have been well understood, since before the launch of Ethereum as a blockchain. In this editorial, we will discuss the various solutions which have been created the past few years to address these limitations.

In the midst of the ICO bubble, high transaction volumes crowded the network and raised gas prices. This brought scaling challenges — which Ethereum developers were well aware of and had already begun addressing — though to the media’s attention would make you think otherwise.

While Ethereum scaling may be a brave new world for some, the options for addressing throughput have been on developers radar’s for years:

  1. Scale Ethereum itself to be able to handle the increased transaction load (e.g., Serenity and Casper)

  2. Reduce the load on the main chain by moving the bulk of transactions to a second layer an only using the base layer during transaction settlement (e.g., Payment Channels, State Channels, Plasma, and Sidechains)

“Layer One” solutions like Sharding and Casper have been on the Ethereum roadmap for a few years, but have been plagued by multiple setbacks that have prevented significant progress on the implementation and development front. Even after these improvements, there will still be a need for “Layer Two” scaling mechanisms which provide even higher throughput, private transactions, and lower transaction fees.

Before diving into the various Layer Two solutions, we ask that you think of Ethereum as a global settlement layer rather than a holistic world computer. This means that Ethereum serves to settle any and all transactions which have been conducted off the main chain and enforce value transfers accordingly. It is this use case of the blockchain serving as an unbiased third party for arbitration on which all second layer solutions operate.

At a high level, any layer two solution follows this formula, or some variation of it:

  1. Two or more parties agree to a set of rules by which they will be to join and exit a Layer Two solution.

  2. These parties then encode those rules into a smart contract which requires that each party put down a security deposit.

  3. After putting down their security deposits, all parties can operate between each other off-chain while submitting intermittent updates to the on-chain smart contract.

  4. When one or more parties wished to exit the layer two solution, they will typically provide some cryptographic proof that is an accurate representation of each parties’ remaining security deposit.

  5. There is a challenge period where the proof can be disputed and thrown away. If the challenge period elapses, then the related parties will exit the layer two solution with their updated balances.

Layer Two innovations like Plasma™ and Payment Channels/State Channels, some of which are already processing real payments in production, will facilitate the bulk of Ethereum transactions. Scaling a public blockchain (particularly one with such a robust consensus mechanism) is difficult, to be sure. But it is by no means impossible; in fact, smart contract support and the EVM allow for novel scaling solutions and greater extensibility than other chains attempting to scale with a second layer on strictly UTXO-based scripts, which aren’t as extendable, by design (a different set of trade-offs and benefits, like everything in Computer Science).

DApps’ struggles with user retention are well publicized, but years of scaling research and implementation are enabling the UX and low latency necessary to support high MAU dApps. In short, Ethereum’s Layer Two solutions are nearly ready for primetime (with firms like Cent and Spankchain [NSFW], and others, already serving mainnet users) and are poised to upend the narrative that Ethereum can’t scale. The proceeding sections discuss limitations of highly-touted traditional scaling methods and make the case for Ethereum’s suite of robust, generalizable solutions.

Traditional Scaling Methods: Off-chain and Lightning

Most traditional scaling methods boil down to the observation that many interactions don’t require rigorous consensus to be considered final by the parties involved. For example, if a retailer and a customer agree that a service was rendered satisfactorily in exchange for a specified payment, there’s no reason for third-, fourth-, and fifth-party confirmation to occur. What matters are two factors: (i) certainty that the payer will fulfill their side of the bargain, and (ii) that neither payer nor payee has to trust that a third party will faithfully execute the transaction on their behalves.

This framework allows us to consider off-chain scaling, wherein transactions are conducted off the main blockchain and later settled on the chain. To comply with (i), payers must cryptographically and irrevocably commit to transfer funds; to comply with (ii), those funds must be transferred in a trust-less manner and the transaction must be enforceable on-chain if need be.

These criteria underpin Bitcoin’s Lightning Network, which has (rightly) been the subject of widespread media coverage. Think of it like a bar tab: participants agree to pay small amounts over the course of an evening but only settle up at the end of the night. This is an oversimplification of Lightning Network of course; a more detailed explanation can be found here.

Lightning Network is undeniably good for Bitcoin and holds great potential for Layer Two bitcoin scaling. Due in part to extensive media coverage, Lightning Network is often viewed as a panacea for Bitcoin’s scaling issues. Meanwhile, there’s been a slew of articles hailing “Ethereum-killer blockchains” and opining that Ethereum is incapable of scaling. In a few words, this is wrong.

First, Ethereum is more than capable of scaling payment volume in a very similar manner to Lightning Network. Hashed Timelock Contract (HTLC)-based payment channels are just as feasible on Ethereum as they are on Bitcoin, and in fact Ethereum enables more innovative and user-friendly multi-hop strategies than Bitcoin can, and they can be deployed far more easily.

Because Bitcoin uses an unspent transaction output model (UTXOs), funds must actually be passed utilizing traditional cryptographic messaging methods to conduct transactions (even those off-chain). In contrast, Ethereum’s account balance system allows for simpler and less costly off-chain balance updates.

For example, Connext’s implementation of payment channels (which has been processing payments in production for Spankchain for nearly a few months) uses “threads”, a multi-hop implementation that allows parties to directly pass balance updates amongst themselves rather than relying on hash-locked payment routing. This is a computationally cheaper, equally fast, and equally secure approach that’s likely better suited to many transaction patterns than Lightning Network.

Moreover, complex contract interactions are a bit more overhead intensive to deploy, as bitcoin scripting is somewhat limiting. The UTXO model, though an excellent method for sending/receiving signed transactions to be verified on a blockchain-based network, means you have to augment your scripts for more novel use cases (i.e. escrows). With the generalizability of Ethereum, and the capability to create tokens/registries/non-fungible assets and other community accepted smart contract standards, building modular and interoperable contracts that target the EVM, is simply more seamless.

Generalized State Channels and Counterfactual Instantiation

Smart contract and EVM support on Ethereum enables a wide variety of applications that are not currently feasible on non-Turing-complete platforms like Bitcoin, due to its architecture and design decisions — which lower its overall attack surface, which in-turn puts greater focus on its permission-less P2P payments use case as its most touted feature.

Because Turing-complete scripts are more complicated to execute than simple transactions, however, these capabilities increase the overall congestion on Ethereum (and causes the size of the state to grow at a must faster pace).

We’ve already discussed how payment channels can cut fees and latency for peer-to-peer payments, but Ethereum supports much more complex transaction logic that payment channels don’t address.

Generalized State Channels, however, propose one solution to scaling issues associated with complex contract interactions. Right now, stateful contract interactions that enable the use cases that Ethereum is known for must be executed on the blockchain. The thinking of many Ethereum bears is that as more and more contracts are deployed, function calls will slowly overwhelm the network and drive gas prices through the roof (!!).

Layer One scaling, which has received the vast majority of media coverage, asks how we can accommodate more of these complex interactions on mainnet; Layer Two solutions like Generalized State Channels and Plasma (more on this later) ask how we can move more of these functions off-chain, while retaining the security and integrity we’re provided by the mainnet (given certain trade-offs).

The security of payment channels relies on the ability of each party to “go on-chain” and use a smart contract to adjudicate and rectify disputes. That is, payment channels let two parties behave as though they are transacting on-chain even though they aren’t. Because they have the ability to go on-chain at any time, as the balance updates that they send back and forth carry the weight of on-chain transactions; in a dispute the contract simply decides whose balance update is more recent by polling the mainnet chain. On-chain dispute resolution is costly though in terms of time and gas, so rational actors would avoid this scenario. And, if most state channels are using secure and audited standards, we can create interoperable systems with fast finality, that are bound by the same cryptographic assurances as mainnet interactions, with drastically reduced/almost zero gas cost.

This approach begs the question: if we can incentivize parties to behave as though a simple contract exists on-chain, can we do the same for more complex logic? One strategy is known as counterfactual instantiation. There are a few different implementations, but they revolve around the same principle: state is passed into the generalized framework once at the onset and can be manipulated according to a contract specified (but not deployed) when the channel is opened. Dispute cases are adjudicated by the contract as well. Because participants have the ability to go on-chain and invoke the contract, though, all are incentivized to behave as though it exists.

The effects of production-ready Generalized State Channels that leverage counterfactual instantiation will be two-fold:

  1. Operations involving contracts that can now be counterfactually instantiated and will all occur off-chain; the sheer volume of deployed contracts will decrease relative to the status quo. This will reduce network congestion, benefitting contracts that must be deployed on-chain.

  2. Operations that occur off-chain in Generalized State Channels don’t incur confirmation times or gas fees; this will radically improve user experience and allow Ethereum (as a whole) to accommodate orders-of-magnitude-larger transaction volume.

Connext, Counterfactual, Perun, and others are actively working towards Generalized State Channel frameworks which will directly address the network congestion, user experience, and cost issues that many cite as Ethereum’s Achilles heels. These solutions are enabled by smart contract functionality, are significantly more extensible than UTXO-based scaling solutions, retain the security of the underlying blockchain, and have the potential to unlock the new markets and business opportunities promised by Ethereum. We believe that Generalized State Channels have the potential to be as transformative for Ethereum as Serenity; whether due to poor information accessibility or inadequate publicity efforts, they have not gotten their (rightfully) due attention.

Exploring Lightning Network & Plasma

Lightning
Lightning was the starting ground for UTXO based payment channels, atomic swaps, and more. The work that has been done by Olaoluwa Osuntokun, Joseph Poon, and the entire ecosystem of Lightning researchers and engineers is impressive.

There are a few working implementations of the Lightning protocol and specification, including the LND project (by Lightning Labs, headed by its Chief Scientist, Olaoluwa — written in Go), and the C-lightning project (written in C).

On top of exciting additions like “Watchtowers” (services that watch your payment channels for fraud, and remain online so your node does not have to be — in return for a fee), the Neutrino wallet (Lightning Lab’s experimental light client — also written in Go), there are a slew of other improvements in the pipeline as the Lightning specification and developer community matures and grows.

Some of the hard research is currently focused on: Splicing (partial deposit/withdraw and parallel channel deployment); Wumbo (removal of the channel capacity limit); Multi-Path Payments (breaking a payment into several, allowing for it to be routed over multiple routes — think sharding); Hidden Destinations (public routes for payments to private channels) and more hard work is being done repeatedly at conferences and by independent teams all over the world.

The work by the Lightning team and scaling UTXO-based chains — utilizing some bleeding-edge implementations of crypto — is no small feat, and cannot be downplayed. The often problem is that people seek to directly compare Lightning and Ethereum’s Layer Two scaling measures using similar methodologies that don’t consider the trade-offs and unique capabilities the two varying solutions offer, due to the unique architecture of the underlying root chain (i.e. UTXO model versus the account model in Ethereum).

Plasma
Generalized state channels are far from the only option for scaling Ethereum.
Plasma is a second-layer scaling solution that, in-tandem with state channels, seek to provide additional throughput, and finality, but with some additional trade-offs.

Plasma, which you can think of as more a “proto-chain”, one that seeks to mimic as much of the root chain’s integrity and security as possible, just with a varying cost component, which is typically higher than when compared to state channels (due to replicating more of the main chain’s functionality onto a new substrate above it).

Plasma takes the entirety of the off-chain state, and maintains a fullstate of it, hashed to the root mainnet chain (which has its own set of risk trade-offs, though that’s constantly being improved through additional research).

Though throughput can be greater than the main chain’s, unlike state channels where there is no formal consensus algorithm, Plasma chains can bring their own unique consensus algorithm, complete with its custom blocktimes, too (which possess their own series of trade-offs). Although throughput/finality is not as fast, they are far more permissible and accessible when compared to state channels, as anyone can access the root chain’s state that’s been broadcasted and join — whereas state channels are only available to their agreed upon counter-parties (in most current implementations). And, state channels are no longer available after a channel closes, making them economic machines with finite lifespans, as they are purposely built to be more semi-permanent.

Though in Plasma, since you have to save every state interaction into the root chain, from your child chain, these costs are higher depending on which version of Plasma you opt to implement. With breakthroughs in how to best implement Plasma happening regularly with many teams spread globally, we’re sure a common standard will arise with a sensible set of trade-offs that can be applied to a wide array of use cases.

Power of Interoperable Standards

Non-custodial liquidity and how to most efficiently and securely transmit it in a number of different scenarios involving n >1 participants is an on-going discovery that continues to expand on the emerging science of cryptoeconomics and how various mechanisms operate in adversarial conditions.

ERC standards like ERC-20/ERC-721 make make Ethereum Layer Two scalability tech and dApps more socially secure, given there are community accepted norms and best-practices around which standards to implement for certain use cases. This is especially important when these various standards — which eventually seek to interact with one another fluidly to enable “decentralized finance” — can talk and communicate interoperably, with minimal friction and cost.

Those frictionless interactions and economies that spring up from the novel interoperability between tokens, non-fungible assets, and Layer 2 scalability create further security for the greater Ethereum network, because all participants are now intertwined in complex economic activity on the additional layers above it; all being built on secure standards, that were audited and accepted by the greater technical community.

The importance of non-custodial architecture, combined with the path of least resistance to the most extendable and generalizable functionality, cannot be understated. These are crucial components and primitives to bringing new and novel economic machines to life, that thanks to expense, regulation, and computational limitation, were once thought impossible to implement into the real-world.

Time For A New Narrative

Scaling blockchains is difficult, and Ethereum is no exception. But lionizing “Ethereum-killer” blockchains, or its pre-existing alternatives, all because Ethereum supposedly can’t scale, minimizes the remarkable work that the Ethereum community is doing on Layer Two technology. Layer One solutions are in the works and will likely prove transformative for the network down the road, but Layer Two solutions are hitting the market now.

The narrative that Ethereum can’t scale and the idea that Layer One solutions are the only plans to scale the network are tiresome and are being actively disproven in production environments on a daily basis. Today, Ethereum is a slow and unstoppable platform for programmable money; the potential of such a system is self-evident. An entirely novel financial system could be built on top of Ethereum, and Layer Two solutions will pave the way for radical new markets that leverage this decentralized financial stack.

Value transfer, governance, new kinds of markets and incentive structures, community coordination, and even proper implementation of tax policy are possible on Ethereum. Ethereum developers see this future and are building the dApps to make it happen. Other Ethereum developers are building the protocols to make the network usable at a large enough scale to usher in that future.

This editorial is not intended as a knock on alternative blockchain implementations, many of which are pushing forward the bleeding edge of cryptographic research as stated prior. Nor is it a case for ICOs, shilling, and misguided hype. Rather, it is a case for Ethereum scalability, for a decentralized economic future that uses the Ethereum blockchain as a settlement layer and facilitates the bulk of transactions with Layer Two technologies. It is a case for the Ethereum that we see, and that we hope will get its due in the public eye, and see the light of day.

Subscribe to our Newsletter to get this in your inbox:

Amentum GP Newsletter
Essays and analyses from the Amentum GP team.amentum.substack.com

State Channel Resources & Guides:

General Discussion and Articles:
ETHResear.ch
LearnChannels
Github Curated Resource List
Lightning Ecosystem Breakdown

Getting Started with State Channels:

State Channels For Babies: Part 1
State Channels For Babies: Part 2
State Channels For Babies: Part 3

State Channels for Developers:

The Redemptive Greed That Will Drive Decentralization: Part 1
The Redemptive Greed That Will Drive Decentralization: Part 2

State Channels For Dummies: Part 1
State Channels For Dummies: Part 2
State Channels For Dummies: Part 3
State Channels For Dummies: Part 4
State Channels For Dummies: Part 5
State Channels For Dummies: Part 6

Loading more posts…