Ethereum Trusted Setup (Cryptography Rationale)

# Ethereum Trusted Setup (Cryptography Rationale) # Overview For [EIP-4844](https://hackmd.io/@protolambda/eip-4844-implementer-notes), Ethereum needs four different Structured Reference Strings (SRS) each of different sizes. Each SRS has a secret associated with it. For security, the SRS's must be computed in such a way that no single person knows the secret associated with them. The solution is to have multiple people contribute to the secret. If all of these people collude, then they can recover the secret. If even one person does not collude, then the secret is unrecoverable. The process of multiple people contributing to the secret is known as a ceremony. This document will outline the assumptions and decisions made when designing the ceremony. # Goals - Allow a developer whom wants to contribute to the ceremony, to be able to easily create their own implementation. - Allow those in third world countries to be able to contribute to the ceremony *As a corollary of the first goal, the algorithms needed for the coordinator and the verifier, may be significantly more complex than that for the contributor.* # Product Requirements - Contributors should be able to contribute to the ceremony in under two minutes on a particular device. - Coordinators should be able to verify a contributors contribution to all four SRS's in under 2 seconds on a particular device. >Note: For those verifying a ceremony after the fact, we do not have any explicit requirements. # Assumptions - We care more about bandwidth than compute time. This is because in third world countries, they will more significantly be limited by their internet connection than by their phone power. - Following standards and conventions already present in the Ethereum protocol is important. This means that we may not follow some of the design decisions made by previous ceremonies. - The coordinator will be a trusted entity. We will operate under the model of *trust but verify*. - Assuming that some third world countries are using 2G in the worse case. We assume that third world countries have an internet speed of [64-128Kbps](https://rantcell.com/comparison-of-2g-3g-4g-5g.html). This is in kilobits, so its 8-16 kilobytes per second. # Out of Scope - The frontend which includes the queuing system for contributors is out of scope. We will only refer to the frontend, insofar as a decision made in the cryptography will affect it. - Where the coordinator stores the information needed to verify the ceremony after the fact. - The selection process for choosing and rotating coordinators and or whether we will allow multiple coordinators - The criteria for ending the ceremony # Open Questions - What are the metrics on the time it takes the contributor to compute stages in contribution? ie which parts take the longest - What happens if a contributor, in the middle of the ceremony claims that a coordinator is malicious? - How do we encourage contributors to come back after the ceremony has completed to verify that their contribution was included in the final SRS? - (Technical) By using compressed points, how much time are we adding to the contributer's compute time? - (Technical) By using JSON, how much megabytes are we adding to the transferred file? UTF-8 can use 1-4 bytes per character # Approach ## Trusted Coordinator Model As mentioned, we assume that the coordinator is honest. We should however be careful here as a coordinator can be hacked, so we trust but verify. We justify the use of this model by the fact that security of the ceremony relies on contributors claiming that they did indeed participate in the ceremony _and_ that their contribution was included. If a coordinator behaves maliciously, then the contributor will simply not make any claims. This model is powerful because it allows us to delay a lot of the verification to different stages in the ceremony. More importantly, to stages that are not time sensitive. - Coordinator does not need to initially verify the messages sent to them by the coordinator. They can assume its correct, contribute, then perform the necessary checks after. - The SRS's that the coordinator sends to the contributor can have subgroup checks delayed until after contribution. - The check that the SRS is of the correct structure, is delayed until after the ceremony has completed. A malicious coordinator _could_ send contributors a random list of group elements. We would only be able to verify this after the fact. Since the contributor does not need to do a structure check, they will not need to implement pairings. This aligns with the first goal of having a simple implementation for developers. ## Serialisation It is standard in Ethereum to use JSON and so the decision has been made to serialise the SRS's in JSON form. This aligns with assumption 2, however it does not completely align with assumption 1 as JSON serialisation is not the most efficient serialisation strategy compared to a binary file. This is justified by the fact that the file size is ~10MB. Given that 10 Megabytes is 10,000 Kilobytes. On a 8-16Kilobytes per second connection, it would take 10-20 minutes. **Is this really acceptable?** ## Multiple Ceremonies Since we are conducting four separate ceremonies, it is possible to conduct these asynchronously. For simplicity, the decision was made to have a contributor contribute to all four ceremonies at once. The cryptography is implemented in terms of a single ceremony and we call the appropriate methods four times. ## Overall Algorithm There are many different variations to the trusted setup. The most popular ones being based off of Groth16. Since we did not need a Groth16 setup, our setup resembles the Ignition setup by the Aztec Network which in turn follows the rationale laid out in [this eprint](https://eprint.iacr.org/2021/219.pdf). For more information, on the technical changes, once can look [here](https://hackmd.io/C0lk1xyWQryGggRlNYDqZw)