I worked at the Ethereum Foundation from May 2021 until April 2026. During those 5 years, I focused on coordinating core development, funding via Protocol Guild, and researching Ethereum’s political economy.

This article will provide a personal perspective on the EF, alongside some of the urgent challenges the ecosystem needs to face. These include the difficulties of distributing legitimacy as well as the impending protocol funding crisis. I argue that these threads point towards a necessary reset of the social, political, and economic contracts between Ethereum stakeholders. Only then will we be able to unlock an effective institutional succession.

Subtraction and legitimacy

Over the last 7 years, the Ethereum Foundation management and Board have developed an organizational and ecosystem philosophy which it calls "Subtraction". If the concept is new to you, here are the earliest and latest incarnations:

• EF Spring Update, 2019: "Following a philosophy of subtraction means resisting the natural tendency of organizations to grow and accumulate value within themselves, and ensure instead that this value is created outside the Foundation in the broader Ethereum ecosystem."

• EF Mandate, March 2026: "Our goal is to reduce the Foundation's relative influence over time. This is not retreat or sabotage. Subtraction is rather a process of ensuring Ethereum's maturity... robust enough to outgrow and outlast us."

In my view, the policy has been most successful in broadly communicating that the EF is not interested in being the sole center of power, but less successful in specifying the contours of what it won't or can't do. As a consequence, the ecosystem has struggled to bootstrap the initiatives to structurally address these gaps. While I respect the aspiration to avoid the accrual and abuse of power, it seems that legitimacy has a stubborn tendency towards power-law pooling. Meaning, there is still only one organization with the magnitude and blend of legitimate aspects as the EF has. We can see the tension between the policy and the sum of meaningful vectors which the org still retains:

• the Ethereum Foundation name and brand trust, accumulated over more than a decade of protocol stewardship and consistent, non-extractive behavior

• Vitalik's continued affiliation with the org and Board, which carries unique weight in the eyes of builders, users, and institutions worldwide as inventor, co-founder, Chief Scientist

• being the neutral non-profit which received the ICO funds and the premine

• ownership of comms and media assets like ethereum.org, the @ethereum handle, ethereum.eth, youtube channels, intellectual property like logos and trademarks, events like Devcon and DevConnect

• historically, direct employment of roughly ~25% of active core protocol contributors, and many of its key researchers, who are employed solely for the good of the protocol and are not exposed to diverging interests

• historically, a treasury with a sole purpose of supporting the Ethereum ecosystem, which provided material support for many core teams

I provide this list simply to point out the inherent challenges around distributing legitimacy. Even as the stated policy of the org, and with the follow-through of its staff: there is an institutional inertia, narrowness of purpose, and a set of artifacts which always act against it being fully realized.

Legitimacy is downstream of repeated competency, which is itself downstream of resources. The treasury was the ultimate unlock of a good portion of the EF's legitimacy, and it is the vector changing fastest.

The Funding Crisis

The most practical and unavoidable funding outcomes of Subtraction have begun to take effect over the past 12 months:

• A finite and increasingly constrained treasury: The EF has exhausted much of its ETH treasury to bootstrap the ecosystem the last 10 years, even coming close to completely running out in the early days. This was critical funding in an important period. To better manage outflows of the remaining funding, they announced a treasury plan in June 2025 to reduce spend, ensuring the org stays solvent in the medium term. The plan describes a glide path from 15% annual spend to a 5% endowment-level baseline by 2030. The next EF transparency report, promised to be released this year, may give more information. The ongoing execution of this plan will continue to have ripple effects throughout the ecosystem.

• The expiration of the Client Incentive Program: the CIP, a major 4-year effort to fund client teams via staking, expired in April 2026. No replacement appears to be forthcoming.

From recent conversations across all core development, there is a risk we will enter a slow-burning funding crisis within the next 3-9 months. While it may appear as a one-time episodic gap, I believe it is symptomatic of larger structural issues related to gathering and allocating funding. This risks damaging our institutional capacity: the hard-won ability to orchestrate industry-leading feature and maintenance delivery across +10 clients, research, coordination teams. This capacity to securely deliver complex features is only maintained by significant, consistent funding: roughly $30mm annually across a variety of increasingly constrained sources. When compared to the shared resources this funding produces today, and the long-term ambition of the project, this is quite a small cost.

Without continuous funding, we lose people with critical context built up over years, fall behind on looming challenges like quantum computing or scaling, and ultimately risk mainnet's reputation for reliability. We cannot assume contributors will still be available when funding conditions improve, let alone account for the cost to morale for those who remain. I believe we are underweighting the risk of this underinvestment in continuity. When we register the resulting symptoms in 12-18 months, the damage will be much harder and more costly to reverse.

Finally, protocol changes are always more complex and take longer than expected, even when accounting for unknown unknowns. Whatever your perspective on the shape the protocol will take in 5 or 10 years (and the maintenance beyond), there is a risk it becomes an unfunded mandate. We should not accept this ambiguity.

Succession Planning

For reasons both practical and philosophical, the EF will not be the prime steward for Ethereum's next 10 years. Vitalik’s recent post says it most explicitly:

“Fiscally, the EF was originally designed to fulfill a limited work scope defined in the token sale docs and other pre-launch materials (building the chain software; getting through Frontier, Homestead, Metropolis, Serenity), which was fully completed in 2022; it was not designed to be an eternal steward.”

There is no subtext to read into, so I will take him at his word. It is time for new institutions to bring Ethereum to the world. We have an enormous amount of work left to be done to scale the chain, harden its guarantees, and make it more accessible - let alone the crucial regular maintenance the network requires.

Who should we allocate institutional legitimacy to as this succession materializes? I believe the urgency of this transition calls for an earnest exploration of new social, political, and economic contracts between ecosystem stakeholders. These should consider:

1. recognition and active stewardship of each interdependent network resource: software (EVM/clients), network (Ethereum), and asset (ETH).

2. scalable, accountable, neutral funding mechanisms to ensure we keep the critical shared resources listed above thriving. Legitimacy is downstream of resources. Every funding mechanism proposed to date has tradeoffs, ranging from benign to disqualifying. I will be writing more on this design space, including in-protocol funding, in the near future.

3. the pursuit and celebration of broad adoption as a first-class citizen: we should aim to create the most robust network resources for the broadest set of public beneficiaries. The EF's Mandate explicitly subordinates adoption to CROPS principles, leaving this as an open gap. We should have an eagerness to engage with the complexity and nuance of our users, to meet them where they are, and bring their constituents into the orbit of our values in protocol form: self-sovereignty, self-determination, human flourishing.

Only by building on the work of the stewards who came before are we able to imagine the necessary new institutions. This process will require your voice, to ensure they are designed and held to the highest standard. The Ethereum project, and its potential as a World Computer, demands our collective ongoing commitment to excellence and ambition.

I hope we will rise to the challenge, reject the reflexive pessimism natural to this time in our industry, and remember to make no small plans.

ethereum commoditizes¹ ² institutional capabilities³

1. i use commoditization in a positive, abundance frame here: where a previously scarce/costly/bespoke resource becomes abundant/cheap/accessible to anyone with internet. eg. the same dynamic that commoditized compute (cloud) and distribution (internet) will now be repeated for institutional/economic coordination.

2. also note that this does not mean there is no differentiation/categorization within this commodity class: ethereum provides best-in-class aggregate resource package: settlement, liquidity, security, uptime, EVM tooling network effects, reliability, protocol specs, jurisdictional distribution, etc

3. guarantees/outcomes/capacity. institutions exist to solve coordination problems across time and space eg. that this action will reliably take place within this timeframe. Governance, property rights, contract enforcement, capital allocation, monetary policy are examples of capabilities that were once scarce or only contained within classic institutions bc of the high cost to bootstrap and maintain legitimacy (+ enforced by inertia and the network effects of scale)

there are parallels to the idea of "infrastructural leapfrogging": seen in classic cases of developing nations bypassing the traditional copper landlines in favor of cell/satellite connectivity. or not using power grids in favor of microgrids/renewables. NOTE: these technologies are all still useful to developed countries

further questions:

• what entities might want to control/steer/capture the production of the commons-based commodity? how would they do this? what benefits could they extract?

• what would be the value of the central native asset $ETH of this institutional substrate? what is the marketcap of institutional legitimacy?

• what, if any, are the resulting externalities?

• what new organizational forms will result from flooding local markets with abundant commoditized legitimacy in places that previously had an undersupply?

• where has this dynamic previously materialized? (credit rating agencies, google reviews + ratings)

• when institutional trust is costless, what benefits/agency will be returned to the individual? or orchestrated together for collective benefit?

• how might institutional stability be injected into contexts/countries/communities that have not been able to establish these traditions?

see also: @0xstark's hardness frame https://paragraph.com/@josh-stark/ethereum-s-distinctive-property-is-hardness

and also @js_horne hyperstructures https://zine.zora.co/issue/intergenerational-dynamics/hyperstructures-redux

and also @arjunbhuptani's talk on institutions, anarchism, utilities, why are we here:

Thanks to Carl, Cheeky, Jonas, and Tim for review and comments. Cover image from the NOAA page on corals - “most corals are made up of hundreds to hundreds of thousands of individual coral polyps.”

1. “Public Goods” vs “Dependencies”

2. Funding Round Tradeoffs

3. Reflecting on OP Retro Round 5

4. Possible modifications for rounds

“Public Goods” vs “Dependencies”

In the Ethereum ecosystem, the term “public goods” has been applied to objects of widely varying themes, scales, and impact: niche media, podcasts, free software, local events, national regulatory reform, global climate advocacy, user safety, products & applications, even fun side projects. We have failed to develop standards of rigor for the use of the term. When it applies to everything, it describes nothing. True public goods are actually quite uncommon. Let’s re-anchor to the actual definition: “a commodity or service that is provided without profit to all members of a society”. We have neglected the “all members” provision of the definition, which implies scale:

• Is this resource available to and depended on by a broad public outside of its originating niche? simply being open source or having a feature limited free tier is not sufficient to qualify

• If this resource stopped existing, how many people would be negatively impacted?

We can sidestep ambiguities about the meaning of "public goods" by reframing the discussion around "dependencies" instead. “Dependency” is better suited for the Ethereum software ecosystem: crucial bits of infrastructure (eg. networks, software, libraries) not directly maintained by an actor. Consider this dependency ordering:

1. Applications: User-facing, built with libraries and smart contract languages, which consume blockspace provisioned by;

2. L2s: which rely on the;

3. Ethereum L1 network for settlement/censorship resistance guarantees, which emerges from many actors running instances of;

4. L1 client software, which is maintained and improved by hundreds of peers.

Protocol Guild was created to provide funding for the peers mentioned in #4, who are of existential importance to Ethereum's entire ecosystem, enabling all applications and activities that operate on top of it. And yet, funding for this work falls far short of matching its scale and impact. When we do encounter large-scale shared resources, we are not good at recognizing their scale/impact and funding it proportionally.

Funding Round Tradeoffs

Round-based funding mechanisms are a mainstay in the Ethereum ecosystem: Gitcoin, Optimism, Octant, CLRFund, DAODrops, Giveth, etc. Recurring rounds are good for building consistency norms, and allowing breaks where the operating team can iterate.

But they come with tradeoffs, which I first wrote about in 2021 around the initial Protocol Guild Pilot:

1. attention games

2. eligibility scoping

3. high expectations of evaluators

4. atomization incentive

Recurring rounds demand attention from allocators/evaluators/funders and beneficiaries alike. Participating projects are forced to compete against each other, dedicating time and energy campaigning or sprinting to fill out applications - scarce resources which should ideally be put towards the work that they are seeking funding for. “Popularity contests” in Vitalik’s recent words.

Eligibility needs to be broad enough to attract applicants, but acceptably narrow enough to satisfy funders (large projects funding Gitcoin, OP Foundation giving OP), allocators (badgeholders, QF matchers, GLM lockers), round operators. Round operators have some incentive to build and maintain mindshare - not necessarily to develop or enforce a strong definition. If you can’t get projects to show up, it’s harder to claim legitimacy for the program. Perhaps in response to community recognition of the section above, round-based funding mechanisms have experimented with the permissiveness of their eligibility:

1. Gitcoin started using narrower thematic rounds, where projects can be evaluated against those with similar profiles. However, they maintain a broad-based, “big tent” approach to eligibility and the definition of Public Goods.

2. Optimism added categories in Round 3 to reduce the evaluative bandwidth expected of badgeholders, but in practice projects could select multiple categories so it was less useful. In this round there was community pushback about the presence of large VC-funded projects. In response, operators reminded the community that eligibility made no consideration for the origin of funding. More subtly, people switched from using “RetroPGF (Retroactive Public Goods Funding)” to “Retro Funding”. Round 4 saw the shift to standalone rounds for specific categories, the first being “Onchain Builders”.

3. Octant caps the number of projects per round (currently 30), which forces GLM allocators to narrow in on what’s important and not spread funding over a long-tail of varying applicants. This choice is unique among these three programs. However, the program definition of public goods is still only loosely enforced by the Octant team.

Unreasonably high expectations are placed on the evaluative capabilities / context familiarity of allocators (eg. QF matching funders, badgeholders, GLM lockers). This “wisdom of the crowd” becomes a proxy for “public goodness” / “value to the commons” / “value created”. Allocators usually commit to this on top of their existing full-time engagements, and are asked to evaluate the niche technical projects under consideration. When the pool of allocators is relatively small or known, this opens up the possibility for public/private lobbying. Vitalik’s “popularity contest” comment also applies here.

Finally, by capping rewards per project, or by failing to make allocators aware of the size of the beneficiary set (i.e. number of recipients), these programs can incentivize atomization - the artificial separation of commons-scale resources into more and more granular forms. Companies, teams, projects, or individuals seek to represent themselves separately, outside of their collaborative contexts, because it is the rational strategy to maximize their funding. This increases the bandwidth expected of round operators (who have to conduct the initial eligibility filter), allocators (they have to review more projects), and potential beneficiaries (more time spent filling out applications for multiple projects or individuals).

Reflecting on OP Retro Round 5

The idea of “incentivizing atomization” was especially apparent in the most recent OP Retro Round 5. For a data driven overview, please check out Carl’s excellent piece: Opening up the ballot box (RF5 edition). As he states “The reward function is a game, and players will optimize for it.” The outcomes suggest a number of possible causes, which are outlined below.

Initial eligibility & atomization

The optimal approach was to claim max impact for the smallest number of beneficiaries, or split large projects into smaller ones. This graph illustrates the benefit clearly:

To further emphasize what the above graphs are showing us, let’s rank the annotated projects by how much OP was received per person:

1. Ethereum POS Testnet

   1. 1 beneficiary

   2. 1 project

   3. 52k OP / person

2. Independent Ethereum Client Contributor

   1. 1 beneficiary

   2. Contributing to 5 projects

   3. 37k OP / person

3. Geth*

   1. ~10 beneficiaries

   2. 1 project

   3. 23k OP / person

4. Protocol Guild

   1. ~185 beneficiaries

   2. 29 teams/projects

   3. 1k OP / person (vested over 4 years)

There is a clear funding discrepancy when considering the number of beneficiaries per project and the resulting OP per person.

* While it’s true that the OP-stack has a strong dependency on Geth software, the broader L1 context should be considered. There, stability and resilience is achieved only through client diversity - how strongly should this be surfaced in the allocation?

Legibility is not impact

Badgeholders were asked to evaluate the 9 months of work since the end of Round 3. In March 2024, the Dencun upgrade was shipped to Ethereum mainnet. Network upgrades require extensive coordination between hundreds of core contributors: building rough consensus on EIP feature sets, implementing and testing, releasing software, fuzzing and testing, testnet upgrades and more. The Dencun upgrade included a new feature called EIP-4844 (in development since March 2022), which passed on incredible 10-100x cost reductions to users of L2s that adopted it.

If we use Protocol Guild as a proxy representative for many of these contributors, the impact provided to Optimism is massive. But the work benefits differently depending on the level of legibility or context it is presented through. The same work was valued 37x (Independent contributor) and 52x (POS Testnet) more impactful when shown from a higher level representation: the commons guild.

Stewardship is less legible - for good reason

It’s also possible that badgeholders define impact as something distinct. However, the ultimate impact only emerges from the consistent, cumulative, quiet grind to maintain software over long periods - not any brilliant breakthroughs by a genius team in isolation. Protocol Guild bundles together individuals for funding in the same way the shared infrastructure is produced. (Read more here - “Protocol Guild: a funding framework for the Ethereum commons”.)

An illustrative case study can be found in the beneficiary backlash to the EIP-4844 contributors collection from March 2023. Here, OP Round Operators tried to celebrate a shortlist of contributors to an anticipated Ethereum protocol feature with additional funding (admirable!). However, the operators were rebuffed by the same people. The list reflected individuals who had worked directly on the feature, but not any of their colleagues which had done other necessary but less visible work: fixing bugs, improving node performance and accessibility, optimizing sync code, creating the spec, running devops infrastructure, testing the implementations, etc. For that reason, many beneficiaries asked that any allocation be forwarded to a mechanism better suited to recognize collective work: Protocol Guild. The design of the round plays a big part in whether this strategy is optimal or not.

Misconceptions about levels of PG funding

There is a lot of work yet to be done to bring a scalable, usable, and secure Ethereum to the world. The likelihood of the protocol achieving escape velocity is most possible when it has a broad, competent, and stable set of maintainers. This scalability, usability, and security expertise has ripple effects out into the broader Ethereum Mainnet and EVM ecosystems, Layer 2s, and DeFi projects. Core contributor stability is most likely to happen when the positions can offer incentives which are:

• Competitive: Ethereum L1 maintainers are undercompensated relative to the industry. Protocol Guild’s actionable, driving motivation is to set a compensation floor for this work.

• Consistent: Through the industry’s boom and bust cycles, stability is cherished where it can be found. All donations to Protocol Guild are vested by default over 4 years though immutable smart contracts which cannot be turned off or clawed back.

Over the next 12 months, Protocol Guild will only provide $51k to the median member (as of Oct 30 2024 - Dune Dashboard). We do not believe this is sufficient relative to the existential importance of the work, and so continue our fundraising and advocacy efforts to increase the agency of core maintainers.

