diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 1f72d5ca..89c62e4d 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -15,33 +15,34 @@ - [Week 7 | Research](/eps/week7-research.md) - [Week 8 | Dev](/eps/week8-dev.md) - [Week 8 | Research](/eps/week8-research.md) + - [Week 9 | Dev](/eps/week9-dev.md) + - [Week 9 | Research](/eps/week9-research.md) - [Contributing](contributing.md) - **Protocol Wiki** - The Protocol - [Overview](/wiki/protocol/overview.md) - [History](/wiki/protocol/history.md) - - [Coordination](/wiki/protocol/pm.md) - - [Data Structures](/wiki/protocol/data-structures.md) - - [CS Resources] - Execution Layer - [EL Clients](/wiki/EL/el-clients.md) - [EL Specs](/wiki/EL/el-specs.md) - Client architecture - [EVM](/wiki/EL/evm.md) - - [Precompiled Contracts](/wiki/EL/precompiled-contracts.md) - - [Transaction](/wiki/EL/transaction.md) - - [DevP2P] + - [Transaction anatomy](/wiki/EL/transaction.md) - [JSON-RPC](/wiki/EL/JSON-RPC.md) + - [Data Structures](/wiki/el/data-structures.md) + - [DevP2P] + - [Precompiled Contracts](/wiki/EL/precompiled-contracts.md) - [Consensus Layer](/wiki/CL/overview.md) - [CL Clients](/wiki/CL/cl-clients.md) - [CL Specs](/wiki/CL/cl-specs.md) + - Client architecture - [Proof-of-Stake] - [Beacon API] - [Networking](/wiki/CL/cl-networking.md) - - Client architecture - Development - [Core development](/wiki/dev/core-development.md) - - [Network upgrades](/wiki/dev/upgrades.md) + - [Coordination](/wiki/protocol/pm.md) + - [CS Resources] - Testing and security - [Testing overview](/wiki/testing/overview.md) - [Incidents](/wiki/testing/incidents.md) @@ -61,7 +62,7 @@ - [ePBS](/wiki/research/PBS/ePBS.md) - [ET](/wiki/research/PBS/ET.md) - Proof of Stake - - [Upgrades](/docs/wiki/research/Beacon%20Chain%20Upgrades.md) + - [Upgrades](/docs/wiki/research/cl-upgrades.md) - SSF - SSLE - [Light Clients](/wiki/research/light-clients.md) @@ -71,12 +72,14 @@ - EOF - Portal Network - [Cryptography](/wiki/Cryptography/intro.md) - - [ECDSA](/wiki/Cryptography/ecdsa.md) + - [ECDSA](/wiki/Cryptography/ecdsa.md) + - [Keccak256](/wiki/Cryptography/keccak256.md) - BLS - [Commitments] - Polynomials - Commitment schemes - ZK + - [Post-Quantum Cryptography](/wiki/Cryptography/post-quantum-cryptography.md) - [Protocol Fellowship](/wiki/epf.md) - **Wiki Info** diff --git a/docs/eps/intro.md b/docs/eps/intro.md index 27f615b7..07938c53 100644 --- a/docs/eps/intro.md +++ b/docs/eps/intro.md @@ -39,7 +39,7 @@ The second part of the program offers two distinct tracks focused on development | April 3 | Verkle trees | [Josh Rudolf](https://github.com/jrudolf) | Research | | April 8 | Consensus client architecture | [Paul Harris](https://github.com/rolfyone) | Development | | April 10 | MEV and censorship | [Barnabe Monnot](https://github.com/barnabemonnot) | Research | -| April 15 | Devops and testing | [Paritosh](https://github.com/parithosh) | Development | +| April 15 | Devops and testing | [Parithosh](https://github.com/parithosh) | Development | | April 17 | Purge and Portal Network | [Piper Merriam](https://github.com/pipermerriam) | Research | | April 22 | Cryptographic precompiles | | Development | | April 24 | SSF and PoS Upgrades | [Francesco D’Amato](https://github.com/fradamt) | Research | diff --git a/docs/eps/presentations/week9-dev.pdf b/docs/eps/presentations/week9-dev.pdf new file mode 100644 index 00000000..3e2e6387 Binary files /dev/null and b/docs/eps/presentations/week9-dev.pdf differ diff --git a/docs/eps/week5.md b/docs/eps/week5.md index 2b3c398c..cbed8e22 100644 --- a/docs/eps/week5.md +++ b/docs/eps/week5.md @@ -13,7 +13,7 @@ Before starting with the week 5 content, make yourself familiar with resources i Additionally, you can read and get ready by studying the following resources: - https://ethereum.org/en/roadmap/ -- https://notes.ethereum.org/@domothy/roadmap +- https://domothy.com/roadmap/ - https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum - https://ethereum.org/en/community/research/#active-areas-of-ethereum-research - https://domothy.com/blobspace/ @@ -61,4 +61,4 @@ Additionally, you can read and get ready by studying the following resources: - https://scroll.io/blog/kzg - [Ethereum data structures](https://arxiv.org/pdf/2108.05513.pdf) - https://ethresear.ch/t/execution-tickets/17944 -- https://notes.ethereum.org/@ipsilon/evm-object-format-overview \ No newline at end of file +- https://notes.ethereum.org/@ipsilon/evm-object-format-overview diff --git a/docs/eps/week9-dev.md b/docs/eps/week9-dev.md index 9a102107..394783aa 100644 --- a/docs/eps/week9-dev.md +++ b/docs/eps/week9-dev.md @@ -1,27 +1,44 @@ -# Study Group Week 9 | MEV and censorship resistance +# Study Group Week 9 | Local testing and prototyping -This research talk is dedicated to MEV and censorship resistance, discusses the current state and proposals being worked on. +This development talk is dedicated to testing and prototyping forks locally, it discusses the current state and ideas being worked on. -Join the presentation by [Paritosh](https://twitter.com/parithosh_j), the Ethereum testnet guru from EF Devops on [Wednesday, April 15, 4PM UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-china-shanghai-ny-new-york-city-japan-tokyo-australia-sydney-india-delhi-argentina-buenos-aires/apr-15-2024/4pm). +Watch the presentation by [Parithosh](https://twitter.com/parithosh_j) on StreamETH channel or Youtube. Slides are [available here](https://github.com/eth-protocol-fellows/protocol-studies/blob/main/docs/eps/presentations/week9-dev.pdf). -The talk will be streamed live on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) and [Youtube](https://www.youtube.com/@ethprotocolfellows/streams), links will be provided before the call in the [Discord server](https://discord.gg/addwpQbhpq). Discord also serves for the discussion and questions during the stream. + ## Pre-reading Before starting with the week 9 development content, make yourself familiar with resources in previous weeks, especially week 4 presentation on testing and the node workshop. It's important to understand the current architecture of the protocol and its basic tooling. Additionally, you can get ready by studying the following resources: -- [#TestingTheMerge retrospective](https://www.youtube.com/watch?v=pIlRYW5HQgA&pp=ygURcGFyaXRvc2ggZXRoZXJldW0%3D) +- [Quest for the Best Tests, a Retrospective on #TestingTheMerge by Pari](https://archive.devcon.org/archive/watch/6/quest-for-the-best-tests-a-retrospective-on-testingthemerge/?tab=YouTube) +- [Dencun testing](https://www.youtube.com/watch?v=88tZticGbTo) -## Outline +## Preparation +- [Install kurtosis and docker on your system](https://docs.kurtosis.com/quickstart/) -- Local testing -- Prototyping -- Handy devops tools? -- Shadow forks? - -## Additional reading and exercises +## Outline +- What do we test and why? +- Importance of Local testing +- How can I prototype a tool or change? +- What are devnets? How do we spin them up? +- Shadow forks +- Handy devops tools + - Kurtosis + - Template-devnets + - Assertoor + - Forky + - Tracoor + - Dora + - Goomy-blob + - Xatu +- Run your own local devnet and shadowfork! + +## Additional reading and exercises - [Attacknet: Chaos engineering on Ethereum](https://ethpandaops.io/posts/attacknet-introduction/) - [Verkle devnets](https://github.com/ethpandaops/verkle-devnets) -- [Kurtosis](https://github.com/kurtosis-tech/kurtosis) \ No newline at end of file +- [Kurtosis](https://github.com/kurtosis-tech/kurtosis) +- Follow exercises proposed by Pari in the talk + - Modify a client with a custom log message and run it using Kurtosis + - Deploy some of the tolling, connect to your own node on any network \ No newline at end of file diff --git a/docs/eps/week9-research.md b/docs/eps/week9-research.md new file mode 100644 index 00000000..8089b891 --- /dev/null +++ b/docs/eps/week9-research.md @@ -0,0 +1,50 @@ +# Study Group Week 9 | Purge and Portal Network + +Week 9 research talk is focused on history expiry and dives into Portal Network, an overlay network for light clients enabling alternative access to current and historical data. + +Join the presentation by [Piper Merriam](https://twitter.com/parithosh_j), on [Wednesday, April 17, 3PM UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-china-shanghai-ny-new-york-city-japan-tokyo-australia-sydney-india-delhi-argentina-buenos-aires/apr-17-2024/3pm). + +The talk will be streamed live on [StreamEth](https://streameth.org/65cf97e702e803dbd57d823f/epf_study_group) and [Youtube](https://www.youtube.com/@ethprotocolfellows/streams), links will be provided before the call in the [Discord server](https://discord.gg/addwpQbhpq). Discord also serves for the discussion and questions during the stream. + +## Pre-reading + +Before starting with the week 9 research content, make yourself familiar with resources in previous weeks, especially week 5 presentation on roadmap. You should understand the execution client database structure, the difference between ancient and current data. + +Additionally, you can get ready by studying the following resources: +- [Statelessness and history expiry, Ethereum.org](https://ethereum.org/en/roadmap/statelessness/) +- [Portal Network web](https://www.ethportal.net/) + +## Outline + +- History expiry in Ethereum execution clients +- Portal Network + +## Additional reading and exercises + +- EIP-4444 + - https://eips.ethereum.org/EIPS/eip-4444 +- SELFDESTRUCT Removal EIPS (many are stale) + - https://eips.ethereum.org/EIPS/eip-6049 + - https://eips.ethereum.org/EIPS/eip-6780 + - https://eips.ethereum.org/EIPS/eip-2936 + - https://eips.ethereum.org/EIPS/eip-4758 + - https://eips.ethereum.org/EIPS/eip-4760 + - https://eips.ethereum.org/EIPS/eip-6046 + - https://eips.ethereum.org/EIPS/eip-6190 + - EOF things: https://hackmd.io/@shemnon/mega-eof-scoping +- LOG reform + - https://eips.ethereum.org/EIPS/eip-7668 + - https://github.com/ethereum/EIPs/pull/8368 +- Address Space Extension + - https://github.com/ethereum/EIPs/pull/8385 + - https://ethereum-magicians.org/t/thoughts-on-address-space-extension-ase/6779 + - https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485 + - https://notes.ethereum.org/@ipsilon/address-space-extension-exploration +- State Expiry + - https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal + - https://medium.com/@chaisomsri96/statelessness-series-part1-state-expiry-history-expiry-2bbd5835b329 (did not fully vet this article) + - https://notes.ethereum.org/@vbuterin/state_expiry_eip + - https://hackmd.io/@vbuterin/state_expiry_paths +- General Stateless Roadmap Things + - https://ethereum.org/en/roadmap/statelessness/ +- [The Portal Network, EthZurich 2023](https://www.youtube.com/watch?v=8MUii5W2sMc) diff --git a/docs/index.html b/docs/index.html index 373c6610..df52dab1 100644 --- a/docs/index.html +++ b/docs/index.html @@ -408,6 +408,15 @@ document.body.appendChild(editCSS); } + + + + + diff --git a/docs/wiki/Cryptography/ecdsa.md b/docs/wiki/Cryptography/ecdsa.md index d0236317..533ddbd4 100644 --- a/docs/wiki/Cryptography/ecdsa.md +++ b/docs/wiki/Cryptography/ecdsa.md @@ -276,6 +276,9 @@ This discussion is a preliminary treatment of Elliptic Curve Cryptography. For a And finally: **never roll your own crypto!** Use trusted libraries and protocols to protect your data and transactions. +> ℹ️ Note +> ECDSA faces potential obsolescence from quantum computers – learn about how [Post-Quantum Cryptography tackles this challenge.](/wiki/Cryptography/post-quantum-cryptography.md) + ## Further reading **Elliptic curve cryptography** diff --git a/docs/wiki/Cryptography/post-quantum-cryptography.md b/docs/wiki/Cryptography/post-quantum-cryptography.md new file mode 100644 index 00000000..d3a11c76 --- /dev/null +++ b/docs/wiki/Cryptography/post-quantum-cryptography.md @@ -0,0 +1,100 @@ +# Post-Quantum Cryptography + +Classical cryptography safeguards information by leveraging the inherent difficulty of certain mathematical problems. Such group of problems as prime factoring, discrete logarithm, graph isomorphism, and the shortest vector problem etc. fall under the area of mathematical research called the ["Hidden Subgroup Problem (HSP)"](https://en.wikipedia.org/wiki/Hidden_subgroup_problem). + +In essence, these problems makes determining the structure of a secret subgroup (size, elements) within a large group computationally intractable without the knowledge of a "secret" (private) key. This one-way "trapdoor function" is employed by public-key cryptography algorithms for their security. + +[RSA's](https://en.wikipedia.org/wiki/RSA_(cryptosystem)) security rests on the **factoring of large prime numbers**. In contrast, [ECDSA's](/wiki/Cryptography/ecdsa.md) security is based on the elliptic curve **discrete logarithm problem**. Solving either of these hidden subgroup problems becomes exponentially harder as the key size increases, making them computationally infeasible for classical computers to crack. This fundamental difficulty safeguards encrypted data. + +However, the landscape is shifting. + +Quantum computers, harnessing the principles of quantum mechanics, offer novel computational approaches. Certain quantum algorithms can solve these classical cryptographic problems with exponential efficiency compared to their classical counterparts. This newfound capability poses a significant threat to the security of data encrypted with classical cryptography. If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptography currently in use. + +[Shor's algorithm](https://ieeexplore.ieee.org/document/365700) for integer factorization is the most celebrated application of quantum computing. It factors n-digit integers in a time complexity less than $O(n^3)$, a significant improvement over the best classical algorithms. + +This is where the field of post-quantum cryptography comes in. It aims to develop new algorithms that remain secure even in the presence of powerful quantum computers. + +## Timeline + +According to the survey done for ["Quantum Threat Timeline Report 2020"](https://globalriskinstitute.org/publication/quantum-threat-timeline-report-2020/) most experts believe that there is <5% threat to the public-key cryptography until 2030. However, it is predicted that the risk substantially increases to about 50% by 2050. + +Currently, the most [advanced quantum computers](https://en.wikipedia.org/wiki/List_of_quantum_processors) have <2000 physical qubits. Breaking Bitcoin's encryption within an hour (ideal time window) [requires approximately 317 million physical qubits](https://pubs.aip.org/avs/aqs/article/4/1/013801/2835275/The-impact-of-hardware-specifications-on-reaching). + +Steady progress is being made in quantum research; one survey respondent notes: + +> It is not always the case [..] but I find that my predictions are often more pessimistic than what actually happens. I take this as a sign that the research is accelerating. + +Note that these predictions are somewhat subjective and might not reflect real progress which is mostly not open to public. Advanced threat actor might have access to powerful quantum computing sooner than public and use strategies like [retrospective decryption](https://en.wikipedia.org/wiki/Harvest_now%2C_decrypt_later). + +## Post-Quantum risk to Ethereum + +Ethereum accounts are secured by a two-tier cryptosystem. A private key is used to generate a public key through [elliptic curve multiplication](/wiki/Cryptography/ecdsa.md). This public key is hashed using [keccak256](/wiki/Cryptography/keccak256.md) to derive the Ethereum address. + +The immediate post-quantum threat is the ability to reverse elliptic curve multiplication securing ECDSA thus exposing the private key. This makes all externally owned accounts (EOA) vulnerable to a quantum attack. Assuming the hashing function that maps a public-key to an ethereum address is still safe, extracting its private key is still challenging but vulnerable nonetheless. + +In practice, most users’ private keys are themselves the result of a bunch of hash calculations using [BIP-32](https://github.com/bitcoin/bips/blob/b3701faef2bdb98a0d7ace4eedbeefa2da4c89ed/bip-0032.mediawiki), which generates each address through a series of hashes starting from a master seed phrase. This makes revealing the private key even more computationally expensive. + +EthResearch has an [ongoing proposal](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901) for a hard-fork in the event of a post-quantum emergency, the key actions being: + +1. Revert all blocks after the first block where it’s clear that large-scale theft is happening +2. Traditional EOA-based transactions are disabled +3. A new transaction type is added to allow transactions from smart contract wallets (eg. part of [RIP-7560](https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664)), if this is not available already +4. A new transaction type or opcode is added by which you can provide a STARK proof which proves knowledge of (i) a private preimage x, (ii) a hash function ID `1 <= i < k` from a list of k approved hash functions, and (iii) a public address A, such that `keccak(priv_to_pub(hashes[i](x)))[12:] = A`. The STARK also accepts as a public input the hash of a new piece of validation code for that account. If the proof passes, your account’s code is switched over to the new validation code, and you will be able to use it as a smart contract wallet from that point forward. + +The approach, however, is not perfect. Some users will still loose funds since not all blocks from the event of an attack will be reverted. This is because it is incredibly hard to reliably detect a quantum attack on the network as [domothy highlights](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901/14): + +> Picture a single large exchange wallet being drained by a quantum computer. Everyone would naturally assume it was a security failure of some kind on the exchange’s end. Or if a smart wallet relying on discrete log assumption gets drained, a smart contract bug/exploit would be the first thing that comes to mind. Or the quantum-enabled attacker avoids high profile targets altogether and slowly steals funds from various large EOAs, and we never even know a quantum attack took place. + +Further, KZG commitment schemes powering [EIP-4844](/wiki/research/scaling/core-changes/eip-4844.md) would also need to be upgraded to prevent fraudulent commits. + +## Research + +Post-quantum cryptography is an active area of research. Several organizations are working on prototyping, development, and standardization of new post-quantum algorithms. + +### NIST Post-Quantum Cryptography + +The [NIST Post-Quantum Cryptography standardization](https://csrc.nist.gov/projects/post-quantum-cryptography) effort is a competition like process to solicit, evaluate, and standardize one or more quantum-resistant public-key cryptographic algorithms. + +### Selected Algorithms by NIST as part of third round in 2022 + +#### I. Public-key Encryption and key-establishment algorithms + +- [CRYSTALS-KYBER](https://pq-crystals.org/) by Peter Schwabe et al. + +#### II. Digital signature algorithm + +- [CRYSTALS-DILITHIUM](https://pq-crystals.org/) by Vadim Lyubashevsky et al. +- [FALCON](https://falcon-sign.info/) by Thomas Prest et al. +- [SPHINCS+](https://falcon-sign.info/) by Andreas Hulsing et al. + + NIST's ["2022 status report"](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=934458) documents the standardization process, evaluation criteria, and security models. + +### Post-Quantum Cryptography Alliance + +[Post-Quantum Cryptography Alliance (PQCA)](https://pqca.org/), an open and collaborative initiative by [linux foundation](https://www.linuxfoundation.org/press/announcing-the-post-quantum-cryptography-alliance-pqca) to drive the advancement and adoption of post-quantum cryptography. + +[The Open Quantum Safe (OQS)](https://openquantumsafe.org/) project under this initiative is an open-source project that aims to support the transition to quantum-resistant cryptography. + +### The Crypto Forum Research Group + +The [Crypto Forum Research Group](https://datatracker.ietf.org/rg/cfrg/about/) within the Internet Engineering Task Force has standardized the stateful hash-based signature scheme ["XMSS: eXtended Merkle Signature Scheme."](https://datatracker.ietf.org/doc/rfc8391/) + +## Production usage + +Following pilot projects and research initiatives are exploring PQC usage in production: + +- [Anchor Vault](https://chromewebstore.google.com/detail/omifklijimcjhfiojhodcnfihkljeali) is a chrome plugin allows adding a quantum-resistant proof using Lamport's signature for securing ERC tokens. +- Signal has implemented ["Post-Quantum Extended Diffie-Hellman"](https://signal.org/docs/specifications/pqxdh/#introduction) in production for key agreement protocol. +- Chromium started supporting ["Hybrid Kyber KEM"](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html) to protect data in transit. +- Apple has implemented [PQ3](https://security.apple.com/blog/imessage-pq3/) to protect iMessage against key compromise from a quantum attack. + +## Resources + +- 📝 Daniel J. Bernstein and et al, ["Introduction to post-quantum cryptography"](https://pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf) +- 📝 Wikipedia, ["Quantum algorithm."](https://en.wikipedia.org/wiki/Quantum_algorithm) +- 📝 P.W. Shor, ["Algorithms for quantum computation: discrete logarithms and factoring."](https://ieeexplore.ieee.org/document/365700) +- 📝 NIST, ["Post-Quantum Cryptography."](https://csrc.nist.gov/projects/post-quantum-cryptography) +- 📝 ETHResearch, ["How to hard-fork to save most users’ funds in a quantum emergency."](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901) +- 📝 ETHResearch, ["ETHResearch: Post-Quantum"](https://ethresear.ch/tag/post-quantum) +- 📝 Vitalik Buterin, ["STARKs, Part I: Proofs with Polynomials."](https://vitalik.eth.limo/general/2017/11/09/starks_part_1.html) +- 📝 Wikipedia, ["Lamport's Signature."](https://en.wikipedia.org/wiki/Lamport_signature) diff --git a/docs/wiki/protocol/data-structures.md b/docs/wiki/EL/data-structures.md similarity index 100% rename from docs/wiki/protocol/data-structures.md rename to docs/wiki/EL/data-structures.md diff --git a/docs/wiki/protocol/pm.md b/docs/wiki/dev/pm.md similarity index 100% rename from docs/wiki/protocol/pm.md rename to docs/wiki/dev/pm.md diff --git a/docs/wiki/research/PBS/ePBS.md b/docs/wiki/research/PBS/ePBS.md index 8b1164e8..044488b0 100644 --- a/docs/wiki/research/PBS/ePBS.md +++ b/docs/wiki/research/PBS/ePBS.md @@ -1,5 +1,11 @@ # Enshrined Proposer-Builder Separation (ePBS) +## Roadmap tracker + +| Upgrade | URGE | Track | Topic | Cross-references | +|:-------:|:-----------:|:---------:|:---------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| ePBS | the Scourge | MEV track | Endgame block production pipeline | intersection with: [ET](https://ethresear.ch/t/execution-tickets/17944), [PEPC](https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4), [IL](https://eips.ethereum.org/EIPS/eip-7547) | + ## TLDR; Enshrined Proposer-Builder Separation (ePBS) refers to integrating the PBS mechanism directly into the Ethereum blockchain protocol itself, rather than having it operate through external services or addons. This integration aims to formalize and standardize the separation between the roles of block proposers and block builders within the core protocol rules, enhancing the system's efficiency, security, and decentralization. diff --git a/docs/wiki/research/Beacon Chain Upgrades.md b/docs/wiki/research/cl-upgrades.md similarity index 95% rename from docs/wiki/research/Beacon Chain Upgrades.md rename to docs/wiki/research/cl-upgrades.md index 092b19ef..8c121ccf 100644 --- a/docs/wiki/research/Beacon Chain Upgrades.md +++ b/docs/wiki/research/cl-upgrades.md @@ -1,4 +1,4 @@ -## BEACON CHAIN UPGRADES +# Beacon Chain upgrades ### Inclusion Lists ### Preconfirmations diff --git a/docs/wiki/research/roadmap.md b/docs/wiki/research/roadmap.md index e69de29b..81f39f2d 100644 --- a/docs/wiki/research/roadmap.md +++ b/docs/wiki/research/roadmap.md @@ -0,0 +1,3 @@ +# Roadmap + +Overview of the research landscape. Check week 5 presentation. \ No newline at end of file diff --git a/docs/wiki/testing/hive.md b/docs/wiki/testing/hive.md index e69de29b..eddd3b09 100644 --- a/docs/wiki/testing/hive.md +++ b/docs/wiki/testing/hive.md @@ -0,0 +1,3 @@ +# Hive testing + +https://github.com/ethereum/hive \ No newline at end of file diff --git a/docs/wiki/testing/incidents.md b/docs/wiki/testing/incidents.md index e69de29b..9685046b 100644 --- a/docs/wiki/testing/incidents.md +++ b/docs/wiki/testing/incidents.md @@ -0,0 +1,4 @@ +# Notable mainnet incidents + +- [Post-Mortem Report: Ethereum Mainnet Finality (05/11/2023)](https://medium.com/offchainlabs/post-mortem-report-ethereum-mainnet-finality-05-11-2023-95e271dfd8b2) +- [Minority split 2021-08-27 post mortem](https://github.com/ethereum/go-ethereum/blob/master/docs/postmortems/2021-08-22-split-postmortem.md) \ No newline at end of file diff --git a/notes/Week 8 EPFsg Research Track - Protocol Services.pdf b/notes/Week 8 EPFsg Research Track - Protocol Services.pdf new file mode 100644 index 00000000..ec3b80a0 Binary files /dev/null and b/notes/Week 8 EPFsg Research Track - Protocol Services.pdf differ diff --git a/notes/wiki_contributors_meeting/2024-04-18_kickoff_call.md b/notes/wiki_contributors_meeting/2024-04-18_kickoff_call.md new file mode 100644 index 00000000..6dcec092 --- /dev/null +++ b/notes/wiki_contributors_meeting/2024-04-18_kickoff_call.md @@ -0,0 +1,74 @@ +# Wiki Contributors Meeting #1 - April 18, 2024 (5PM UTC) + +## Agenda + +- Current state of the wiki, issues, PRs +- Feedback from contributors, share your perspective +- Discuss and come up with tasks to accomplish, filling content gaps +- Future of the wiki + +## Participants + +- Angus +- Aritra +- Gorondan +- Kira +- Mario +- meldsun0 +- Nagu +- Rahul +- Rory +- Siddharth + +## Notes + +### Current State of the Wiki and Contributing + +- Mario shared the goals behind developing EPF WIKI. Mario noted the high quality of contributions thus far. +- Kira sees the wiki as a repository to document their learning. They are currently working on Prism client and consensus layer. Overlapping content during collaboration was identified as a point of friction. +- Gorondan emphasized the importance of improved collaboration to expedite completion of open PRs. +- Aritra suggested that pre-agreed upon document flow could lead to better collaboration. +- Rory wondered how to encourage more people to contribute. +- meldsun0 suggested potential reasons for contributor hesitancy, such as difficulty using GitHub. They proposed reaching out to encourage more active participation. +- Mario acknowledged that the contributing.md document might be overwhelming. He asked for further input on the state of the wiki and contributing experience. +- Kira suggested checking for existing content before contributing new sections. Mario confirmed this will be highlighted in the contributing.md document. +- The landing page was discussed as a potential barrier to entry. Mario suggested improvements and mentioned promoting the wiki once closer to completion. +- Gorondan proposed promoting the wiki to raise awareness and encourage contributions. Mario agreed and suggested a meetup to share the project. + +### Previous Cohorts and Contributing Experience + +- Rory inquired about previous cohort involvement with the wiki. Mario confirmed this is the first cohort to work on the wiki. While other cohorts have created content, it's not centrally collected. He hopes this wiki serves as a foundation for future cohorts. +- Rory suggested mimicking the core developer experience with breakout rooms for wiki contribution. +- meldsun0 proposed assigning section ownership. Mario found it an interesting idea but unsure if anyone's willing to take ownership. +- Aritra expressed interest in owning the consensus layer section, finding the approach appealing. +- Gorondan suggested approaching the wiki as a collaborative project to collectively complete it. Mario agreed and encouraged volunteers to claim responsibility for sections. +- Rory expressed interest in contributing to the testing section. + +### Open Issues, Roadmap, and Content Gaps + +- Gorondan mentioned his PR on the roadmap and received positive feedback from Mario, who encouraged continued work on it. +- Mario suggested working on open issues and identifying content gaps. While "boring" topics like client overviews are essential for beginners, focusing on these areas was suggested. +- Gorondan expressed willingness to work on client documentation. +- Rahul suggested to include a section about EIPs. Mario confirmed he would add that. +- Sid mentioned el-architecture as a topic he is working on. +- Kira indicated they would submit PRs for sections of interest shortly. Mario mentioned opening more issues later. Everyone was encouraged to comment on existing issues or create new ones. +- Mario acknowledged the importance of bridging basic gaps, mentioning a dependency tree. He emphasized covering foundational topics to provide a starting point for users. +- Originally hoping to have the wiki ready by the end of the study group, Mario acknowledged it might take longer. A target of mid-May was proposed to assess progress and prepare for public promotion. + +### Closing Thoughts + +- To maintain the wiki, Mario suggested continuing these calls, proposing bi-weekly meetings. Timezone preferences were discussed, with most favoring bi-weekly meetings. +- Gorondan raised the challenge of using links in open PRs and suggested faster PR merging. Mario explained the option to fetch updates from upstream but acknowledged considering faster merging. He identified himself as a potential bottleneck and encouraged pinging him to expedite reviews. +- Nagu suggested using reference wikis as a last pass for additional edits once the content is mostly complete. They also inquired about delegating tasks from Mario's workload. +- Mario welcomed assistance with reviewing existing content and onboarding new contributors. +- Nagu proposed cross-posting PRs in the wiki-writers group to encourage reviews. Mario confirmed the GitHub bot already serves this purpose. + +## Next Steps + +- Interested contributors can claim ownership of sections. +- Finalize the meeting schedule, aiming for bi-weekly. +- Contributors are encouraged to open issues for missing content. + +## Meta + +For every meeting, create a new file inside `/notes/wiki_contributors_meeting` using the convention `YYYY-MM-DD_description.md`; eg.`2024-04-01_kickoff_call.md`. This helps preserve chronological order when sorting files. diff --git a/wordlist.txt b/wordlist.txt index 993eafb6..bc62886f 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -21,14 +21,15 @@ Assche Assertoor assignees autoplay +backfill Bankless Barnabe -backfill Beiko Bertoni BFT bitrate bitwise +BIP BLOBHASH blockchain blockchain's @@ -49,14 +50,15 @@ cdots centric chainId cli +cmd CoC codebase codebases CODECOPY config congestions +Consensys Corbellini -cmd Crypto cryptocurrencies cryptocurrency @@ -65,6 +67,7 @@ cryptoeconomically cryptographic cryptographically Cryptopedia +cryptosystem cybersecurity Cypherpunks D'Amato @@ -88,7 +91,9 @@ Devcon Devops devp Devs +devnet Diffie +DILITHIUM discv distro docsify @@ -101,6 +106,7 @@ EB ECADD ECC ECDSA +ECDSA's ECMUL ECPAIRING ECRECOVER @@ -116,6 +122,8 @@ Elmore ELs Encodings env +EOA +EOAs EOF EOY eP @@ -146,6 +154,7 @@ Femboy finalise Forkchoice forkchoiceUpdatedV +Forky FOSS frameborder Francesco @@ -166,12 +175,15 @@ getPayloadV getters Gilles Goron +Goomy gpg Grafana Guillaume hoc Holesky Hsiao +HSP +Hulsing ics iframe ify @@ -196,12 +208,15 @@ Katex keccak Keccak's keecak +KEM Kleppmann Koblitz +KYBER KZG KZGCommitment KZGProof Lamport +Lamport's Lefteris libp lifecycle @@ -215,6 +230,7 @@ Longrightarrow LST Lua LuaVM +Lyubashevsky mainnet Mário mathbb @@ -232,6 +248,7 @@ MMPTs MODEXP modularity Monnot +mortem MPT MSIZE mstore @@ -245,6 +262,7 @@ natively newPayloadV NFT NIST +NIST's NOXX Occhipinti offsites @@ -252,12 +270,13 @@ onchain Oorschot OpenRPC OpenZeppelin +OQS OSI OSI's Parametrizing params Pari -Paritosh +Parithosh Pectra PeerDAS Peeters @@ -267,11 +286,16 @@ Playdate pmod POC POS +PQCA +PQ +PQC pre -preconfirmations precompile precompiled precompiles +preconfirmations +preimage +Prest privateKey probabilistically programmability @@ -282,6 +306,7 @@ PUSHX py Pyspec pytest +qubits radix Rareskills README @@ -301,21 +326,27 @@ rollups rollup's RPC RPCs +RSA +RSA's runtime scalability scalable schemas Schocken +Schwabe SECG secp SELFDESTRUCT sexualized SHA Shafu +shadowfork sharding ShareAlike Shead Shimon +Shor +Shor's Silverman Sipser SLOAD @@ -323,6 +354,7 @@ smlXL SNARKify socio solvm +SPHINCS SSF SSLE SSTORE @@ -331,6 +363,7 @@ SSZ stakers Stallman StateDB +stateful stateRoot stf StreamEth @@ -343,6 +376,7 @@ Tetris textnormal TODO TPS +tracoor tradeoff transactional trapdoored @@ -359,6 +393,7 @@ underbrace Unformatted upstreamed utils +Vadim validator validators Vanstone @@ -375,6 +410,8 @@ WebRTC Whitepaper WIP WSS +Xatu +XMSS XORed xy Yellowpaper @@ -424,3 +461,17 @@ bloXroute's centralisation ethresear mevboost +Potuz's +cryptoeconomics +EF +Attacknet +devnets +Kurtosis +Aritra +Gorondan +Kira +meldsun +Nagu +onboarding +rahul +Siddharth \ No newline at end of file