Code Monkey home page Code Monkey logo

kzg-ceremony-specs's Introduction

Powers of Tau Specification

These documents comprise a specification for Ethereum's Powers of Tau (PoT) setup for use in KZG commitments in EIP-4844 (Proto-Danksharding) and ultimately Full Danksharding.

The ceremony takes place between participants and the sequencer. Participants are the entities that contribute their secret randomness to the final output $\tau$ s. The role of the sequencer is to act as the common point of interaction for all participants as well as verifying participants' contribution as the ceremony progresses.

Table of contents

10,000 ft Overview

We are performing a ceremony to generate Powers of Tau for KZG proofs on Ethereum. The output of the ceremony consists of 4 (distinct) sets of Powers of Tau each with a different maximum power:

  1. $([\tau_1^0]_1, [\tau_1^1]_1, \dots, [\tau_1^{2^{12}-1}]_1])$, $([\tau_1^0]_2, [\tau_1^1]_2, \dots, [\tau_1^{64}]_2])$
  2. $([\tau_2^0]_1, [\tau_2^1]_1, \dots, [\tau_2^{2^{13}-1}]_1])$, $([\tau_2^0]_2, [\tau_2^1]_2, \dots, [\tau_2^{64}]_2])$
  3. $([\tau_3^0]_1, [\tau_3^1]_1, \dots, [\tau_3^{2^{14}-1}]_1])$, $([\tau_3^0]_2, [\tau_3^1]_2, \dots, [\tau_3^{64}]_2])$
  4. $([\tau_4^0]_1, [\tau_4^1]_1, \dots, [\tau_4^{2^{15}-1}]_1])$, $([\tau_4^0]_2, [\tau_4^1]_2, \dots, [\tau_4^{64}]_2])$

BLS Cryptography

Due to a lack of standardisation for a complete API for BLS curves, we define our own in BLS.md.

Contributions

Due to the simplicity of this PoT setup, the full contribution is sent as a json file between the sequencer & participants. This allows the use of a RESTful API between the two. See contribution documentation for the contribution format requirements.

Initialization

The ceremony is initialized to initialContribution.json.

kzg-ceremony-specs's People

Contributors

asanso avatar carlbeek avatar flcl42 avatar glamperd avatar gswirski avatar nicoserranop avatar philsippl avatar ralexstokes avatar stefanbratanov avatar xujiandong avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kzg-ceremony-specs's Issues

Signature of Participant Identity

Ideally, a participant's contribution can be verified in both directions, that is the participant signs a message stating that Alice.eth contributed secret $[x]_2$, but also the ceremony has the option to sign Alice.eth with x as a private key, so that the public can verify Alice's claims.

[Discussion] API Options

Dynamic vs Static queues

One complexity of the queuing mechanism is whether the queue can be altered after it has been created. That is, if participants are absent or are taking little time to participate etc. can the coordinator shuffle the slots up to achieve a greater overall throughput. A queue that can be changed after creation I am labeling a dynamic queue.

Dynamic Queue Pros:

  • A higher throughput can be achieved by not having to use the participation time-out as the slot time for every participant.
  • Participants that go offline can be removed from the queue

Emulating dynamic queues

If a particular API doesn't natively feature dynamic queuing capabilities, the functionality can be added manually.

  • Participants can request a custom time-out/slot-duration when registering in the queue depending on their implementation/compute resources
  • The coordinator has relatively strict requirements for when a participant must show up for their slot, if they are late (>8 seconds), the slot is made free for someone else to request
  • Queued participants can poll the coordinator to check if an earlier slot has opened up
  • We implement a heartbeat requirement for queued participants. If you are offline, you get dropped from the queue. (I am not a fan of this idea due to the complexity of writing your own implementation.)

API Options

RESTful API

Pros:

  • Dead simple & everyone already familiar
  • Implementations & tooling in every language (implementors could even use cURL etc.)

Cons:

  • Dynamic queues need to be emulated as described above

Websockets

Pros:

  • Easily extendable to dynamic queues by having the server emit events when a queue is moved forward

Cons:

  • Complexity

AMQP

Pros:

  • Comes with tooling for queuing
  • built in mechanisms for checking attached client is still alive

Cons:

  • Lacks (stable) implementations in many langues (eg rust)
  • Complicated architecture for participant implements to understand

API Questions

Am trying to implement the new API, have some questions:

  • /info/current_state returns a '#/components/schemas/CeremonyStatus' but should return a transcript imo
  • info/status and info/current_state require authWithEth while contribute, abort and try_contribute do not?
  • Caller should pass a participant when calling abort, where do we get this from?
  • Caller should pass ParticipantQueueStatus when calling try_contribute where do we get this from?
  • CeremonyStatus is not specified
  • The lifecycle.md says optional data should be retrieved using /ceremony/status while the yml only defines /info/status, same with auth and login

[Discussion] Optimistic contribution

As a means of speeding up contributions, the participant could contribute optimistically:

  1. Participant assumes the transcript they receive from the coordinator is honest (doesn't' have any low-order elements mixed into any of the points)
  2. Participant mixes in their randomness & uploads updated transcript to coordinator
  3. Participant software only now does subgroup checks
  4. Participant attests to their contribution on twitter etc iff checks pass

This means the rate at which participants can contribute is limited by the powers of tau multiplications alone.

`initial_ceremony.json` fails pubkey-uniqueness check

The initial_ceremony.json is seeded with $g_1$ and $g_2$ as the powersOfTau and as such, the witness.pot_pubkeys are the same across all of the transcripts which fails the pubkey-uniqueness check.

Options for addressing this are:

  • Add a special case for the first pot_pubkey
  • Use a different public secret $[x_i]_2$ for each of the transcripts
  • Use secret randomness $[x_i]_2$ for each of the transcripts

Check `len(g1_powers)` in json schema

Currently, there is no check on the number of powers in the PowersOfTau as the manual checks were removed in favour of using the json schema to implement these checks which hasn't been implemented yet.

Remove "Sequencer handover" language?

Handover of the sequencer role will require continued access to the list of all accounts used thus far in the ceremony. During handover, the retiring sequencer must export a list of all identifiers, and the new sequencer must import the list.

the specs mention a handover, i believe from early discussions about passing around the Sequencer function. should this text be removed now that the Sequencer isn't moving between entities?

Git usernames from the transcripts don't have leading @

The specs and the transcript schema say that git usernames must have leading @, but none of the git addresses in the latest transcript contain it which causes validation to fail if we don't modify the schema manually. Is the spec outdated?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.