Possible modifications for rounds

We assume that dependency funding rounds are interested in efficiently and accurately rewarding impact within a set of beneficiaries. Incentivising “aggregation” (that is, applicants not being incentivised to represent themselves separately outside of their collaborative contexts) would;

• Significantly lower the overhead/bandwidth required of operators/allocators/evaluators and participating beneficiaries;

• Avoid the emerging equilibrium where beneficiaries try to game the eligibility framework with multiple projects or where individuals atomize their work;

• Reduce the technical domain expertise required of operators and allocators (which they may lack), because aggregation forces a level of self-curation by applicants, serving as an initial eligibility filter.

Here are a few thoughts on how to internalize the benefits of aggregation to proportionally fund large-scale common resources:

Remove caps on allocations

• A well-meaning guardrail intended to limit the domination of a particular project, but which artificially suppresses the average project size. Bigger is better for reducing overhead.

• Tradeoff: a misallocation by badgeholders could be compounded, but we already expect too much of them, so not much of a departure.

Give special consideration to projects with a large number of beneficiaries

• Add a new category of beneficiary outside of the Retro format which has guaranteed access to a stream of resources, e.g. 1% of new emissions or Superchain inflows (in the spirit of PG’s 1% pledge).

• Tradeoff: This assumes the method for counting the number of beneficiaries/project contributors is trustworthy, alongside significant penalties for misreporting.

• Tradeoff: recipients from this tier need to be explicitly added or removed by badgeholders via governance.

Cap projects per round

• True shared goods are quite uncommon. This forces allocators to choose “what really matters” and incentivizes baskets of applicants.

• Eg. Octant rounds are limited to 30 and require GLM lockers to choose any additions to each round.

• Tradeoff: some marginally positive projects may find themselves on the other side of the cutoff. Places more expectation/pressure on the capability of allocative/curative mechanisms.

Explicitly weight the number of beneficiaries in the allocation formula

• Built into allocation: have badgeholders allocate “OP per contributor” (instead of a total OP amount for a project). This amount per contributor is then multiplied by the self-reported number of contributors to produce the amount per team/project.

