Try   HackMD

New PG docs

old docs top level page in new? new docs
0-homepage ✅ 2.0 homepage
1-proposal-rationale ➡️ rename to 2.6 2.1 Membership
2-existing-mechanisms ❌ 2.2 Eligibility
3-smart-contract ✅ rename to 2.3 2.3 Onchain
4-roles-expectations ➡️ folded into 2.1 and 2.2 2.4 Donate
5-initial-pilot ➡️ folded into 2.8 2.5 design principles
6-operating-guidelines ➡️ folded into 2.1 and 2.2 2.6 the Ethereum commons
7-anticipated-concerns ❌ 2.8 design rationale
8-case-studies ❌ 2.9 resources
9-membership ✅ rename to 2.1
10-donate ❌
11-resources ✅ rename to 2.8

Homepage

Protocol Guild is a collective funding mechanism for Ethereum Layer 1 R&D. It has three components:

  • an eligibility framework
  • a member registry
  • onchain contracts (vest and split)

The eligibility framework determines which projects' contributors should receive a share of the funding flow. This framework can then be used to maintain an active member registry. The registry addresses and weights are regularly published onchain to the split, where vested funding can be claimed.

Protocol Guild is only concerned with managing these components and soliciting funding to support the eligible work. The day-to-day stewardship discussions surrounding the Ethereum protocol continue to happen in existing non-PG venues (All Core Devs calls, ethresear.ch, Magician's forum) with the participation of a much broader set of contributors. Donations to fund PG have no bearing on stewardship decisions taking place in those existing venues.

This is a simple but powerful mechanism which allows Ethereum core protocol R&D to be funded in the same way it is produced: a commons of peers and their collaborative effort over time.

There are three main sections of the docs:

Now - let's learn together! :shield: :chains:

"And, Ebling, there's another, greater purpose. Hari Seldon founded two Foundations three centuries ago; one at each end of the Galaxy. You must find that Second Foundation." Foundation, Isaac Asimov

Eligibility

Protocol Guild eligible projects must:

  • be fully open source: both “source available” and free to fork, modify, redistribute
  • have a regular presence in R&D or governance venues, such as
    • specification repos (e.g. consensus-specs, execution-specs, execution-apis)
    • research forums (e.g. ethresear.ch), feature prototyping (e.g. EIPs, devnets, etc.)
    • regular protocol calls (e.g. AllCoreDevs, testing/interop calls, etc.)
  • target at least one of the following projects/areas:

  1. Ethereum core protocol maintenance and development

  2. Research and implementation experiments related to potential protocol changes

  3. Spec work resulting from the above (should be implementation agnostic, unopinionated)

  4. Protocol Guild

    • General comms
    • Fundraising
    • Research related to the evolution of the Guild itself
    • Internal maintenance for the Guild membership

Context

The eligibility framework is a "best effort representation" of Ethereum Layer 1 R&D. It tries to be sufficiently accomodating to what is the core protocol, but not any broader. This framework has been modified previously and will likely continue to be: more restrictive in some places and more permissive in others.

Contributing to the efforts referenced above does not guarantee Guild membership. While this list tries to be explicit by linking to example repos, there are some research areas which can't be linked to a single repo.

Formal organizational affiliations are not necessary for membership. It may be the case that some members of an organization will be eligible but others will not be.

Independent or unaffiliated contributors are considered by the same guidelines as any contributors "officially" part of teams/projects.

How to Modify the Framework

Changing the eligibility framework can be made through a PR to the documentation repo. This PR should add the project in the appropriate section, along with the following info:

  • Name of project
  • start date of the project
  • Summary of why this project should be considered eligible/ineligible

Membership

Active Members

The membership is a set of people working within the eligible projects who have also opted into Protocol Guild. As of the last onchain update (May XX, 2024) Protocol Guild had 176 members who cumulatively contributed over 600 years of effort to protocol stewardship. See the latest membership numbers here.

  • existing table

Membership Requirements

All current members have been contributing:

  1. to one or more of the list of eligible projects.
  2. continuously for at least 6 months ahead of inclusion. This work is expected to be ongoing (e.g. not a short-term or one-off project). To avoid removal from the current membership, any breaks in contribution must be shorter than 1 quarter (3 months). Beyond this length, the member should be moved to "Inactive" status until contribution resumes.
  3. in a roughly full-time capacity. Anything less receives a partial weighting.

Adding a Member

An existing member should make a PR at this repo which proposes an addition to the member list above, along with the accompanying info:

  • Name / Identifier
  • Affiliated project they work on which is eligible
  • Links to relevant eligible work, eg. GitHub, research
  • 3-4 sentence summary of their contributions

See some examples here: open or closed PRs

Discussion should be open for at least one week to give members time to review and discuss.

Bias or conflicts of interest of the nominator should be disclosed, if they exist, e.g. where one is an advisor to the other’s side project. After one week of rough consensus, the PR should be merged or rejected.

Removing a Member

Self-removal, affiliation, weights

Removals from the active membership should come from the member themselves, i.e. self-removal. Where this isn't possible due to extenuating circumstances, the member should be notified or tagged on the PR so they are aware of the changes.

Affiliation and weight changes should include some rationale for the change, ideally from the member themselves and seconding by a colleague.

Forced-removal

This situation occurs when another member proposes the removal of an existing member - even if they are continuing with eligible work. This should only happen in special circumstances where the cost of contention is higher than the loss of institutional legitimacy which their continued membership would produce.

The PR should include ample references to the alleged misconduct and justification for the removal. To date, this method has never been used.

Time-weight formula

The mechanism uses a formula with member-specific inputs to produce a time-weight:

time_weight = SQRT((start_date - months_inactive) * full_or_part_time)

Each member's time-weight is updated onchain every quarter along with an Ethereum address they control to allocate the funding flowing through the mechanism. Let's explore each of the formula components below.

1.time_weight

Our formulation recognizes the local knowledge contributors gain over time, and uses that as a proxy for "value to the commons" and to allocate funding to members. Existing contributor weights get "diluted" as newcomers show up. Continuing contributors get additional weight per month they are active.

2.start_date

The mechanism is retroactive: the earlier a contributor shows up, the higher their weight allocation for funding.

3.months_inactive

Members can take up to 3 months break without triggering a membership change. Beyond that, the mechanism tracks breaks to ensure weights are a fair representation of contributions.

4.full_or_part_time

  • full-weight: 1.0x
  • partial-weight: 0.5x

These multipliers roughly track the effort per week given by contributors. Full-weight is considered full-time, at least 40 hr/wk. Partial-weight is anything between 20 - 40 hr/wk.

5.SQRT

The final step of the formula uses a Square Root to compress the weight range. This is done to not overly privilege long-term members over newer contributors.

Time-weight example

The table and graphs below illustrate how the 5 year weight change of a hypothetical three member Guild. The effect of the square root can be seen in how the difference between older and newer contributors gets smaller over time.

0 12 24 36 48 60
Peer 1 (starting weight 6mo) 4.24 5.48 6.48 7.35 8.12 8.12
Peer 2 (starting weight 24mo) 6.00 6.93 7.75 8.49 9.17 9.17
Peer 3 (starting weight 12mo, part to full-weight at 18 months) 3.46 6.00 6.93 7.75 8.49 8.49

Raw Weights
Relative Weights

Quotes

  • existing content
Last changed by 
 
tvanepps
0
174

Read more

kzg special contributions

The Cryptosat team kicked off the Special Contribution period with a contribution from space aboard their Crypto 2 satellite. Read about what they did and how on their blog.

Jul 26, 2023
KZG Ceremony - Final Verification options

This is basically a question of where the boundary between individuals verifying and client teams implementing lies. How much work should be required to verify that client teams correctly put the output of the ceremony into the clients? Do we need everyone to verify the exact file gets included in clients, or are we ok having only some people do it and anyone can check at any time.

Jun 30, 2023
Announcing the KZG Ceremony

High fees have made life difficult for travelers through these Dark Forests. The Pools of Mem once clouded, now clarified by the filter of 1559, reveal that they are not deep enough to sustain. Legends tell of a society flourishing under the abundance brought about by DankShard, of giant Roll-Ups subsisting on fields of nourishing Data Blobs, each supporting their own fractal nutrient layers. To summon DankShard, our guides point us to a Ceremony. All members of the Lands of Ether and abroad are encouraged to contribute. Each will add their unique contribution to the collective and in doing so, illuminate the path forward. Overview The KZG Ceremony is a coordinated public ritual which will provide a cryptographic foundation for Ethereum scaling efforts like EIP-4844 (aka proto-danksharding). These types of events are also known as "Trusted Setups," famously used by Zcash to bootstrap the chain's privacy features. However, they can also be used to support scaling mechanisms, as Ethereum plans to do. Proto-danksharding requires a new cryptographic scheme: KZG Commitments. will generate a structured reference string (SRS) which is needed for the commitments to work. An SRS is secure as long as one participant in the ceremony successfully conceals their secret.

Apr 16, 2023
KZG Special Contribution Info

Join the Grantee telegram chat here Book your Special Contribution slot here This document outlines a number of points which may help steer your Special Contribution. If you have a question not addressed here, please join the telegram channel above and share it! 👩‍🔬 Special Contributions differ from regular contributions in that you may only login if your address has been whitelisted and only during your contribution slot and that you will have a dedicated 4 hour slot to do you contribution. This means, no waiting in the lobby and that you can take (up to) the full 4 hours to complete your contribution. If for some reason you miss your chosen slot, please reach out to Carl or Trent ASAP. 👩‍💻 We recommend the client from either Ignacio (client, docs) or Patricio (client, docs). Both allow for offline contributions which use local files as input and output, instead of networked response to the Sequencer Server. This is the method many of you will be using for your contribution.

Mar 9, 2023
Read more from tvanepps
Published on HackMD