├── LICENSE ├── README.md ├── closed-rfps ├── Sign-in with Ethereum RFP.md ├── beacon-chain-security.md ├── blst-audit.md ├── das.md ├── eip-3074-audit.md ├── eth2-deposit-cli.md ├── expand-address-to-32-bytes-implementation-and-spec-development.md ├── staking-operator-docs.md └── state-expiry-initial-implementation-and-spec-development.md └── open-rfps └── pectra-system-contracts-audit.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 Ethereum Foundation 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Requests for Proposals 2 | 3 | This is a public repository of Requests for Proposals (RfP) for work and projects in the Ethereum ecosystem. 4 | 5 | ## Open RFPs 6 | 7 | * [Pectra System Contracts Bytecode Audit](./open-rfps/pectra-system-contracts-audit.md) -- **Proposals due October 11, 2024** 8 | 9 | -------------------------------------------------------------------------------- /closed-rfps/Sign-in with Ethereum RFP.md: -------------------------------------------------------------------------------- 1 | # Sign-in with ethereum RFP 2 | 3 | ## Introduction 4 | 5 | The Ethereum Foundation (EF) and True Names LTD (ENS) would like to announce a Request for Proposals (RFP) for the creation of a Sign-In with Ethereum specification, a package using Oauth for easy implementation by web2 services, and a Javascript library for the user-facing part of sign-in. 6 | 7 | * [Sign-in with Ethereum RFP](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Sign-in-with-Ethereum-RFP) 8 | * [Introduction](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Introduction) 9 | * [Scope](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Scope) 10 | * [Process Summary](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Process-summary) 11 | * [Fee structure](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Fee-structure) 12 | * [Invoices](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Invoices) 13 | * [Payment method](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Payment-method) 14 | * [Bidding instructions](https://notes.ethereum.org/@djrtwo/sign-in-with-ethereum-RFP#Bidding-instructions) 15 | 16 | 17 | ## Scope 18 | 19 | * **Survey current practices:** Examine existing uses of Sign-In with Ethereum, look at the code, and talk to the developers. Determine what developers are doing and why, how it could be improved, and what best practices have already emerged. 20 | 21 | * **Specification:** Write a specification for how Sign-In with Ethereum should work, both with and without Oauth. Include best practices and recommended graphics. The specification should be simple and generally follow existing practices. Avoid feature bloat, particularly the inclusion of lesser-used projects who see getting into the specification as a means of gaining adoption. The core specification should be decentralized, open, non-proprietary, and have long-term viability. It should have no dependence on a centralized server except for the servers already being run by the application that the user is signing in to. The basic specification should include: Ethereum accounts used for authentication, ENS names for usernames (via reverse resolution), and data from the ENS name’s text records for additional profile information (e.g. avatar, social media handles, etc). 22 | 23 | * **Oauth implementation:** Create an Oauth implementation that makes it easy for services to add Sign-In with Ethereum to their existing sign-in options. This can be the refinement of an existing implementation (e.g. Pelith’s Eauth project) based on the specification, or can be created from scratch. 24 | 25 | * **Javascript library:** Create a Javascript library for the user-facing part of the sign-in process. This should be able to be used with or without the Oauth implementation. 26 | 27 | ## Process summary 28 | 29 | The entire process can be summarised as follows: 30 | 31 | 1. **Request:** Release of RFP (this post) 32 | 2. **Gather:** Vendors submit proposals 33 | 3. **Deliberate:** EF and ENS decide which proposal(s) to accept, and come up with a plan based on the resources and needs of the accepted proposal(s) 34 | 4. **Propose:** EF proposes the plan to vendor, and makes adjustments based on vendor’s feedback 35 | 5. **Begin:** Vendor accepts and work begins 36 | 6. **Work:** Vendor works on the tasks, in communication with EF and ENS as necessary, and seeking public feedback as appropriate 37 | 7. **Finish:** Work is complete, final payments are made 38 | 8. **Maintenance:** EF and ENS put in place a plan for ongoing maintenance and development of the specification, Oauth package, and Javascript library 39 | 40 | ## Fee structure 41 | 42 | ### Invoices 43 | 44 | Based on the timeline of this engagement, the chosen vendor(s) will be expected to submit two invoices: 45 | 46 | * a first invoice of 40% of the total engagement fee at the start of the engagement 47 | * a second invoice of 60% of the total engagement fee at the end of the engagement, following the delivery of the final product and a 5 day review period. 48 | 49 | ### Payment method 50 | 51 | The vendor will be given the option to be paid in fiat money (via bank transfer) or ETH. 52 | 53 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at (https://www.coingecko.com)[https://www.coingecko.com]) 54 | 55 | ## Bidding instructions 56 | 57 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 58 | 59 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 60 | 61 | Proposals must be submitted before July 30th, 2021 at 5pm PST*. We expect to take up to 2 weeks to deliberate and respond. 62 | 63 | Please send initial confirmations, and proposals (in PDF format) to the following address: rfp@ethereum.org 64 | 65 | Feel free to send us any questions you may have: rfp@ethereum.org 66 | -------------------------------------------------------------------------------- /closed-rfps/beacon-chain-security.md: -------------------------------------------------------------------------------- 1 | # Beacon chain security+testing RFP 2 | ## Introduction 3 | The Ethereum Foundation (EF) would like to announce a Request for Proposals (RfP) for general security and testing engagements related to the beacon chain and the upcoming merge of Ethereum to the beacon chain. 4 | 5 | - [Beacon chain security+testing RFP](https://notes.ethereum.org/@lsankar/security-rfp#Beacon-chain-securitytesting-RFP) 6 | - [Introduction](https://notes.ethereum.org/@lsankar/security-rfp#Introduction) 7 | - [Scope](https://notes.ethereum.org/@lsankar/security-rfp#Scope) 8 | - [Potential areas of focus](https://notes.ethereum.org/@lsankar/security-rfp#Potential-areas-of-focus) 9 | - [live network analysis](https://notes.ethereum.org/@lsankar/security-rfp#live-network-analysis) 10 | - [network load testing and simulation](https://notes.ethereum.org/@lsankar/security-rfp#network-load-testing-and-simulation) 11 | - [client load testing](https://notes.ethereum.org/@lsankar/security-rfp#client-load-testing) 12 | - [novel fuzzing](https://notes.ethereum.org/@lsankar/security-rfp#novel-fuzzing) 13 | - [formal verification](https://notes.ethereum.org/@lsankar/security-rfp#formal-verification) 14 | - [consensus attacks](https://notes.ethereum.org/@lsankar/security-rfp#consensus-attacks) 15 | - [new consensus test vectors](https://notes.ethereum.org/@lsankar/security-rfp#new-consensus-test-vectors) 16 | - [merge and sharding r&d](https://notes.ethereum.org/@lsankar/security-rfp#merge-and-sharding-rampd) 17 | - [Process summary](https://notes.ethereum.org/@lsankar/security-rfp#Process-summary) 18 | - [Fee structure](https://notes.ethereum.org/@lsankar/security-rfp#Fee-structure) 19 | - [Invoices](https://notes.ethereum.org/@lsankar/security-rfp#Invoices) 20 | - [Payment method](https://notes.ethereum.org/@lsankar/security-rfp#Payment-method) 21 | - [Bidding instructions](https://notes.ethereum.org/@lsankar/security-rfp#Bidding-instructions) 22 | 23 | ## Scope 24 | The EF will consider any proposals that further the security and robustness of Ethereum’s beacon chain and the upcoming merge (migration from PoW to PoS). In practice, this means any of the specifications or code in: 25 | 26 | - [the eth2spec](https://github.com/ethereum/eth2.0-specs) 27 | 28 | - any of the following 4 clients: 29 | 30 | * [lighthouse](https://github.com/sigp/lighthouse) 31 | 32 | * [teku](https://github.com/ConsenSys/teku) 33 | 34 | * [prysm](https://github.com/prysmaticlabs/prysm) 35 | 36 | * [nimbus](https://github.com/status-im/nimbus-eth2) 37 | 38 | - supporting core libraries (e.g. libp2p libs, crypto libs, etc) 39 | 40 | 41 | 42 | **This is an open call.** The RfP is broad and intended to cover a wide variety of engagements. Proposals should be formed based on your team’s expertise along with the challenges and needs at hand. 43 | 44 | For some ideas around what could constitute a good engagement, see the following section. 45 | 46 | ## Potential areas of focus 47 | The following are some representative starting points. 48 | 49 | This list is neither exhaustive nor is it very detailed. Proposals are expected to be much more fleshed out than anything found here. 50 | 51 | ### live network analysis 52 | Use tools to gather data and analyzelive beacon chain networks (both testnets and mainnet). There is a lot going on at the network layer and likely much to better understand and improve. 53 | ### network load testing and simulation 54 | Use simulation (e.g. using [Protocol Labs’ Testground](https://docs.testground.ai/)) to understand network propagation, finality, and liveness under varied conditions. 55 | ### client load testing 56 | Subject beacon chain clients to varied load profiles or under sub-optimal resource consumption to better understand general load, dos vectors, and potential targets for optimization. 57 | ### novel fuzzing 58 | [Sigma Prime’s beacon-fuzz](https://github.com/sigp/beacon-fuzz) fuzzes critical state transition targets today. Introduce novel fuzzing methods and targets beyond those already covered by beacon-fuzz. 59 | ### formal verification 60 | Apply formal verification techniques to verify the spec, critical tools, components of clients, or cryptographic libraries. Existing work in this domain includes Runtime Verifications [K beacon-chain-spec](https://github.com/runtimeverification/beacon-chain-spec) and [ConsenSys’s dafny spec.](https://github.com/ConsenSys/eth2.0-dafny) 61 | ### consensus attacks 62 | Studies of new theoretical attacks on beacon chain consensus. 63 | ### new consensus test vectors 64 | Extensions of consensus test vectors to aid client compliance. 65 | ### merge and sharding r&d 66 | The two major upgrades coming to the beacon chain are the merge and sharding. Any experiments, research, development, or analysis that helps get us there safely and quickly. 67 | ## Process summary 68 | The entire process can be summarized as follows: 69 | 70 | 1. **Request:** Release of RFP (this post) 71 | 2. **Gather:** Vendors submit proposals 72 | 3. **Deliberate:** EF decides which proposal(s) to accept, and comes up with a plan based on the resources and needs of the accepted proposal(s). 73 | 4. **Propose:** EF proposes the plan to vendor, and makes adjustments based on vendor’s feedback 74 | 5. **Begin:** Vendor accepts and work begins 75 | 76 | ## Fee structure 77 | ### Invoices 78 | Based on the timeline of this engagement, the chosen vendor(s) will be expected to submit 2 invoices: 79 | a first invoice of 40% of the total engagement fee at the start of the engagement 80 | a second invoice of 60% of the total engagement fee at the end of the engagement, following the delivery of the summary report and a 5 day review period. 81 | ### Payment method 82 | The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. 83 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at [https://www.coingecko.com](https://www.coingecko.com)). 84 | ### Bidding instructions 85 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 86 | 87 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 88 | 89 | Proposals must be submitted before April 20th, 2021 at 5pm PST*. We expect to take 1 week to deliberate and respond. 90 | 91 | Please send initial confirmations, and proposals (in PDF format) to the following address: rfp@ethereum.org 92 | *Feel free to send us any questions you may have: rfp@ethereum.org* -------------------------------------------------------------------------------- /closed-rfps/blst-audit.md: -------------------------------------------------------------------------------- 1 | ## Introduction 2 | 3 | The [Ethereum Foundation](https://ethereum.foundation/) (EF) and [Protocol Labs](https://protocol.ai/) (PL) would like to announce a Request for Proposals (RfP) for a security review of [`blst`](https://github.com/supranational/blst). 4 | 5 | [`blst`](https://github.com/supranational/blst) (pronounced ‘blast’) is a BLS12-381 signature library written in C and assembly focused on performance and security. 6 | 7 | ## Table of Contents 8 | 9 | 10 | 11 | - blst audit 12 | - [Introduction](https://notes.ethereum.org/@djrtwo/blst-rfp#Introduction) 13 | - [Table of Contents](https://notes.ethereum.org/@djrtwo/blst-rfp#Table-of-Contents) 14 | - Preliminaries 15 | - [BLS signatures](https://notes.ethereum.org/@djrtwo/blst-rfp#BLS-signatures) 16 | - [Pairings](https://notes.ethereum.org/@djrtwo/blst-rfp#Pairings) 17 | - [BLS signatures in eth2](https://notes.ethereum.org/@djrtwo/blst-rfp#BLS-signatures-in-eth2) 18 | - [A note on BLS12-381](https://notes.ethereum.org/@djrtwo/blst-rfp#A-note-on-BLS12-381) 19 | - [Spec requirements](https://notes.ethereum.org/@djrtwo/blst-rfp#Spec-requirements) 20 | - [Standardization efforts](https://notes.ethereum.org/@djrtwo/blst-rfp#Standardization-efforts) 21 | - [Ciphersuites](https://notes.ethereum.org/@djrtwo/blst-rfp#Ciphersuites) 22 | - [Version of code for audit](https://notes.ethereum.org/@djrtwo/blst-rfp#Version-of-code-for-audit) 23 | - [Scope of audit](https://notes.ethereum.org/@djrtwo/blst-rfp#Scope-of-audit) 24 | - [Repository Structure](https://notes.ethereum.org/@djrtwo/blst-rfp#Repository-Structure) 25 | - [Dependencies](https://notes.ethereum.org/@djrtwo/blst-rfp#Dependencies) 26 | - [Specific areas of focus](https://notes.ethereum.org/@djrtwo/blst-rfp#Specific-areas-of-focus) 27 | - [Process summary](https://notes.ethereum.org/@djrtwo/blst-rfp#Process-summary) 28 | - [Engagement timeline](https://notes.ethereum.org/@djrtwo/blst-rfp#Engagement-timeline) 29 | - [Deliverables](https://notes.ethereum.org/@djrtwo/blst-rfp#Deliverables) 30 | - Fee Structure 31 | - [Invoices](https://notes.ethereum.org/@djrtwo/blst-rfp#Invoices) 32 | - [Payment method](https://notes.ethereum.org/@djrtwo/blst-rfp#Payment-method) 33 | - [Selection criteria](https://notes.ethereum.org/@djrtwo/blst-rfp#Selection-criteria) 34 | - [Bidding instructions](https://notes.ethereum.org/@djrtwo/blst-rfp#Bidding-instructions) 35 | 36 | 37 | 38 | ## Preliminaries 39 | 40 | ### BLS signatures 41 | 42 | The [Boneh–Lynn–Shacham](https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham) (BLS) signature scheme allows a user to verify that a signer is authentic. 43 | 44 | Signatures are elements of an elliptic curve group, and a [pairing](https://en.wikipedia.org/wiki/Pairing-based_cryptography) is used for verification. 45 | 46 | The scheme has a variety of important properties. For our purposes, two distinguishing ones are: 47 | 48 | 1. **Signature aggregation.** A collection of signatures (signature_1, …, signature_n) can be aggregated into a single signature. Moreover, the aggregate signature can be verified using only 2 pairings, as opposed to 2n pairings, when verifying n signatures separately (verifying a signature requires 2 pairing operations). Furthermore the most expensive part of pairing computation, the final exponentiation, can be done [once per aggregate](https://ethresear.ch/t/fast-verification-of-multiple-bls-signatures/5407). 49 | 2. **Threshold signatures.** Threshold signatures allows verifiers to check that a threshold number of nodes have signed something. Specifically, threshold signatures allow for a private key to be spread across multiple nodes. Any subset of these nodes, as long as they are more than some threshold number, can then sign a message, without bringing their private keys together. 50 | 51 | ### Pairings 52 | 53 | A [pairing](https://en.wikipedia.org/wiki/Pairing-based_cryptography) is a bilinear map defined between groups. In the context of BLS signatures, it is a map `e: G1 x G2 --> GT` where `G1`, `G2`, and `GT` are distinct subgroups of the same prime order. 54 | 55 | [Pairings](https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627) greatly expand what elliptic curve-based protocols can do, enabling things like threshold signatures, for example. 56 | 57 | ### BLS signatures in eth2 58 | 59 | In eth2, validators are organised into committees to do their work. A vote cast by a validator is called an attestation. And an attestation is comprised of many elements, specifically: 60 | 61 | - a vote for the current beacon chain head 62 | - a vote on which beacon block should be justified/finalised 63 | - a vote on the current state of the shard chain 64 | - the signatures of all of the validators who agree with that vote 65 | 66 | Attestations are designed to be easily combined such that if two or more validators have attestations with the same votes, they can be combined by adding the signatures fields together in one attestation. This is what we mean by aggregation. 67 | 68 | This is the mechanism by which eth2 scales the number of validators. By breaking the validators up into committees, validators need only to care about their fellow committee members and only have to check very few aggregated attestations from each of the other committees. 69 | 70 | Eth2 makes use of the aggregation property of BLS signatures to reduce the computational cost. On the specific curve chosen (BLS12-381), signatures are 96 bytes each. 71 | 72 | ### A note on BLS12-381 73 | 74 | [BLS12-381](https://electriccoin.co/blog/new-snark-curve/) is part of a family of curves described by [Barreto, Lynn, and Scott](https://eprint.iacr.org/2002/088.pdf). It’s a curve that’s both secure and optimized for pairing operations. 75 | 76 | The 12 is the [embedding degree](https://hackmd.io/@benjaminion/bls12-381#Embedding-degree) of the curve. 77 | 78 | The 381 is the number of bits needed to represent a coordinate (in Fq) on the curve: the field modulus, `q`. In other words, the 381 means that the prime in the finite field `Fq` is of 381 bits. The size of this number is guided both by [security requirements](https://hackmd.io/@benjaminion/bls12-381#Security-level) and implementation efficiency. 79 | 80 | > Note that the BLS (Barreto-Lynn-Scott) in BLS12-381 is different from the BLS (Boneh–Lynn–Shacham) in BLS signature scheme. The BLS signature scheme works with many curves, BLS and non-BLS. 81 | **Full description** 82 | 83 | ``` 84 | u = -0xd201000000010000 85 | k = 12 86 | q = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab 87 | r = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001 88 | E(Fq) := y^2 = x^3 + 4 89 | Fq2 := Fq[i]/(x^2 + 1) 90 | E'(Fq2) := y^2 = x^3 + 4(i + 1) 91 | ``` 92 | 93 | For a more thorough introduction to the curve, and it’s properties, see [here](https://hackmd.io/@benjaminion/bls12-381). 94 | 95 | ### Spec requirements 96 | 97 | The BLS signature requirements for phase 0 are described in the beacon chain spec [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/beacon-chain.md#bls-signatures). 98 | 99 | ### Standardization efforts 100 | 101 | The relevant IETF standardization efforts are [BLS12-381 curve](https://tools.ietf.org/id/draft-yonezawa-pairing-friendly-curves-02.html), [Hash-To-Curve draft 9](https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-07), and [BLS Signatures draft 2](https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature-02). 102 | 103 | ### Ciphersuites 104 | 105 | A ciphersuite describes the building blocks (a curve, mapping a message to a point on the curve, a signature scheme, magic constants/ID, etc) underpinning a crypto protocol. 106 | 107 | For our purposes the relevant ciphersuites are: 108 | 109 | - Hash-To-Curve: 110 | 111 | ``` 112 | BLS12381G2_XMD:SHA-256_SSWU_RO 113 | ``` 114 | 115 | - Curve: BLS12-381 116 | - Hash_to_curve: targets the G2 curve 117 | - Hash_to_field_Fp2: produces a pseudo randombytes with expand_xmd 118 | - Hash function is SHA2-256 119 | - Mapping_Fp2_to_G2 uses Simplified Shallue-van de Woestijne-Ulas Method 120 | - RO: hashing uses the “indifferentiable from random oracle” method 121 | 122 | - BLS Signatures: `BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_` 123 | 124 | - BLS Proof-of-possession: `BLS_POP_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_` 125 | 126 | ## Version of code for audit 127 | 128 | The github commit of the code for audit will be determined at the start of the audit. The `blst` code is developed in the open at https://github.com/supranational/blst 129 | 130 | ## Scope of audit 131 | 132 | The audit should focus on assessing the security and correctness of the Go and Rust binding implementations, along with the underlying C code found in the `src` directory. Optionally, the assembly found in the `asm` directory can also be considered to be in scope, but proposals will be accepted that do not audit this code. 133 | 134 | ## Repository Structure 135 | 136 | **Root** - Contains various configuration files, documentation, licensing, and a build script 137 | 138 | - Bindings 139 | 140 | \- Contains the files that define the blst interface 141 | 142 | - Blst_aux.h - contains experimental functions not yet committed for long-term maintenance 143 | 144 | - Blst.swg - provides definition file for creating blst bindings in Java and Python using SWIG 145 | 146 | - Blst.h - provides C API to blst library 147 | 148 | - blst.hpp - provides prototype C++ API to blst library 149 | 150 | - Go 151 | 152 | \- folder containing Go bindings for blst, including tests and benchmarks?= 153 | 154 | - **Hash_to_curve**: folder containing test for hash_to_curve from IETF specification 155 | 156 | - **Java** - folder containing an example of how to use SWIG Java bindings for blst 157 | 158 | - **Python** - folder containing an example of how to use SWIG Python bindings for blst 159 | 160 | - **Rust** - folder containing Rust bindings for blst, including tests and benchmarks 161 | 162 | - Src 163 | 164 | \- folder containing C code for lower level blst functions such as field operations, extension field operations, hash-to-field, and more 165 | 166 | - **Asm** - folder containing perl scripts that are used to generate assembly code for different hardware platforms including x86 with ADX instructions, x86 without ADX instructions, and ARMv8 167 | 168 | - Build 169 | 170 | \- this folder containing a set of pre-generated source files for a variety of operating systems. The purpose of this folder is for users who do not want to go through the build process. 171 | 172 | - **Coff** - executable code for use on Unix systems 173 | - **Elf** - executable code for use on Unix systems 174 | - **Mach-o** - executable code for use on MacOS systems 175 | - **Win64** - executable code for use on Windows systems 176 | 177 | ## Dependencies 178 | 179 | The library is intended to be compliant with the following IETF draft specifications: 180 | 181 | - [IETF BLS Signature V2](https://tools.ietf.org/html/draft-irtf-cfrg-bls-signature) 182 | - [IETF Hash-to-Curve V9](https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve) 183 | 184 | ## Specific areas of focus 185 | 186 | The goal of the audit should be to improve the assurance that the cryptography code is correct and well implemented. Additionally, because this library will be used in a consensus system, it is critical that identical outputs are returned for both the Rust and Go bindings. 187 | 188 | ## Process summary 189 | 190 | The entire process can be summarised as follows: 191 | 192 | 1. **Request:** Release of RfP (this post) 193 | 2. **Gather:** Vendors submit proposals 194 | 3. **Deliberate:** EF and PL decide which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal. 195 | 4. **Propose:** EF and PL propose the plan to vendor, and makes adjustments based on vendor’s feedback 196 | 5. **Begin:** Vendor accepts and work begins 197 | 198 | ## Engagement timeline 199 | 200 | The proposed timeline of the engagement is approximately 1 month. 201 | 202 | The engagement is broken up into the following stages: a vendor assessment, followed by a break for developer response and mitigation, followed by a review phase from the vendor. 203 | 204 | The vendor will then summarize findings and publish the results to help the community understand the work that was done. 205 | 206 | | Stage | Description | 207 | | :---- | :--------------------------: | 208 | | 1 | Vendor assessment period | 209 | | 2 | Developer issue response | 210 | | 3 | Vendor review issue response | 211 | | 4 | Vendor summarises findings | 212 | 213 | Members of the EF, PL, and `blst` contributors will be available at all times to answer questions and comments during the assessment period in order to make life as easy as possible for the vendor. 214 | 215 | ## Deliverables 216 | 217 | Deliverable will take the form of Github issues in the [relevant Github repository](https://github.com/supranational/blst) for every security concern found. 218 | 219 | As outlined above, the vendor will provide a report distilling the lessons learnt, and summarising the issues submitted. 220 | 221 | ## Fee Structure 222 | 223 | ### Invoices 224 | 225 | Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices: 226 | 227 | - a first invoice of 40% of the total engagement fee at the start of the engagement 228 | - a second invoice of 60% of the total engagement fee at the end of the engagement, following the delivery of the summary report and a 5 day review period. 229 | 230 | ### Payment method 231 | 232 | The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. 233 | 234 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at [https://www.coingecko.com](https://www.coingecko.com/)). 235 | 236 | ## Selection criteria 237 | 238 | The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly: 239 | 240 | ``` 241 | Expertise in applied cryptography and cryptographic systems 242 | Expertise in low level, optimised code 243 | Experience with the C, Rust, and Go programming languages 244 | Experience with assembly programming 245 | ``` 246 | 247 | The EF, PL, and `blst` maintainers have considerable expertise in these domains and are ready to support the vendor. 248 | 249 | ## Bidding instructions 250 | 251 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 252 | 253 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 254 | 255 | Proposals must be submitted before *September 18th at 5pm PST*. We expect to take 1 week to deliberate and respond. 256 | 257 | Please send initial confirmations, and proposals (in PDF format) to the following address: [rfp@ethereum.org](mailto:rfp@ethereum.org) 258 | 259 | *Feel free to send us any questions you may have: [rfp@ethereum.org](mailto:rfp@ethereum.org)* -------------------------------------------------------------------------------- /closed-rfps/das.md: -------------------------------------------------------------------------------- 1 | # Data Availability Sampling Networking RFP 2 | 3 | The Ethereum Foundation (EF) is seeking proposals for projects looking to contribute to the domain of Data Availability Sampling (DAS) with respect to its implementation in peer to peer networks. This problem domain is under-explored, and we are excited to invite additional teams and individuals to explore this with us. 4 | 5 | In particular, the EF is requesting proposals that aim to design, refine, build, analyze, and test both theoretical and practical DAS techniques. This is a critical problem space in Ethereum p2p networking. 6 | 7 | The EF has earmarked **$1.5M in funding** for this RFP and is looking to accept not one, but a number of proposals. Proposals can span from formal design/analysis to more practical engineering and testing. 8 | 9 | * [Problem statement](#Problem-statement) 10 | * [RFP Details](#RFP-Details) 11 | * [Bidding instructions](#Bidding-instructions) 12 | 13 | ## Problem statement 14 | 15 | ### High level 16 | 17 | DAS is critical for any blockchain design that provides data availability guarantees beyond the resources of any standard node on the network -- e.g. Layer-1 comes to consensus on 1MB of data per second, but any standard node on the network only has the resources (bandwidth, storage, etc) to validate/download 50kb per second. 18 | 19 | In a DAS model, nodes randomly sample data that has been erasure encoded to ensure data is available and (in the event of data being missing or withheld) reconstruct portions of the data. 20 | 21 | To read more about the Data Availability problem and DAS please see these resources: 22 | * [A note on data availability and erasure coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) 23 | * [Fraud and Data Availability Proofs](https://arxiv.org/abs/1809.09044) 24 | * [Recent Ethereum sharding design proposal](https://notes.ethereum.org/@dankrad/new_sharding) 25 | * [DAS Requirements and tools](https://notes.ethereum.org/@djrtwo/das-requirements) 26 | 27 | ### Requirements 28 | 29 | DAS can be divided into a number of problems: 30 | 1. Disseminate small amounts of data to all nodes (samples or sets of samples) to support sampling from other nodes, in a way that supports random sampling (see 2) 31 | 2. Support queries for random samples in an efficient and safe way 32 | 3. Identify and reconstruct missing data (to then disseminate, 1 & 2) 33 | 34 | For a deeper discussion of these requirements, please see [here](https://notes.ethereum.org/@djrtwo/das-requirements). 35 | 36 | In an exploration of one or more of these requirements, we suggest you parametrize the relevant values and analyze under various considerations (e.g. `DATA_PER_BLOCK`, `NETWORK_NODE_COUNT`, etc) 37 | 38 | Note that designs should be analyzed/tested in both the happy case as well as under a diverse adversarial environment -- e.g. where does the design break down, under what type of adversary, what types of attacks are available, etc.; examples of typical attacks on DAS are: 39 | * Data withholding attacks (attacker overtakes/bribes the validator set to vote for an invalid block) 40 | * Temporary withholding attack (same attack but attacker later makes the data available) 41 | * Targeted eclipse attacks, where the attacker makes samples available to a subset of node, but not enough to reconstruct the data 42 | * DOS attacks, where the attacker breaks data availability sampling in such a way that all or a certain subset of samples are never retrievable 43 | Analyzing these attacks as well as coming up with new ones is part of this RFP. 44 | 45 | ## RFP Details 46 | 47 | As noted above, the EF is looking to accept multiple proposals pertaining to DAS networking that aim to design, refine, build, analyze, and/or test both theoretical and practical DAS techniques. 48 | 49 | ### Process summary 50 | 51 | The entire process can be summarized as follows: 52 | 53 | 1. **Request:** EF releases RFP (this post) 54 | 2. **Gather:** Teams submit proposals 55 | 3. **Deliberate:** EF analyzes proposals, discusses dynamically any suggestions in structure, direction, fee schedule, and/or timeline, and comes up with a plan based on the resources and needs of the accepted proposal(s). 56 | 4. **Propose:** EF proposes a final structure of the proposal based upon deliberations/discussions. 57 | 5. **Begin:** Team accepts and work begins 58 | 59 | ### Engagement timeline 60 | 61 | The EF proposes projects be structured either as 3, 6, or 12 month engagements with milestones/check-ins throughout (more for longer engagements). 62 | 63 | Initial proposals will not be accepted for longer than 12 month engagements. Subsequent proposals and grants can be formulated for followup work in the event this engagement goes well and a continuation is warranted. 64 | 65 | ### Deliverables 66 | 67 | The team is expected to define their own deliverables as a part of scoping the project. Deliverables can include but are not limited to -- formal papers, design documents, instructional videos, survey specifications, implementations, creation or extension of library code, experimental results, and blog posts. 68 | 69 | ## Bidding instructions 70 | 71 | Upon reception of this request, interested Teams are expected to confirm receipt and intention to submit a proposal. 72 | 73 | In this confirmation, Teams should explain what they need from the EF in order to get started. This is a complex domain -- the EF is happy to help get you up to speed via sharing additional resources and/or answering direct questions. 74 | 75 | Proposals must be submitted by July 1, 2022. 76 | 77 | Please send initial confirmations, and proposals (in PDF format) to the following address: rfp@ethereum.org 78 | 79 | _Feel free to send us any questions you may have: rfp@ethereum.org_ -------------------------------------------------------------------------------- /closed-rfps/eip-3074-audit.md: -------------------------------------------------------------------------------- 1 | # EIP-3074 (AUTH and AUTHCALL) Audit 2 | 3 | ## Introduction 4 | 5 | The [Ethereum Foundation](https://ethereum.foundation/) (EF) and [Quilt](https://quilt.link/) (Q) would like to announce a Request for Proposals (RfP) for a security review of [EIP-3074: AUTH and AUTHCALL opcodes](https://eips.ethereum.org/EIPS/eip-3074). 6 | 7 | [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) introduces a mechanism in the EVM that can make subcalls as a certain `CALLER`. The `CALLER` is derived from a signature included on-chain. This mechanism has widespread use cases, including sponsored transactions, batched transactions, non-sequential transactions, and more. 8 | 9 | However, this EIP changes the existing security properties of the network. Because `CALLER` is the defacto authentication mechanism on-chain, a mechanism that allows contracts to masquerade as EOAs could introduce new threats. The goal of this audit is to uncover and investigate these threats. 10 | 11 | ## Table of Contents 12 | 13 | 14 | 15 | - EIP-3074 (AUTH and AUTHCALL) Audit 16 | - [Introduction](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Introduction) 17 | - [Table of Contents](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Table-of-Contents) 18 | - [Version of Code for Audit](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Version-of-Code-for-Audit) 19 | - [Scope of Audit](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Scope-of-Audit) 20 | - Specific Areas of Focus 21 | - [Wallet Integration](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Wallet-Integration) 22 | - [Potential Invoker Bugs](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Potential-Invoker-Bugs) 23 | - [Existing Smart Contracts](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Existing-Smart-Contracts) 24 | - [Sponsor-Sponsee Relationship](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Sponsor-Sponsee-Relationship) 25 | - [Process summary](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Process-summary) 26 | - [Engagement timeline](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Engagement-timeline) 27 | - [Deliverables](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Deliverables) 28 | - Fee Structure 29 | - [Invoices](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Invoices) 30 | - [Payment method](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Payment-method) 31 | - [Selection criteria](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Selection-criteria) 32 | - [Bidding instructions](https://notes.ethereum.org/@djrtwo/eip-3074-audit-rfp#Bidding-instructions) 33 | 34 | 35 | 36 | ## Version of Code for Audit 37 | 38 | The git commit of the specification for audit is will be decided near the start of the audit. For now, refer to the latest information contained in the [core EIP](https://eips.ethereum.org/EIPS/eip-3074). 39 | 40 | ## Scope of Audit 41 | 42 | EIP-3074 offers a flexible primitive to develop novel wallet extensions, however, this flexibility increases the surface area of unintended consequences it may have for users and existing applications. 43 | 44 | The audit should thoroughly review the EIP specification and explore all potential security concerns discovered, but should primarily focus on the security of user assets, new threat models for users and their wallets, and the feasibility of writing secure invoker contracts. 45 | 46 | The analysis of the safety of the network itself (ex. denial of service attacks) is explicitly not in scope. Economic modeling of sponsored transactions is also not in scope. 47 | 48 | ## Specific Areas of Focus 49 | 50 | The following areas are highlighted as particular areas of concern or sensitivity. 51 | 52 | ### Wallet Integration 53 | 54 | Signing a single malicious `AUTH` message would be enough for an adversary to gain full control over an EOA. It should be determined if a wallet can be reasonably expected to protect users from this. 55 | 56 | ### Potential Invoker Bugs 57 | 58 | The EIP strongly recommends users interact only with trusted invokers that have undergone rigorous audits and static analysis. That said, it is still possible for a bug to be discovered in these trusted contracts. This would mean that any EOA that has interacted with the invoker in the past could be at risk. The possibility and range of severities for these bugs in heavily audited invoker contract should be discussed. 59 | 60 | ### Existing Smart Contracts 61 | 62 | Currently, it is possible to determine if a smart contract is executing in the first frame of a transaction by checking that `CALLER == ORIGIN`. This EIP allows the transaction’s originator to set itself as the `CALLER` at any call depth, therefore breaking the aforementioned assumption. It should be determined how contracts use the above check and if existing contracts rely on this assumption, how they would break when the assumption is invalidated. 63 | 64 | ### Sponsor-Sponsee Relationship 65 | 66 | This relationship is hinted at in the EIP, but not thoroughly discussed because it is orthogonal to the actual specification. However, the design of the EIP is highly motivated by the relationship between sponsor and sponsee. Therefore, an audit of the EIP should examine how the two parties will interact. 67 | 68 | Specifically, it should be possible, using primitives provided by the EIP, to build a system enabling sponsored transactions, while preventing situations where: 69 | 70 | - The sponsor receives payment from the sponsee, but the sponsee’s intended action is not executed. 71 | - The sponsee is able to perform an action, but does not reimburse the sponsor. 72 | - The sponsee is able to repeatedly waste sponsor resources (ex. gas fees, nonces, etc), without incurring a proportional cost itself. 73 | 74 | ## Process summary 75 | 76 | The entire process can be summarized as follows: 77 | 78 | 1. **Request:** EF releases RfP (this post) 79 | 2. **Gather:** Vendors submit proposals 80 | 3. **Deliberate:** EF and Q decides which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal. 81 | 4. **Propose:** EF and Q proposes the plan to vendor, and makes adjustments based on vendor’s feedback 82 | 5. **Begin:** Vendor accepts and work begins 83 | 84 | ## Engagement timeline 85 | 86 | The proposed timeline of the engagement is approximately 1 month. 87 | 88 | The engagement is broken up into the following stages: a vendor assessment, followed by a break for developer response and mitigation, followed by a review phase from the vendor. 89 | 90 | The vendor will then summarize findings and publish the results to help the community understand the work that was done. 91 | 92 | | Stage | Description | 93 | | :---- | :--------------------------: | 94 | | 1 | Vendor assessment period | 95 | | 2 | Developer issue response | 96 | | 3 | Vendor review issue response | 97 | | 4 | Vendor summarises findings | 98 | 99 | Members of the EF and Q will be available at all times to answer questions and comments during the assessment period in order to make life as easy as possible for the vendor. 100 | 101 | ## Deliverables 102 | 103 | The vendor will provide a report summarising the audit findings, distilling the lessons learnt, and an outline of each security issue discovered. 104 | 105 | ## Fee Structure 106 | 107 | ### Invoices 108 | 109 | Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices: 110 | 111 | - a first invoice of 40% of the total engagement fee at the start of the engagement 112 | - a second invoice of 60% of the total engagement fee at the end of the engagement, following the delivery of the summary report and a 5 day review period. 113 | 114 | ### Payment method 115 | 116 | The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. 117 | 118 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at [https://www.coingecko.com](https://www.coingecko.com/)). 119 | 120 | ## Selection criteria 121 | 122 | The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly: 123 | 124 | ``` 125 | Familiarity with the EVM, common smart contract techniques 126 | Familiarity with cryptocurrency key management and wallets 127 | High level understanding of meta-transaction relayer architectures 128 | ``` 129 | 130 | The EF and Q have considerable expertise in these domains and are ready to support the vendor. 131 | 132 | ## Bidding instructions 133 | 134 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 135 | 136 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 137 | 138 | Proposals must be submitted before April 18, 2021. We expect to take 1 week to deliberate and respond. 139 | 140 | Please send initial confirmations, and proposals (in PDF format) to the following address: [rfp@ethereum.org](mailto:rfp@ethereum.org) 141 | 142 | *Feel free to send us any questions you may have: [rfp@ethereum.org](mailto:rfp@ethereum.org)* -------------------------------------------------------------------------------- /closed-rfps/eth2-deposit-cli.md: -------------------------------------------------------------------------------- 1 | # Eth2 deposit CLI security audit: request for proposals 2 | 3 | 4 | 5 | 6 | ## Introduction 7 | 8 | 9 | 10 | 11 | We would like to announce a Request for Proposals (RfP) for a security review of the eth2 deposit CLI (written in python). 12 | 13 | 14 | 15 | 16 | This method of approaching auditors is new for us. In the past, we’ve chosen to organise audits by approaching a single auditor directly. 17 | 18 | 19 | 20 | 21 | We’re moving in this direction in order to try and get a more diverse pool of auditors on the scene. 22 | 23 | 24 | 25 | 26 | This request describes the [eth2 deposit CLI](https://github.com/ethereum/eth2.0-deposit-cli) in detail, the scope of the security assessment, the deliverables expected, and a suggested timeline. 27 | 28 | 29 | 30 | 31 | It also provides guidelines on fee structure, selection criteria, and bidding instructions. 32 | 33 | 34 | 35 | 36 | ### What is eth2? 37 | 38 | 39 | 40 | 41 | Eth2 is the next generation of Ethereum. It’s a multi-year plan to improve the scalability, security and programmability of Ethereum, without compromising on decentralization. 42 | 43 | 44 | 45 | 46 | In contrast to Ethereum today, eth2 uses proof-of-stake (PoS) to secure its network. And while the current chain will continue to exist as its own independent proof-of-work chain for a little while to come, the transition towards PoS starts with the launch of the [beacon chain (phase 0)](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB) later this year. 47 | 48 | 49 | 50 | 51 | ### Why are deposits important? 52 | 53 | 54 | 55 | 56 | In order to make this transition possible, eth2 requires active participants, known as validators, to deposit ETH as collateral in exchange for receiving rewards for actions that help the network reach consensus. 57 | 58 | 59 | 60 | 61 | In a sentence: if deposits can’t happen safely, then there are no validators, and eth2 doesn’t launch. 62 | 63 | 64 | 65 | 66 | ## Project description 67 | 68 | 69 | 70 | 71 | The purpose of the deposit CLI is to provide a secure, simple, offline method for aspiring validators to generate keystores and the [`DepositData`](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB#Deposit) required to become a validator on eth2. 72 | 73 | 74 | 75 | 76 | #### Keystores 77 | 78 | 79 | 80 | 81 | Keystores are files that contain private keys encrypted with a user’s password. Validator clients use keystores as a method for exchanging keys since they can be safely stored and transferred between computers, provided the password is not stored on the same computer. 82 | 83 | 84 | 85 | 86 | The deposit CLI generates a keystore for each validator with the appropriate signing keys. 87 | 88 | 89 | 90 | 91 | #### DepositData 92 | 93 | 94 | 95 | 96 | `DepositData` is the data supplied by the user to the [deposit contract](https://notes.ethereum.org/@av80r/Eth2-deposit-CLI-audit_RFP) (a necessary step to become a validator). 97 | 98 | 99 | 100 | 101 | The deposit CLI generates a JSON file with the necessary `DepositData`. 102 | 103 | 104 | 105 | 106 | ### Process 107 | 108 | 109 | 110 | 111 | #### 0. Clone repository 112 | 113 | 114 | 115 | 116 | ``` 117 | 118 | git clone https://github.com/ethereum/eth2.0-deposit-cli.git 119 | 120 | ``` 121 | 122 | 123 | 124 | 125 | #### 1. Install dependencies and run CLI 126 | 127 | 128 | 129 | 130 | For Linux or MacOS users: 131 | 132 | 133 | 134 | 135 | ``` 136 | 137 | ./deposit.sh install 138 | 139 | ./deposit.sh 140 | 141 | ``` 142 | 143 | 144 | 145 | 146 | For Windows users: 147 | 148 | 149 | 150 | 151 | ``` 152 | 153 | sh deposit.sh install 154 | 155 | sh deposit.sh 156 | 157 | ``` 158 | 159 | 160 | 161 | 162 | Note that you can also run the CLI (second command) with optional flags: 163 | 164 | 165 | 166 | 167 | ``` 168 | 169 | --num_validators= 170 | 171 | --mnemonic_language=english 172 | 173 | --folder= 174 | 175 | --chain= 176 | 177 | ``` 178 | 179 | 180 | 181 | 182 | #### 2. Input preferences 183 | 184 | 185 | 186 | 187 | Upon entering the interactive CLI you’re asked to choose the number of validators you wish to run 188 | 189 | 190 | 191 | 192 | ``` 193 | 194 | Please choose how many validators you wish to run: 195 | 196 | ``` 197 | 198 | 199 | 200 | 201 | And your preferred language 202 | 203 | 204 | 205 | 206 | ``` 207 | 208 | Please choose your mnemonic language (czech, chinese_traditional, chinese_simplified, english, spanish, italian, korean) [english]: 209 | 210 | ``` 211 | 212 | 213 | 214 | 215 | #### 3. Type password to secure keystores & generate mnemonic 216 | 217 | 218 | 219 | 220 | You’re then asked to type a password 221 | 222 | 223 | 224 | 225 | ``` 226 | 227 | Type the password that secures your validator keystore(s): 228 | 229 | Repeat for confirmation: 230 | 231 | ``` 232 | 233 | 234 | 235 | 236 | Correctly confirming the password, generates the Mnemonic. 237 | 238 | 239 | 240 | 241 | #### 4. Write down Mnemonic 242 | 243 | 244 | 245 | 246 | ``` 247 | 248 | This is your seed phrase. Write it down and store it safely, it is the ONLY way to retrieve your deposit. 249 | 250 | 251 | 252 | 253 | 254 | weird tool evoke because fish enter review forget panda coffee ceiling stadium car happy strategy proud genius adapt like vocal jewel trial void inspire 255 | 256 | 257 | 258 | 259 | 260 | Press any key when you have written down your mnemonic. 261 | 262 | ``` 263 | 264 | 265 | 266 | 267 | #### 5. Generate keys, keystores, and deposit data 268 | 269 | 270 | 271 | 272 | ``` 273 | 274 | Please type your mnemonic (separated by spaces) to confirm you have written it down: 275 | 276 | ``` 277 | 278 | 279 | 280 | 281 | Once you’ve proven you’ve written down the mnemonic, you get your keys 282 | 283 | 284 | 285 | 286 | ``` 287 | 288 | ##### ##### 289 | 290 | ## ##### ## 291 | 292 | ### ## ####### ######################### 293 | 294 | ## ## ##### ## ## 295 | 296 | ## ##### ## ## 297 | 298 | ## ## ## ### 299 | 300 | ######## ## #### 301 | 302 | ## ## ### ##### ##### 303 | 304 | # ## # ##### 305 | 306 | # # # ##### 307 | 308 | ## ## ## 309 | 310 | ## ## ## 311 | 312 | ## ### ## ## 313 | 314 | ############### ## ## 315 | 316 | ### ## ## 317 | 318 | ############################# ## 319 | 320 | ## ### 321 | 322 | ####### ################# ### 323 | 324 | ## ## ## ## ## ### 325 | 326 | ############## ############# 327 | 328 | Creating your keys. 329 | 330 | Saving your keystore(s). 331 | 332 | Creating your deposit(s). 333 | 334 | Verifying your keystore(s). 335 | 336 | Verifying your deposit(s). 337 | 338 | 339 | 340 | Success! 341 | 342 | Your keys can be found at: 343 | 344 | Saving your keystore(s) 345 | 346 | ``` 347 | 348 | 349 | 350 | 351 | A Keystore (containing the relevant signing key) is generated for every validator. Note that, to cut down on confusion, validators aren’t given keystores for their withdrawal keys. 352 | 353 | 354 | 355 | 356 | ``` 357 | 358 | Creating your deposit(s) 359 | 360 | ``` 361 | 362 | 363 | 364 | 365 | A JSON file is created containing the necessary `DepositData`. 366 | 367 | 368 | 369 | 370 | ### Resources 371 | 372 | 373 | 374 | 375 | - [Validated: staking on eth2 #0](https://blog.ethereum.org/2019/11/27/validated-staking-on-eth2-0/): Intro to eth2 and staking 376 | 377 | - [Validated: staking on eth2 #4 Keys](https://blog.ethereum.org/2020/05/21/keys/): Key reading ;) 378 | 379 | - [EIP 2333](https://eips.ethereum.org/EIPS/eip-2333): BLS Key Generation 380 | 381 | - [EIP 2334](https://eips.ethereum.org/EIPS/eip-2334): BLS Deterministic Account Hierarchy 382 | 383 | - [EIP 2335](https://eips.ethereum.org/EIPS/eip-2335): BLS Keystore 384 | 385 | - [Deposit CLI repository](https://github.com/ethereum/eth2.0-deposit-cli) 386 | 387 | - [Deposit Launchpad repository](https://github.com/ethereum/eth2.0-deposit) 388 | 389 | - [Deposit Contract repository](https://github.com/ethereum/eth2.0-specs/tree/dev/deposit_contract) 390 | 391 | - [Deposit Contract formal verification](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) 392 | 393 | - [eth2 specs](https://github.com/ethereum/eth2.0-specs/blob/v0.10.0/specs/phase0/beacon-chain.md#depositdata): Phase 0, The Beacon Chain 394 | 395 | - [Phase 0 for Humans](https://notes.ethereum.org/@djrtwo/Bkn3zpwxB) 396 | 397 | 398 | 399 | 400 | ## Security assessment scope 401 | 402 | 403 | 404 | 405 | The scope of this security engagement includes the review of the following eth2 components: 406 | 407 | 408 | 409 | 410 | ``` 411 | 412 | eth2 deposit cli 413 | 414 | ``` 415 | 416 | 417 | 418 | 419 | The assessment will focus on identifying vulnerabilities that can lead to the following (non-exhaustive list): 420 | 421 | 422 | 423 | 424 | ``` 425 | 426 | - Incorrect generation of the mnemonic 427 | 428 | - Incorrect calculation of the withdrawal key 429 | 430 | - Incorrect derivation of the signing key 431 | 432 | ``` 433 | 434 | 435 | 436 | 437 | Our main concern is the correct calculation of the withdrawal key, since it is not validated anywhere else (the signing key is verified in the deposit launchpad UI). Within this, it will be important to verify that: 438 | 439 | 440 | 441 | 442 | ``` 443 | 444 | - The secret key is derived correctly 445 | 446 | - Withdrawal credentials == hash(private key)* 447 | 448 | - The withdrawal key can be rederived from the mnemonic 449 | 450 | ``` 451 | 452 | 453 | 454 | 455 | Other areas of concern include: 456 | 457 | 458 | 459 | 460 | ``` 461 | 462 | - Verify that installation instructions are correct on all operating systems 463 | 464 | - Verify that Keystore is a valid implementation of EIP 2335 465 | 466 | - Verify that deposit_data JSON is a valid representation of DepositData 467 | 468 | - Verify the scope for users to input invalid/undesirable flags 469 | 470 | - Verify that keys and passwords aren't inadvertantly leaked via memory or log files.** 471 | 472 | ``` 473 | 474 | 475 | 476 | 477 | *More formally, withdrawal credentials, as defined [here](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase0/deposit-contract.md#withdrawal-credentials), should equal `b'\x00' + hash(public_key)[1:]`. 478 | 479 | 480 | 481 | 482 | **For example via shell history. Not via more complicated means such as timing attacks though (e.g. because [py_ecc](https://github.com/ethereum/py_ecc) is not constant time). 483 | 484 | 485 | 486 | 487 | ## Process summary 488 | 489 | 490 | 491 | 492 | The entire process can be summarised as follows: 493 | 494 | 495 | 496 | 497 | 1. **Request:** EF releases RfP (this post) 498 | 499 | 2. **Gather:** Vendors submit proposals 500 | 501 | 3. **Deliberate:** EF decides which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal. 502 | 503 | 4. **Propose:** EF proposes the plan to vendor, and makes adjustments based on vendor’s feedback 504 | 505 | 5. **Begin:** Vendor accepts and work begins 506 | 507 | 508 | 509 | 510 | ## Engagement timeline 511 | 512 | 513 | 514 | 515 | The proposed timeline of the engagement is approximately 1 month. 516 | 517 | 518 | 519 | 520 | The engagement is broken up into the following stages: a vendor assessment, followed by a break for developer response and mitigation, followed by a review phase from the vendor. 521 | 522 | 523 | 524 | 525 | The vendor will then summarize findings and publish the results to help the community understand the work that was done. 526 | 527 | 528 | 529 | 530 | | Stage | Description | 531 | 532 | | :---- | :--------------------------: | 533 | 534 | | 1 | Vendor assessment period | 535 | 536 | | 2 | Developer issue response | 537 | 538 | | 3 | Vendor review issue response | 539 | 540 | | 4 | Vendor summarises findings | 541 | 542 | 543 | 544 | 545 | Members of the EF will be available at all times to answer questions and comments during the assessment period in order to make life as easy as possible for the vendor. 546 | 547 | 548 | 549 | 550 | ## Deliverables 551 | 552 | 553 | 554 | 555 | Deliverable will take the form of Github issues in the [relevant Github repository](https://notes.ethereum.org/@av80r/Eth2-deposit-CLI-audit_RFP) for every security concern found. Our recommended Github issue process can be found [here](https://notes.ethereum.org/@av80r/Eth2-deposit-CLI-audit_RFP). 556 | 557 | 558 | 559 | 560 | As outlined above, the vendor will provide a report distilling the lessons learnt, and summarising the issues submitted. 561 | 562 | 563 | 564 | 565 | ## Fee Structure 566 | 567 | 568 | 569 | 570 | ### Invoices 571 | 572 | 573 | 574 | 575 | Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices: 576 | 577 | 578 | 579 | 580 | - a first invoice of 40% of the total engagement fee at the start of the engagement 581 | 582 | - a second invoice of 60% of the total engagement fee at the end of the engagement, following the delivery of the summary report and a 5 day review period. 583 | 584 | 585 | 586 | 587 | ### Payment method 588 | 589 | 590 | 591 | 592 | The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. 593 | 594 | 595 | 596 | 597 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at [https://www.coingecko.com](https://www.coingecko.com/)). 598 | 599 | 600 | 601 | 602 | ## Selection criteria 603 | 604 | 605 | 606 | 607 | The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly: 608 | 609 | 610 | 611 | 612 | ``` 613 | 614 | Experience with using the Python programming language 615 | 616 | Familiarity with hash functions 617 | 618 | Familiarity with cryptographic signature schemes* 619 | 620 | Experience with reviewing software 621 | 622 | ``` 623 | 624 | 625 | 626 | 627 | The EF has considerable expertise in these domains and is ready to support the vendor. 628 | 629 | 630 | 631 | 632 | *e.g. BLS signatures. 633 | 634 | 635 | 636 | 637 | ## Bidding instructions 638 | 639 | 640 | 641 | 642 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 643 | 644 | 645 | 646 | 647 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 648 | 649 | 650 | 651 | 652 | Proposals must be submitted before *June 12th, 12 PM EST*. We expect to take 1 week to deliberate and respond. 653 | 654 | 655 | 656 | 657 | Please send initial confirmations, and proposals (in PDF format) to the following address: [rfp@ethereum.org](mailto:rfp@ethereum.org) 658 | 659 | 660 | 661 | 662 | We’re also happy to arrange pre-bid meetings, should you feel there’s a need. 663 | 664 | 665 | 666 | 667 | ## Summary 668 | 669 | 670 | 671 | 672 | While we have conducted audits in the past, this is our first time going down the RfP path. We’re excited to get the ball rolling, and expect to learn a great deal from this experience. 673 | 674 | 675 | 676 | 677 | Feel free to send us any questions you may have: [rfp@ethereum.org](mailto:rfp@ethereum.org) -------------------------------------------------------------------------------- /closed-rfps/expand-address-to-32-bytes-implementation-and-spec-development.md: -------------------------------------------------------------------------------- 1 | # Extend addresses to 32 bytes: Request for Proposals 2 | 3 | ## Introduction 4 | 5 | The Ethereum Foundation would like to announce a Request for Proposals (RfP) for the research and development needed to extend Ethereum addresses from 20 bytes to 32 bytes. 6 | 7 | The proposed mechanism for this extension can be found here on the Ethereum Magicians forum: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485 8 | 9 | This proposal is for an open ended engagement with three goals to be implemented in two stages. 10 | 11 | 1. Stage 1: 12 | - Additional research into the proposed mechanism for expanding addresses to 32 bytes to validate the approach and gain broader buy in from core devs 13 | 2. Stage 2: 14 | - Implement it in one of the mainnet Ethereum client codebases. (Besu, Geth, Nethermind, OpenEthereum, TurboGeth). 15 | - A complete specification in the form of an EIP suitable for consideration by core devs and implementations by other client teams. 16 | 17 | ## Scope 18 | 19 | We are looking for an open ended engagement with an individual or team (referred to as "vendor") who can commit their time towards the research and development necessary to modify the core Ethereum protocol to support 32 byte addresses. 20 | 21 | The vendor should expect to: 22 | 23 | - Analyze and report on the impact this change would have on the broader ecosystem of tooling. 24 | - Leverage communication channels such as the R&D Discord and Research and Magicians forums to engage the core development community 25 | - Research Forums: https://ethresear.ch/ 26 | - Magicians Forums: https://ethereum-magicians.org/ 27 | - R&D Discord: *Invite available upon request* 28 | - Produce technical write ups and explanations of the proposed scheme 29 | 30 | ### Stage 1 31 | 32 | The expansion of Ethereum addresses from 20 bytes to 32 bytes is currently only loosely specified in the linked Ethereum Magicians forum post. Additional research is necessary to extend what is layed out in tha HackMD document into a fully specified set of protocol changes. In this stage, vendor should focus on gaining a detailed understanding of the problem, producing detailed write ups of what they learn, exploration into potential problems, exploration and understanding of any trade-offs present in the scheme. This process should include continuous feedback and engagement with the core development community. 33 | 34 | 35 | ### Stage 2 36 | 37 | Once research has validated that the address expansion appears to be viable, and there is clear buy-in from the core development community, work should shift towards a concrete spec and accompanying implementation in a mainnet Ethereum client. 38 | 39 | - The specification should take the form of one or more EIP documents 40 | - The implementation should be suitable for running a test network 41 | 42 | > EIP: Ethereum Improvement Proposals - https://github.com/ethereum/EIPs 43 | 44 | 45 | ## Process Summary 46 | 47 | The entire process can be summarized as follows: 48 | 49 | - **Request**: EF releases RfP (this post) 50 | - **Gather**: Vendors submit proposals 51 | - **Deliberate**: EF decides which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal. 52 | - **Propose**: EF proposes the plan to vendor, and makes adjustments based on vendor’s feedback 53 | - **Begin**: Vendor accepts and work begins 54 | 55 | 56 | ## Timeline 57 | 58 | We expect this project to take around four months, however we also expect this to vary based on things like team size and prior expertise. Proposals should include a projected development timeline which we will actively re-evaluate as the project progresses. 59 | 60 | 61 | ## Deliverables 62 | 63 | - Public facing development updates should be published on a 2-week interval. These can be simple factual updates about what work has been completed and what work is in progress. 64 | - A Specification suitable for broader client adoption. This will likely be a collection of EIP proposals. 65 | - A mainnet client implementation in a fork of one of the existing mainnet client codebases. 66 | - Presentation of EIP proposals in AllCoreDevs and engagement in AllCoreDevs discussions. 67 | - Attendence and engagement in public calls such as AllCoreDevs 68 | - Engaging with the EF on experiments, analytics, etc if requested 69 | 70 | 71 | ## Fee Structure 72 | 73 | ### Invoices 74 | 75 | The chosen vendor will be expected to submit invoices every 2 months. 76 | 77 | 78 | ### Payment method 79 | 80 | The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. 81 | 82 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at https://www.coingecko.com). 83 | 84 | ## Selection Criteria 85 | 86 | The selected vendor will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly: 87 | 88 | ``` 89 | Familiarity with the Ethereum "State" trie 90 | Familiarity with the EVM and the various places where 20-byte address types are used. 91 | Familiarity with how ecosystem tooling uses addresses 92 | ``` 93 | 94 | > The scope of this work is large enough that we will be preferring teams over individuals. Individuals are still encouraged to submit a proposal as there may be options available for collaboration. 95 | 96 | 97 | ## Bidding Instructions 98 | 99 | 100 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 101 | 102 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 103 | 104 | Proposals must be submitted before **TODO**. We expect to take 1 week to deliberate and respond. 105 | 106 | Please send initial confirmations, and proposals (in PDF format) to the following address: rfp@ethereum.org 107 | 108 | > Feel free to send us any questions you may have: rfp@ethereum.org 109 | -------------------------------------------------------------------------------- /closed-rfps/staking-operator-docs.md: -------------------------------------------------------------------------------- 1 | # Staking Operator Documentation RFP 2 | 3 | The Ethereum Foundation (EF) is seeking proposals from technical experts to create better documentation for staking operators. Technical documentation is needed to help up-skill existing operators from hobbyists, and smaller staking operators to a professional level. 4 | 5 | This documentation should focus on high-level guidance rather than step-by-step instructions to ensure that operators continue to function with a diversity of setup. The aim of this documentation is to increase the number of professional staking operators available to the Ethereum community to complement and expand various staking protocols. 6 | 7 | ## **Problem statement** 8 | 9 | ### **High level** 10 | 11 | The diversity of staking operators is critical to Ethereum aiding in both decentralisation and security. 12 | 13 | Today, there are roughly only 60 - 100 staking operators capable of running staking operations at scale. 14 | 15 | A number of new pools and staking groups are emerging in this space, but there is a lack of resources to give a high level overview of the different options available in running staking operations. 16 | 17 | ### **Requirements** 18 | 19 | The technical staking operator documentation should include (not exhaustive): 20 | 21 | - **Monitoring** 22 | - **Updates and Releases** 23 | - **On-Call/Incidence response** 24 | - **Resource scaling** 25 | - **Migration** 26 | - **Availability/Uptime** 27 | - **Key management** 28 | - **Security** 29 | 30 | There are a number of ways to approach these topics and the documentation should give high level view on how to think about and approach the various problems with the tools and techniques available rather than a specific step-by-step guide. 31 | 32 | A successful applicant should have technical knowledge in Ethereum staking operations and securing production systems. 33 | 34 | ### **RFP Details** 35 | 36 | As noted above, the EF is looking to accept only one proposal from an independent consultant or small team with strong technical knowledge in staking operations and securing production systems. 37 | 38 | ### **Process summary** 39 | 40 | The entire process can be summarized as follows: 41 | 42 | 1. **Request:** EF releases RFP (this post) 43 | 2. **Gather:** Consultants submit proposals 44 | 3. **Deliberate:** EF analyzes proposals, discusses dynamically any suggestions in structure, direction, fee schedule, and/or timeline, and comes up with a plan based on the resources and needs of the accepted proposal(s). 45 | 4. **Propose:** EF proposes a final structure of the proposal based upon deliberations/discussions. 46 | 5. **Begin:** Team accepts and work begins 47 | 48 | ### **Engagement timeline** 49 | 50 | The EF proposes projects be structured as a two to four-month engagement with milestones/check-ins throughout. 51 | 52 | Initial proposals will not be accepted for longer than four-month engagements. Subsequent proposals and grants can be formulated for follow-up work in the event this engagement goes well and a continuation is warranted. 53 | 54 | ### **Deliverables** 55 | 56 | The consultant is expected to refine their deliverables as a part of scoping the project. Deliverables can include but are not limited to -- website/wikis, blog posts, technical graphs/diagrams, instructional videos, etc. 57 | 58 | EF can facilitate feedback from staking operators after the initial draft. 59 | 60 | ## **Bidding instructions** 61 | 62 | Upon reception of this request, interested consultants are expected to confirm receipt and intention to submit a proposal. 63 | 64 | In this confirmation, Teams should explain what they need from the EF in order to get started. The EF is happy to help get you up to speed via sharing additional resources and/or answering direct questions. 65 | 66 | Proposals must be submitted by 8th July 2022. 67 | 68 | Please send initial confirmations, and proposals (in PDF format) to the following address: [rfp@ethereum.org](mailto:rfp@ethereum.org) 69 | 70 | *Feel free to send us any questions you may have: [rfp@ethereum.org](mailto:rfp@ethereum.org)* 71 | 72 | -------------------------------------------------------------------------------- /closed-rfps/state-expiry-initial-implementation-and-spec-development.md: -------------------------------------------------------------------------------- 1 | # State Expiry: Request for Proposals 2 | 3 | ## Introduction 4 | 5 | The Ethereum Foundation would like to announce a Request for Proposals (RfP) for the research and development needed to take the proposed concept for "State Expiry" from its current form into a complete specification and client implementation. 6 | 7 | State Expiry is a proposed scheme for introducing economic bounds on the total state size necessary to operate a node on the Ethereum network. The current proposed scheme is currently described in this document: https://hackmd.io/@vbuterin/state_expiry_paths 8 | 9 | This proposal is for an open ended engagement with three goals to be implemented in two stages. 10 | 11 | 1. Stage 1: 12 | - Additional research into the proposed scheme to validate the approach and gain broader buy in from core devs 13 | 2. Stage 2: 14 | - Implement it in one of the mainnet Ethereum client codebases. (Besu, Geth, Nethermind, OpenEthereum, TurboGeth). 15 | - A complete specification in the form of an EIP suitable for consideration by core devs and implementations by other client teams. 16 | 17 | ## Scope 18 | 19 | We are looking for an open ended engagement with an individual or team (referred to as "vendor") who can commit their time towards the research and development necessary to bring "State Expiry" to a point where it can be included in the core Ethereum protocol. 20 | 21 | The vendor should expect to: 22 | 23 | - Leverage communication channels such as the R&D Discord and Research and Magicians forums to engage the core development community 24 | - Research Forums: https://ethresear.ch/ 25 | - Magicians Forums: https://ethereum-magicians.org/ 26 | - R&D Discord: *Invite available upon request* 27 | - Produce technical write ups and explanations of the proposed scheme 28 | 29 | 30 | ### Stage 1 31 | 32 | "State Expiry" is currently only loosely specified in the linked HackMD document. Additional research is necessary to extend what is layed out in the HackMD document into a fully specified set of protocol changes. In this stage, vendor should focus on gaining a detailed understanding of the problem, producing detailed write ups of what they learn, exploration into potential problems, exploration and understanding of any trade-offs present in the scheme. This process should include continuous feedback and engagement with the core development community. 33 | 34 | 35 | ### Stage 2 36 | 37 | Once research has validated that the scheme appears to be viable, and there is clear buy-in from the core development community, work should shift towards a concrete spec and accompanying implementation in a mainnet Ethereum client. 38 | 39 | - The specification should take the form of one or more EIP documents 40 | - The implementation should be suitable for running a test network 41 | 42 | > EIP: Ethereum Improvement Proposals - https://github.com/ethereum/EIPs 43 | 44 | ## Process Summary 45 | 46 | The entire process can be summarized as follows: 47 | 48 | - **Request**: EF releases RfP (this post) 49 | - **Gather**: Vendors submit proposals 50 | - **Deliberate**: EF decides which proposal to accept, and comes up with a plan based on the resources and needs of the accepted proposal. 51 | - **Propose**: EF proposes the plan to vendor, and makes adjustments based on vendor’s feedback 52 | - **Begin**: Vendor accepts and work begins 53 | 54 | 55 | ## Timeline 56 | 57 | We expect this engagement to be open ended with an estimated lower bound of 6 months and upper bound of 18 months. 58 | 59 | 60 | ## Deliverables 61 | 62 | - Public facing development updates should be published on a 2-week interval. These can be simple factual updates about what work has been completed and what work is in progress. 63 | - A Specification suitable for broader client adoption. This will likely be a collection of EIP proposals. 64 | - A mainnet client implementation in a fork of one of the existing mainnet client codebases. 65 | - Presentation of EIP proposals in AllCoreDevs and engagement in AllCoreDevs discussions. 66 | - Attendence and engagement in public calls such as AllCoreDevs 67 | - Engaging with the EF on experiments, analytics, etc if requested 68 | 69 | 70 | ## Fee Structure 71 | 72 | ### Invoices 73 | 74 | The chosen vendor will be expected to submit invoices every 2 months. 75 | 76 | 77 | ### Payment method 78 | 79 | The vendor will be given the option to be paid in Fiat money (via bank transfer) or ETH. 80 | 81 | If the vendor chooses to be paid in ETH, the value of ETH described under the agreement will be the value in USD at NYSE closing time (4 PM EST) on the day prior to the due date (as described at https://www.coingecko.com). 82 | 83 | ## Selection Criteria 84 | 85 | The selected vendor will *either* have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP **or** have sufficient base knowledge and expressed intent to learn. 86 | 87 | Areas of expertise that will be beneficial: 88 | 89 | ``` 90 | Familiarity with the Ethereum "State" trie 91 | Familiarity with the EVM 92 | Familiarity with the concept of imposing economic bounds on the total state size 93 | ``` 94 | 95 | The scope of this work is large enough that we will be preferring teams over individuals. Individuals are still encouraged to submit a proposal as there may be options available for collaboration. 96 | 97 | This RfP is intented to be an on-ramp to core protocol development. We are not interested in "mercenary" work. Applicants should have an intrinsic interest in continued work on the core Ethereum protocols. 98 | 99 | 100 | ## Bidding Instructions 101 | 102 | 103 | Upon reception of this request, interested vendors are expected to confirm receipt and intention to bid on the engagement. 104 | 105 | In this confirmation, they should explain what they need from us in order to get started. As well as bring attention to areas in which they feel they do not have significant expertise. We will use this information to try to provide appropriate entrance material for the engagement. 106 | 107 | Proposals must be submitted before **TODO**. We expect to take 1 week to deliberate and respond. 108 | 109 | Please send initial confirmations, and proposals (in PDF format) to the following address: rfp@ethereum.org 110 | 111 | > Feel free to send us any questions you may have: rfp@ethereum.org 112 | -------------------------------------------------------------------------------- /open-rfps/pectra-system-contracts-audit.md: -------------------------------------------------------------------------------- 1 | # Pectra System Contracts Bytecode Audit RFP 2 | 3 | The Ethereum Foundation is soliciting proposals for an audit of the bytecode of three smart contracts related to the Pectra hard fork. These are system contracts to be used by EIPs 2935, 7002, 7251 (linked below). They will be deployed prior to the hard fork or as part of its migration. 4 | 5 | ## Audit Requirements 6 | 7 | The audit should focus **exclusively** on the smart contract bytecode, referenced in the EIPs below. It **should not** encompass all of the EIPs, or client implementations of the EIPs, including their interactions with the contracts. 8 | 9 | The audit should validate whether the contracts' bytecode meet the functionality described in the EIPs. The audit should also highlight any potential security vulnerabilities associated with the contract, both as part of its normal utilization and by malicious users. If and where applicable, the audit should ideally propose fixes or improvements to the contract code. 10 | 11 | There is a possibility the EIP authors may make changes to the contract code after the publication of this RFP, although we do not expect their semantics to change significantly. The latest versions of the bytecode will be shared with auditors prior to the beginning of the audit. 12 | 13 | ### [EIP-2935: Serve historical block hashes from state](https://eips.ethereum.org/EIPS/eip-2935) 14 | 15 | The contract contains a ring buffer of historical block hashes and two code paths, `get` and `set`, depending on the caller. Expected calldata formats and behavior for each are specified in the EIP. 16 | 17 | ### [EIP-7002: Execution layer triggerable withdrawals](https://eips.ethereum.org/EIPS/eip-7002) 18 | 19 | The contract contains a queue of staking withdrawal requests and three code paths depending on the caller and input: `add_withdrawal_request`, `get_excess_withdrawal_requests`, and `read_withdrawal_requests`. Excess withdrawal requests beyond what the consensus layer can process are queued and a fee is calculated to prevent spam requests. 20 | 21 | In addition to the semantics in the EIP, the audit should evaluate the contract behavior prior to the first system call -- noting the initial withdrawal request fee. The first system call will occur in the first block following the hard fork, but the contract can be called before then. 22 | 23 | A [geas](https://github.com/fjl/geas) implementation of the contract can be found in [this repository](https://github.com/lightclient/sys-asm). 24 | 25 | ### [EIP-7251: Increase the MAX_EFFECTIVE_BALANCE](https://eips.ethereum.org/EIPS/eip-7251) 26 | 27 | The contract contains a queue of requests to consolidate validators in response to a consensus layer parameter change. It contains three code paths depending on the caller and input: `add_consolidation_request`, `get_excess_consolidation_requests`, and `process_consolidation_requests`. A fee is charged for consolidation requests based on excess requests to be processed, similar to 7002. 28 | 29 | In addition to the semantics in the EIP, the audit should evaluate the contract behavior prior to the first system call -- noting the consolidation request fee calculated using `EXCESS_INHIBITOR`. 30 | 31 | A [geas](https://github.com/fjl/geas) implementation of the contract can be found in [this repository](https://github.com/lightclient/sys-asm). 32 | 33 | ## Proposal Submission 34 | 35 | To submit a bid for the audit, please email your proposal to rfp@ethereum.org with the subject line "Pectra System Contracts Bytecode Audit" by October 11, 2024. 36 | 37 | Proposals should include a summary of work to be performed, a timeline for completion of the audit, and a price for the engagement. Proposals will be judged on technical expertise, possible start dates, and cost, at the discretion of the Ethereum Foundation. 38 | 39 | Accepted proposals will be confirmed by October 22, 2024 at the latest. 40 | --------------------------------------------------------------------------------