• Lighter-touch: only surface the number of beneficiaries on each profile. Badgeholders have this available to inform their decisions, but are not obligated to use it in the final allocation (whether “OP per person” or "total OP per project”). This approach could also be surfaced in ranking tools like Pairwise.

• Tradeoff: This assumes the method for counting project contributors is trustworthy, alongside significant penalties for misreporting.

I acknowledge that these suggestions come with their own challenges. While they are deeply influenced by my experiences building and soliciting funding for Protocol Guild, the ideas could simplify round operations for all participants. My observations of Optimism, Gitcoin, Octant are surfaced here only because they are in the arena, funding the good fight.Looking forward to feedback, thanks for reading 🙏

***************************************

Commons are productive systems which create resources for collective benefit. Some examples from the broader digital commons, include Wikipedia, Linux, and Ethereum.

In Ethereum, sets of peers produce three resources: a blockchain network, an asset, and media. The way they are produced matters to their integrity and fundamental characteristics. Taken together, these resources create a larger valuable whole we call Ethereum. These interwoven resources can be extended outside of their original production contexts, but still within the bounds of the broader commons.

Neither peers nor external capital can make complete ownership claims to these digital resources without destroying their integrity. However, open governance processes can also be acted on from a distance (in contrast to natural physical commons). In light of these conditions, capital seeks influence within the frameworks of production themselves.

1. network

• mainnet, Ethereum Layer 1, L1, chain state, history, forks, L2s

• protocols: fork choice, EIP-4844, p2p gossip, syncing

• Anyone can use or operate Ethereum network infrastructure. Each participant running a node independently chooses which protocol version to run, resulting in an emergent set of actors who agree to be bound by the same set of rules. For example: an open validator set alongside credible neutrality norms make it more difficult for internal or external actors to fully own the entire consensus process. However, value can still be extracted by purchasing agency, (e.g. Proposer-Builder Separation), or by encumbering the Proof of Stake mechanism (e.g. restaking, liquid staking tokens).

2. asset

• ether, ETH, wrapped, restaked, bridged, LSTs

• protocols: POS issuance, EIP-1559 burn

• Anyone can purchase, transfer or hold individual units of Ether as a private good. However, because the network and the software define emergent features of the asset, it cannot exist outside of either context. Actors interested in influencing its supply, characteristics, or uses must engage with the other forms of resource production.

3. media

• software, specs, EVM, p2p code, research, All Core Dev call transcripts, Ethereum Improvement Proposals (EIPs)

• protocols/norms: open source software, permissive licensing, public by default, open governance,
rough consensus,
collaboration

• Anyone can use, modify, or contribute to technical media. The production of these artifacts are structured by technical, legal and social protocols. The permissive licensing of open source software (OSS) sidesteps the restrictive norms of commercial software, carving out a space for software media to exist on its own terms. This resource is inclusive of artifacts of the governance processes. When boxed out of media ownership, capital surfaces extractable influence by funding and directing the labor of those producing the media. Norms of openness and working in public are helpful to curtail capture, but can never fully prevent it.

Comprehensive funding information across all nonprofit and for-profit entities engaged in this media production is hard to come by, but necessary for community self-assessments. The community and labor engage, but their agency could be enhanced.

I believe that funding streams should be passed through simple protocols. They should be transparent, legible, sustainable and accountable. They should be held to the same standards of rigor that we expect of network protocols.

Protocol Guild is one such candidate funding protocol. There are a few things which make it unique in the landscape of protocol funding mechanisms (1):

1. narrow mandate

   1. just focused on funding - does not direct work - not involved in Ethereum governance, upgrades cycles

   2. Read more here

2. broad self-curation

   1. 181 members come from across all of L1 core development (client teams, research, coordination, support). the most knowledgeable people curate the membership

   2. The watershed, not one of the rivers

   3. See the eligibility frameworks and eligible projects here

3. members are individuals

   1. funding doesn’t flow to teams, companies, or projects - we wanted members to represent themselves and retain their agency

   2. See the member list here

4. 4yr onchain vesting contract

   1. this list of members is published onchain: immutable vesting contract means transparent, legible assurances for funders and members

   2. Smart contract architecture here

   3. Comprehensive funding Dune dashboard here

5. designed with time in mind

   1. Regular curation and vesting are crucial recognition that Ethereum is a resource commons being stewarded over time: in the same way, our funding streams should be allocated with that in mind. the Ethereum of 2015 is different from what we have today, just as it will look very different in 2035.

   2. per member allocations are time-weighted by months active - read more

As a mirror to our resource production, the mechanism assembles a collective whole capable of providing benefits which would be inaccessible to maintainers seeking funding on their own. Vested funding and deterministic member allocations - both onchain - create legibility and certainty for both funders and beneficiaries alike.

The challenges of capture and influence are not unique to Ethereum - see other digital commons precedents like Linux and Red Hat (2). More broadly, the history of natural commons is rife with examples of exploitation until exhaustion - often by return-seeking capital. These are incompatible logics: extract value for private gain VS cede value for shared benefit. In pursuit of its own ends, capital destabilizes the healthy equilibrium of commons management.

It's worth remembering that some historic natural commons have survived despite inhospitable contexts. Existing outside of popular awareness, continuously sustained - some for thousands of years - Inuit fishing practices (4000 years), Ifugao rice terraces (2000), Dehesa farming system (2000). In the same way, blossoming digital commons should practice the posture and develop the mechanisms necessary to ensure uncaptured longevity.

1. In another article I plan to explore the theoretical and tradeoffs bundled by in-protocol funding ie. minted de novo by the software rulesets which set how validators/miners are compensated for consensus participation but directed instead to an onchain or offchain allocation mechanism (foundation, for-profit, DAO). Our goal with Protocol Guild is to construct it robustly enough that it would be capable of taking in-protocol funding, but then scale it through opt-in norms like the 1% Pledge to never have to push that lever.

2. Capital and enclosure in software commons: Linux & Ethereum

****************************

BONUS - reading that has informed the development of Protocol Guild and this article:

• systemantics: the systems bible - John Gall

• Ethereum is game-changing technology, literally - Virgil Griffith

• The moral character of cryptographic work - Phillip Rogaway

• Meditations on moloch - Scott Alexander

• Incorporating the Digital Commons - Benjamin Birkinbine

• Seeing like a State - James C. Scott

• Rivals: How Scientists Learned to Cooperate -  Lorraine Daston

• Emissaries guide to worlding - Ian Cheng

• One from Many: VISA and the Rise of Chaordic Organization - Dee Hock

• The viable system model: a briefing about organisational structure - Raul Espejo

• Speech by Senior Minister Lee Kuan Yew on Ministerial Salaries in Parliament

Thanks to Tim beiko and Josh Davis for review

Over the last 2.5 years, I helped to launch the initial version of Protocol Guild and steward it toward its current state. On seeing its success, many people have suggested that the model should be reproduced for other Ethereum software stacks. While I agree this should be explored, I hope that people undertake the efforts with the right context and caution.

Whether you’re already familiar with Protocol Guild or not, please read these two links first. The rest of the post will not be as useful without their information.

• the docs

• So - you want to start a Guild? (April 2023)

This post covers:

• Soil for the seed

• Recommendations for other potential Guilds

  • Case study: Dev Tooling Guild

  • Case study: Basic Infrastructure Guild

Soil for the seed

These are my personal reflections on some of the unique preconditions which were important in shaping the Protocol Guild’s initial eligibility, ongoing governance, and eventual funding. I want to stress that these may not all be present in other contexts, and therefore, any other experiments will require different approaches.

To start, there are existing shared community values/understanding:

• the Ethereum L1 is still evolving

  • the maintainers already work together daily in a high-trust environment, which makes self-curation possible

  • the Ethereum L1 requires full-time engagement, which makes it much easier to determine who is contributing

  • the community understands the importance of funding this work, which is upstream of a lot of the user/protocol applications (eg. scaling, censorship resistance) all projects built on Ethereum have a dependency on the network, and an incentive to ensure it is well maintained.

  • L1 political/social credible-neutrality of software production is important. client software infrastructure can’t/shouldn’t be monetized in the same way a dev tooling or app-level project could be

• the L1 security/robustness assurance requires there to be many differentiated clients: helps to avoid extreme contention around adding new eligible projects. (ofc discussion around members/eligible projects does occur and needs to be facilitated, and eventually may hit a limit)

• L1 stewardship is highly specialized

  • community understands this institutional knowledge is important to retain/fund long-term. protocol devs are in very high demand, should be compensated on the risk/reward/”value to the commons“ curve

  • very high threshold for producing relevant work narrows the curation scope in terms of eligible projects, makes it easier to determine per-member eligibility

Other attributes which helped the mechanism:

• L1 protocol can be outlined in specifications

  • Execution spec (EELS), consensus spec, Execution API

• this is a very helpful reference for scoping eligibility: what bits of software implement the spec, what projects interface with the spec? see diagram below:

• L1 protocol is logically centralized (single state machine)

  • helps define eligiblity: what helps the chain come to consensus?

  • clear infra dependency for funders e.g. L2s

Recommendations for other potential Guilds

Here are some tips for anyone considering whether a Guild-like funding mechanism might be useful for their particular domain.

• eligibility drives the mechanism

  • eligibility is the mechanism’s purpose codified into a set of rules: “what are we incentivizing” - it is easier to form this around an existing group of people, rather than pursuing software projects that don’t exist yet and trying to bootstrap them

  • it might take a long time (3-6 months) to build initial consensus on boundaries. be laser focused on making eligibility as explicit as possible early on, well before raising any funding. not taking appropriate time to do this early may produce issues later

  • membership should be broad enough to bootstrap legitimacy, but not overly broad so that consensus is impossible or there is too much overhead to operate it

• talk it out

  • the membership must develop the ability to talk clearly about the eligibility framework - it may need to be expanded or adjusted as part of the learning process. dependence on a facilitator/bootstrapping party for too long will be unhealthy

• coordination is crucial

  • there need to be high-context individuals driving the effort, moving towards milestones, advocating on the group’s behalf - at least for the bootstrapping process

• keep it simple

  • try to design the simplest (but still internally consistent) eligibility framework possible. accommodating too many edge cases early on make it harder to adjust if needed

• scale slowly

  • run a time/funding bound pilot (1 yr/ $Xmm). if operators pump a mechanism full of funding it’s not suited to handle, it’s liable to implode

  • consistency over time >> legitimacy >> funding - dont rush/switch the order

• new levels, new devils

  • as financial incentives available through the mechanism increase, new and unexpected dynamics may emerge. e.g. between commercial entities and the software projects which they host

  • member orgs may still fundraise in the same rounds that the overarching Guild mechanism participates in

  • if the effort seems to have legs beyond an initial Pilot, will likely need a legal entity

Of course, Guilds could probably be bootstrapped even with one or more several of these not being met - much of it comes from my experience with Protocol Guild.

Case study: Dev Tooling Guild

I believe this would be the next best adjacent space to consider creating a Guild-like funding mechanism for. There’s an existing group of maintainers working on dev tooling that requires relatively high context to contribute to. Here’s a rough pass at a possible high level eligibility:

• libraries

  • web3.py, web3.js, ethers.js, web3j, viem, alloy, nethereum

• dev frameworks

  • hardhat, foundry, remix, ape

• languages + compilers

  • solidity, vyper, fe, yul, yul+

• Other

  • Sourcify

Please do not reference this list as gospel if you are involved in efforts to start this guild, it is simply an informed guess.Once you have a high level framework set, you have to decide individual eligibility.

• How would a maintainer role be defined for the individuals working on the projects above? Full-time effort equivalent? Or more abstractly to accommodate the range of projects?

Open Questions

• what would be the guiding rationale for why this org and the specific eligibility is needed?

• naming matters in memetics/communicating scope quickly. DTG might not be the best to do this

• there is no spec to help define the edges of eligibility

  • when has a language/dev interface reached broad enough adoption to be considered? Protocol Guild requires new clients to meet specific requirements before being considered for eligibility

  • and the inverse, how to decide when old tooling gets surpassed by new tech? this is also an open question for Protocol Guild.

• As with Protocol Guild, some software is coupled with a commercial/capital entity that leverages the free product for its own ends. How should this be considered, at all, in the scoping of the high-level/maintainer eligibility?

• This list is centered on the EVM - how does this fit in the multi-VM L2 world? (both in terms of deciding scope and potential funders

Case study: Basic Infrastructure Guild

see VBs recent idea and my response here:

Open Questions

• no “infra” spec to help define the edges

• trying to wrap too many software categories into the same mechanism

  • bridging infra is very different from contract languages

• overly broad mandate

  • incentivizing tokenless products is a very different goal than providing ongoing funding to existing projects

• how many light-clients? which zkEVMs?

I don’t mean to pick apart a tweet length idea, but these are the sorts of questions that come up for me when thinking about the idea.

Hopefully this was helpful to any prospective Guild summoners! Reach out if you have questions, or follow the Guild account. ⛓️🛡️

The views shared here are my own and may not necessarily represent those held by Protocol Guild members or the Ethereum Foundation. Cover image from Spirited Away (2001).

If you prefer to listen, audio versions can be found here:

• Linux & Ethereum: Commoning vs Commodifying (Sept. 2023) Protocol Berg

• Safeguarding Ethereum’s Soul: Protocol Guild and governing the digital commons (Nov. 2023) The Blockchain Socialist

• Capital and Enclosure in Software Commons: Linux & Ethereum (March 2024) Summer of Protocols

I take inspiration from the work of Benjamin Birkinbine, including Incorporating the Commons and “Commons Praxis: Towards a Critical Political Economy of the Digital Commons”. Thanks to Josh Stark, Joshua Dávila (The Blockchain Socialist), Mike Neuder, Tim Beiko, Anna Thieser, Alex Stokes, Davide Crapis, Scott Moore, Cheeky Gorilla, Kevin Owocki, and reviewers Y + C for feedback.

Please DM (farcaster, twitter) with any thoughts.

Outline

1. Common and commons

2. Software commons case studies

   1. Linux

   2. Ethereum

3. Conclusion

1. Common and commons

As Giuliani & Vercellone (2019) argue, common is a mode of resource production in the same way capital is. These modes have “internal logic[s]” (Wright, 2020) which animate productive entities (eg. commons, companies). The allocation of benefits produced by the entity determines which mode it aligns with:

• Common asks: How can the benefits/assurances/surplus value be distributed to the largest public?

• Capital asks: How can the benefits/assurances/surplus value accumulate to private entities?

The standard framework for comparing the resources produced by these systems considers two main characteristics:

• Excludability: can anyone be prevented from using the resource?

• Rivalry: does someone’s use of the resource prevent another from using it? This term is also known as “subtractability:” to what degree someone’s use removes a portion from the total available.

Software (e.g. Linux, Ethereum) is a Symbiotic Good:

• Anti-rival: From Nikander et al (2020): “For many digital goods, their real (social) value … increases the more they are used, in stark contrast to material goods, whose value almost always decreases as they are used and consumed.” As a software protocol is more broadly adopted, each user benefits from a wider array of associated services, products, shared local knowledge. As digital artifacts, the cost to produce one additional unit is negligible (i.e. approaches a marginal cost of 0).

• Non-excludable: Open Source Software (OSS) licensing enables actors external to the production process to use, modify, and suggest changes to the software. Different licenses on this software can create different levels of excludability, but the overall expectation is that others will use and modify the software, and that the code is publicly accessible (aka “source available”).

Commons

Each commons is a local manifestation of the greater common mode logic. Here’s my framing for how they produce and allocate resources:

Peers

A set of individual actors come together to build something of mutual interest. As peers hosted within a commons process, they share the responsibility of shaping the system. They bring their unique perspectives, experiences, and tools which inform their labor.

Constraints

The labor of contributors is structured within constraints:

• Pre-existing: the weather of a particular geography, the licenses attached to existing software

• Self-imposed: social/political/economic relationships, decision-making, norms, frameworks of production, etc.

Constraints define the obligations expected of and rights given to contributors. They also directly affect the inherent characteristics - the shape - that the resource takes on.

Resource

The underlying process, resource output, surplus value/positive externalities generated in the production are all fully available to the entire contributor graph. It’s unlikely that commons resource would be stewarded in the same way or have the same characteristics outside this set of peer relationships. Yochai Benkler describes this dynamic as “commons based peer production.”

It’s interesting to frame the resource and its structure as an entity, or an “egregore.” This is a non-physical being which “exists in virtue of the collective ritual activities of a group yet operates autonomously, according to its own internal logic, to materially influence and control the group’s activities. The group creates the egregore, and the egregore creates the group, in a self-reinforcing feedback loop." (Wright, 2021)

Enclosure

In the common mode of production, the benefits/assurances/surplus value are under the domain of involved peers. Because commons are suited for producing unmonetized and yet still valuable artifacts, other modes like capital find their way to the edges. This produces a dynamic where external actors may encroach on the peer production, or co-opt part or all of the resource output towards private benefit. Academia calls it “enclosure,” Birkinbine calls it “incorporation,” and the Ethereum community calls it “capture” or in another frame, Moloch: the God of coordination failures.

The phenomenon is a suffocating constriction of the possibility space.

The diagram above illustrates a company or a former commons - now fully enclosed by capital. The resource output (i.e. surplus value) is only allocated to a subset of the membership.

Consider the historic enclosure of English pastures. These shared spaces provided grass to support livestock, which in turn produced manure for fertilizing fields. This production was maintained through social agreements between the local community members.

However, things changed with the royal appointment of a new baron. As he erected walls and combined plots, the previous stewards were prevented from utilizing the land according to their “ancient customary rights.” These have been superseded by a new framework, with the baron and his house at the center. This new dynamic is bootstrapped under a regime of physical violence, and normalized over time by social, political or religious justification.

Digital objects are able to sidestep some pressures which physical objects cannot. However, subtle but dangerous encroachment may surface in the political, social, or technical processes of software production. In fact, the additional surplus value bound up within the anti-rivalry of networked protocols may make them even more attractive.

2. Software Commons

This next section will examine Linux and Ethereum as software commons, including their:

• Resource outputs

  • who can consume them?

  • how are they used by contributors or others not involved in production?

  • what are the unique characteristics that they have?

• constituent parts

  • who can contribute to stewardship?

  • what types of labor are needed?

  • which frameworks guide the work of contributors?

• capital entities

  • how do they engage with the output or the production process?

  • what does enclosure look like?

As you read below, consider the similarities and differences between the two projects. What can the Ethereum community learn from Linux’s 33 years?

2.1 Linux

Linux was started in 1991 by then-student Linus Torvalds. In 2001, Microsoft’s Steve Ballmer called it “a cancer.” Today, the project has grown to become what many consider the largest collaborative development project.

Peers - Developers

As of the Dec. ‘22 6.1 release, the vast majority of Linux contributors are employed by companies who offer Linux-related products or services. Contributors with no company affiliation were only 4% by changesets/PRs, or 2.8% by lines changed. The largest employers were Huawei (9.2% by changesets/PRs) and Oracle (12% by lines changed).

Constraints - OSS norms, BDFL, GPLv2

• OSS etiquette - eg. detailed pull requests, bug reports.

• Social dynamics: contributors must cooperate to create software of this scale and complexity. Linus has been unofficially designated BDFL (benevolent dictator for life). The term recognizes the significant weight, and even deference, the community gives his opinions on the direction of Linux.

• Legal frameworks: the “General Public License v2” (GPLv2) allows software to interface with the legal system. “You may copy, distribute and modify the software as long as you track changes/dates in source files. Any modifications to or software including (via compiler) GPL-licensed code must also be made available under the GPL along with build & install instructions.”

• Labor hierarchies: formal/informal teams work on different parts of the kernel. Various roles include writing code, reviewing, testing, long-term maintenance for older versions, who has merge access, etc.

Resource: Kernel

The Linux kernel is the resource produced by this commons process.

• The core component of the Linux operating system (OS), made up of 30mm lines of code

• In contrast to most web standards, no spec. According to Linus “specs are close to useless.”

• Low excludability: the kernel source code is available for anyone to use.

• Anti-rival: one person consuming (reading or running) this digital code does not restrict another’s ability to do the same, and they both benefit from there being more Linux users.

• The kernel cannot be run as user software in isolation.

Expanding the Linux commons

The kernel ecosystem is extended by other communities and projects, here under the umbrella of consumers and producers of kernel related software. Software commons are especially generative in how they allow adjacent ecosystems to emerge.

One of the main community types are called “distributions,” aka “distros” (DIST 1-4). They extend the kernel to create useful software for end users, e.g. Ubuntu, Fedora and Debian. Other non-distro software projects (SW 1, 2) create a wide array of distro related plugins and tools.

These projects share some important resources with the base commons:

• Resource: All projects must interface with the kernel source code to varying degrees

• Contributors: some may be part of both the distro and kernel production processes.

• Constraints: core norms and frameworks likely carry over. but it’s also possible they get diluted with distance, or the project hosting context eg. within a large commercial entity vs. as a small community project.

User-bound state

Each square is an instance of distro software being run by a user, whether they are individuals, teams, or organizations. The boundaries of each running distro system traces the shape of each user profile e.g. a corporation running an enterprise Linux OS to manage internal processes, customer records, etc. The software is inward facing.

User feedback is an important part of software commons: what’s working, what needs to be improved, and feature requests.

Linux enclosure

I will caveat this section by acknowledging that companies (and their employees) engage in the commons as a condition of their environment, not as abstract adversarial actors. Enterprise software purchasers want certain guarantees when purchasing software: contractually obligated long-term support, or an entity to serve suits to. Though it may be harder for a commons to provide these same guarantees, it certainly doesn’t justify the negative effects brought by conflict between the two modes of production.

Further, the size and complexity of the Linux commons makes it unlikely to ever be completely enclosed (i.e. the medieval pasture example in the first section, a single entity controlling production). There are significant costs to production which would eat into the benefits realized by free-riding on the surplus value of the commons.

Enclosure happens in degrees, starting at the edges and working its way in. Commercial entities engage in shared production so long as it serves their profit motive.

• Commercial entities hiring/acquiring kernel contributors grants access to their social/political/technical capabilities at the center of the commons. It ostensibly appears as a positive move to share the responsibility of commons stewardship. However, through incentives, pressure, or inertia, employees may end up aligning more with the goals of the employer instead of what the commons needs.

• Commercial entities may also act as a legal host for a distro community, or deeply align their products. In Linux, capital entities are able to fully enclose/host entire distros because that’s where the software production process ends.

In both of these approaches, contributors simultaneously participate in the common and capital modes of production. Benkler describes this as “the boundary of the firm becom[ing] more porous” (Wealth of Networks, 2006).

Case Study: Red Hat

Founded in 1993, Red Hat (RH) has decades of Linux grassroots experience. They’ve used that to build what some call the most financially successful open source company, leading to a $34B acquisition in 2018. However, this path to success has often come at the expense of commons stability. Consider this 10 year progression:

• In 2014, RH “partnered” with CentOS: a struggling distro project. RH believed the state of the project reflected poorly on their work. In exchange for legal support, job security for contributors, and stability, Red Hat was given a permanent board majority and de facto control of the project.

• In 2019, RH was acquired by IBM. Company posts from the time claimed that “Red Hat’s mission and unwavering commitment to open source will remain unchanged.”

• The honeymoon didn’t last very long. In 2020 RH deprecated CentOS, which had by then been reinvigorated as a popular community distro. Future work and support for past releases was terminated. RH directed previous CentOS users to CentOS Stream, a new project missing most of the “Red Hat Enterprise Linux” (RHEL) compatibility developers were looking for.

• In 2023 RH restricted access to RHEL source code - their flagship product. Many in the Linux community believe this violates the spirit of long-standing GPLv2 licensing norms. Even though RH employees “were also conflicted about the new policy,” the external interests of the commercial actor ultimately trump their employees’ well-intentioned posture towards commons norms.

A relationship which depended on the health of the commons became more clearly representative of investors and capital.

Seeking resources to sustain their efforts, grassroots communities may unwittingly shape themselves to accommodate entities uninterested in the health of the commons. When priorities shift, capital is happy to disengage from committing resources. This dependency dynamic introduces the risk of structural instability for the greater self-reliant commons.

At the end of the day, capital’s bottom line is top of mind.

2.2 Ethereum

Ethereum was announced in 2013 by former journalist Vitalik Buterin, and went live in 2015 under the audacious tagline of “world computer.” In 2018, venture capitalist Fred Wilson suggested in strong terms that “Ethereum should be more like a company.” Today, it has become the world’s largest blockchain network.

Peers - Developers, Researchers, Facilitators

People with expertise in the areas of distributed systems, networking, game theory, mechanism design, cryptography, virtual machines, etc. These individuals include:

• Developers: maintaining and preparing client releases. Sanity checking research ideas for practicality and viability, implementing proof of concepts.

• Researchers: dissecting the realities of the network as it exists today, understanding deficiencies that can be improved in the future, crafting proposals to make it more robust & censorship resistant

• Facilitators: coordinating network upgrades, ensuring upgrades balance the needs of the ecosystem and the protocol, and devops, security and testing in support of client teams

For-profit and nonprofits provide many contributors with financial support in a variety of forms. There are some unaffiliated individuals who contribute on their own for a variety of reasons, including curiosity, intellectual challenge, respect from peers, etc.

Constraints - ACD, EIPs, Specs

• In addition to OSS norms found in the Linux Commons around respecting licenses and collaborative efforts, the Ethereum community holds shared values:

  • censorship resistance: including both accessibility for users, and decentralization for the network

  • autonomy/self-determination

  • permissionlessness

  • privacy advocacy

• Venues like the All Core Devs call, Eth R&D Discord, ethresear.ch and Ethereum Magician’s forum host discussions for a globally distributed contributor set. Participants are able to build consensus around which particular changes are of highest priority.

• The EIP process structures the way changes to the protocol are specified

• Ethereum Execution Layer Specification (aka EELS), Consensus Specs, Yellow Paper, Ben Edgington’s Upgrading Ethereum: specifications and related items are an important set of artifacts which steer how the protocol develops and describes itself. They range from the purely representational to functional testing components and are used at various points in the network upgrade process. This library of references is a key enabler for Ethereum’s robust offering of 10+ unique clients which can all interoperate within this distributed system

• Social Dynamics: there is no single leader. Even though Vitalik’s opinions do hold significant weight, he has largely stepped back from regular involvement in core protocol stewardship. He doesn’t have any override power if social consensus disagrees with his perspective.

Resource - the Ethereum software commons

The Ethereum commons produces a body of software artifacts which can come to consensus on the output of EVM computations run in globally distributed environments. This is a collective snapshot of what the Ethereum protocol is today and what it might look like in the near future. It reflects the values of its contributor set, is available for anyone to explore, and open source.

This includes the client software which can read and write to EVM state. Each Ethereum client implements the spec with opinionated decisions on the language, features, database, research areas, and more:

• Execution layer - Erigon, Besu, Geth, Nethermind, Reth, EthJs

• Consensus layer - Lighthouse, Lodestar, Nimbus, Prysm, Teku

While many of the full-time contributors to each project are paid by a commercial entity which acts as the “host,” the set of contributors is typically broader than just the entity itself. The diversity of client approaches is the product of and reinforces the norm of political polycentrism. In an ideal case, there is a healthy distribution of many client types. This produces a more technically robust, fault-tolerant network. For example, a client in a new language opens a path to Ethereum contributions for any developer in that community, while also providing protection against issues that might appear in other languages.

Embedded capital resources

The fact that the Ethereum commons produces a blockchain and not another form of software has important implications.

Usable right away

Whereas the Linux kernel doesn’t produce anything for users until distros add their features, running Ethereum software produces a usable artifact right away. From the genesis block, Ethereum has always had a broad range of individual enthusiasts, communities, organizations, and infrastructure all using the chain at the same time. While this brings a welcome variety of use cases and perspectives, it can sometimes be challenging for the commons stewards to set feature priorities.

Single global artifact

Operators from around the world run the client software releases and come to consensus on a single instantiation of state and history (i.e. “mainnet” “chainID=1” “ETH L1”). In contrast to Linux (the kernel doesn’t produce anything on its own, distros needed to produce many isolated/private instances), the Ethereum software commons outputs a single, public software artifact. This is a globally distributed system, a world computer. Users running the software as part of consensus activities are an important part of the feedback loop.

Reading state + history is low excludability, anti-rival: the more people using and referencing EVM infrastructure the greater the value to the individual user. Anyone running a node can access this by running their own node. The chain data can be called a “Knowledge Commons” - the records are available for anyone to verify: a widely available, rich dataset of organizational, financial, and cultural relationships.

Writing to state is low excludability, high rivalry: the number of concurrent users is capped by the block gas limit to ensure that resource requirements for node operators don’t grow too quickly. While it is a digital object, there are constraints to be mindful of: cost of storage, bandwidth, compute, etc. In the happy path, the network participants only discriminate based on the fee offered by each transaction to write to the state. As Ethereum scales its trustless settlement assurances through Layer 2s, the degree of rivalry will decrease.

Embedded capital engines

Perhaps most significantly: the Ethereum commons has capital circuits directly embedded within itself at the level of production. Monetization/productization /commodification isn’t added later by an independent company (as in Linux): the software is birthed with perpetual incentives.

• Proof of Work consensus depended on financial incentives, and Proof of Stake introduced an even more direct relationship between capital and consensus. This area of the protocol also sees growing engagement from extra-protocol actors (e.g. commercial staking services, liquid staking providers, restaking systems, etc), each with their own incentives.

• The native asset ether (ETH) is used to pay for state changes, and to reward validators for participating in consensus which advancing the chain. While Ethereum’s lack of onchain governance prevents capital having a direct voice (in the form of ETH) in stakeholder decision making, the asset holders may try to steer the protocol down suboptimal paths.

• Blockspace (and any associated MEV) can be considered a separate infrastructure/resource supply chain

In the perspective of this article, the embeddedness of capital feels contradictory, and potentially counterproductive to commons stewardship. There’s a universe of possibilities, with two defining frames:

• Capital and the protocols/parameters it manifests as are ultimately subject to the influence of the software commons contributors. This allows for a healthy counterbalance to any influence capital is able to exert through the actors engaged in these systems.

• The close proximity causes unforeseen challenges to ongoing protocol stewardship. Capital creates more instability, unpredictability, and faster (and more complete) enclosure in the underlying commons.

Expanding the Ethereum commons

The broader Ethereum commons includes producers and consumers of EVM blockspace:

• Projects which modify the commons software to produce additional differentiated instances of EVM state/history/blockspace eg. other L1s, L2s

• Users transacting

• Applications developed by teams create demand

A broad array of entities are implicated in this production process because of how they share resources and constraints:

They must share code, software, information: all actors are building off of the EVM

They might share the labor of individuals. Their efforts may shape the core protocol to benefit all other blockspace producing/consuming actors (eg. EIP 4844) or in the degenerate case, a single L2 trying to influence protocol decisions in their favor. The overlaps are illustrative and do not generalize to every occurrence of the type.

They might share norms on how to produce/steward the software.

They might share the same blockspace/state/history: network-bound state. This enhances the anti-rival characteristics of the resource.

• Independent EVM chains e.g. L1 Y. there is no blockspace relationship

• EVM chains which have (or are working towards) trustless guarantees for passing state between them (canonical bridges) - L2 A, L2 B. They consume state on the Ethereum L1

• Applications creating demand for blockspace

• Individuals consuming blockspace

To engage with the Ethereum software product, all of these actors are required to step outside of their immediate domain. Practically, this means they can’t ever have exclusive control over the underlying software production or the resulting blockspace.

Ethereum enclosure

I’d like to preface this section with some caveats.

• It’s possible for companies to share the values of the Ethereum commons. Companies are not default evil, and neither are companies with differentiated revenue streams. It’s just that the fundamental goals of capital and the commons are incompatible.

• Though money/assets/resources will always be part of the commons management process - its effects are most strongly felt when it’s seeking a return.

A large multinational corporation has projects adjacent to but outside of the commons. They acquihire the team building a Layer 2, which gives them access to the political/social relationships which comprise the Ethereum software commons.

Superficially, the goals of capital and the commons may seem coincident as “grow the impact of the blockspace product/system.” In the short term, and as expressed by individual actors, this may actually be true! However, on longer timelines these goals are ultimately conflicting in terms of who the benefits accrue to, and in what form.

The commons asks: How can the benefits/assurances of the system be scaled to the largest public?

• Lowering barriers to verify state validity (running a node)

• Lowering barriers to produce blockspace (validating, censorship resistance)

• Lowering barriers to consume blockspace (permissionless user access, censorship resistance)

Capital asks: where can private benefit be extracted?

• Inserting into/extracting profit from state verification (explorers)

• Inserting into/extracting profit from blockspace production (MEV, hosted validation)

• Inserting into/extracting profit from blockspace consumption (user experiences, products)

There are constraints on what capital can do in pursuit of these goals, including to what degree and by what methods. (how easy it is to fit to the capital entities chosen form):

• Isolated entities cannot fully enclose blockspace production systems without compromising crucial characteristics, ie. availability, credible neutrality, censorship resistance.

• The EVM ecosystem shares the same public/private key infra, making user lock-in to a particular product less feasible - this increases user agency.

• Relative to Linux, the EVM ecosystem is a public system that lends itself to decomposition of the blockspace production stack, aka “protocol surface area”. This makes it harder for any single capital entity/small groups to dominate (absent cartelization) over longer timelines. Ultimately, “big C” Capital benefits even when projects fail to build profitable product and cycle out of the ecosystem.

• In the same way the expanded commons takes on some of the constraints, any systems integrating/layering on top have to be designed in a particular way. Both technically and legally with regard to OSS licenses.

• Relationships between blockspace (e.g. L1 and L2) cannot be broken without fundamentally changing the nature of the blockspace.

Given these limits, capital may turn to commons governance (i.e. any future protocol changes, aka the “process”) to give voice to its interests. This may materialize as:

• Commercial entities competing between each other (e.g. Layer 2s, investment firms) to influence the shape of the core protocol features to their benefit/ their portfolio companies’, or to prevent others from benefitting.

• Larger companies hosting client teams in order to access/leverage their local knowledge/position in the commons production. This can be either by permanently acquiring a team, or short-term consulting.

• Legacy organizations looking to stay ahead of obsolescence (e.g. web2 dipping its toes into web3) or to create regulatory moats.

There are downsides to this:

• Capital biases towards speed, not long term sustainability. Timelines shorten to match the short-term benefit of actors, rather than the long-term benefit of the broader commons and the public welfare it is capable of producing.

• Commons stewardship which leans too heavily on the presence of capital (extrinsic motivations) risks crowding out other intrinsic motivations (e.g. vibes, respect from peers, challenging oneself).

4. Conclusion

Software commons are an increasingly important part of our daily lives. The people and frameworks involved are able to provision novel goods outside of the state/market dichotomy.

Not all software commons will experience the same enclosure dynamics. Those that do can still exist and thrive in spite of it - perhaps it only becomes problematic when the scale of extraction becomes too large relative to the rest of the commons. It remains to be seen whether this conflict is an unavoidable early phase of commons bootstrapping or perhaps this will be a site of ongoing ever-increasing conflicts between the two modes.

It’s also possible for capital and the people wielding it to exercise restraint i.e. “dont kill the golden goose.” The underlying motivation (e.g. build a moat now to profit in the future) will eventually surface.

Linux is an ongoing demonstration of the possibilities and challenges involved in software commons stewardship. At the start of our own work, the Ethereum community should better develop a critical understanding of capital’s interest.

Today, the protocol community is largely aligned on the vision for near-term Ethereum. Layer 2 teams are a crucial component to making this work, and should be celebrated. In the future, will the different parts of the community agree on the right path forward?

Do native forms of capital embedded in resource production give a better ability to modify negative externalities? Or does it supercharge incentives for external capital to enter and co-opt the resource production system over time? How can we develop better heuristics for thinking about this challenge and developing safeguards?

There are decision-making norms which try to privilege the health of the network commons against apathy and “death by a thousand capital cuts”. As the number of profit-seeking stakeholders inevitably increases, will this always be the case?

Red Hat the hero

While Red Hat comes away as the villain, that wasn’t always the case. In the lead-up to their 1999 IPO, the team attempted to create a list of all Linux contributors in order to make them stockholders.

By doing so, Red Hat was able to celebrate the work of the thousands of community members that made the IPO even possible in the first place. The company recognized the importance of completing the commons funding circuit.

I believe the Protocol Guild is a promising experiment (among many others) to produce similar outcomes for Ethereum contributors, while being more efficient, impactful, and consistent. I plan to write more about the symbiotic relationship between Protocol Guild and the commons funding circuit. Until then, learn more about the project in the docs, twitter, and Dune dashboard.

Thanks for reading - find me at farcaster or twitter.

Funding allocation primitives

While it’s still a project in development, the Guild was structured to facilitate funding with the lowest bureaucratic overhead possible imposed on members. At its core are two very basic primitives, which are present in all funding allocation mechanisms.

1. a curation process which produces a list of eligible recipients

   1. Protocol Guild uses “self-curation” by individual peers working on core development. This is somewhat contingent on a high-trust community of peer stewards, where the assumption is that high quality work will still be produced absent invasive oversight. This is also enabled through the perspective of a collective protocol emerging from the collaborative stewardship by many constituent parts, instead of something like a competitive RFP process.

   2. Communities using Coordinape also use self-curation

   3. Members of the Gitcoin DAO curate the requirements and categories for Grants Rounds, which ultimately results in a list of grantees available for quadratic funding." Source

   4. The Optimism Foundation sets the scope for RPGF rounds, and then filters applications accordingly

2. a weighting mechanism applied to that list

   1. Protocol Guild uses time-weighting instead of subjective peer ranking. While it’s true this prevents more granular measures of individual impact, using time-weighting sidesteps the contention that might come out of peer ranking, doesn’t require time to apply, and is objective and transparent to members.

   2. Coordinape uses peer ranking where the particulars are decided by each community using the tool

   3. Gitcoin places a max cap (IIRC 15%) to prevent any one project from being allocated too much of any single matching pool. Additionally, the preferences of the public are interpreted via Quadratic Funding (QF) to allocate $ weights

   4. OP RPGF rounds delegate the weighting responsibility to Badge Holders, instructing them to use the rough heuristic of “impact = profit.”

The shape of the Guild

While Protocol Guild strives for simplicity, the institutional form is pretty opinionated:

1. in response to a unique set of framing conditions related to funding Ethereum core protocol development

2. To intentionally constrain the decision space imposed on members

These may not map exactly to your situation, but are perhaps still useful for informing your decisions. Below are some of the Guild’s characteristics, reasons why they are so central to the mechanism, and a few things to consider in your exploration.

1. Member curation

   1. The Guild expects that the membership curates itself, not an external council/funder. Is the domain to evaluate easily observable? Is it roughly clear to see who is doing what work consistently? The Guild is concerned with a very narrow domain: core Ethereum protocol stewardship defined by this eligibility framework.

   2. How easily could you make a list which covers the a sufficient number of contributors? Inarticulate eligibility frameworks may produce many edge cases, and potentially overwhelm your membership’s curation efforts.

   3. It’s important to find the right balance between overly permissive and overly restrictive curation. Having too many narrowly defined mechanisms (eg. one grant per individual) introduces excessive overhead to sponsors and members. Overly broad eligibility makes it hard to convincingly advocate the necessity of funding to potential sponsors eg. something like “Open Source Guild” would have 10s of thousands of potential members and is effectively impossible to curate or fundraise for.

2. Broad based funding

   1. The Guild responded to a void in the commons funding space: a holistic core protocol that allows contributors to cooperate instead of compete for funding

   2. Are there funders who have expressed interest and are looking for a Guild-like mechanism in your space? Having the distribution mechanism is only one part of the equation. You will still have to do the non-trivial work of outreach to funders, demonstrating the value of past work, and making this case into the future. Starting with interested sponsors makes your work much less taxing.

3. Onchain

   1. The Guild has ~150 members from 20+ teams. An onchain mechanism was necessary to facilitate funding from onchain orgs, with the lowest possible overhead, while also transparently & trustlessly distributing the funding.

   2. If your project is a one-off grant to a small number of people, it may not make sense to be onchain

4. Concerned with funding holistic stewardship

   1. The Ethereum protocol will still be evolving over the next 5-10 years. The Guild exists to fund and incentivize a stable pool of contributors over that period.

   2. Just as the Ethereum distributed system takes inputs from many actors to produce a unified global state, the production of the underlying software combines efforts from many contributors. There is no single entity which maintains and evolves the protocol in isolation. Protocol Guild reproduces the qualities inherent to the production of a software commons as a funding stream. With this tool, the ecosystem can now share the collective responsibility of funding core protocol stewardship.

   3. If you’re going to go through the trouble of bootstrapping a new institution and norms to fund it, it may be best to only do it for long term projects centered on the same domain, eg. ongoing workstreams with high trust between the collaborators.

   4. The Guild makes iterated social commitments (eg. quarterly membership updates) to continue curating, which builds trust with sponsors.

5. Autonomous weighting & disbursement

   1. The Guild has no treasury allocation process, at least in the traditional sense. Instead, it cedes that to an objective time-weighting and trustless vesting mechanism. The intentional tradeoff to foreclose this decision space from ourselves gives us lower governance overhead/ possible contention, at the cost of lower weighting granularity and less flexibility in funding disbursement.

   2. If you intend to distribute grants to specific grants/applicants, following the autonomous strategy may not make sense.

   3. Do you want to take feature requests in exchange for funding? The Guild does not do this and may not be the right mechanism for your project. If you’re interested in funders having a say in disbursements, then check out simple Moloch DAOs where membership proposals must come with funding attached, and grant governance rights over the treasury.

6. Independent of external governance outcomes

   1. The Guild is concerned with a very narrow scope: producing a list of contributors, and building norms around funding it as a mechanism. Inasmuch as there is one, the entity and its collective membership claims no ownership over Ethereum governance. Setting development goals is the purview of the community through existing venues like the All Core Dev calls, the R&D Discord, client teams, and forums (eg. ethresear.ch, ETH Magicians)

   2. For potential other Guild projects: Is funding coupled with long-term governance of the software the contributors produce? Approaching this is a much larger design space than the Guild attempts to address - any attempts should keep this in mind.

Hopefully this was helpful to any prospective Guild summoners! Please do reach out on Twitter if you have questions or to be added to the Guild discord, or follow the Guild account. ⛓️🛡️

Thanks to Tim Beiko, cheeky-gorilla and Justin Florentine for review and feedback.

The permissionless nature of Ethereum has costs — but it is necessary & beneficial - this essay has been paired with dark forest audio. listen here while you read

TLDR;

Ethereum is technically, socially, and politically permissionless — meaning anyone can access these layers. Though this openness introduces costs to the community, it is what makes Ethereum such a dynamic ecosystem. We must always remember this reality and not be dissuaded or distracted from what we are building: a global arena for cooperative games.

Introduction

In their “Ethereum is a Dark Forest” article, Dan Robinson and Georgios Konstantopoulos drew a comparison between Ethereum’s adversarial environment and the concept of a “dark forest.” The metaphor comes from a book of the same name, and is used to describe “an environment in which detection means certain death at the hands of advanced predators.”

This comparison usefully described the Ethereum mempool, a virtual space where pending transactions wait to be included in blocks. The mempool is closely monitored by bots of unknown origin who monitor transactions and their potential end states. If there’s profit to be made, they will ruthlessly frontrun or outbid these transactions. Profit equates to detection in the dark forest, and as Dan and Georgios painfully experienced, it’s nearly impossible to avoid these predators. Their objectives did not align with those whom were lurking in the shadows.

Ethereum is a Dark Forest at every layer

In what follows, I extend the Dark Forest metaphor to also encompass other technical aspects of Ethereum, as well as its social and political layers. Just as anyone can watch the mempool for transactions to exploit, actors can leverage each layer to their ultimate benefit, whether or not they have the long-term interests of the community in mind.

A few examples:

• Technical: deploying to mainnet, adding state to the chain, watching the mempool in order to frontrun

• Social: participating in social graphs, twitter hot takes, donating to Gitcoin grants

• Political: lobbying for or against specific technical changes, participating in rough consensus, attending All Core Dev calls

When this happens, it feels like others are freeloading on infrastructure they haven’t contributed towards. If it’s other community members, that they are abusing infrastructure or bandwidth that could better be used.

While the impact of Ethereum’s permissionlessness can be frustrating and disorienting at every layer it is expressed, we must remember that it behaves this way by design. In fact, an alternative ecoystem where we’ve lost its chaotic inputs is actually much more concerning, and ultimately yield less interesting projects. It would be indicate a loss of antifragility and weakness: we are fortunate this hasn’t occurred yet. This current blend of characteristics are what make Ethereum revolutionary and worthy of our continued investment.

Celebrating and embracing Ethereum’s Dark Forest characteristics

It is well worth remembering that in only 5 years, Ethereum has become:

• an emergent collection of technical, social, and political characteristics not replicated in any other ecosystem

• the host to a dizzying array of permissionless experimentation via an ever-growing open toolset of mechanisms

• defined by a distributed and ever-growing global community that allows institutions, moneys and irrevocable contracts to be conjured

Think about that for a moment — this is an amazing set of properties all in one ecosystem! All of these are the result of Ethereum’s origination and growth as a Dark Forest ecosystem: permissionless, chaotic, and open to all.

These attributes run parallel to one of the Ethereum community’s favorite frames, the Cathedral and the Bazaar. Both the Bazaar and the Dark Forest are sources of continuous energy for the community. Anyone, from any background and any country, can access what we are cultivating — this is a powerful motivation for us to continue our efforts.

What Ethereum enables

We’ve seen people from around the world leveraging Ethereum’s capabilities. As Virgil put it, “Ethereum is an unprecedented arena for playing cooperative games.” (Source). An arena full of coordination machines: tools and infrastructure that continue to operate, regardless of what happens in the physical world. In true credible neutral fashion, these coordination machines can be for any purpose: from the inspiring to the common, from the mundane to the evil.

Again, it is worth reminding ourselves that Ethereum enables:

• open organizations anyone can create or join

• blindingly transparent records

• globally accessible financial products and markets

• community currencies

• non-extractive remittances

• non-custodial financial services

• marketplaces that compensate creatives fairly

• persistent scripts deployable to a global computer

• portable non-state identities

• local fantasy sports league betting

• unfettered speculation

• payment rails for ransomware

• financialization of our most sacred human experiences

• permissionless scams

• multinationals coordinating local resource extraction

• assassination markets

When expectations diverge from reality

Both remarkably good and remarkably bad potentials populate this list. If we become overwhelmed by negative outcomes, it may seem at times that Ethereum is not worth the effort.

This summer’s yield farming escapades once again highlighted the schism in community narrative expectations. On one side, prominent voices raising concerns about the speed of experimentation, callbacks to “The DAO” and ICO fervor. On the other, the celebration of radical experimentation and of participation in those experiments.

The community contains different perspectives on how quickly and in what ways the ecosystem should develop. It’s crucial to understand that this is the latest manifestation of an old pattern that will continue as long as blocks are produced. There will be future manias, rampant speculation, unending schemes to twist the capacity of Ethereum.

All of these can be ascribed to Molochs: opportunistic meta-monsters living in the forest with us, with the sole intent of perpetuating coordination failures (Meditations on Moloch). Manias like yield farming introduce uncertainty into our expectations, upend norms, strip collective meaning from our individual frameworks — not least of all putting gas prices through the roof.

All three layers (technical, social, political) host a myriad of *other *non-community or community-adjacent entities. These entities sometimes have wildly different end purposes for Ethereum, but they all look to leverage its Dark Forest capabilities.

They may try to use the social and political layers to gain support or funding, even diverting attention from worthwhile projects. Some entities will end up having negative long-term ecosystem or regulatory impacts. Some will foment their own manias, and some will gaslight the core community into confusion about what are worthy goals and how to pursue them. Given the permissionless access to the tech and the malleability of the social and political layers, it’s impossible to anticipate or prevent every possibility.

What can the community do?

Help me kill this particular Moloch: we need to be better at fully accepting the reality of the Dark Forest, at each layer. We need to play long-term games with our own adversarial mindset. We need to understand we share every layer with both aligned and non-aligned entities. We need to embrace — or tolerate — the uncertainty, the seeming instability of a permissionless ecosystem.

Do we believe there are still worthwhile technical, social and political experiments to be had on Ethereum? Then we must get better about weathering the temporary feeling that we’ve lost the beautiful vision.

The space for purpose-driven positive outcomes is as strong as ever, and will continue to blossom — even if it might feel more hidden right now. Focus on maintaining your own resolve until the mechanisms that you value are valued by others. And not just others in the ecosystem — there’s the entire rest of the planet to welcome into the Dark Forest!

Both now and in the future, we’re building this as a community. This is a massive collective experiment. The forest requires a diversity of interests, backgrounds and skills as inputs to craft its cooperative games and coordination machines. It needs some people that urge caution, and others that push the envelope. This is how it should be, and it is our ability to negotiate between these poles that makes me as hopeful as I’ve ever been that what we are building together will continue to be realized.

In conclusion

Ethereum has always been an adversarial environment. Its Dark Forest characteristics are what make it unique when compared to every other crypto platform and community. Because Ethereum’s technical, social, political and layers are permissionless, anyone can use and abuse them. We cannot control this access, but we can control our reaction to actual or perceived cooption.

In times of rapid narrative change, we must remind ourselves of the foundational reasons we first started. We should double down and recommit to our efforts of cultivating Ethereum’s Dark Forest. After all, the space for positive outcomes is as strong as ever.

Molochs will always live in the forest with us. I’ve chosen to continue building Ethereum while they sleep — I hope you will as well.

Thanks to Justin, Kevin, Ameen and anon others for feedback. Thanks to Dan, Georgios and Virgil for inspiration.

TLDR: i think GPUs will get cheaper, but not at the Merge

first we should consider whether a miner has ROId aka "broken even." they are much more likely to ride through the Merge. these are probably long-term miners who have been through things, unlikely to make quick decisions, and bc they are already ROId, don't need to

just because they don't need to, doesn't mean they won't. getting a good price before others may be tempting enough to drop out pre-Merge and hedge

larger operations might also project out to see they will make X$ by mining and Y$ by selling the GPUs, and the day that Y>X, you would expect them to sell

if they haven't ROId, it's a little more complex. some may try to frontrun the flood, but there's less pressure in absolute $ terms if you run a small setup. some are hobbyists doing it for fun, or can use GPUs for gaming if things become too unprofitable

however, as we know, difficulty is self balancing - if miners leave to sell their hardware, it becomes that much more lucrative to stick around and get the last ETH block rewards from PoW

based on what i've observed, i think this "frontrunning" effect will be less dramatic. as mentioned, Ethereum still pays the best out of any GPU coin. leaving that income on the table doesn't seem likely

second, inertia + a "wait and see approach" are strong predictors

case in point, 1559 (Aug. '21) was projected to significantly cut miner revenues, but bc Ethereum is so profitable it didn't seem to effect total hashrate. (IIRC the May '21 drop is related to china mining bans). meaning - many miners waited it out and ended up sticking around

adding to "wait and see" factor: miners (and the rest of us lol) don't know exactly when the Merge/the end of PoW will take place. we have projections and best guesses, but it will be ready when its ready. i don't blame miners for not acting within this uncertainty

interestingly, HR growth rate since EOY has slowed - is this The Market already whispering its expectations? I wonder if total hashrate / growth rate will materially react to an announcement of total terminal difficulty TTD (akin to block height in a regular network upgrade)

quick interjection about TTD

trent.eth

@trent_vanepps

6. The Merge will use accumulated difficulty (Total Terminal Difficulty) to trigger the PoW → PoS upgrade, instead of block height

"An attacker cld use a minority of hash power to build a malicious chain fork that wld satisfy the block height req"

More: eips.ethereum.org/EIPS/eip-3675#…

trent.eth

@trent_vanepps

5. To any stakers: you should start running a local execution layer (EL) client ahead of the Merge.

In the future, outsourcing this to third-party providers will open up stakers to slashing risk under the Proof of Custody game: dankradfeist.de/ethereum/2021/…

59

7:50 AM • Mar 8, 2022

so back to miners that haven't ROId: based on reddit discussion, many miners expect to move to a lower hashrate GPU coin. given this is a very common public sentiment, i'm pretty sure it's not going to work out as expected

ethereum provides income for most of the GPU hashrate market today. after the Merge, they need to look elsewhere if they choose to keep mining

it seems to follow that the chains will not be able to maintain the same level of profitability when ~95% more hashrate suddenly redistributes itself

this point is often countered with the claim that "miner inflows = demand/ interest in the coin = significant price increases" seems like motivated reasoning at best

so again: i think GPUs will eventually fall in price, but whether it happens directly at the Merge or not depends on how many miners have ROId, and how much the want to hedge against future unprofitability in the GPU world

maybe a slow bleed? we'll see!

caveat - keep in mind i have a pretty limited perspective, i don't have insights into non-english mining communities, or how larger miners plan to operate

that's it - check out additional discussions here on r/ethereum which partially prompted these tweeeets

Find an accompanying vibe from this playlist for fun! Collect this story as an NFT above!

I settle back into the chair slowly, my hand brushing against the frayed edges of the cushion. It feels like entering a hallucination, a possession, an out of body experience. A memory structure scaffolds itself around my descending consciousness.

…

It was from a book of old stories told to young children before bed.

Your mother always told the one about the universe being the dreams of two children. They were just about your age, seven seasons old. "They sleep on their backs near each other, listening out into the quiet of the night ... shhh, be very still, can you hear their quiet breaths?"

…

It's a steady trickle now, I can feel it.

…

As the story goes: one child is the beginning of our universe; the other is its end. Between both of them, every possible reality.

Her eyes close as the familiar cadence of words rattles through your ears. "I see the smoke of dreams leaking from their heads. Sometimes thick, pouring out from an ear, and sometimes barely a wisp, floating from the corner of an eye." Her details always made the story.

…

The vision blooms up against the curve of my skull, but I still retain enough of my Self.

…

The story was powerful for some nascent minds, taking it as foundation to construct their own internal universes.

"Enveloping atmospheres drift in and out of their sleeping minds, creating clouds of possibilities. This is what things can be and what things cannot be," she'd describe. "Their fingers softly twitch as though pulled by something in their dreams. And just at the edge of the mist, the bottom of their feet peeking out."

Your own fingers are itching to jump, to be anything but still.

"Particles gather into dense little clouds at each confluence of creative and destructive potential, hanging all around their heads. Versions of us exist in each cloud."

You can see them floating above you, hands now still at your side.

"Running through the center of each cloud is a fine silver wire - linking each possible future to its neighbor" she hums. From afar, it seems to hang in the air, unmoving, but a subtle shimmer tells you that something about it is alive. Even from this distance, you can hear faint notes of its energy reach you, beckoning towards sleep.

The scene laid out in front of you creates an irresistible tug. "The near-perfect stillness of the children, the mist, the vibrating potential of each cloudy future, the linking infinite wire." A bit of the mist reaches out across the distance to inspect your cheek, drawn by the something crackling behind your eyes.

The children start to fade out of view, buried as the hum of the mesh crescendos in your ears.

…

My senses have been nearly overwhelmed. My mental self is occupied, recounting revolutions I never lived.

Suddenly I'm moving, shrinking - transported to the center of a reality-cloud, the children lost from view. The wire becomes a massive column looming in my vision. It's a floating monolith, imprinted with the record of realities it has passed through, worn nearly smooth by the intervening voids, and then overlaid again.

Time dilates around me, slowing the rush of aeras to a crawl. Jubilant celebrations, forgotten betrayals, improbable exploits: they all left their trace here.

Must ... read the records.

I move closer with difficulty, pushing against masses obscured by the mist. As my hand reaches towards the structure, I notice flecks of dust flying off my fingernails. And then more shooting out of knuckles and from between fingers.

I stop to watch the streams of particles peel off and away, even up to my wrist. Small parts of me leading towards the looming being just ahead.

The particles deposit themselves onto the etched face of the column and quickly harden. It's become information, nestled within an intricate sea of sibling glyphs. Iconography mirrors the sequence of the children’s twitching hands as they dreamt this memory. Their unsettled sleep signed our hidden pasts, absurd realities, impossible futures.

We have marked our records.

The sensation of departure remains strangely present on my fingers, still drawn by some current. All around, tendrils whip out of the cloud, pushing a part of themselves towards the structure. The same ritual cycle of disintegration, forming and hardening repeats.

I look up, following the metal as it arcs away from me across the void through another cloud. My own silhouette is there, staring down at the most recent story to leave my fingertips. Still further, a third me tries to pool the dust as it drains, to stop its escape.

We are all marking memories.

I notice I've started to drift back out of the scene, my work slowly receding in front of me.

…

The children reappear alongside with your mother's echoing voice.

"Their comforts and discomforts inform the tenor of our reality. Can you feel it? There's a realignment of the order coming." One of the children below stirs, and the lattice of wires respond in agitation.

Her story is working. It droops your eyelids and loosens your arms. You curl up in the remaining third between the children.

Her final whispers reach down into your fading consciousness. "That's why we sleep - to give them recognition for what they do, to honor their sleep, and let them rest. Join the deep sleep of the other children, to contribute your own stillness to their efforts."

You're stretched out on the same plane as the two dreamers. Your eyes are nearly closed, the last sliver of vision obscured by smoke.

You begin to dream. The field of clouds responds, realigning with the new input. The points of density resettle into a new distribution.

…

Finally, I'm back. I can feel the silver thread from my fingertips, pulling out the door. Directed by us, and pulling us along.

• This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. Eager to make commercial exceptions for any artists who are inspired by the story and want to illustrate components!

• Inspired in part by:

  • Jon Gold’s Epochs project (follow him here)

  • the Joe Lightfoot podcast

  • Ted Chiang’s “Arrival”

Before starting, remember that this is not an “official” roadmap, and represents a limited, subjective view of where things stand.

👉 Note: If you need to get a better understanding of the technical terms used in this article, please reference the Consensys Blockchain Glossary.

The Names have changed

Timeline → Ongoing

Let’s talk about what we call things. While it may seem strange to start here, remember that naming frameworks are informed by roadmaps. Below are two examples of recent changes to popular terminology, as well as the reasons for the change.

Execution and Consensus

For all intents and purposes, the terms “Eth1” and “Eth2” are no longer used in core development—see Tim Beiko’s “Great Renaming” doc. 

The old naming scheme suggested two issues, namely that “Eth1 comes first, and Eth2 only after” and that “Eth1 will cease to exist once Eth2 exists.” Danny Ryan has previously pointed out the issue, starting in Oct. 2020. Even though the Beacon Chain has been running alongside mainnet since it launched, using Eth1 and Eth2 suggests that the earlier version goes away at some point. In reality, the chain-state will be seamlessly wedded to the Beacon Chain with the Merge.

No data will be lost, no migration is required.

Instead of Eth1 or Eth2, we’ve shifted to “execution” and “consensus.” I recommend you read Danny’s in-depth post here. In short, execution refers to all things at the user layer: applications, account balances, tokens, etc. This can also be referred to as the “state.”

Consensus is then the Proof of Stake mechanisms that bind everything together: finality, the fork choice rule, validators, and incentives.

In a post-merge environment, both of these layers coexist together.

Features, not Phases

Phases are another term we’ve moved beyond. In the past, they referred to a specific protocol change, e.g. “Phase 0 is the Beacon Chain.” 

Late last year, there was an informal, gradual reframing of “phases” to “features.” To start, using “features” is more flexible. When designs are updated or scope expanded/reduced, it’s harder to communicate that the shorthand “Phase X” has changed instead of just calling it by the name of the feature proposal.

Second, and in keeping with the “Execution and Consensus” section above, it indicated sequentiality: that “Phase X” must be followed by “Phase X+1.” A good example of this not working in the current timeline is with The Merge (previously “Phase 1.5”) being prioritized ahead of Data Sharding (previously “Phase 1”).

Biasing towards “features” means names are atomic, easily reordered when needed, and more clearly communicate their ultimate impact.

Epistemic Flexibility

More abstractly, I like to think that both of the changes above are grounded in an epistemic flexibility—epistemic means “related to knowledge or knowing.” In other words, it’s a flexible mode of knowledge formation that allows our community to better comprehend the unstructured creativity produced by the bazaar.

We are able to make adaptive decisions about a roadmap because we’re not locked into phases or sequentiality. There’s humility in acknowledging and internalizing that we don’t have complete maps of the territory. This is an important part of Ethereum philosophy, and I’m glad to see it put down stronger roots.

It may take a while for the broader community to adjust to new naming norms, but we’ll get there! Thanks in advance for helping us out with this important effort :)

The Merge

Timeline → 5-8 months

Now that we’ve addressed naming, let’s talk about the next exciting Ethereum feature: The Merge. This refers to Ethereum’s impending switch from Proof-of-Work (PoW) to Proof-of-Stake (PoS). 

It’s one of the most widely anticipated protocol changes for both Ethereum as well as the broader crypto space. For much of our industry’s existence, PoW and its negative perceptions around energy consumption have dominated popular media. Ethereum will be the largest protocol ever to hot swap its consensus mechanism, and in turn, hopefully change the narrative.

Benefits to the Protocol

The Merge includes many major improvements to the protocol:

• As soon as the upgrade goes live, the chain becomes more secure. Blocks become “finalized” after a certain point, introducing slashing disincentives for chain reorgs by validators—i.e. validators reorganizing blocks or their internal transactions. 

• Second, PoS removes the immense energy consumption and hardware waste  associated with PoW. Researchers estimate that Ethereum’s energy use will drop by up to 99.95%. A tiny fraction of regular commodity hardware will replace the current set of ASICs and GPUs that currently run Ethereum consensus. These two effects will lead to a more energy-efficient, diverse, geographically distributed, and antifragile set of consensus participants.

• Third, Ethereum PoS sets the stage for sharding, a similarly significant protocol change that will separate the chain into many concurrent threads. Sharding supercharges L2 scaling efforts by increasing the blockspace available for data availability and settlement.

• Fourth, ETH priority fees that currently go to miners will instead go to a validator-controlled address on the execution layer. This means the ETH is immediately liquid. Given that full withdrawals of staked ETH will only go live in the Shanghai upgrade later next year, this is a significant improvement for validators with locked-up capital.

• Finally, the upgrade will reduce annual ETH issuance from the current net-3.5% to roughly net-0%.

The Path to the Merge

The first major event laying the foundation for the Merge was Rayonism, a month-long hackathon earlier this year. This effort simulated what the chain would look like after the Merge happens as well as how consensus / execution clients will talk to each other.

More recently, we had the Amphora interop. This week-long event continued to build on the success of Rayonism, but adding the crucial moment of transition from PoW to PoS. 10 client teams contributed, and by the end of the week, a devnet modeling the transition had been successfully run!

If you’d like to learn more about both events, check out Tim Beiko’s post “Amphora: A Major Merge Milestone.”

The learnings from that event have been incorporated into the latest release of the Merge specs, called “Kintsugi.” Concurrently, there is a long-lived devnet called Pithos. This will restart a number of times throughout Q4’21-Q1’22 to retest the moment of transition from PoW to PoS with the updated spec. Once this transition is reasonably stable, existing testnets like Goerli can be upgraded to match the spec.

Interested community members can follow along with "The Merge Mainnet Readiness Checklist, a comprehensive overview of the remaining tasks.

Shanghai Upgrade

Timeline → 10-12 months

One of the interesting things about Ethereum post-Merge is that though the chain ends up merged, the clients remain independent. This includes how they are architected, as well the teams that work on them. For validators, this means an abundance of choice. Each execution client can be combined with each consensus client, and vice versa, in every permutation. For fun, I put together a list of possible names for these combo clients here.

Independent execution and consensus layers also allow for uncoupled upgrade processes when needed. This nicely slots into the Ethereum philosophy of separation of concerns. In other words, several smaller changes are usually more manageable than one monolithic one.

However, the Shanghai upgrade will couple changes to both layers in order to make validator withdrawals possible. This allows validators to exit their ETH from the consensus to the execution layer, binding them together even more closely. Once the ETH is exited from the Beacon Chain, then it can be used just how people use it today: as a store of value, to pay for NFTs, or pay transaction fees. There are many other proposals being considered for the execution layer, but nothing has been formally accepted into Shanghai.

We won’t know the acceptable scope until we get much closer to the Merge actually going live.

Ethereum Research

Timeline → Ongoing

While the above is being specified, implemented, and tested, there are other parallel research efforts pushing Ethereum forward.

Data Sharding

After the switch to Proof of Stake, sharding is probably the most significant upcoming change to Ethereum. Note that current proposals are focused on data sharding, and not execution. This feature gives L2s much more blockspace to store data, but it wouldn’t support native user transaction execution like we’re familiar with on mainnet. Rollups today currently use Ethereum for this type of settlement operation. Foundational research for this type of sharding is less complex, meaning it can get to mainnet and supercharge L2s even faster.

Prioritizing data availability is in line with where scalability research and applications have already been moving over the past 18 months. A good crystallization of this possible future is spelled out in Vitalik’s Oct 2020 post “A rollup centric ethereum roadmap”. This is a nice example of epistemic flexibility in the wild!

At some point in the future, the community may decide to add sharded execution.

This remains an open research question.

State Expiry & Weak Statelessness

This area of research will reform how the protocol handles state. State refers to all user records, including contracts, tokens, NFTs, and addresses. In Ethereum today, users incur a one-time cost per transaction to remain in the state indefinitely. Long term, this is not sustainable.

Several proposals with different tradeoffs have been explored over the years, including things like state rent and ReGenesis.

One leading proposal is called “Weak Statelessness.” This changes the way Ethereum nodes hold and process state. Specifically, only block proposers would be required to store state, while all other nodes can verify blocks statelessly. Here’s how it would affect different user profiles:

• Users: Can discard state, but need to submit a “witness” along with their transaction. Witnesses are proofs that are sent alongside a transaction to prove that it is valid

• Non-Validator nodes: Can discard state

• Validators / block proposers: Can discard state if relying on a third party for block production

• Block Producers: No change, still need all state. Uses witnesses from users to craft blocks that contain valid state changes

The companion proposal is called “State Expiry.” Here, state can become inactive, or ‘expire’ from the active state, if not accessed within a set period. This could be ETH in cold storage or abandoned ERC20s a community migrated away from. If a user wants to reactivate their state, any sent transaction needs to be accompanied by a witness. One benefit of limiting the active state size is that nodes should be more manageable to sync and maintain.

Both of these concepts are being actively researched, benchmarked, and implemented with Proof of Concepts. Dive deeper into current progress:

• Link roundup from Guillame Ballet

• Links from the EthR&D Discord Guidebook

… and so much more

There’s so much more that I could write about, like EVM improvements and ways to harden consensus mechanisms, but we’ll save them for another post.

If you’re interested in working on these important problems, DM me for an invite to the Ethereum R&D Discord.

Or, you can dive into the long-form EthResearch forum.

🙏 Thanks for reading, and to Danny Ryan, Tim Beiko and Mario Havel for reviewing.

Taipei Ethereum Meetup presentation

Vitalik recently presented his thoughts on Rollups and the problem of Data Availability as related to Layer 2 solutions in both Ethereum 1.0 and 2.0. His talk contains some fascinating constructions that will likely see further iterating from teams in the space. This a crucial area of research because trust-minimised blockchain scaling mechanisms are still sorely needed for projects looking to grow their userbase. If you have the time I recommend listening to the full talk.

Slides

PREVIOUS RESEARCH

The foundational concepts that this talk builds on first surfaced in an August 2018 post by Vitalik, crediting “availability engines” to Justin Drake. In September 2018, an ETHresearch post expanding on the topic received significant discussion. In January 2019 a collaboration between EF researchers and Matter Labs produced a proof of concept called Ignis on the Rinkeby testnet. Here’s the original post from the teams and a Trustnodes interview / demo.

Here is a great talk from ETHDenver 2019 by Alex Gluchowski and Kent Barton with more details on the Rollup mechanism: Scaling With Zero Knowledge. There is also a good exploration on the differences between SNARKs and STARKs.

Finally, it looks like Matter Labs is continuing their work on scaling via snarks thanks to an EF grant — check the announcement here along with more resources.

I’ve typed up a rough transcript of Vitalik’s talk below that tries to capture the essence of each section. Hopefully people find this useful.

BACKGROUND / MASTERCOIN

• Here’s a new kind of L2 construction — not the same as L2 for scalability (plasma / state channels) — which uses BC as a place for data storage and not computation. Computation can be done with zk-snarks.

• Some history: think of Mastercoin as a meta protocol on top of BTC. Defines a different set of rules for interpreting tx. BTC is data store but not state execution. Special txs can be denoted by a flag.

• Drawbacks to Mastercoin: Not light client friendly (need BTC blockchain and Mastercoin node). Activity in MC protocol cannot influence BTC chain, which limits overall functionality

• Now we have ETH 1.0 and soon™ we will have ETH 2.0 — can we do something similar to Mastercoin?

ZK ROLLUP

• ZK rollup (not ignis, not ignis plasma) can help with scalability by a factor of 30 today, higher in the future. How it works: Onchain contract only stores one value: the merkle root of a merkle tree

• Users send txs, which are gathered by a special actor called a relayer and put into a zKsnark. Publishes previous state, new state which includes transactions that were bundled together

• Is this similar to Plasma? (both are contracts that hold merkle roots) Difference is that Plasma needs complex exit games / withdrawal periods in order to deal with possibility of malicious operators (data availability)

• No data availability problem with zK Rollup because all transactions are published to chain, without signatures

• 13 bytes per publish X 68 gas per byte = 884 gas versus current cost of 21k for simple tx currently

• Instead of having ETH mainchain verify each signature transaction, the zKsnark proves tx validity. Computation and storage is moved offchain. Merkle root stays onchain. This avoids central operator / relayer. Because the data is published onchain, anyone can verify.

• This can be improved by not including nonce, removes 2 bytes (11 bytes per publish X 68 gas per byte = 748 gas)

• Note: instant deposits and withdrawals. Withdrawals: Coins are moved from their merkle Branch to mainchain and then merkle root updates. A deposit would be the inverse, but additionally gives the user an account ID. There would possibly be many floating around.

• This construction could increase simple payments from 15 tx/s to 500 tx/s, relatively safely.

• One takeaway from Stanford 1.x workshop (recorded livestream) was that data is overpriced relative to other operations. Though there are concerns with state, adding 1 kb to the blocksize will not make things much worse. Possibility that in Istanbul the gas cost of simple tx will be reduced, thus increasing throughput of ETH 1.x to over 1000 tx/sec

TAKING ROLLUP FURTHER

• Rollup should be able to support more complex state transitions, including things like Uniswap, high performance exchanges, multiple tokens, privacy preserving computation, ENS — all using “SNARK + publish tree details” paradigm.

ZK ZK ROLLUP (Bose–Einstein condensate 🙃)

• Basic idea: take ZK rollup but with mini version of zcash inside. (primer on zCash: users publish txs with SNARKs saying “I have a valid spend certificate for some coin hash in the state. Here is a new coin hash”

• zCash, continued — user has secret S, coin hash: h(s + 1), spend certificate: h(s + 2). SNARK proves that the spend certificate belongs to an existing coin, but not which one. Verification function should also check that spend certificate has not been revealed

• The relayer wouldn’t be publishing txs, it would be publishing receipts (105 bytes X 68 gas = 7140 gas per tx). Here we put a single SNARK which verifies that for every single tx included there is a SNARK attached (one level of recursion). Verifying SNARKs onchain, it would require 500k gas

BEACON CHAIN — PHASE 1

• What if we wanted to do more? Enter Beacon Chain phase 1 of ETH 2.0. Shard chains as data-only chains means 2.8 MB/sec of data availability

• Each zK zK rollup is 105 bytes / meaning 27k privacy preserving transactions / sec if fully consuming the 2.8 MB. If we don’t care about privacy then that 27k increases by a factor of 10

• Get rekt scamcoins LOL VB can’t even choose which is the worst at TPS claims

• The barrier is that these systems rely on data and computation (albeit a tiny amount). ETH 2.0 (Phase 1) doesn’t have computation but lots of data, whereas ETH 1.0 has computation: Let’s bridge the two.

ETH2 IN ETH1 LIGHT CLIENT

• ETH 2.0 research team has spent a lot of time making the 2.0 architecture light client friendly

• Requires 80kb of merkle branches per 9 days when persistent committees switch (also could be amortised over 9 days), plus 500 bytes per header

• Would need BLS-12-381 precompile in ETH1 clients

• ETH 1 chain could be computation layer that hooks into 2.0 chain, requires that data for roll-up schemas be published on 2.0 chain

OTHER USES FOR SCALABLE DATA AVAILABILITY ENGINES

• Plasma chains w/ much more frequent commitments, Dapps storing messages onchain, blockchain protocols w/ independent (“sovereign”) state transition functions piggybacking on Ethereum for Data availability

SPEEDING UP CROSS-SHARD TRANSACTIONS

• Weakness of current sharded design: communication between shards has a delay (waiting for crosslinks, ~6 minutes)

• The rough proposal to get around this latency is a mechanism that allows one shard to see the roots of another shard. This would probably work most of the time

• A quick exploration for when users want to transfer tokens between shards: they can publish tx to smart contract with root ( containing an expected token transfer), along with a security deposit

• “merkle root of shard is 0x12345 and I agree to lose 100 ETH (the deposit) if this claim is wrong”

• In the context of the registry storing token balances, user who posted 100 ETH deposit (while waiting for x-shard transaction to come through) then has their balance updated to a conditional state: if state root claim is correct I have x + transferred amt, if not correct I only have original amount (minus forfeited ETH deposit)

• Think of it as quantum superposition inside of SC (storing both states / both possibilities). Only resolved once contract becomes aware of state root of original shard via crosslink

• This superposition can then be transferred between users without them knowing (wallets would show optimistic values until ~6 minutes later and the crosslink were actually sent through)

GENERAL PURPOSE PRIVACY

• ZEXE: a UTXO based system that preserves privacy

BENEFITS OF LAYER 2 COMPUTATION

• Philosophically, Layer 1 does not need to be overly complex to optimise properties — block-times, x-shard communications, x-shard synchronous messaging support, privacy, etc

• Theoretically ETH 2.0 Phase 3 might be sufficient forever, no need for super quadratic sharding

• Exception would be increasing shards or updating cryptography

• Other blockchains have made this claim but the reality is once you have scalable data availability and enough expressivity at least to verify zKSnarks and state transitions (minimum threshold for power and complexity)you can build all necessary L2 on top

• L1 might get harder and harder to change, but this is fine for computational L2 if they are on top of scalable data availability (2.8 mb / sec)

QUESTIONS

Q: Doesn’t L2 stuff preclude turing complete languages / won’t work with zKsnarks?

There’s a difference between math definition of TC vs what crypto community means. Math: TC means computational lang. That are so general that you can’t tell when a computation will stop (Snark needs to know this beforehand)

Crypto: uses TC to mean expressive enough to make applications with complex internal state (plasma, makerdao, uniswap, verification engines for these L2) BTC can’t do these things, ETH can. ZEXE is UTXO based model but can as well.

TC is the wrong word but it is the case that you can do things that are expressive enough for constructing applications inside of zKsnarks.

Q: Should we be worried about the 30% hash rate loss during the bear market?

It is an issue but not something really to worry about. ETC (Ethereum Classic)has been attacked but only has 3% hashrate of ETH chain. If it becomes a significant concern then Phase 0 can be used as a finality mechanism for the 1.0 chain POW clients. 51% attack would then only allow censoring blocks, not reverting blocks

Q: There will always be competition between degree of decentralisation between base layer and Application layer. Does data availability and SNARKs always mean centralisation? [partially inaudible]

This new class of L2 is interesting - doesn’t need to solve for data availability issues. Centralisation can be reduced. Compare Plasma and Rollup: Plasma data availability problem means there needs to be an operator, who can then waste users time with 2 week coin lockup if malicious. Rollup has no data availability issue bc if a relayer disappears, another can quickly take their place. Possible harm is reduced, L2s like Rollup are part of the solution.

Q: Are you considering two phase commit protocol [inaudible] when doing cross-shard communication?

Contract yanking helps to solve train and hotel problem. (interacting with 2 objects on different shards) Should the ETH chain support synchronous on L1? No, it introduces too much complexity.

Right now, between two crosslinks you can calculate the state transitions in a shard as being a function of the data in a shard and the beacon chain. Doesn’t depend on what happens in other shards

Having synchronous cross-shard calls breaks this invariant, makes state calculation game much more complicated, though you could implement a L2 like Rollup that would help support synchronous cross-shard calls.

Q: What is the relationship between “third-party” L2 solutions (Celer) and other Ethereum L2 solutions?

Celer is a L2 that provides its own data availability solution, Plasma also does this. Rollup does computation offchain and has data availability handled onchain. Has different tradeoffs.

Find me @trent_vanepps on twitter for discussion or corrections. ✌

Serenity session at ETHMagicians: Paris 2019

Participants: Mehdi Zerouali (Sigma Prime), Diederik Loerakker / Protolambda (independent developer), Zak Cole (Whiteblock), Justin Drake (EF), Carl Beekhuizen (EF), Yannick Luhn(Brainbot), Greg Markou (Chainsafe), Lane Rettig (EWASM)

Facilitated by Lane Rettig and María Paula Fernández.

Note: the dialogue has been modified and condensed for easier readability — this is meant as a rough transcript. Please reach out to the people mentioned on gitter if you have more specific questions.

1. Transition from 1.0 to 2.0: are any hard forks required?

Justin- Zero hardforks are needed. The only prerequisite would be to set up the deposit contract on 1.0. However, a hard fork on 1.0 could add the functionality of finality taken from 2.0. This allows issuance to be drastically reduced (factor of 10 or 20, near the security of Ethereum Classic). Every 6 minutes the chain is finalised, conceivably could come to rely only on transaction fees. Other benefit from finalisation is fungibility of the ETH token, two-way transfer between the two chains.

Finalisation of blocks is an independent effort from 2.0. It is key that 1.0 clients are aware of the 2.0 chain — this is either as a full node of the beacon chain OR by being a light client of both. It will take time for this to occur, perhaps near Phase 1, sometime next year.

2. Transition from 1.0 to 2.0: what is the path for Dapp developers?

Greg- It might be too early. Could drain resources from both researchers and dapp developers to explore this now.

Zak- Agrees it is too early, the spec isn’t entirely complete yet. No defined function for peering / communication mechanisms. Network layer needs to be solid before looking at application layer.

3. Transition from 1.0 to 2.0: what is the timeline for dapps testing their work?

Mehdi- The only thing available soon will be testnets. Lighthouse will have a testnet within the next few weeks. It’s too early to guide dapp developers on what their dapp might look like on 2.0: the EVM is deprecated by EWASM. Developers should look into EWASM.

4. Token moving from 1.0 to 2.0- what does that look like?

Justin- Deposits can be between 1–32 ether, these are locked in the deposit address (burner address). Within the beacon chain if you are not actively validating you can transfer between addresses (perhaps for arbitrage). This is purely a system chain, with no user transactions.

5. Will there be economic abstraction in 2.0?

Justin- Initially the beacon chain will have very limited throughput at 16 txs per block. Wouldn’t be a great mechanism to abstract fees. One research idea is a single unified Plasma chain to pay tx fees on any shard. This removes need for ether dust on every shard to pay for transactions. This problem of fee abstraction is more pressing in 2.0 than 1.0 (note, I think there may be a slight disconnect between the question and answer. Typically this refers to paying system transaction fees in something other than the base token, e.g. tokens paying tx fees in the place ether).

Carl- The beacon chain can be considered a state machine: not designed for arbitrary computation, with a finite actions and systems to update. Not designed for general purpose computation.

6. Will the randomness produced by the Beacon Chain be available to smart contracts (e.g. a dice game)?

Carl- Yes. We now have a secure random beacon that can be used across the chain by dapps. Unbiasable and with the same properties that are used in consensus.

7. What will happen to smart contracts that are on 1.0? Migration?

Justin- If you have a 1.0 contract with a long projected life, the 1.0 chain will most likely live on for decades. However, it’s important that it remains sustainable, issuance needs to not be that high. This can be accomplished through 2.0 finalisation, might be able to live on transaction fees alone. Other approach would be to embed 1.0 chain as a contract within 2.0 — this seems ambitious as an engineering question. Is it worth the time and effort?

8. Will the ETH 1.0 chain be isolated?

Justin- At the very least you would be able to transfer Ether between both chains.

Carl- Merkel roots of data from ETH 1.0 chain can be included on 2.0 chain (proving accounts).

9. Why is it necessary to reduce issuance on 1.0? If there is a chain reorg on 1.0 a year into the new chain, how would that affect 2.0?

Justin- Issuance can be reduced because 1.0 is finalised by 2.0. At most it could be a 6 minute reorg from a bad miner. Issuance should be reduced because it is expensive for investors to get continuously diluted — ideally would be .5% for the entire Ethereum system. Secondly, it is environmentally expensive. With POS you get better security for a cheaper price.

10. For dapp developers considering other chains who may launch sooner, how will this affect the 2.0 product?

Greg- We live in a multi-chain future. If dapps want to move to other chains they will, but their users might not. Layer 2 solutions will likely fill that deficiency before forcing dapps to move to other chains.

11. Could the deposit address on 1.0 be read by contracts on 2.0, allowing for some communication? What does the migration path actually look like?

Carl- Goes back to the idea of using merkel roots to include data, same conditions apply if 2.0 is finalising 1.0. Long term it depends on what happens with 1.0 (1.x, EWASM), if there is a WASM interpreter running in a shard then data will be more accessible.

Zak- Keep building / developing as you are, but anticipate that you may have to restart / redeploy on 2.0. Will present fewest vulnerabilities and security issues.

Diederik- If the 1.0 chain keeps running, you wouldn’t want to run on both at the same time. May want to stop support on 1.0, take state roots of the dapp and reinitialise on 2.0. Doesn’t need to be defined in the protocol.

12. How would you know which shard your contract gets deployed on? What do cross-shard calls look like?

Carl- It will be your choice, each will have different gas markets which will lead to economic load balancing.

Lane- Considered baking the load balancing into the protocol but it was incredibly complicated. Population density / cost of living analogy. Higher densities might have network effects but there are also costs associated with it. Yanking will also allow for asynchronous contract movement between shards.

Justin- Cross shard calls is a design space with tradeoffs, no single answer, like Plasma. People will try different things and standards will emerge. One thing to consider is that there will be basic infrastructure at the protocol layer in the form of crosslinks. This is a way for every shard to have light client access to other shards. Most likely there will also be basic asynchronous cross-shard calls. This works by having a special contract on each shard that burns ether sent to it. The burn generates a receipt which can then be consumed on the shard on the other end of the transaction as soon as the sending shard has been finalised through the beacon chain.

13. Would transactions (contract calls) spanning multiple blocks be feasible or is it better to deploy all contracts a tx might touch on a single shard?

Justin- Latency from basic infrastructure would be one epoch, 6 minutes. To get anything faster you can also experiment with optimistic approaches. Assume that the checkpoint will be finalised but don’t wait for it, and then layer your next actions on top of that. If for some exceptional reason this does not occur there would be a revert mechanism built in. The design space opens up here — you can trade off certainty of execution vs. latency.

14. As core researchers how can we listen to and respond to the concerns of dapp developers?

Lane- Reddit AMAs, had a 2.0 AMA recently.

Justin- One of the biggest concerns for 2.0 will be storage fees. Good news is that there is movement in the form of 1.x which will help give feedback. This also applies to the Plasma research, state channels, etc. Getting close to world computer will require these Layer 2 solutions.

Lane- None of the 2.0 work requires a 1.0 hard fork, however, there will be experimental efforts like storage fees that will likely take place via a 1.0 HF. EWASM is also important on this front.

15. VDF (verifiable delay function) ELI5? What is the difference between a VDF and POW today?

Justin- We need VDFs to get a very high quality of randomness. RANDAO gets a pretty good version but these together get basically perfect randomness. ELI5: There are ~100 people in a dark room, with a die in the middle. They are asked to roll the die, however some do not participate honestly because they are asleep or malicious. They cannot see the die. If there is only one honest person rolling the die, then the end result is no one can know what the final value will be. VDFs provide a mechanism to keep the lights off for a preset period of time and not before. It’s an artificial delay mechanism for seeing the unique answer that will only be seen at a future time. Malicious actors are constrained by physics.

16. What is the perceived value with VDFs?

Justin- Originally the idea was to harden the consensus layer because RANDAO is vulnerable to two attacks. In RANDAO, the last entity invited to reveal in an epoch can choose to not reveal — this biases the randomness by one bit. In the “last revealer attack” if they somehow manage to control the last 3 slots, then they can control 3 bits of attack surface (8 random number possibilities). If randomness can be biased in one epoch, malicious actors can use that bias even more in the next epoch —meaning you push your slot closer to the reveal period. This is called the “amplification attack”: if you control 35% of the stake, you would be able to put yourself in the last revealer position 50% of the time.

To address these biases at the protocol layer, we have security margins. One way is to have stronger assumptions, ie, that people are honest. If there were better randomness, your assumption that 70% of the network is honest can be reduced to 66%.

A second, more tangible value for strong randomness (VDF) is at the application layer. Would be incredibly important for something like a billion $ lottery, where one biased bit of randomness increases the odds of payout for large players.

17. How do implementer teams make sure your clients talk to each other?

Mehdi- Biweekly implementer calls help to coordinate the teams on development. In terms of the protocol layer, there are also test vectors set by the Ethereum Foundation which each implementation is on par with the specification. Will hopefully see a multi-client testnets in a few weeks time.

18. What are the biggest challenges facing implementers?

Mehdi- Funding. This problem is not unique to the Ethereum space, affects all of open source. Need to find sustainable business models. Another challenge is balancing between their current work and staying up to date with the spec.

Greg- The Chainsafe implementation in Javascript has seen issues with numbers. How to properly handle this with regard to communication between clients? Also difficult when the spec is not versioned, however this has been fixed recently by the research team.

Mehdi- The naiive implementation of the spec would not work, would require a lot of optimisation. This is a requirement on top of the spec implementation.

19. When should specification optimisations occur?

Diederik- There is a tradeoff between optimising prematurely or researching for a better solution.

Carl- From a spec writing perspective we have optimised for readability. It should be easy to understand. The research team has been moving away from a plaintext script towards python executables (exe). They want clients to come up with different optimisations to solve problems in different ways. Trying to avoid all clients failing in the same way and possibly missing better optimisations. If everyone is focused on different methods of achieving the naiive spec this is probably better for the health of the ecosystem in the long run.

Greg- We need client competition to a certain degree. Client specific optimisations on top of a barebones spec leads to different tradeoffs.

Mehdi- Simplicity was certainly a design goal for Ethereum Serenity. The spec does not necessarily need to have all client optimisations built into it. He views the client as a public good.

Lane- It’s part of the Ethereum ethos to have multiple implementations (as compared to Zcash or Bitcoin). Important to point out that there have been consensus failures, it’s a useful method to catch bugs.

20. What is the advantage to having more than 2–3 client implementations?

Lane- There might be diminishing returns.

Diederik- In terms of ETH 2.0 it’s important that large groups of validators do not fail at the same time if their client has the same bug. Diversity is healthy for the validator ecosystem.

Zak- Language differences play a part. Different clients can be more modular depending on the usecase. There is a lack of standards / specifications for what clients are required to do — will lead to healthy competition.

Greg- Diminishing returns are real, probably already. First, the spec is not quite finished and bugs are being found. Case in point, being able to transfer on the Beacon Chain activates validators and then they are being slashed because they aren’t aware. Second, readability is huge. The spec is complex, not everyone knows Rust. Third, contributions to upstream libraries. All the teams need libp2p so all each language is completing what they need, leading to a more unified feature set. (Looks at camera: Dean, we don’t need a client in swift)

Lane- Readability is important. The yellow paper is challenging to understand, he finds the Trinity source code easier. Reading the client implementation might be easier than digesting math for developers. There is also other types of experimentation going on, e.g. business models.

21. What project coordination would be helpful for both developing the spec and helping across teams?

Greg- Happens in gitter or side communications between implementers. The researchers are doing an incredible job letting people know what’s up, Danny especially. We’re still in the research phase, though very close to finalising. Additional formal coordination isn’t necessary quite yet, perhaps when the cross-client testnets are closer it might be more important.

Mehdi- Agree, Danny is doing an amazing job. It’s also difficult in a decentralised environment because no one formally told him to do it. Wouldn’t work in a commercial context, a researcher acting as a project manager would be unheard of.

Greg- Implementers call standup gives a good enough of an understanding between client teams. With a cross-client testnet it will come down to implementers chatting with each other.

Zak- A working multi-client testnet has been challenging. Need conformance tests, performance metrics, functional docker files. Might be good to have Cat Herders coordinate a multi-client testnet, should not be the responsibility of the client developers. Please try to move away from writing everything to memory.

Diederik- Need to shift from single to multi-client testnets. This is difficult because there is still undefined pseudo-code in the spec. There are plans to formalise these parts of the spec. They want big picture test vectors to make sure clients generally confirm state transitions and also agree on networking.

22. What is the ETH 2.0 roadmap? How has it evolved?

Justin- The roadmap is bigger than the spec, which only refers to Phase 0. The roadmap has evolved significantly over the years, up until recently it was primarily driven by the research team (Vitalik and Vlad mostly). The roadmap is changing in relatively smaller ways. One example is the addition of transfers — will the BETH token be fungible, will there be tax implications? It was a low hanging change. Phase 0, 1 and 2 are pretty well defined — what come after is more blurry. They would like to have a quantum secure chain after that, part of the reason they gave the grant to Starkware. Starks are probably powerful enough to handle all of those problems, including signature aggregation (replacing BLS signatures), can be useful for VDFs. Another non-quantum secure part is randomness — whereas right now they use BLS signatures, there is a new design requirement for ETH 2.0: it should be friendly to MPCs (n of m staking pools).

23. What’s one thing you would change about the roadmap if you could?

Diederik- In the short term, from Phase 0 to 1 there is room for concurrent research on how shards can be upgraded individually.

Mehdi- We had to throw away a lot of Rust code but we learned a lot, it’s fine. One thing they would have done differently is to maybe wait until a release candidate was ready. Much better now with releases and a change log.

Greg- Disagrees with the Kyokan report claim that there isn’t input from implementers to researchers, he can still ask questions.

Zak- Thinks there should be more formal verification. Should be a feedback between formal verification and the eventual spec changes. Formal verification is is like establishing a blueprint for a building. Should occur before construction begins.

24. Is there any interaction between the EEA and the ETH 2.0 efforts?

Zak- There is not much interaction or interest in 2.0. They are focused on enterprise implementations, 2.0 seems too far into the future. Too early to say what will happen in the future.

25. What is the best way to approach “execution engines” in Phase 2 (look at EVM, consult with dapp devs)? Where is the best place to discuss these ideas?

Zak- ethereum-magicians.org OR ethresear.ch. Gitter is a great place to voice your opinion.

Greg- For dapp devs they can still contribute to EWASM issues, join some gitters, github issues. Just because you don’t write code doesn’t mean you can’t contribute.

Lane- All avenues are developer friendly, perhaps not for non-developers. Cat herders are a great way to get involved if you are non-technical. Build a design ring if you are a designer.

Hopefully people find this helpful. Thanks to Fluence for livestreaming and Lane / MP for facilitating. If there are any errors or inconsistencies, comment or message me. I can also be found here, looking for work.

Quick summary of key takeaways from Episode 66.

The Zero Knowledge podcast consistently puts out fantastic content and I recommend checking out their archive. Episode 66 featured Danny Ryan of the Ethereum Foundation and focused mainly what ETH 2.0 will look like and the process to get it to where it is today. If you are able, take the time and listen to the full thing.

I pulled out things I found interesting for others to reference. This writeup assumes general knowledge of the Ethereum ecosystem and blockchains in general. Some of it paraphrases Danny’s words and some is my own commentary. Let’s jump right in!

GUEST BACKGROUND

• Danny Ryan is from Louisiana.

• He fell into the coordination role somewhat by chance because people found he was the only one to respond to their questions.

• ETH 2.0 is acknowledgement that while Ethereum in general is awesome, there is a ton to learn from recent research. Evolution is necessary to remain a viable, system built on best practices.

ETH 1.X

• Whether ETH 1.x becomes a shard is really a community question, a research question. Though there are some technical challenges depending on the option.

• Option 1: Roll ETH 1.0 into 2.0 once it reached an acceptable stability. (but how?)

• Option 1A: 1.x as exceptional shard construction — however, separate rules from other shards and a legacy code base is really bad combination. Also wouldn’t be compatible with forecasted need for state fees.

• Option 1B (favored by danny): write EVM interpreter in WASM. deploy as contract on ETH2.0— fork state root into contract and ether balances, then users can interact with 1.0 state by providing “merkel witnesses.” The community could then deprecate maintenance for ETH 1.0 but still interact with the historic state. Stateless nature means there wouldn’t be any issues with state fees.

• Option 2: allow legacy chain to operate in perpetuity. At this point there is potential to use ETH 2.0 to finalise 1.0, allowing mining rewards to decrease further.

• Option 3: Have mining rewards be a function of how much ETH is left on ETH 1.0

• Generally, he thinks there are “promises” that need to be upheld, like an Augur market related to Mars that expires in many years.

ETH 2.0 PREHISTORY

• At the beginning of 2018 there were two parallel upgrades under development: Casper FFG and a sharding manager contract. Both would have “enshrined contracts” within the existing ethereum state to manage the complexity of POS logic and maintaining shards.

• A lot of work was done on both options, Danny wrote EIP 1011. However, there were serious limitations to making both work on the existing chain. IE rate limiting (tx / sec) >> highly inefficient to process shards >> # of validators is limited >> in turn limits scalability and decentralisation.

• The research team also realised that these two “foundational games” might compete with each other for blockspace and economic inputs. There were also roadblocks with EVM inefficiency. In May 2018, there was a turning point.

• Some researchers took inspiration from other next efforts, including Dfinity. They needed to “break out of the EVM”, with benefits from more radical decisions.

• This blank slate decision allows both the community and economic weight to seed the new chain. The research team can move faster, unencumbered — it’s incredibly difficult to engineer a new design onto a plane in flight.

ETH 2.0 ARCHITECTURE

• Existing ETH chain will seed new POS chain that lives and exists in parallel. 1.0 will have a deposit contract (essentially a burn address). This emits a receipt that allows entrance to the beacon chain.

• The Beacon chain is the core of ETH 2.0, where: validators exist, rewards and penalties happen, blocks are finalised, shard crosslinks occur, RNG (random number generator) mechanisms live. Danny terms it a “spinechain” User accounts don’t live there, doesn’t have a virtual machine. (here’s an awesome simulation / visualisation I came across!)

• Anna asked how close it is to Polkadot’s relay chain. Danny says it is similar: It’s natural in POS systems for validators to congregate. This is where Casper and POS occurs, block justification and finalisation. POW doesn’t need this because RNG happens “extraprotocol”.

SHARD CHAINS

• Shards exist outside of the beacon chain. Analogous to ETH 1.0 but there will be 1024 of them running concurrently.

• Think of it like a growing tree, starting with the beacon chain as the trunk. Branches growing out are shards, sending water and energy (communications / txs) produced to the other branches via the central trunk. Leaves are addresses. (this seems like a really obvious analogy but I like how intuitive it is. Tell me where it breaks)

• Shard chains host accounts, contracts, state and state execution.

• Validators (on the beacon chain) are assigned to validate on a specific shard but also provide crosslinking between shards, approximately every 6 minutes. (spider webs or vines transferring kinetic energy?) They sit in small committees, ensuring that data is available between shards and helping to finalise points of the shard chain.

• The number of crosslinks you can fit per block is dynamic, depending on the number of validators. With 4 million validators, the expectation is that all shards will be crosslinked to each other every epoch. (every 64 slots, about 6 minutes).

• This method of communicating is asynchronous: meaning not occurring at the same time. It’s baked into the base layer. Synchronous calls cannot be included because it “explodes the complexity” in making ETH 2.0 work. Reorganisations on one shard could then lead to cascading reorgs on others. This would increase shard dependencies and increase system fragility.

• Alternatives include: synchronous L2 proposals or encumbrances (contracts on different shards both enabled to signal promises that allow an actor to claim an asset once the beacon chain catches up — lol someone audit this explanation).

INTEROPERABILITY

• Danny believes that interoperability is inevitable but cannot make a guess as to how many chains will exist. There might be long power tail of chains depending on their usage.

• Fredrik asks where interoperability lives within ETH 2.0: would Polkadot link into the Beacon chain or one parachain per shard?

PHASE 1

• This phase is where the system adds shard chains and data consensus.

• There is also the possibility of finalising the ETH 1.0 chain via ETH 2.0. Requires 1.0 clients to be light clients of 2.0 — this allows the most recent state root to be exposed. That way, clients on 1.0 can make claims about 2.0 data via Layer 2 mechanisms.

• There is also a concept of “economic load balancing”, simply meaning that contracts / accounts on expensive shards will eventually self-distribute to less populated shards. This doesn’t guarantee complete homogeneity in shard traffic but will be a strong influence.

• “Yanking” might be used to move correctly enabled contracts between shards.

• Phase 1 research (shard consensus) is happening concurrent to the regular Phase 0 spec releases.

SPEC EVOLUTION

• About 6 months ago the spec transitioned from a research to engineering project.

• Research out in the open is a little different — feedback comes earlier in the process and more frequently.

• After Casper deprecation it has settled into an iterative process, making things more elegant. Since September the focus has been on fitting together research components in a sane way.

• There have been too many teams jumping in last fall — Danny suspects he may have been a little early to signal that. Either way he is very proud of attaining a concrete Phase 0.

• Overall, the process was “mild chaos”. Working in isolation at the beginning (on a private document) meant that big decisions could be made quickly. Operating on Github, teams are now been able to dialogue with research as it happens — hardens up the protocol.

• Bikeshedding has been an issue (see serialisation discussions). EF does have a leadership position, can make strong suggestions. Danny is beginning to err to ship mode, even though there are smaller optimisations still being suggested by client implementers.

• Over time they may introduce a more formalised EIP process for 2.0 development.

CLIENT DEV TEAMS

• There is a lot of excitement from the teams. Competition exists where devs are able to optimise for specific user groups (miners, archive nodes, resource constrained devices), API buildouts, validators interfaces, multiple node connections, languages, additional baked in tools.

LOOKING FORWARD

• Putting hard release dates are dangerous. Danny expects Beacon Chain to launch in 2019.

• Within the next two months there will be viable beacon clients and short-lived testnets. Hopefully this leads to longer-lived testnets. Appreciates the structure of Cosmos’ Game of Stakes. Might be valuable to set up similar adversarial environments and attempt to collude.

• Phase 1 is not too complex / difficult. Should follow shortly after, a lot of these efforts are moving in parallel. Working with EWASM team for Phase 2 spec.

• Important to note — there is a lot of concrete gains at each Phase / iteration. But it’s equally important to remember that ETH 1.x still exists.

Thanks for reading through, hope you found this rough transcript useful! If you find any inaccuracies shoot me a message here or twitter and I’ll fix it.

If you want to get involved in the Ethereum 2.0 efforts, please check out ethresearch, the sharding gitter room. You can find the hosts Anna and Fredrik on Twitter. ✌️ 🙏

Scaling Ethereum through ephemeral economies

To date, scaling Ethereum has taken two forms: Layer 1 client improvements (L1), or Layer 2 (L2) mechanisms. While L1 scaling is realised through incremental code upgrades, L2 comes in the form of higher level external systems that leverage the greater security of the basechain.

Canto’s unique value proposition emerges as a hybrid with a foot in both camps. Simply put, client changes in the form of a new L1 subprotocol would enable L2 mechanisms to bloom more easily. The spec was recently released to the ETH Magician’s forum, check them out below:

• canto-ethereum/spec (broken link)

• CANTO: A Scalable Blockchain System Interconnect Model

I highly recommend reading both in full, as most of the information in this overview is taken in some form from there. If you’re short on time or technicals, follow along as we jump into what makes Canto an idea worth pursuing.

ORIGIN

The idea for Canto came up over beers between Antoine Toulme (Consensys) and Zak Cole (Whiteblock) in November 2018. Their discussion focused on a few roadblocks: ETH 2.0 is going to take some time and there’s no guarantee that ETH 1.0 (1.x) improvements would all be implemented. How could they help push Ethereum forward with the current environment? From this frustration Canto was born. The name comes from poetry, referring to “one of the major divisions of a long poem.”

Following this initial brainstorm and some work, Will Meister (Consensys) and Daniel Choi (Whiteblock) were brought in to hash out some of spec details.

ARCHITECTURE: SUBPROTOCOLS

Conceptually, Canto is simple: the proposal hinges on a new Ethereum subprotocol. Every up-to-date ETH client includes four subprotocols, denoted by a short prefix: eth, les (light clients) shh (whisper), and bzz (swarm). The subprotocols facilitate important activities onchain in addition to the basic functions of the network.

Here’s a quick analogy. Imagine a client as a smartphone that only has 4 apps installed. Connecting users is limited to the design of only these 4 apps. Of course, this smartphone still allows people to do productive things, but what if another app could be added? Canto’s new app is a subprotocol named “can.”

“Can” would allow the creation of subnets, a catch-all term from networking: if Ethereum is the top-level network, Canto makes sub-networks that reside within it. These are flexible constructions that allow incredible design diversity, encompassing the potential of Plasma-like sidechains, novel testnets, ephemeral interactions, channels, games, and more.

Being embedded within a client at L1, but also facilitating an expressive L2. It permits mainchain to subnet communication while in the form of a client-integrated mechanism generator. It’s difficult to overemphasise how beneficial this arrangement is when compared to Plasma chains that have gone live. These require extensive coordination between operators and validators, maintenance, and monitoring to remain viable. While there are benefits like dependability and security, the marginal cost for each new chain is still quite high. This prevents rapid iteration and optimization of parameters for unique uses.

Here’s a rough equivalent: the role the ERC20 standard played during the 2017 runup. A thousand flowers (and some weeds) bloomed:

While some projects may have considered launching their own chains, the absence of hash-security combined with the network effects an ERC20 utility token precluded the notion (exchange support, existing high-quality code, etc.). Similarly, Canto could facilitate the coordination node services, operators, validators and users in a streamlined mechanism. Granted, hindsight shows that the majority of ERC20s were poorly designed, unnecessary, or outright scams. For better or worse, the barrier for ephemeral economies has dropped significantly.

A final comparison between ICOs and Canto is the role of ETH in this ecosystem. ETH from fundraising served first as operational runway for legitimate efforts, while the less scrupulous took large paydays and ran. Comparatively, Canto allows ETH to remain onchain as a staked bond placed in order to create the subnet. This further removes the need for high-stakes fundraising in deference to small scale experimentation.

The coordination process surrounding this creation would naturally accrue to marketplaces — see Livepeer’s Transcoder Explorer for a good example of service providers differentiating around a few simple variables.

In Canto, the design space expands from 1 to N dimensions. To start, there are the initialising parameters: consensus mechanism, privacy, gas economics, whether to implement research initiatives like state rent, among others. Will the subnet communicate with other subnets? How will node operators be rewarded? Templates, and template companies a la Wordpress, will spring up in and around these marketplaces. There is also room for the generalized mining narrative to thrive, as facilitators and supporters of subnet economies.

Second order effects of Canto, will be interesting to follow as it develops traction within the community.

SMART CONTRACTS

Every subnet begins and is maintained through the same core of contracts, hosted on the Main ETH chain — however, the spec section on Contract Creation is a better source for technical readers.

COMPARED TO PLASMA

Though Canto may initially appear similar to Plasma, there are some important distinctions between them.

Similarities:

• Both are L2 scaling solutions

• Both require some degree of coordination to kick off the network

• Shared challenges in the design of mass exit mechanisms (load balancer back to mainnet).

Differences:

• Canto ships with native flexibility when it comes to hardware and validator requirements. Discussed previously, Plasma requires significantly more coordination, whereas Canto might start as a wild west marketplace predicated on degrees of reputation.

• Smart Contracts on Plasma are a challenge — read “Why is EVM-on-Plasma hard?” from Kelvin Fichter.

COMPARED TO POLKADOT

Outside of Ethereum proper, Canto might also resemble Polkadot, a Parity project; again, there are important differences.

Similarities:

• Both are systems of smaller ‘dapp-chains’ that coordinate around a connecting base chain.

• Both enable smart contracts.

Differences:

• Canto is a ‘plug and play’ solution that runs within Ethereum, while Polkadot on a separate blockchain with a new architecture.

• Polkadot has a more rigid architecture that only allows for PoS — while the Ethereum basechain only permits PoW currently. Canto offloads onchain activity to to flexible subnets that can be PoW, PoS, PoA

• Canto’s subnets are “logically isolated from one another, responsible for their own security and function” while Polkadot’s parachains require interoperation in order to pool security collectively.

• Every parachain on Polkadot operates under on-chain governance. Canto leaves any governance (or lack of it) up to each subnet to decide.

REMAINING ROADBLOCKS

While Canto is conceptually straightforward, there are still challenges that might slow implementation and the growth of a mature ecosystem.

To start, there’s the actual process to get a subprotocol implemented in a client. Aside from “eth”, light client support launched in January 2017, Swarm in December 2016, when the fledgling ecosystem was relatively small. Given the push today towards ETH 2.0 (and ETH 1.0, 1.x), it’s fortunate that that Canto doesn’t require a hard fork. A single client is all that’s needed to start demonstrating utility, but getting one onboard will take some effort.

Additionally, exit conditions still need to be developed and iterated on. Hopefully the developers will be informed by the large design space growing around Plasma. This is an open area of research that will need careful attention prior to release.

I’m looking forward to seeing development progress over the coming months. Hopefully sometime soon the larger Ethereum ecosystem will get to explore the capabilities of subnets.

WHAT’S NEXT FOR THE TEAM

To start, they are continuing to build out PoCs in Java and Go. You can track their Github progress here (broken link).

Thanks to Antoine (@_tmio) and Zac (@0xzak) for answering my questions and being super helpful. Please reach out with questions below or on twitter. (@trent_vanepps) \n

fork by Estu Suhartono from the Noun Project \n \n On Friday (14.12.18), Hydro announced that they would be forking the 0x protocol and releasing their own implementation. This is the team behind DDEX, the largest relayer in the 0x ecosystem by volume. Among other things, Hydro believes the native token (ZRX) introduces unwarranted friction. Read the announcement from Hydro in full here: Why we are forking 0x.

A Layer 2 project having a token forked away has been discussed hypothetically, but this is one of the first times we’re seeing it play out in the wild. In the context of real tokens and projects with major capital backing, proposing a fork holds a fair bit of weight. Will this be a significant challenge, mutually beneficial, or just a bunch of noise for naught?

0x TOKEN (ZRX)

First, some background on the 0x token. Crypto tokens generally fall into distinct buckets, sometimes moving between buckets as limits are modified. Per the original whitepaper, ZRX was designed as a protocol, or utility, token: proper use of the platform and its services requires an integrated, native component. According to the authors:

Protocol tokens can align financial incentives and offset costs associated with organizing multiple parties around a single technical standard.

Beyond simple network effects, transaction fees paid to Relayers are denominated in ZRX. Encouraging continuous use of the token ensures it “converges on a representative sample of protocol stakeholders over time.” The primary intended benefit is to permit stakeholder participation in various governance activities. These include an ERC20 whitelisting process for trading on the platform, as well as an unspecified voting mechanism through which platform features are prioritised. Finally, there is an unmentioned use of the ZRX token — as a vehicle for fundraising. Setting aside current regulatory uncertainty, the 0x team was able to get significant fundraising via an ICO. This capital has allowed them to launch initiatives like the recently announced Ecosystem Acceleration Program (EAP).

The WP goes on to state that:

0x protocol and its native token will not impose unnecessary costs on users, seek rent or extract value from Relayers.

While architecturally and philosophically this may be true, it’s clear the Hydro team has a strong conviction that there might be a better way.

HYDRO CLAIMS (A WILD UTILITY TOKEN APPEARS!)

In their recent post, Hydro claims there are several issues with the current 0x platform, including order collision, front-running, and poor liquidity. These challenges have been pointed out by other users in the space, including the founder of dYdX, Antonio Juliano, in a recent tweet thread.

There are outstanding questions with ‘rolling your own platform’. Do these issues warrant an entirely new protocol? Or would 0x network effects and aligned incentives outweigh the desire for reduced friction? Could they have been resolved through active governance participation?

Somewhat paradoxically, the team already raised in excess of $31mm in a sale for its Hydro Protocol Token (HOT). Unfortunately for Hydro and its investors, the token is trading at significant discounts relative to the initial sale in January 2018. The uncharitable interpretation is that a new platform will support demand for HOT (read: price appreciation).

According to the Hydro website, there are several key differences when compared to 0x (accessed 14.12.18). They make no mention of fee requirements for each trade, instead intending to use HOT for liquidity pool membership, liquidity incentive mechanisms, and bounties for market makers.

Liquidity incentives could be structured similar to the Uniswap design (read under Fee structure), where providers are rewarded with a cut of platform trades. It is unclear whether Hydro’s fork will use HOT or another, like ETH or DAI, to facilitate these mechanisms. Additionally, they claim front-running will be punishable via an as of yet undescribed governance mechanism.

The public will have to wait until Hydro releases its implementation for further analysis; until then all there is to reference are open claims and past work on DDEX.

GOVERNING VALUE VS. VALUING GOVERNANCE

Hydro claims 0x has neglected their core competency by rapidly expanding into other domains, like Instant trade widgets, NFTs, and ironically, governance. Although 0x has consistently reasoned that integrated governance will allow them to properly accommodate stakeholder needs, they have not implemented this system yet. Had it been, 0x might have been able to accommodate Hydro’s improvements (provided they were a value add) This is a chicken-egg paradox, echoed in a recent twitter poll from Tom Shaughnessy:

Bitcoin has been around for 10 years, Ethereum has been live since mid-2015. The projects built on top of them even younger and it shows: new tech is hard, and these challenges won’t resolve on their own. Determining the structure of governance mechanisms will be an evergreen problem as long as protocols have stakeholders.

Chicken or egg? Governance or value?

It’s important to remember that 0x has been one of the top teams in the Ethereum DeFi space, enabling tons of new experimentation. It’s also worth pointing out that projects are rarely forked like this unless there is something worth forking. Hydro’s protocol may or may not supersede 0x in the future, and that’s the beauty inherent in open-source development and permissionless markets. If a protocol design is better/faster/cheaper, users will move whether they like it or not (liquidity begets liquidity). Tian Li, the DDEX founder, summarizes the sentiment well in their forking announcement:

We either make something people want, or we die. And that’s the way it should be.

The entire space is looking forward to constructive developments from both teams and the continued growth of the DeFi ecosystem. A few things to keep track of over the next 6 months:

• Will 0x feel pressure to develop and deploy governance processes faster?

• 0x may implement some of Hydro mechanisms where applicable (already some hints)

• Open question: Is there a better way to ensure live token distribution besides requiring fees in ZRX?

• Will forking out a project token (and potentially replacing it with your native token) become more commonplace? What projects are ripe for this to happen to? \n

For further context, 0x has released their response to Hydro, teasing some technical features that may match Hydro’s proposals and reaffirming their commitment to governance: link here.

Edit at 16–14–18 21:45 UTC: Here’s a link to an excellent perspective with thoughts on East vs. West VC cartels. (story deleted)

Make it clap if this analysis was helpful, leave a comment below or tell me my takes are bad on Twitter: @trent_vanepps 🙏

State of the Map-US 2018, OpenStreetMap and FOAM’s approach to the challenge of geospatial data verification

From Oct. 5–7th in Detroit, FOAM had the opportunity to participate in State of the Map-US (SOTMUS) as both sponsors and speakers. SOTMUS is an annual gathering for stakeholders of the open-source mapping community based on OpenStreetMap (OSM) in the US. You can learn more about what the organisation does here and here)

I attended the conference as a FOAM community member hoping to see the perspective of people deeply involved in the mapping industry. In this article I will:

1. Give a general overview of OSM and current data verification processes

2. Look back on our experience at the conference along with feedback and reactions from participants

3. Give a call to action for the OSM community on how FOAM can return verification back to local volunteers

WHAT IS OSM AND DATA VERIFICATION?

OpenStreetMap is an initiative started in 2004 with the intent to provide an open and free alternative to other existing mapping solutions. From Wikipedia:

“The creation and growth of OSM has been motivated by restrictions on use or availability of map information across much of the world, and the advent of inexpensive portable satellite navigation devices.”

People from all around the world have participated in mapping their local areas for the past 14 years. By and large, it has worked remarkably well. The OSM community has seen steady growth up to the present and over 3 million changes added per day to the global set.

One reason for OSM’s continued success in data collection has been the fact that anyone can join and edit.

“Contributors include enthusiast mappers, GIS professionals, engineers running the OSM servers, humanitarians mapping disaster-affected areas, and many more.”

However, precisely because of this open nature, there is always the problem of malicious users adding problematic data points; this includes data that is false, malicious or from copy-written sources (more on vandalism here). The most recent significant issue occurred at the end of August, where an OSM user changed the label for New York City to “Jewtropolis”. This was only one change of many, per the NYT:

“One of the [OSM] volunteers made more than 80 anti-Semitic or hate-oriented edits to locations around the world”

The malicious data ended up in front of end consumers that use the OSM base map, an outcome which they certainly would have liked to avoid. Problems of data vandalism, paired with other issues like raised rates elsewhere, have encouraged the growth of enterprise verification on top of OSM. Services like this clean and sanitise data before it makes it to subscribing customers. One of the more prominent companies performing verification is Mapbox, which sells access to their verified data to corporate entities, including Snap, the NYT, and Mastercard.

ENTERPRISE SOLUTIONS TO VERIFICATION

At SOTMUS, Mapbox presented a few of their solutions, one of which included quadrupling the number of human reviewers for every change they incorporate. Another encouraged the use of a central repository called OSMCha that many enterprise stakeholders would be able to use to cross-reference. Other strategies under development include AI and machine learning tools.

It remains to be seen whether these solutions will be both effective and financially sustainable in the long-term. Zooming out, we can see a larger issue, and one which the community has been aware of for a while now: the ethical dilemma of monetising access to data mostly provided by volunteers.

How can local knowledge be accurately represented and updated? What mechanisms can ensure fresh POI data? In his talk at SOTMUS, Lukas Martinelli from Mapbox acknowledged the paramount importance of local knowledge:

“In the end the local contributor knows best. there are languages we don’t speak, … cultural references only you get, and that’s where the community comes in and map gardening needs to get better, we need better tools for that .. that the community can see issues, flag them, fix them, and also mark those bad edits and their hotfixes.”

FOAM agrees — mappers need to have the best tools and most effective frameworks to be successful as the community grows.

The focus on enterprise solutions over time shifted the narrative away from the original OSM ethos of ground truth. Speaking with many attendees at the conference, it was clear that many others felt the same way — while great enterprise work was being done, it seemed like the passionate volunteers who had done much to grow the ecosystem had less and less influence. Are there alternative models that can return value to the users who form the backbone of the community?

WHAT IS FOAM’S APPROACH?

We were happy to share the larger FOAM ideals with the people who stopped by our booth. At its core, FOAM is about keeping data verification and the economic incentives in the hands of the geospatial community, in line with OSM’s original vision.

FOAM is about keeping data verification and the economic incentives in the hands of the geospatial community

To watch Ryan’s lightning talk on the FOAM map at SOTMUS, check out the first talk here:

Our first products are the Spatial Index and the recently released FOAM Map. Both components are complementary within the FOAM vision to construct a new Web3.0 compatible location protocol.

How does the POI mechanism work? Simply put, FOAM tokens are staked by mappers to a point, representing their confidence in the veracity of the POI data. Inaccurate POI data can be challenged by other cartographers. Successful challenges are then rewarded by distributing the previous stake to the participants that voted on the challenge side. For a more detailed dive on mechanics and incentives, check out this writeup:

By requiring an economic stake for mappers adding info, vandalism is not as likely to crop up — hopefully mitigating the previously discussed enterprise centralisation. The opportunity of data validation gets returned to the edges of the network; the users and volunteers. **Most significantly, map stakeholders gain an unprecedented ability to participate in network governance — how parameters are set and the data integrity maintained. **Active mappers now have a seat at the table, a virtuous cycle that compounds directly back into the network.

The FOAM model is open and free for anyone to use or contribute to — hopefully this article piqued your interest in participating. We would love to have anyone take a look at our first live product at map.foam.space.

Learn more about the issues and abuses of user location data in Web2.0 through this reading list.

TLDR: The motivations and demographics of the abstract user participating in incentivised systems are hard to pin down. This article attempts to better describe potential Zone operators for the FOAM network.

USER, OH USER — WHERE ART THOU, USER?

Crypto has an adoption problem. It has been continuously pointed out by critics, somewhat rightly so. For traditional startups, you either persuade users to adopt your product, or search for more capital — in order to get users. For crypto, suffice it to say that funding and deliverables may work via different mechanisms. It is still Very Early(TM) and many important foundational components are being built. However, that doesn’t mean we can’t speculate on the demographics of future users! Where are the masses? What will they look like when they finally materialise? For any emerging space, there’s a good chance appearances will diverge from initial expectations.

These questions are especially relevant for a project like FOAM: a proposed network of synchronised radio receivers that hopes to provide ‘unspoofable’ geolocation authentication. For this write-up, the focus will be on the active operators of the FOAM protocol, not the parties which are paying for location attestations.

As is the case with every crypto network, motivated parties are integral to co-creation as mechanism maintainers (h/t to Rhys Lindmark). This includes activities such as node running, staking, slashing, relaying, signalling etc. This subset of users facilitates management and expansion of each protocol. Likewise, the FOAM protocol will rely on a network of incentivized actors to initiate and maintain the system of Zones and Zone Anchors for Proof of Location (PoL) services. Find more details about these specific components in the whitepaper.

Similar to PoW networks like Bitcoin and Ethereum, technical knowledge will likely emerge as a precondition and may discourage people from participating (running specialised hardware, comfort learning new software / interfaces). Hardware details are forthcoming but generally it is expected to be the similar to the The Things Network, but using the DASH7 radio protocol.

It’s important to also understand that the final mechanism parameters (e.g. staking thresholds) the team decides on may result in unanticipated effects for future participants. For example, if capital requirements are too high for staking or hardware, smaller players could be pushed out by larger ones.

IF YOU MAINTAIN IT, THEY WILL COME

At first blush, people learning about FOAM may assume Zones will be maintained by independent individuals. However, there are good reasons to believe individuals may end up as a minority within the network; this isn’t necessarily a bad thing. If the mechanisms function as hoped there will be a healthy mix for all types of operators.

The following is a speculation on possible network operators, organised below according to their relative scale.

INDIVIDUALS: The desire for pure decentralisation is an overwhelming theme in crypto. The smaller the party, the less centralised — and a smaller possibility for cascading failures. Private homeowner / operators costs will be limited to hardware acquisition and a bit of person-to-person networking to set up the minimum: four Anchors for a Zone. Individuals simply looking to experiment with the technology might run one zone with family / friends in their city.

Motivations: tech enthusiast, decentralist ideology, anti-Big Brother, profit.

COLLECTIVES: Extrapolating further from individuals, it’s easy to imagine groups forming with the specific objective of coordinating local FOAM coverage. This type of organisation would strike a good balance between the scale of a large company but the local knowledge of individual operators. Local collectives are intrinsically motivated through skin-in-the-game incentives: their efforts directly lead to better Zone coverage in their city. Collectives would likely thrive in niches where municipal bodies are not interested in participating (lack of time, funding) and companies cannot justify the investment into smaller addressable markets.

Looking at other mechanisms within the FOAM ecosystem, also consider the benefits of pooled efforts with regard to curating POIs against malicious challenges, coordinating Zone placement for deployment efficiency, or signalling to maximise mining rewards (h/t Paul Momoh). These are clear benefits that could lead individuals to coordinate.

However, that’s not to say that there aren’t challenges present. Productive coordination layered on top of the base layer protocol incentives would require a form of consensus. Governance, the lurking bugbear of decentralisation, would certainly follow. The difficulty, of course, is to not allow the subsequent petty politics to remove the advantages achieved through coordination. Fortunately, there are many projects building tools for crypto-native strategising, including Aragon (Luis Cuende), Colony, and DAOstack. It’s exciting to imagine possible synergies within the crypto-petri dish.

Motivations: Local civic pride, community growth, profit.

INSTITUTIONAL ZONES: This set includes malls, office parks, university campuses, industrial parks, Special Economic Zones (SEZs)— large expanses of private or limited access space.

One interesting condition here is the possibility for a non-competitive fee market. Imagine a sprawling manufacturing property that accepts sensitive deliveries. Their Zone is the only one accessible at that location, and they require location authentication upon delivery of goods. That is, prices for attestation may become artificially inflated given a monopoly over local nodes. External participants might be able to provide coverage for limited portions of the property edge, but this would only help to a certain extent.

Motivations: May run their own Zones to ensure constituents have access to a well maintained system with superior coverage. Profit / monopolist advantage in the case of single providers + large area.

MUNICIPALITIES: A city or urban area, with the local government running Zones as a public service. Several benefits include use of geographically distributed infrastructure like utility poles, trained workforce to install / maintain a large network at scale, ability to self-fund hardware acquisition through a tax. First responders would have a system more dependable than GPS.

Similar to institutional users, issues could arise from a maladjusted fee market. For example, if a local public network ends up partially subsidised it would disincentivise additional Zones from forming because of artificially depressed fees. Reaching further, if the government contracted out the network to a third party could their contract ban additional independent nodes? Granted, this appears unlikely, given it seems like a potential infringement on freedom of activity given that the protocol operates on an unlicensed radio spectrum.

Motivations: public utility, offered at lower cost to verified city residents perhaps. More dependable geo-location for city services.

**PRIVATE COMPANIES: **It seems this group will be the most impactful in the long-term build-out of the FOAM network (especially the later stages). Advantages emerge at scale which are hard to overstate. These include large hardware contracts, experience dealing with specialised tools and components, the ability to support in-house legal teams, access to pools of capital in order to finance regional expansions, developed synergies in managing network assets, etc.

Several scenarios can be forecasted, possibly interwoven:

• where one company focuses on a single city exclusively, leveraging existing relationships, knowledge for permitting

• where a company achieves extensive horizontal integration, entering a variety of regional markets

• a situation where municipalities or institutions contract a larger company (as previously mentioned) — this could also be the case for specific use cases or unusual conditions

Consider the case where a company (Uber, FedEx) sees a particular market where location authentication would be an upsell — they are compelled to operate Zones because they recognise the long-term value it adds to a market.

Similar to a municipal operator, large companies can also eke out a coverage advantage through legal pressures. Consider that these companies may get owners of private property (think dense urban areas with high rises / condos) to sign “non-compete” agreements in exchange for a one time lump-sum or a % of future authentication fees. In effect, this would oblige owners to enforce Zone Anchor bans on their premises. Granted, this condition would ultimately be difficult to implement given the probable range of each Anchor. If actually carried out, it would unfortunately result in a less egalitarian protocol distribution.

Motivations: Profit, adding to an existing service or product as an upsell.

SUMMARY

The next few years will be incredibly interesting as networks launch and iterate, verifying the soundness of their incentive theory. There will likely be other types of FOAM operators that haven’t considered and uncertain edges between categories. Variety in operator types would certainly add to the network’s Antifragility(TM).

Hopefully these thoughts will inspire other FOAM enthusiasts to think of more participant types and edge case behavior. I’m looking forward to the FOAM Utility Token Sale and participating in the network when it launches later this year.