diff --git a/.gitignore b/.gitignore index d8d18ff1..19b6da4d 100644 --- a/.gitignore +++ b/.gitignore @@ -2,7 +2,5 @@ **/.vscode .idea/ node_modules/ - package-lock.json package.json - diff --git a/development-updates.md b/development-updates.md index a1bb6472..383e1451 100644 --- a/development-updates.md +++ b/development-updates.md @@ -1,3 +1,5 @@ + + # Development Updates This document includes all development updates by contributors to EPF cohort 5. [Learn more](/program-guide/repo-guide.md#development-updates) about creating your development updates. @@ -30,7 +32,7 @@ Phase one is the very beginning of the cohort. The first few weeks are dedicated | [Dirk Jäckel](https://github.com/biafra23) | [Update 0](https://hackmd.io/@dirkjaeckel/epf5-week-0) | [Update 1](https://hackmd.io/@dirkjaeckel/epf5-week-1) | [Update 2](https://hackmd.io/@dirkjaeckel/epf5-week-2) | | [Dsorken](https://github.com/Dsorken) | | [Update 1](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/SkLb4AnrR) | [Update 2](https://hackmd.io/869h8TPrQOmKgY45gQj2DQ) | | [Ekaterina Riazantseva](https://github.com/KatyaRyazantseva) | [Update 0](https://hackmd.io/@katya-blockchain-dev/epf5-week-0) | [Update 1](https://hackmd.io/@katya-blockchain-dev/epf5-week-1) | [Update 2](https://hackmd.io/@katya-blockchain-dev/epf5-week-2) | -| [georgesheth](https://github.com/georgesheth) | [Update 0](https://hackmd.io/@georgesheth/SJ2FqiVSR) | | | +| [georgesheth](https://github.com/georgesheth) | [Update 0](https://hackmd.io/@georgesheth/SJ2FqiVSR) | | [Update 2](https://hackmd.io/@georgesheth/BJGl24HYA) | | [ghili](https://github.com/ghiliweld) | [Update 0](https://hackmd.io/@ghili/HJoy-VBS0) | [Update 1](https://hackmd.io/@ghili/ry9-_kISR) | [Update 2](https://hackmd.io/@ghili/H1DgDRaHC) | | [Glory Agatevure](https://github.com/gconnect) | [Update 0](https://hackmd.io/@gconnect/BJbfBMI8A) | [Update 1](https://hackmd.io/@gconnect/B1gGpB8LC) | [Update 2](https://hackmd.io/@gconnect/r1Gq-I8LC) | | [jsvisa](https://github.com/jsvisa) | | [Update 1](https://hackmd.io/@jsvisa/rkNslE3HR) | [Update 2](https://hackmd.io/@jsvisa/rkmWSpBUA) | @@ -44,6 +46,7 @@ Phase one is the very beginning of the cohort. The first few weeks are dedicated | [Léa Na](https://github.com/lean-apple) | | [Update 1](https://hackmd.io/@leanapple/epf-5-week-1) | [Update 2](https://hackmd.io/@leanapple/epf-5-week-2) | | [MaxDav](https://github.com/MaximeDavin) | | [Update 1](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/r1KDDcaSR) | [Update 2](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/rJ1c4-w8A) | | [MeldSun](https://github.com/meldsun0) | [Update 0](https://hackmd.io/@3juAdBVCRtaXnRB_valWsA/SJb4ugVE0) | | | +| [Md Amaan](https://github.com/Redidacove) | | [Update 1](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/HJ-vfiHB0) | | | [Nikhil](https://github.com/nikhilkumar1612) | | | [Update 2](https://hackmd.io/@zTxe9ZSCTiOhard8DLV68A/rkzSKnULR) | | [Nilav](https://github.com/gerceboss) | | [Update 1](https://hackmd.io/@gerceboss/rkEjSyiBA) | [Update 2](https://hackmd.io/@gerceboss/r1ObxCUUC) | | [mrk1tty](https://github.com/garv-aga) | | [Update 1](https://hackmd.io/@mrk1tty/B1rZCb9HA) | [Update 2](https://hackmd.io/@mrk1tty/B1T_N1OUA) | @@ -64,9 +67,10 @@ Phase one is the very beginning of the cohort. The first few weeks are dedicated ## Phase 2: Deep dive With the gained insight into the protocol, the following weeks serve as a deep dive into a chosen topic. By the first month, you should finish the initial research about a specific problem and propose a project, including a roadmap. Get some ideas from the [project proposal template](projects/project-template.md). + | Name/GH | Week 3 | Week 4 | Week 5 | Project proposal | | ------------------------------------------------------------ | --------------------------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [0xpanicError](https://github.com/0xpanicError) | [Update 3](https://hackmd.io/@0xpanicError/epf-update_3) | [Update 4](https://hackmd.io/@0xpanicError/epf-update_4) | | | +| [0xpanicError](https://github.com/0xpanicError) | [Update 3](https://hackmd.io/@0xpanicError/epf-update_3) | [Update 4](https://hackmd.io/@0xpanicError/epf-update_4) | | [ssf-consensus-research](projects/ssf-consensus-research.md) | | [0xSulpiride](https://github.com/0xSulpiride) | [Update 3](https://hackmd.io/@sulpiride/rkfLFIw8A) | [Update 4](https://hackmd.io/@sulpiride/HkaTPOeDR) | [Update 5](https://hackmd.io/@sulpiride/By0potbuR) | | | [Abhimanyu](https://github.com/ABresting) | | | | | | [Aditya Gupta](https://github.com/1010adigupta) | [Update 3](https://hackmd.io/@adigupta/S1_Lq4-wR) | [Update 4](https://hackmd.io/@adigupta/rJ2y2koDR) | [Update 5](https://hackmd.io/@adigupta/rym-4nXdR) | [reth-verkle-poc](projects/reth-verkle-poc.md) | @@ -74,110 +78,105 @@ With the gained insight into the protocol, the following weeks serve as a deep d | [Amin](github.com/amintalebi) | | [Update 4](https://hackmd.io/@amintalebi/HJt9O9lvC) | [Update 5](https://hackmd.io/@amintalebi/ry9EVn6vA) | [FOCIL Geth and Prysm PoC](projects/focil-geth-and-prysm-poc.md) | | [Another Dev](https://github.com/Another-DevX) | [Update 3](https://hackmd.io/@btcZWytfSNOGdxJyufkirQ/Bk9f7MlvA) | | | | | [Ashely Yan](https://github.com/AshliaYan) | [Update 3](https://hackmd.io/@Ashelyyan/Sk-DjQJDR) | [Update 4](https://hackmd.io/@Ashelyyan/rkfZvzsvR) | [Update 5](https://hackmd.io/@Ashelyyan/BJ8oPqz_A) | [Enhanced DHT Proposal with Rated List and Hierarchical Levels](projects/enhanced-dht-proposal-with-rated-list-and-hierarchical-levels.md) | -| [Ashen](https://github.com/y1cunhui) | | | | | -| [Bastin](https://github.com/Inspector-Butters) | [Update 3](https://hackmd.io/@Bastin/By8UVwlPA) | | [Update 5](https://hackmd.io/@Bastin/HyqHfO9OR) | [Light Client Support in Prysm](https://github.com/eth-protocol-fellows/cohort-five/blob/main/projects/light-client-support-in-prysm.md) | +| [Bastin](https://github.com/Inspector-Butters) | [Update 3](https://hackmd.io/@Bastin/By8UVwlPA) | | [Update 5](https://hackmd.io/@Bastin/HyqHfO9OR) | [Light Client Support in Prysm](projects/light-client-support-in-prysm.md) | | [BobLiu](https://github.com/Akagi201) | [Update 3](https://hackmd.io/@Akagi201/epf-cohort5-week3) | [Update 4](https://hackmd.io/@Akagi201/epf-cohort5-week4) | | | -| [Boma Naps](https://github.com/bomanaps) | [Update 3](https://hackmd.io/@bomanaps/B1-vbGxv0) | [Update 4](https://hackmd.io/@bomanaps/rJMH3Pdw0) | [Update 5](https://hackmd.io/@bomanaps/SkRfuOzuC) | | -| [Caleb](https://github.com/Tomi-3-0) | [Update 3](https://hackmd.io/@tc3rGbpwSe6dJwI2nuYQsw/ByPQxR6LA) | [Update 4](https://hackmd.io/@tomi0x/caleb-epf5-week4) | [Update 5](https://hackmd.io/@tomi0x/epf5-week5) | [ePBS implementation in Nimbus](cohort-five/projects/eip-7732-implementation-in-nimbus.md) | -| [Chirag](https://github.com/chirag-parmar) | [Update 3](https://hackmd.io/@chirag-parmar/HJyYwEev0) | [Update 4](https://hackmd.io/@chirag-parmar/SJOk7wKDA) | [Update 5](https://hackmd.io/@chirag-parmar/B1m3PjzdA) | | +| [Boma Naps](https://github.com/bomanaps) | [Update 3](https://hackmd.io/@bomanaps/B1-vbGxv0) | [Update 4](https://hackmd.io/@bomanaps/rJMH3Pdw0) | [Update 5](https://hackmd.io/@bomanaps/SkRfuOzuC) | [Securing Grandine's Performance](projects/securing-grandines-performance.md) | +| [Caleb](https://github.com/Tomi-3-0) | [Update 3](https://hackmd.io/@tc3rGbpwSe6dJwI2nuYQsw/ByPQxR6LA) | [Update 4](https://hackmd.io/@tomi0x/caleb-epf5-week4) | [Update 5](https://hackmd.io/@tomi0x/epf5-week5) | [ePBS implementation in Nimbus](projects/eip-7732-implementation-in-nimbus.md) | +| [Chirag](https://github.com/chirag-parmar) | [Update 3](https://hackmd.io/@chirag-parmar/HJyYwEev0) | [Update 4](https://hackmd.io/@chirag-parmar/SJOk7wKDA) | [Update 5](https://hackmd.io/@chirag-parmar/B1m3PjzdA) | [Enhanced DHT Proposal with Rated List and Hierarchical Levels](projects/enhanced-dht-proposal-with-rated-list-and-hierarchical-levels.md) | | [ChloeZhu](https://github.com/Chloezhu010) | | | | | -| [Cloud](https://github.com/0xClouds/) | | | | | | [DanGoron](https://github.com/gorondan) | | [Update 4](https://hackmd.io/@kboomro/HyeZXZgxO0) | [Update 5](https://hackmd.io/@kboomro/HkfNC7edR) | [enshrined Operator-Delegator Separation specification](projects/eods-specification.md) | | [Daniel Knopik](https://github.com/dknopik) | [Update 3](https://hackmd.io/@dknopik/epf-week3) | [Update 4](https://hackmd.io/@dknopik/epf-week4) | [Update 5](https://hackmd.io/@dknopik/epf-week5) | [Network Simulations with Shadow](projects/network-simulations-with-shadow.md) | | [Dirk Jäckel](https://github.com/biafra23) | | | | | | [Dsorken](https://github.com/Dsorken) | [Update 3](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/HJ9rQ0kD0) | [Update 4](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/r1VWP5_wA) | [Update 5](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/H19snvxuA) | [Besu Portal Client](projects/besu-portal-client.md) | | [Ekaterina Riazantseva](https://github.com/KatyaRyazantseva) | [Update 3](https://hackmd.io/@katya-blockchain-dev/epf5-week-3) | [Update 4](https://hackmd.io/@katya-blockchain-dev/epf5-week-4) | [Update 5](https://hackmd.io/@katya-blockchain-dev/epf5-week-5) | [PeerDAS metrics](projects/peerdas-metrics.md) | -| [georgesheth](https://github.com/georgesheth) | | | | | +| [georgesheth](https://github.com/georgesheth) | [Update 3](https://hackmd.io/@georgesheth/rJxnQBrtC) | [Update 4](https://hackmd.io/@georgesheth/HJKkx3NSR) | [Update 5](https://hackmd.io/@georgesheth/Hk2r2BHFC) | [Push Based Custom Ceiling Partial Withdrawal for EIP-7251 (MaxEB)](projects/Push-Based-Custom-Ceiling-Partial-Withdraw-for-EIP7251-MaxEB.md) | | [ghili](https://github.com/ghiliweld) | [Update 3](https://hackmd.io/@ghili/Hy-NPDvI0) | [Update 4](https://hackmd.io/@ghili/ByCdpKVP0) | [Update 5](https://hackmd.io/@ghili/S1XOsWfdR) | [SSZ Benchmarking and Optimization](projects/ssz-benchmarking-and-optimization.md) | | [Glory Agatevure](https://github.com/gconnect) | [Update 3](https://hackmd.io/@gconnect/rJijgCI8C) | [Update 4](https://hackmd.io/@gconnect/r1TakB_wA) | [Update 5](https://hackmd.io/@gconnect/Skw5Z7f_A) | [Native Ephemery Testnet Client Pair Implementation](/projects/native-ephemery-client-pair-implementation.md) | | [Hamid Bateni](https://github.com/irnb) | [Update 3](https://hackmd.io/@irnb/epf_week3) | [Update 4](https://hackmd.io/@irnb/epf_week4) | [Update 5](https://hackmd.io/@irnb/epf_week5) | [Inclusion List with Plausible Deniability](projects/attestation-based-inclusion-list.md) | | [Hangleang](https://github.com/hangleang) | [Update 3](https://hackmd.io/@hangleang/epf5-week3) | [Update 4](https://hackmd.io/@hangleang/epf5-week4) | [Update 5](https://hackmd.io/@hangleang/epf5-week5) | [PeerDAS in Grandine](projects/peerdas-grandine.md) | -| [Hopinheimer](https://github.com/hopinheimer) | [Update 3](https://hackmd.io/@hopin232/HyIxzVgDA) | [Update 4](https://hackmd.io/@hopin232/HkD7QcRDA) | [Update 5](https://hackmd.io/@hopin232/HJ3vEtGO0) | | -| [Ifeoluwa Oderinde](https://github.com/owanikin) | [Update 3](https://hackmd.io/@ZpBFaS-NSO-5Xkdm4jwolg/HJAO40qUC) | | | | +| [Hopinheimer](https://github.com/hopinheimer) | [Update 3](https://hackmd.io/@hopin232/HyIxzVgDA) | [Update 4](https://hackmd.io/@hopin232/HkD7QcRDA) | [Update 5](https://hackmd.io/@hopin232/HJ3vEtGO0) | [Enhanced DHT Proposal with Rated List and Hierarchical Levels](projects/enhanced-dht-proposal-with-rated-list-and-hierarchical-levels.md) | +| [Ifeoluwa Oderinde](https://github.com/owanikin) | [Update 3](https://hackmd.io/@ZpBFaS-NSO-5Xkdm4jwolg/HJAO40qUC) | | [Update 5](https://hackmd.io/@ZpBFaS-NSO-5Xkdm4jwolg/Sy8ieKZu0) | | | [Jihoon Song](https://github.com/jihoonsong) | [Update 3](https://hackmd.io/@jihoonsong/SkUIKCLLR) | [Update 4](https://hackmd.io/@jihoonsong/SJH-cXMdA) | [Update 5](https://hackmd.io/@jihoonsong/rkc04VzuR) | [Prototyping ePBS](/projects/prototyping-epbs.md) | | [jsvisa](https://github.com/jsvisa) | [Update 3](https://hackmd.io/@jsvisa/epf5-week3) | [Update 4](https://hackmd.io/@jsvisa/epf5-week4) | [Update 5](https://hackmd.io/@jsvisa/epf5-week5) | | | [kira](https://github.com/shyam-patel-kira) | [Update 3](https://hackmd.io/@kira50/BkH7kE-P0) | [Update 4](https://hackmd.io/@kira50/epf-week-4) | [Update 5](https://hackmd.io/@kira50/epf-week-5) | [ePBS implementation in Prysm](/projects/epbs-implementation-in-prysm.md) | | [Krishang](https://github.com/kamuik16) | | [Update 4](https://hackmd.io/@kamuik16/epf-week-4) | | | | [Ktl_XV](https://github.com/ktl-xv) | | | | | | [Léa Na](https://github.com/lean-apple) | [Update 3](https://hackmd.io/@leanapple/epf5-week3) | [Update 4](https://hackmd.io/@leanapple/epf5-week4) | | [FOCIL Ligthouse and Reth PoC](projects/focil-lighthouse-and-reth-poc.md) + [Axum transition in lighthouse](projects/axum-transition-in-lighthouse.md) | -| [MaxDav](https://github.com/MaximeDavin) | [Update 3](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/BJC0tglDR) | [Update 4](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/SyeNEsFPR) | [Update 5](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/ByZLWAfu0) | | +| [MaxDav](https://github.com/MaximeDavin) | [Update 3](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/BJC0tglDR) | [Update 4](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/SyeNEsFPR) | [Update 5](https://hackmd.io/@jdpsr0d9T9ivhzYDDyuQBg/ByZLWAfu0) | [Prysm libp2p Implementation](projects/Prysm_libP2P_Implementation.md) | | [MeldSun](https://github.com/meldsun0) | | | | | | [mrk1tty](https://github.com/garv-aga) | | | | | | [Nikhil](https://github.com/nikhilkumar1612) | | | | | -| [Nilav](https://github.com/gerceboss) | [Update 3](https://hackmd.io/@gerceboss/SkdMHQgDR) | [Update 4](https://hackmd.io/@gerceboss/SygXTUKDR) | [Update 5](https://hackmd.io/@gerceboss/r14_HdMuC) | | -| [Rahul](https://github.com/guha-rahul) | [Update 3](https://hackmd.io/@0xrguha/BJIrH-lPA) | [Update 4](https://hackmd.io/@0xrguha/ry5hgvKw0) | [update 5](https://hackmd.io/doCmLTjqQuCOtuorR2QL4A) | | -| [raxhvl](https://github.com/raxhvl) | [Update 3](https://epf.raxhvl.com/week/3) | [Update 4](https://epf.raxhvl.com/week/4) | [Update 5](https://epf.raxhvl.com/week/5) | | +| [Nilav](https://github.com/gerceboss) | [Update 3](https://hackmd.io/@gerceboss/SkdMHQgDR) | [Update 4](https://hackmd.io/@gerceboss/SygXTUKDR) | [Update 5](https://hackmd.io/@gerceboss/r14_HdMuC) | [PeerDAS in Nimbus](project/peerdas-nimbus.md) | +| [Rahul](https://github.com/guha-rahul) | [Update 3](https://hackmd.io/@0xrguha/BJIrH-lPA) | [Update 4](https://hackmd.io/@0xrguha/ry5hgvKw0) | [update 5](https://hackmd.io/doCmLTjqQuCOtuorR2QL4A) | [Light Client Support in Prysm](projects/light-client-support-in-prysm.md) | +| [raxhvl](https://github.com/raxhvl) | [Update 3](https://epf.raxhvl.com/week/3) | [Update 4](https://epf.raxhvl.com/week/4) | [Update 5](https://epf.raxhvl.com/week/5) | [EVM Memory Repricing](project/evm-memory-repricing.md) | | [Richa](https://github.com/Richa-iitr) | [Update 3](https://hackmd.io/@iri/rJrPvd08C) | [Update 4](https://hackmd.io/@iri/rkbRsVtPA) | [Update 5](https://hackmd.io/@iri/HkJ2kR4O0) | | | [Rodrigo Herrera](https://github.com/) | [Update 3](https://hackmd.io/@rodrigoh/update3) | | | | | [RoryArredondo](https://github.com/arredr2) | [Update 3](https://hackmd.io/@arredr2/Bkehft2IR) | [Update 4](https://hackmd.io/@arredr2/BJ_GbXzDA) | | | -| [Rose Jethani](https://github.com/rose2221) | [Update 3](https://hackmd.io/@0xrosetteeee/Week3) | [Update 4](https://hackmd.io/@0xrosetteeee/Week4) | [Update 5](https://hackmd.io/@0xrosetteeee/BJw067Eu0) | | +| [Rose Jethani](https://github.com/rose2221) | [Update 3](https://hackmd.io/@0xrosetteeee/Week3) | [Update 4](https://hackmd.io/@0xrosetteeee/Week4) | [Update 5](https://hackmd.io/@0xrosetteeee/BJw067Eu0) | [Prysm libp2p Implementation](projects/Prysm_libP2P_Implementation.md) | | [Rupam Dey](https://github.com/rupam-04) | [Update 3](https://hackmd.io/@rupam-04/Week3) | [Update 4](https://hackmd.io/@rupam-04/Week4) | [Update 5](https://hackmd.io/@rupam-04/Week5) | [Light Client Support in Prysm](projects/light-client-support-in-prysm.md) | | [Saeid](github.com/xm0onh) | | | | | | [Sayan](https://github.com/threehrsleep) | [Update 3](https://hackmd.io/@threehrsleep/epf_week3) | | [Update 5](https://hackmd.io/@threehrsleep/epf_week5) | [Direct(non-http) integration of Lighthouse-Reth & Tracing integration in Lighthouse](projects/direct-integration-of-lighthouse-reth-and-tracing-integration-in-lighthouse.md) | | [Scar Face](https://github.com/scarfacedotcom) | | | | | | [Siddharth Vaderaa](https://github.com/SiddharthV1) | [Update 3](https://hackmd.io/@Xoznc0kESi6cRDnApMs5rQ/rkGyp1lDR) | | [Update 5](https://hackmd.io/@sidvdr/SJtOgPGOR) | [Op code implementations, tests, code analysis and statistics for Nethermind's IL-EVM](projects/opcode-implementations-test-coverage-code-analysis-and-stats-il-evm-nethermind.md) | -| [Vaiz_07](https://github.com/07Vaishnavi-Singh) | | | | | -| [Zarathustra](https://github.com/Karrenbelt) | [Update 3](https://hackmd.io/@zarathustra/HkqZFJ6OC) | [Update 4](https://hackmd.io/@zarathustra/rJ6vhJT_0) | [Update 5](https://hackmd.io/@zarathustra/SkiLqdmFR) | +| [Zarathustra](https://github.com/Karrenbelt) | [Update 3](https://hackmd.io/@zarathustra/HkqZFJ6OC) | [Update 4](https://hackmd.io/@zarathustra/rJ6vhJT_0) | [Update 5](https://hackmd.io/@zarathustra/SkiLqdmFR) | | ## Phase 3: Execution The actual project development is the main part of the program. Post your regular progress updates here during the development phase, share your issues and successes with others. -| Name/GH | Week 6 | Week 7 | Week 8 | Week 9 | Week 10 | Week 11 | Week 12 | Week 13 | Week 14 | Week 15 | Week 16 | Week 17 | Week 18 | Week 19 | Week 20 | Week 21 + | -| ------------------------------------------------------------ | --------------------------------------------------------------- | --------------------------------------------------------------- | ------ | ------ | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | --------- | -| [0xpanicError](https://github.com/0xpanicError) | | | | | | | | | | | | | | | | | -| [0xSulpiride](https://github.com/0xSulpiride) | | [Update 7](https://hackmd.io/@sulpiride/HktpwlNY0) | | | | | | | | | | | | | | | -| [Abhimanyu](https://github.com/ABresting) | | | | | | | | | | | | | | | | | -| [Aditya Gupta](https://github.com/1010adigupta) | [Update 6](https://hackmd.io/@adigupta/H139c34KA) | [Update 7](https://hackmd.io/@adigupta/S1m6RhVFC) | | | | | | | | | | | | | | | -| [AkshatGada](https://github.com/AkshatGada) | | | | | | | | | | | | | | | | | -| [Amin](github.com/amintalebi) | | [Update 7](https://hackmd.io/@amintalebi/HkEeAJBK0) | | | | | | | | | | | | | | | -| [Another Dev](https://github.com/Another-DevX) | | | | | | | | | | | | | | | | | -| [Ashely Yan](https://github.com/AshliaYan) | | [Update 7](https://hackmd.io/@Ashelyyan/HyM3r7EK0) | | | | | | | | | | | | | | | -| [Ashen](https://github.com/y1cunhui) | | | | | | | | | | | | | | | | | -| [Bastin](https://github.com/Inspector-Butters) | [Update 6](https://hackmd.io/@Bastin/Hke55_9dR) | | | | | | | | | | | | | | | | -| [BobLiu](https://github.com/Akagi201) | | | | | | | | | | | | | | | | | -| [Boma Naps](https://github.com/bomanaps) | [Update 6](https://hackmd.io/@bomanaps/rk9iDg3uR) | [Update 7](https://hackmd.io/@bomanaps/BkYhOEEFA) | | | | | | | | | | | | | | | -| [Caleb](https://github.com/Tomi-3-0) | [Update 6](https://hackmd.io/@tomi0x/SJuzaz4FC) | [Update 7](https://hackmd.io/@tomi0x/rJgQTG4Y0) | | | | | | | | | | | | | | | -| [Chirag](https://github.com/chirag-parmar) | [Update 6](https://hackmd.io/@chirag-parmar/BJalEhs_C) | | | | | | | | | | | | | | | | -| [ChloeZhu](https://github.com/Chloezhu010) | | | | | | | | | | | | | | | | | -| [Cloud](https://github.com/0xClouds/) | | | | | | | | | | | | | | | | | -| [DanGoron](https://github.com/gorondan) | [Update 6](https://hackmd.io/@kboomro/rJUw1tsdA) | [Update 7](https://hackmd.io/@kboomro/HkUxl2NtR) | | | | | | | | | | | | | | | -| [Daniel Knopik](https://github.com/dknopik) | | [Update 7](https://hackmd.io/@dknopik/epf-week7) | | | | | | | | | | | | | | | -| [Dirk Jäckel](https://github.com/biafra23) | | | | | | | | | | | | | | | | | -| [Dsorken](https://github.com/Dsorken) | [Update 6](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/BkVmDusOC) | | | | | | | | | | | | | | | | -| [Ekaterina Riazantseva](https://github.com/KatyaRyazantseva) | [Update 6](https://hackmd.io/@katya-blockchain-dev/epf5-week-6) | [Update 7](https://hackmd.io/@katya-blockchain-dev/epf5-week-7) | | | | | | | | | | | | | | | -| [georgesheth](https://github.com/georgesheth) | | | | | | | | | | | | | | | | | -| [ghili](https://github.com/ghiliweld) | | | | | | | | | | | | | | | | | -| [Glory Agatevure](https://github.com/gconnect) | | | | | | | | | | | | | | | | | -| [Hamid Bateni](https://github.com/irnb) | [Update 6](https://hackmd.io/@irnb/epf_week6) | | | | | | | | | | | | | | | | -| [Hangleang](https://github.com/hangleang) | [Update 6](https://hackmd.io/@hangleang/epf5-week6) | | | | | | | | | | | | | | | | -| [Hopinheimer](https://github.com/hopinheimer) | | | | | | | | | | | | | | | | | -| [Ifeoluwa Oderinde](https://github.com/owanikin) | | | | | | | | | | | | | | | | | -| [Jihoon Song](https://github.com/jihoonsong) | [Update 6](https://hackmd.io/2m8UzqdDRWSl1bhA5XJhUQ) | [Update 7](https://hackmd.io/v67JgkcwQEKcDEyaYSWqFw) | | | | | | | | | | | | | | | -| [jsvisa](https://github.com/jsvisa) | [Update 6](https://hackmd.io/@jsvisa/epf5-week6) | [Update 7](https://hackmd.io/@jsvisa/epf5-week7) | | | | | | | | | | | | | | | -| [kira](https://github.com/shyam-patel-kira) | [Update 6](https://hackmd.io/@kira50/epf-week-6) | [Update 7](https://hackmd.io/@kira50/epf-week-7) | | | | | | | | | | | | | | | -| [Krishang](https://github.com/kamuik16) | | | | | | | | | | | | | | | | | -| [Ktl_XV](https://github.com/ktl-xv) | | | | | | | | | | | | | | | | | -| [Léa Na](https://github.com/lean-apple) | [Update 6](https://hackmd.io/@leanapple/epf5-week-6) | | | | | | | | | | | | | | | | -| [MaxDav](https://github.com/MaximeDavin) | | | | | | | | | | | | | | | | | -| [MeldSun](https://github.com/meldsun0) | | | | | | | | | | | | | | | | | -| [mrk1tty](https://github.com/garv-aga) | | | | | | | | | | | | | | | | | -| [Nikhil](https://github.com/nikhilkumar1612) | | | | | | | | | | | | | | | | | -| [Nilav](https://github.com/gerceboss) | | | | | | | | | | | | | | | | | -| [Rahul](https://github.com/guha-rahul) | | | | | | | | | | | | | | | | | -| [raxhvl](https://github.com/raxhvl) | [Update 6](https://epf.raxhvl.com/week/6) | | | | | | | | | | | | | | | | -| [Richa](https://github.com/Richa-iitr) | [Update 6](https://hackmd.io/@iri/SJ4cj_0O0) | | | | | | | | | | | | | | | | -| [Richard Smith](https://github.com/ret2happy) | [Update 6](https://hackmd.io/@HAPPY/Hk4MbV7K0) | | | | | | | | | | | | | | | | -| [Rodrigo Herrera](https://github.com/) | | | | | | | | | | | | | | | | | -| [RoryArredondo](https://github.com/arredr2) | | | | | | | | | | | | | | | | | -| [Rose Jethani](https://github.com/rose2221) | [Update 6](https://hackmd.io/@0xrosetteeee/Week6) | | | | | | | | | | | | | | | | -| [Rupam Dey](https://github.com/rupam-04) | [Update 6](https://hackmd.io/@rupam-04/Week6) | [Update 7](https://hackmd.io/@rupam-04/Week7) | | | | | | | | | | | | | | | -| [Saeid](github.com/xm0onh) | | | | | | | | | | | | | | | | | -| [Sayan](https://github.com/threehrsleep) | [Update 6](https://hackmd.io/@threehrsleep/epf_week6) | | | | | | | | | | | | | | | | -| [Scar Face](https://github.com/scarfacedotcom) | | | | | | | | | | | | | | | | | -| [Siddharth Vaderaa](https://github.com/SiddharthV1) | | [Update 7](https://hackmd.io/@sidvdr/Sy744v4YA) | | | | | | | | | | | | | | | -| [Vaiz_07](https://github.com/07Vaishnavi-Singh) | | | | | | | | | | | | | | | | | -| [Zarathustra](https://github.com/Karrenbelt) | | | | | | | | | | | | | | | | | +| Name/GH | Week 6 | Week 7 | Week 8 | Week 9 | Week 10 | Week 11 | Week 12 | Week 13 | Week 14 | Week 15 | Week 16 | Week 17 | Week 18 | Week 19 | Week 20 | Week 21 + | +| ------------------------------------------------------------ | --------------------------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------- | ------- | ------- | ------- | ------- | ------- | ------- | --------- | +| [0xpanicError](https://github.com/0xpanicError) | | [Update 7](https://hackmd.io/@0xpanicError/epf-upate_7) | [Update 8](https://hackmd.io/@0xpanicError/epf-update_8) | | | | | | | | | | | | | | +| [0xSulpiride](https://github.com/0xSulpiride) | | [Update 7](https://hackmd.io/@sulpiride/HktpwlNY0) | | [Update 9](https://hackmd.io/cWzzO32RTPiW2_mpdlS8vg) | | [Update 11](https://hackmd.io/zszcKKslTDmrre1eRUo1kA) | | | | | | | | | | | +| [Abhimanyu](https://github.com/ABresting) | | [Update 7](https://hackmd.io/@ABresting/Hy5BlmBt0) | | | | | | | | | | | | | | | +| [Aditya Gupta](https://github.com/1010adigupta) | [Update 6](https://hackmd.io/@adigupta/H139c34KA) | [Update 7](https://hackmd.io/@adigupta/S1m6RhVFC) | [Update 8](https://hackmd.io/@adigupta/Sy09KtDqC) | [Update 9](https://hackmd.io/@adigupta/SklJd9P5A) | [Update 10](https://hackmd.io/@adigupta/rySsqDniA) | [Update 11](https://hackmd.io/@adigupta/H1fJpPniC) | | | | | | | | | | | +| [AkshatGada](https://github.com/AkshatGada) | | | | | | | | | | | | | | | | | +| [Amin](github.com/amintalebi) | | [Update 7](https://hackmd.io/@amintalebi/HkEeAJBK0) | | | | | | | | | | | | | | | +| [Another Dev](https://github.com/Another-DevX) | | | | | | | | | | | | | | | | | +| [Ashely Yan](https://github.com/AshliaYan) | | [Update 7](https://hackmd.io/@Ashelyyan/HyM3r7EK0) | [Update 8](https://hackmd.io/@Ashelyyan/rkZ5cK8FC) | [Update 9](https://hackmd.io/@Ashelyyan/r1GsGKkqA) | [Update 10](https://hackmd.io/@Ashelyyan/SJtLsUpqC) | | [Update 12](https://hackmd.io/@Ashelyyan/SJx3gSS-hR) | | [Update 13&14](https://hackmd.io/gyVGdFlISx2xuB1h58fghQ) | | | | | | | | +| [Bastin](https://github.com/Inspector-Butters) | [Update 6](https://hackmd.io/@Bastin/Hke55_9dR) | | | [Update 9](https://hackmd.io/@Bastin/B1Ja58D9C) | | [Update 11](https://hackmd.io/@Bastin/SyNqyCdoA) | | [Update 13](https://hackmd.io/@Bastin/S1n5EXoh0) | | | | | | | | | +| [BobLiu](https://github.com/Akagi201) | | | | | | | | | | | | | | | | | +| [Boma Naps](https://github.com/bomanaps) | [Update 6](https://hackmd.io/@bomanaps/rk9iDg3uR) | [Update 7](https://hackmd.io/@bomanaps/BkYhOEEFA) | | [Update 8&9](https://hackmd.io/@bomanaps/BJxhQdvq0) | [Update 10](https://hackmd.io/@bomanaps/Hyav0dysR) | [Update 11](https://hackmd.io/@bomanaps/HkK9ZUFoC) | | | | | | | | | | | +| [Caleb](https://github.com/Tomi-3-0) | [Update 6](https://hackmd.io/@tomi0x/SJuzaz4FC) | [Update 7](https://hackmd.io/@tomi0x/rJgQTG4Y0) | [Update 8](https://hackmd.io/@tomi0x/r1nbhFpFC) | | [Update 10](https://hackmd.io/@tomi0x/Sk3PryejC) | [Update 11](https://hackmd.io/@tomi0x/r19N_ecjA) | [Update 12](https://hackmd.io/@tomi0x/ByHDAUGnR) | [Update 13](https://hackmd.io/@tomi0x/rJugEho20) | | | | | | | | | +| [Chirag](https://github.com/chirag-parmar) | [Update 6](https://hackmd.io/@chirag-parmar/BJalEhs_C) | [Update 7](https://hackmd.io/@chirag-parmar/rkw6-ArFR) | [Update 8](https://hackmd.io/@chirag-parmar/B1G-_8CK0) | [Update 9](https://hackmd.io/@chirag-parmar/BkTDIOvcC) | [Update 10](https://hackmd.io/@chirag-parmar/B1-JFpljR) | [Update 11](https://hackmd.io/@chirag-parmar/ryhVz1cjC) | [Update 12](https://hackmd.io/@chirag-parmar/BkZL2Xmh0) | | | | | | | | | | +| [ChloeZhu](https://github.com/Chloezhu010) | | | | | | | | | | | | | | | | | +| [DanGoron](https://github.com/gorondan) | [Update 6](https://hackmd.io/@kboomro/rJUw1tsdA) | [Update 7](https://hackmd.io/@kboomro/HkUxl2NtR) | [Update 8](https://hackmd.io/@kboomro/Hkn29XAFC) | [Update 9](https://hackmd.io/@kboomro/SypN8f89R) | | [Update 10 & 11](https://hackmd.io/@kboomro/B1v6pvvjC) | | [Update 12 & 13](https://hackmd.io/@kboomro/BJuCYith0) | | | | | | | | | +| [Daniel Knopik](https://github.com/dknopik) | | [Update 7](https://hackmd.io/@dknopik/epf-week7) | [Update 8](https://hackmd.io/@dknopik/epf-week8) | [Update 9](https://hackmd.io/@dknopik/epf-week9) | [Update 10](https://hackmd.io/@dknopik/epf-week10) | | [Update 12](https://hackmd.io/@dknopik/epf-week12) | | | | | | | | | | +| [Dirk Jäckel](https://github.com/biafra23) | | | | | | | | | | | | | | | | | +| [Dsorken](https://github.com/Dsorken) | [Update 6](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/BkVmDusOC) | [Update 7](https://hackmd.io/tm2GAAOcQo2sqVzZccMbog) | [Update 8](https://hackmd.io/zOgiEg-uROeEffA8A58CQg) | [Update 9](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/HJZiz2P50) | [Update 10](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/rJavwQgoR) | [Update 11](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/HJhsZ5ts0) | [Update 12](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/HJA1ppGhC) | [Update 13](https://hackmd.io/@VgS_FqIfRay_4wp6pMBEgw/SyE8ZZhn0) | | | | | | | | | +| [Ekaterina Riazantseva](https://github.com/KatyaRyazantseva) | [Update 6](https://hackmd.io/@katya-blockchain-dev/epf5-week-6) | [Update 7](https://hackmd.io/@katya-blockchain-dev/epf5-week-7) | [Update 8](https://hackmd.io/@katya-blockchain-dev/epf5-week-8) | [Update 9](https://hackmd.io/@katya-blockchain-dev/epf5-week-9) | [Update 10](https://hackmd.io/@katya-blockchain-dev/epf5-week-10) | [Update 11](https://hackmd.io/@katya-blockchain-dev/epf5-week-11) | [Update 12](https://hackmd.io/@katya-blockchain-dev/epf5-week-12) | [Update 13](https://hackmd.io/@katya-blockchain-dev/epf5-week-13) | [Update 14](https://hackmd.io/@katya-blockchain-dev/epf5-week-14) | | | | | | | | +| [georgesheth](https://github.com/georgesheth) | | [Update 7](https://hackmd.io/@georgesheth/BJ5tkLBtA) | | | | | | | | | | | | | | | +| [ghili](https://github.com/ghiliweld) | [Update 6](https://hackmd.io/@ghili/HJI5KJQ_A) | [Update 7](https://hackmd.io/@ghili/HkBl2pGY0) | [Update 8](https://hackmd.io/@ghili/B1dMYUBYR) | | | | | | | | | | | | | | +| [Glory Agatevure](https://github.com/gconnect) | [Update 6](https://hackmd.io/@gconnect/Sy9n-IKwA) | [Update 7](https://hackmd.io/@gconnect/ryNMVbXY0) | [Update 8](https://hackmd.io/@gconnect/r1wHFvpY0) | [Update 9](https://hackmd.io/@gconnect/r1Q_zrI5A) | [Update 10](https://hackmd.io/@gconnect/SyZOYSlsA) | [Update 11](https://hackmd.io/@gconnect/rkSsQBKi0) | [Update 12](https://hackmd.io/@gconnect/rJq9H2G2A) | [Update 13](https://hackmd.io/@gconnect/rydLjkhnA) | | | | | | | | | +| [Hamid Bateni](https://github.com/irnb) | [Update 6](https://hackmd.io/@irnb/epf_week6) | | | | | [Pivot Update](https://hackmd.io/@irnb/epf_week11) | | | | | | | | | | | +| [Hangleang](https://github.com/hangleang) | [Update 6](https://hackmd.io/@hangleang/epf5-week6) | | [Update 7&8](https://hackmd.io/@hangleang/epf5-week7n8) | [Update 9](https://hackmd.io/@hangleang/epf5-week9) | [Update 10](https://hackmd.io/@hangleang/epf5-week10) | [Update 11](https://hackmd.io/@hangleang/epf5-week11) | [Update 12](https://hackmd.io/@hangleang/epf5-week12) | [Update 13](https://hackmd.io/@hangleang/epf5-week13) | [Update 14](https://hackmd.io/@hangleang/epf5-week14) | | | | | | | | +| [Hopinheimer](https://github.com/hopinheimer) | | [Update 7](https://hackmd.io/@hopin232/S1VgE2j_A) | [Update 8](https://hackmd.io/@hopin232/BJrO3ITFA) | | | [Week 11](https://hackmd.io/@hopin232/Skm863wjA) | | [Week 12&13](https://hackmd.io/@hopin232/r1HZmFh2R) | | | | | | | | | +| [Ifeoluwa Oderinde](https://github.com/owanikin) | | | | | | [Update 11](https://hackmd.io/@ZpBFaS-NSO-5Xkdm4jwolg/BkjyzCKiC) | | | | | | | | | | | +| [Jihoon Song](https://github.com/jihoonsong) | [Update 6](https://hackmd.io/@jihoonsong/SJMKLaoOA) | [Update 7](https://hackmd.io/@jihoonsong/HypZY0EKA) | [Update 8](https://hackmd.io/@jihoonsong/rkag8fRYC) | [Update 9](https://hackmd.io/@jihoonsong/SkAFlxD5R) | [Update 10 & 11](https://hackmd.io/@jihoonsong/SkXyL5YoR) | | [Update 12 & 13](https://hackmd.io/@jihoonsong/BkQdAbm2A) | | | | | | | | | | +| [jsvisa](https://github.com/jsvisa) | [Update 6](https://hackmd.io/@jsvisa/epf5-week6) | [Update 7](https://hackmd.io/@jsvisa/epf5-week7) | [Update 8](https://hackmd.io/@jsvisa/epf5-week8) | [Update 9](https://hackmd.io/@jsvisa/epf5-week9) | [Update 10](https://hackmd.io/@jsvisa/epf5-week10) | [Update 11](https://hackmd.io/@jsvisa/epf5-week11) | | | | | | | | | | | +| [kira](https://github.com/shyam-patel-kira) | [Update 6](https://hackmd.io/@kira50/epf-week-6) | [Update 7](https://hackmd.io/@kira50/epf-week-7) | | [Update 8 & 9](https://hackmd.io/@kira50/epf-week-8-and-9) | | [Update 10 & 11](https://hackmd.io/@kira50/epf-week-10-and-11) | | [Update 12 & 13](https://hackmd.io/@kira50/epf-week-12-and-13) | | | | | | | | | +| [Krishang](https://github.com/kamuik16) | | | | | | | | | | | | | | | | | +| [Ktl_XV](https://github.com/ktl-xv) | | | | | | | | | | | | | | | | | +| [Léa Na](https://github.com/lean-apple) | [Update 6](https://hackmd.io/@leanapple/epf5-week-6) | | [Update 8](https://hackmd.io/@leanapple/epf5-week-8) | | [Update 10](https://hackmd.io/@leanapple/epf-week-10) | | | | | | | | | | | | +| [MaxDav](https://github.com/MaximeDavin) | | | | | [Update 10](https://hackmd.io/JHxszwwaTLiACttuooqvaA) | | | | | | | | | | | | +| [MeldSun](https://github.com/meldsun0) | | | [Update 8](https://hackmd.io/@3juAdBVCRtaXnRB_valWsA/rkgdDhz9C) | | | [Update 9-11](https://hackmd.io/@3juAdBVCRtaXnRB_valWsA/rkgdDhz9C) | | | | | | | | | | | +| [Md Amaan](https://github.com/Redidacove) | | | [Update 8](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/ryVZRyJqC) | [Update 9](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/ryPiTEY9A) | [Update 10](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/rJ4thMaqA) | [Update 11](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/r1QYUhFoC) | [Update 12](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/ryU9XY73A) | [Update 13](https://hackmd.io/@SSF5yRZPR9iw2e_zAYQ_wg/rJ9PyI2hR) | | | | | | | | | +| [mrk1tty](https://github.com/garv-aga) | | | | | | | | | | | | | | | | | +| [Nikhil](https://github.com/nikhilkumar1612) | | | | | | | | | | | | | | | | | +| [Nilav](https://github.com/gerceboss) | | [Update 7](https://hackmd.io/@gerceboss/rJxAKqStR) | | [Update 8 & 9](https://hackmd.io/@gerceboss/SJz9H1tqC) | | | | | | | | | | | | | +| [Rahul](https://github.com/guha-rahul) | | | [Update 8](https://hackmd.io/@0xrguha/H1KhY0E5A) | [Update 9](https://hackmd.io/@0xrguha/rkmJtiD50) | | [Update 10&11](https://hackmd.io/@0xrguha/Sk3ygM9i0) | [Update 12](https://hackmd.io/@0xrguha/r1MwVLmhR) | | | | | | | | | | +| [raxhvl](https://github.com/raxhvl) | [Update 6](https://epf.raxhvl.com/week/6) | [Update 7](https://epf.raxhvl.com/week/7) | [Update 8](https://epf.raxhvl.com/week/8) | [Update 9](https://epf.raxhvl.com/week/9) | [Update 10](https://epf.raxhvl.com/week/10) | [Update 11](https://epf.raxhvl.com/week/11) | [Update 12](https://epf.raxhvl.com/week/12) | [Update 13](https://epf.raxhvl.com/week/13) | | | | | | | | | +| [Richa](https://github.com/Richa-iitr) | [Update 6](https://hackmd.io/@iri/SJ4cj_0O0) | | [Update 7 & 8](https://hackmd.io/@iri/r1_p8URYA) | | [Update 9 & 10](https://hackmd.io/@iri/HkG8Mo65R) | [Update 11](https://hackmd.io/@iri/rJo7hGqj0) | | [Update 12 & 13](https://hackmd.io/@iri/BJ4pSHJaA) | | | | | | | | | +| [Richard Smith](https://github.com/ret2happy) | [Update 6](https://hackmd.io/@HAPPY/Hk4MbV7K0) | | [Update 8](https://hackmd.io/@HAPPY/B1HFOh2K0) | | | | | | | | | | | | | | +| [Rodrigo Herrera](https://github.com/) | | | | | | | | | | | | | | | | | +| [RoryArredondo](https://github.com/arredr2) | | | [Update 8](https://hackmd.io/@arredr2/Skelc2f_R) | | [Update 9 & 10](https://hackmd.io/@arredr2/r1njWlk90) | | | | | | | | | | | | +| [Rose Jethani](https://github.com/rose2221) | [Update 6](https://hackmd.io/@0xrosetteeee/Week6) | | [Update 7 & 8](https://hackmd.io/@0xrosetteeee/update7_8) | [Update 9](https://hackmd.io/@0xrosetteeee/Update9) | [Update 10](https://hackmd.io/@0xrosetteeee/Update_10) | | | [Update 11, 12 & 13](https://hackmd.io/@0xrosetteeee/week13) | | | | | | | | | +| [Rupam Dey](https://github.com/rupam-04) | [Update 6](https://hackmd.io/@rupam-04/Week6) | [Update 7](https://hackmd.io/@rupam-04/Week7) | [Update 8](https://hackmd.io/@rupam-04/Week8) | [Update 9](https://hackmd.io/@rupam-04/Week9) | [Update 10](https://hackmd.io/@rupam-04/Week10) | [Update 11](https://hackmd.io/@rupam-04/Week11) | [Update 12](https://hackmd.io/@rupam-04/Week12) | [Update 13](https://hackmd.io/@rupam-04/Week13) | | | | | | | | | +| [Saeid](github.com/xm0onh) | | | | | | | | | | | | | | | | | +| [Sayan](https://github.com/threehrsleep) | [Update 6](https://hackmd.io/@threehrsleep/epf_week6) | | [Update 7 & 8](https://hackmd.io/@threehrsleep/epf_week7-8) | | [Update 9 & 10](https://hackmd.io/@threehrsleep/epf_week9-10) | | [Update 11 & 12](https://hackmd.io/@threehrsleep/epf_week11-12) | | | | | | | | | | +| [Scar Face](https://github.com/scarfacedotcom) | | | | | | | | | | | | | | | | | +| [Siddharth Vaderaa](https://github.com/SiddharthV1) | | [Update 7](https://hackmd.io/@sidvdr/Sy744v4YA) | [Update 8](https://hackmd.io/@sidvdr/HyBBhxAY0) | | [Update 10](https://hackmd.io/@sidvdr/S1zdd-eiR) | | [Update 12](https://hackmd.io/@sidvdr/rkcqPGXhR) | | | | | | | | | | +| [Zarathustra](https://github.com/Karrenbelt) | | | | [Update 9](https://hackmd.io/@zarathustra/HJ_ocvP5R) | | | | | | | | | | | | | ## Cohort end diff --git a/notes/AdityaGupta.md b/notes/AdityaGupta.md index d79d5dc9..b9794720 100644 --- a/notes/AdityaGupta.md +++ b/notes/AdityaGupta.md @@ -17,4 +17,8 @@ These are my weekly EPF updates: - [Week 4](https://hackmd.io/@adigupta/rJ2y2koDR) - [Week 5](https://hackmd.io/@adigupta/rym-4nXdR) - [Week 6](https://hackmd.io/@adigupta/H139c34KA) -- [Week 7](https://hackmd.io/@adigupta/S1m6RhVFC) \ No newline at end of file +- [Week 7](https://hackmd.io/@adigupta/S1m6RhVFC) +- [Week 8](https://hackmd.io/@adigupta/Sy09KtDqC) +- [Week 9](https://hackmd.io/@adigupta/SklJd9P5A) +- [Week 10](https://hackmd.io/@adigupta/rySsqDniA) +- [Week 11](https://hackmd.io/@adigupta/H1fJpPniC) \ No newline at end of file diff --git a/notes/Bastin.md b/notes/Bastin.md index 5706b300..d5f36ca6 100644 --- a/notes/Bastin.md +++ b/notes/Bastin.md @@ -6,7 +6,7 @@ I'm looking forward to this EPF and I will try my best to produce value. ## My EPF Journey -Here in [this note](https://hackmd.io/@Bastin/r1oxkeNVR) I write down my thoughts and plans in an unorganized manner. this can be considered my thought process through out this program, and these notes are what will later on turn to the development updates. +Here in [this note](https://hackmd.io/@Bastin/r1oxkeNVR) I write down my thoughts and plans in an unorganized manner. this can be considered my thought process through out this program, and these notes are what will later on turn to the development updates. (I stopped using this very soon.) After researching some potential projects, I started with [Light Client Server Support in Prysm](https://github.com/eth-protocol-fellows/cohort-five/blob/main/projects/project-ideas.md#prysm-light-client-support). @@ -19,10 +19,13 @@ For this project the goal is to implement the needed functions for light clients Here you can see my weekly updates as well in the [`development-updates.md`](https://github.com/eth-protocol-fellows/cohort-five/blob/main/development-updates.md): - [Project Proposal](https://github.com/eth-protocol-fellows/cohort-five/blob/main/projects/light-client-support-in-prysm.md) -- +- - [Week 0](https://hackmd.io/@Bastin/HJ6hOLQHC) - [Week 1](https://hackmd.io/@Bastin/HyM3AmnrA) - [Week 2](https://hackmd.io/@Bastin/H1JgDZLU0) - [Week 3](https://hackmd.io/@Bastin/By8UVwlPA) -- [Week 5](https://hackmd.io/@Bastin/HyqHfO9OR) +- [Week 5](https://hackmd.io/@Bastin/HyqHfO9OR) - [Week 6](https://hackmd.io/@Bastin/Hke55_9dR) +- [Week 9](https://hackmd.io/@Bastin/B1Ja58D9C) +- [Week 11](https://hackmd.io/@Bastin/SyNqyCdoA) +- [Week 13](https://hackmd.io/@Bastin/S1n5EXoh0) \ No newline at end of file diff --git a/notes/EkaterinaRiazantseva.md b/notes/EkaterinaRiazantseva.md index 8cb55d69..6d6d0951 100644 --- a/notes/EkaterinaRiazantseva.md +++ b/notes/EkaterinaRiazantseva.md @@ -22,11 +22,10 @@ Draft: [EIP-7594: PeerDAS - Peer Data Availability Sampling](https://eips.ethere ## Consensus clients The overview of the consensus clients: -| Client | Lang | Team | Docs | Repo | -|------------|------------|---------------|-----------------------------------------------------------------|--------------------------------------------------------------| -| Lighthouse | Rust | Sigma Prime | [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) | [Github](https://github.com/sigp/lighthouse) | -| Lodestar | TypeScript | ChainSafe | [Lodestar Docs](https://chainsafe.github.io/lodestar/) | [Github](https://github.com/ChainSafe/lodestar/tree/v1.19.0) | -| Nimbus | Nim | Status | [Nimbus Guide](https://nimbus.guide/) | [Github](https://github.com/status-im/nimbus-eth2) | -| Prysm | Go | Offchain Labs | [Prysm Docs](https://docs.prylabs.network/docs/getting-started) | [Github](https://github.com/prysmaticlabs/prysm) | -| Teku | Java | ConsenSys | [Teku Docs](https://consensys.io/teku) | [Github](https://github.com/Consensys/teku) | - +| Client | Lang | Team | Docs | Repo | +| -------- | -------- | -------- | -------- | -------- | +| Lighthouse | Rust | Sigma Prime | [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) | [Github](https://github.com/sigp/lighthouse) | +| Lodestar | TypeScript | ChainSafe | [Lodestar Docs](https://chainsafe.github.io/lodestar/) | [Github](https://github.com/ChainSafe/lodestar/tree/v1.19.0) | +| Nimbus | Nim | Status | [Nimbus Guide](https://nimbus.guide/) | [Github](https://github.com/status-im/nimbus-eth2) | +| Prysm | Go | Offchain Labs | [Prysm Docs](https://docs.prylabs.network/docs/getting-started) | [Github](https://github.com/prysmaticlabs/prysm) | +| Teku | Java | ConsenSys | [Teku Docs](https://consensys.io/teku) | [Github](https://github.com/Consensys/teku) | \ No newline at end of file diff --git a/notes/Kira.md b/notes/Kira.md index 6a3a31bd..d0462375 100644 --- a/notes/Kira.md +++ b/notes/Kira.md @@ -24,3 +24,7 @@ I'll posting my weekly updates and notes on my [hackmd](https://hackmd.io/@kira5 * [Week 5](https://hackmd.io/@kira50/epf-week-5) * [Week 6](https://hackmd.io/@kira50/epf-week-6) * [Week 7](https://hackmd.io/@kira50/epf-week-7) +* [Week 8 & 9](https://hackmd.io/@kira50/epf-week-8-and-9) +* [Week 10 & 11](https://hackmd.io/@kira50/epf-week-10-and-11) +* [Week 12 & 13](https://hackmd.io/@kira50/epf-week-12-and-13) + diff --git a/notes/Nilav.md b/notes/Nilav.md new file mode 100644 index 00000000..4920f08b --- /dev/null +++ b/notes/Nilav.md @@ -0,0 +1,15 @@ +# Introduction + +Hey everyone, I am Nilav. I am looking forward to do open-source contributions, dive deeper into the protocol and learn about recent research going on. +I will be contributing to the Nimbus codebase and Constantine library during the cohort, related to peerDAS implementation. + +These are my twitter and github handles: +- [Twitter](https://x.com/gerceboss_21) +- [Github](https://github.com/gerceboss) + +# Project Proposal +This is my project proposal for the EPF: [peerdas-nimbus](../projects/peerdas-nimbus.md) + +Project presentation slides: [Slides](https://docs.google.com/presentation/d/13nqyNGN1vUl6KAB2Ogmp5X7qwUY7tpfphIomVOV_fJw/edit?usp=sharing) + +Project Presentation Video link : [Presentation Video](https://youtu.be/NTsfIiPBM6U) \ No newline at end of file diff --git a/notes/RupamDey.md b/notes/RupamDey.md index c3b9232c..a10caf1d 100644 --- a/notes/RupamDey.md +++ b/notes/RupamDey.md @@ -16,4 +16,10 @@ I'll posting my weekly updates on my [hackmd](https://hackmd.io/@rupam-04) * [Week 4](https://hackmd.io/@rupam-04/Week4) * [Week 5](https://hackmd.io/@rupam-04/Week5) * [Week 6](https://hackmd.io/@rupam-04/Week6) -* [Week 7](https://hackmd.io/@rupam-04/Week7) \ No newline at end of file +* [Week 7](https://hackmd.io/@rupam-04/Week7) +* [Week 8](https://hackmd.io/@rupam-04/Week8) +* [Week 9](https://hackmd.io/@rupam-04/Week9) +* [Week 10](https://hackmd.io/@rupam-04/Week10) +* [Week 11](https://hackmd.io/@rupam-04/Week11) +* [Week 12](https://hackmd.io/@rupam-04/Week12) +* [Week 13](https://hackmd.io/@rupam-04/Week13) \ No newline at end of file diff --git a/notes/hangleang.md b/notes/hangleang.md index 672af2b3..048bd13e 100644 --- a/notes/hangleang.md +++ b/notes/hangleang.md @@ -18,4 +18,10 @@ Lastly, thanks to @ghili. I'm permissionlessly fork your note, cause we have som - [consensus-specs/v1.5.0-alpha.3](https://github.com/ethereum/consensus-specs/releases/tag/v1.5.0-alpha.3) - [pectra-devnets repo](https://github.com/ethpandaops/pectra-devnets) by EthPandaOps Team - [peerdas-devnet-1 specs](https://notes.ethereum.org/@ethpandaops/peerdas-devnet-1) by EthPandaOps Team -- [libp2p-pubsub Peer Discovery with Kademlia DHT](https://medium.com/rahasak/libp2p-pubsub-peer-discovery-with-kademlia-dht-c8b131550ac7) \ No newline at end of file +- [libp2p-pubsub Peer Discovery with Kademlia DHT](https://medium.com/rahasak/libp2p-pubsub-peer-discovery-with-kademlia-dht-c8b131550ac7) +- [DAS and Danksharding](https://a16zcrypto.com/posts/article/an-overview-of-danksharding-and-a-proposal-for-improvement-of-das) + +### Tools +- [ENR Viewer](https://enr-viewer.com/): decoding ENR to inspect `csc` field (custody subnet count), maintained by ChainSafe +- [PeerDAS Custody](https://jimmygchen.github.io/peerdas-custody/): compute custody subnets and columns from node ID or peer ID, maintained by [jimmygchen](https://github.com/jimmygchen) from Lighthouse + - [My fork with config updates](https://hangleang.github.io/peerdas-custody/) diff --git a/program-guide/repo-guide.md b/program-guide/repo-guide.md index 2e69b7aa..4e9d6ef6 100644 --- a/program-guide/repo-guide.md +++ b/program-guide/repo-guide.md @@ -37,9 +37,9 @@ You should: The cohort coordination using a public repository is also meant to give you an experience of real-world collaboration in free open-source software (FOSS) development using [Git](https://git-scm.com/video/what-is-version-control). Git tracks changes to code, making collaboration on projects seamless, especially in FOSS where public repositories are the norm. Consider using the Git command line interface (CLI) over using GitHub's web interface. It's an important skill you can learn during the cohort that will serve you well throughout your career. Check out the resources on [using git in the epf.wiki](https://epf.wiki/#/wiki/dev/cs-resources?id=terminals-shell-scripting-and-version-control). -#### 1. Setting up your local repository +#### 1. Forking the repository and setting up your local environment -Install [git](https://git-scm.com/) using a preferred method on your machine and set it up with your github SSH key. You need to [setup ssh](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) and [add the generated key to your github account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) if you haven't done so yet. With your git setup complete, fork the repo to your github account (by clicking the Fork button) and clone the fork locally, for example: +Install [git](https://git-scm.com/) using a preferred method on your machine and set it up with your github SSH key. You need to [setup ssh](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) and [add the generated key to your github account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) if you haven't done so yet. With your git setup complete, **fork the repo** to your github account (by clicking the Fork button) and clone the fork locally, for example: ``` git clone git@github.com:taxmeifyoucan/cohort-five.git diff --git a/projects/Prysm_libP2P_Implementation.md b/projects/Prysm_libP2P_Implementation.md new file mode 100644 index 00000000..e522d28f --- /dev/null +++ b/projects/Prysm_libP2P_Implementation.md @@ -0,0 +1,86 @@ +# Custom golang implementation of libp2p in Prysm +An in-house implementation of the necessary parts of the libp2p protocol in the Prysm client + +## Motivation +The project aims to develop an in-house implementation of p2p communication library and leverage some of the core components from the existing [go-libp2p](https://github.com/libp2p/go-libp2p) libraries. go-libP2P library(and its variants in other languages) are used by almost all consensus clients for p2p network communications among beacon chain nodes. The scope of the project enables the Prysm team to be independent of any third party for the integral components. It also allows for elimination of redundant components from go-libp2p which are not actively used, while achieving the same performance. Implementing the project also involves incorporating a deep understanding of libP2P and networking layer. + +## Project Description +The libP2P protocol has several components for example: Noise, multiplexer, pubsub, ping etc. Not all these components are used by Prysm, hence the major tasks or the solution for the problem at hand are: +* Segregate the components in libP2P which are used in Prysm, this involves a clear marking of: + * the individual elements which can be used as-it-is + * the elements which need refactoring to incorporate only the segments used by libP2P + * the components which can be eliminated completely. + * Thanks to @MaxDav for noting some required changes in his [notes](https://hackmd.io/zIWLqRzWT76I5T_sPbJ0KA). +* Implement a package with the necessary components of libP2P used by Prysm, in sync with [p2p specs for CL](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md). +* Extensively test the package. +* Switch the current libP2P implementation in Prysm to the new package developed. +* Performance analysis and optimizations of the in-house version compared to the Protocol Labs' implementation on Holesky network. + +## Specification + +We'll will following the [CL specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md) for the development of this new package. + +Major components used in Prysm: +* `devp2p/discv5` (outside the project scope) +* `tcp/quic` connection protocols +* `NOISE` protocol negotiation, can be used as-it-is +* [`multistream-select`](https://github.com/multiformats/multistream-select/) +* [`mplex`](https://github.com/libp2p/specs/tree/master/mplex) +* [`yamux`](https://github.com/libp2p/specs/blob/master/yamux/README.md) +* [`gossipsub`](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md) +* [`ssz`](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) encoding + + +## Roadmap + +**Month 1: Design and Initial Development** +- Deep dive into the p2p-interface.md from the consensus specs. Understand the theoretical aspects thoroughly. +- Start examining the existing libp2p components used in the Ethereum beacon chain. Identify which components are utilized by Prysm and which are not necessary. +- Begin the design of the new libp2p for Prysm based on the specs studied. Outline the architecture and identify all dependencies and external libraries needed. +- Start implementing the basic framework of the custom libp2p. Focus on integrating core components that are essential for Prysm’s functionality. + +**Month 2: Development Continuation** +- Continue building out the libp2p implementation, adding more complex functionalities and integrating with Prysm’s existing systems. +- Begin internal testing of individual components. Use the guidelines from the [Prysm’s end-to-end development tools]( https://docs.prylabs.network/docs/devtools/end-to-end) and [Golang principles](https://docs.prylabs.network/docs/contribute/golang-principles) for coding and testing standards. + +**Month 3: Testing and Documentation** +- Develop and implement an extensive testing plan. Test each component individually, followed by integrated testing with the Prysm beacon node. +- Start writing documentation for the new implementation. Ensure all features and modifications are well-documented. + +**Month 4: Deployment and Performance Tuning** +- Integrate the new libp2p implementation into the Prysm beacon node, hidden behind a feature flag. +- Conduct comprehensive performance tests on the Holesky testnet, comparing the new in-house implementation with the external libp2p version. Gather and analyze performance data to identify any issues or potential improvements. + +## Possible Challenges +Since libP2P is already in use among several consensus clients, one key challenge for us would be maintaining the same performance as provided by libP2P. Further the project involves a deep understanding in networking and implementation and refactoring of several components, it might not be that easy to do. +## Goal of the project +* Understand libP2P networking package and its components within the beacon chain. +* Develop and integrate a simplified package tailoring to Prysm's specific requirements of libP2P, while including some of the core dependencies as it-is. +* Performance analysis. + +### Non-goals +* Re-implementing core-dependencies which can be used as-it-is. + +## Collaborators +### Fellows +* [Rose Jethani](https://github.com/rose2221) +* [Richa](https://github.com/Richa-iitr) +* [MaxDav](https://github.com/MaximeDavin) +* [kira](https://github.com/shyam-patel-kira) + +### Mentors +* [manunlp](https://github.com/nalepae) + +## Resources +Relevant codebases: +* [prysm/beacon-chain/p2p](https://github.com/prysmaticlabs/prysm/tree/develop/beacon-chain/p2p) +* [prysm/beacon-chain/sync](https://github.com/prysmaticlabs/prysm/tree/develop/beacon-chain/sync) +* [prysm/cmd/prysmctl/p2p](https://github.com/prysmaticlabs/prysm/tree/develop/cmd/prysmctl/p2p) +* [prysm/tools/enr-calculator](https://github.com/prysmaticlabs/prysm/tree/develop/tools/enr-calculator) +* [go-libP2P](https://github.com/libp2p/go-libp2p/tree/master) + +Specs: +* https://github.com/libp2p/specs + +Others: +* https://docs.libp2p.io/concepts/introduction/overview/ diff --git a/projects/Push-Based-Custom-Ceiling-Partial-Withdraw-for-EIP7251-MaxEB.md b/projects/Push-Based-Custom-Ceiling-Partial-Withdraw-for-EIP7251-MaxEB.md new file mode 100644 index 00000000..c1d3c377 --- /dev/null +++ b/projects/Push-Based-Custom-Ceiling-Partial-Withdraw-for-EIP7251-MaxEB.md @@ -0,0 +1,98 @@ +# Push Based Custom Ceiling Partial Withdrawal for EIP-7251 (MaxEB) +MaxEB, Withdrawal, Deposit, Staking, BeaconStake, Electra, Consensus, Economics + +## Motivation + +1. [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) improves MaxEB, and is [scoping](https://eips.ethereum.org/EIPS/eip-7600) into [Electra](https://ethereum.github.io/consensus-specs/specs/electra/beacon-chain/) Upgrade ([~2025/Q1](https://x.com/TimBeiko/status/1793684244612407687)), and with the mission to [sustain validator set size growth](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989), and preparing for [SSF](https://ethereum.org/en/roadmap/single-slot-finality/) and [ePBS](https://ethereum.org/en/roadmap/pbs/). +2. I have [studied](https://hackmd.io/@georgesheth/HJKkx3NSR) that [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251) has 6 features and explains what they are. Push Based Custom Ceiling Partial Withdrawal is a feature still left for design and implementation, and it is demanded for before or post Electra Upgrade, due to its complexity, more details please see bellow analysis. +3. This project aims to design and implement Push Based Custom Ceiling Partial Withdrawal at coding level ([Spec](https://ethereum.github.io/consensus-specs/specs/electra/beacon-chain/) and [Test](https://github.com/ethereum/execution-spec-tests)). In summary, + + +## Project description + +1. **[Staking withdrawals](https://ethereum.org/en/staking/withdrawals/)** refer to transfers of ETH from a validator account on Ethereum's consensus layer (the Beacon Chain), to the execution layer where it can be transacted with. Stakers need to be able to withdraw their ETH deposited as validator. +2. There are two possible direction to trigger the withdrawals: `Pull-based withdrawals trigger` (e.g. EIP-4788) and `Push-based withdrawals trigger` (e.g. EIP-4895). So far, `Push-Based Withdrawals Trigger` is [more popular]((https://luozhu.mirror.xyz/ojI7HibWU8JcHR2DBUdWZ7WitIYpWXoZDuyEpyRwduk)) and has adopted by multiple EIPs. +3. Before EIP-7251, staking withdrawals looks like: + 1. Requirement: Providing a withdrawal address is required before *any* funds can be transferred out of a validator account balance. + 2. Push-based full exit withdrawal via voluntary exit: Users can **exit staking entirely**, unlocking their full validator balance. + + 1. Users sign and broadcast a "**voluntary exit**" message with validator keys which will start the process of exiting from staking. This is done with your validator client and submitted to your consensus node, and does not require gas. + 2. The process of a validator exiting from staking takes variable amounts of time, depending on how many others are exiting at the same time. Once complete, this account will no longer be responsible for performing validator network duties, is no longer eligible for rewards, and no longer has their ETH "at stake". At this time the account will be marked as fully "withdrawable". + 3. Once an account is flagged as "withdrawable", and withdrawal credentials have been provided, there is nothing more a user needs to do aside from wait. Accounts are automatically and continuously swept by block proposers for eligible exited funds, and your account balance will be transferred in full (also known as a "full withdrawal") during the next [sweep](https://ethereum.org/en/staking/withdrawals/#validator-sweeping). + 3. Push-based MaxEB ceiling Partial withdrawal: **Reward payments of excess balance** over `MAX_EFFECTIVE_BALANCE` (currently set as 32 ETH) will automatically and regularly be sent to a withdrawal address linked to each validator, once provided by the user. + + 1. Any balance above 32 ETH earned through rewards does not actually contribute to principal, or increase the weight of this validator on the network, and is thus automatically withdrawn as a reward payment every few days. + 2. Aside from providing a withdrawal address one time, these rewards do not require any action from the validator operator. This is all initiated on the consensus layer, thus no gas (transaction fee) is required at any step. +4. After [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251), MaxEB is increased from `32 ETH` to `2048 ETH`. It means there is a space for custom ceiling between `32 ETH` to `2048 ETH` which is defined by `MIN_ACTIVATION_BALANCE` and `MAX_EFFECTIVE_BALANCE`. + 1. To be more specific, any excess balance beyond the custom ceiling should enjoy the same mechanism as partial withdraw beyond MaxEB. + 2. Custom ceiling is not an issue [EIP-7251]((https://eips.ethereum.org/EIPS/eip-7251)), as both `both MAX_EFFECTIVE_BALANCE` and `MIN_ACTIVATION_BALANCE` equal to `32 ETH`. +5. What is the impact if we do not implement this custom ceiling partial wirthdrawal along/after [EIP-7251]((https://eips.ethereum.org/EIPS/eip-7251)): + 1. Validators have to fully exit in order to use the stakes and rewards. + 2. It causes more other partial withdrawal queue on Execution Layer, and cost more gas fee to the stakers. +6. What is the benefit if we implement this feature: + 1. This feature benefits to solo stakers to improve their stake financial efficiency. + 2. This feature benefits to institutional stakers to manage and control their staking strategy and operation. + 3. This feature benefits to stakers to reblance stake across node operators, to reduce the risk of lock-in by specific providers. +7. The community discussed heavily on the timeline of this feature nearly in 5 out of 7 EIP-7251 breakout calls [1](https://hackmd.io/@wmoBhF17RAOH2NZ5bNXJVg/S1U86pzgR) [3](https://hackmd.io/@philknows/BJCaLJf1A#Custom-celings-To-be-continued-in-next-meeting) [4](https://hackmd.io/@philknows/Sy2kQAq1C?#Custom-Ceilings) [5](https://hackmd.io/YNy6vhDoQ8Ki6DQNv8tsWA#:~:text=In%20CALL%20%235%2C-,https%3A//hackmd.io/%40philknows/S1JbLXmlA%23Custom%2DCeilings,-Custom%20ceilings%20are) [6](https://hackmd.io/@philknows/Hywht12eR#Custom-Ceilings). And the conclusion is: + 1. This feature should be implemented. + 2. This feature has complexity, and the solid solution is not yet there. + 3. Due to the tight timeline for Electra upgrade, it should be push into another EIP with a solid approach. +8. This project target on this goal to design and implement a solid solution. + +![whiteboard_exported_image (49)](https://hackmd.io/_uploads/BJDPl8BKC.png) + +## Specification + +### Design +![whiteboard_exported_image (51)](https://hackmd.io/_uploads/BJ0-ZLrF0.png) + +### Research +1. We need to research on UX on how to setup a custom ceiling for a validator. +2. We need to research on if and how to control custom ceiling set/update rate limit. +3. We need to research on the impacts of custom ceiling to other existing features, e.g. deposit, top-up, validator consolidation, rewards/penality, withdrawal, etc. + +### Implementation +1. Electra Spec already defined `PendingPartialWithdrawal` container and we can reuse. +2. We need add a variable for custom ceiling in `Validator` construct. +3. We need a help function to get the correct custom ceiling as there are some exceptions we need to handle. +4. We need to update `process_withdrawal_request()` to update excess balance logic based on custom ceiling. +5. We need to update `process_effective_balance_updates()` to take custom ceiling into considtion. +6. We need to implement in execution layer to set/update the validator's custom ceiling. +7. We need to implement a control of the custom ceiling update speed. +8. we need to get the request from the exeuction layer to update BeaconState. +9. We need to update `process_epoch()` to process pending effective balance ceiling set/update. +10. We need to update the hardfork test to take custom ceiling into consideration. + +## Roadmap + +This project will roughly executed in three Phases. +1. Phase 1 (3 weeks): socialise and finalise the design and publish the design document. +2. Phase 2 (3 weeks): research on each topic and observe the comments and publish the research articles. +3. Phase 3 (4 weeks): implement the functions and specs and publish the development document. +4. Phase 4 (2 weeks): develop Pyspec test case and complete the test and PR for final updates to the spec and eips. + +## Possible challenges + +1. This features needs to update on the validator variables, which cause the hardfork and need to develop a seperate trees. +2. This features needs to bring a new UX to setup the custom ceiling. +3. This features needs to research on the impacts to the staking economic and the risks to the ethereum stability. + + +## Collaborators + +### Fellows + +1. [George Shao](https://github.com/georgesheth) + +### Mentors + +To be updated. +Welcome suggestion and collaboration. + +## Resources +1. My other relevent articles on EIP-7251: + - [BeaconState and Validator Balance for EIP-7251](https://hackmd.io/@georgesheth/BJGl24HYA) + - [History of EIP-7251](https://hackmd.io/@georgesheth/rJxnQBrtC) + - [Feature Lists of EIP-7251](https://hackmd.io/@georgesheth/HJKkx3NSR) + - [Implement EIP-7251](https://hackmd.io/@georgesheth/Hk2r2BHFC) + diff --git a/projects/attestation-based-inclusion-list.md b/projects/attestation-based-inclusion-list.md index 0742bb53..83e2da8c 100644 --- a/projects/attestation-based-inclusion-list.md +++ b/projects/attestation-based-inclusion-list.md @@ -1,5 +1,20 @@ # Inclusion List with Plausible Deniability +``` +💡 please check out below document +https://hackmd.io/@irnb/epf_week11 + +I explained the reason why i stopped working on this project and what i'm working on now. +but in short, i stopped working on this project because during the implementation of prototype +I realized that the one-bit-per attester inclusion list has some issue like network congestion, +unsolved open question and attack vectors and because of that i decided to stop working on this +project you can check the document for more details. + +And now (end of 2024 Aug) I decided to dedicate my time to contributing directly to Lighthouse +project through their issues and PRs, and also i'll continue my research on the +censorship resistance and privacy in Ethereum. + +``` This solution tackles censorship issues caused by block builders in PBS and future ePBS. By employing **Reed-Solomon** erasure codes, it introduces a design that offers **plausible deniability** for Inclusion List Committee members, safeguarding them from accountability and legal constraints. diff --git a/projects/eods-specification.md b/projects/eods-specification.md new file mode 100644 index 00000000..667b5741 --- /dev/null +++ b/projects/eods-specification.md @@ -0,0 +1,257 @@ + +# eODS (enshrined Operator-Delegator Separation) specification + +## Motivation + +**What problem is the project solving? Why is it important?** + +Today, ETH delegators allocate their principal to node operators off-protocol, via staking pools. + +The pain is that off-protocol ETH delegation is easily captured by exogenous influences, as seen today in liquid staking, leading to the centralization of staking pools, in the detriment of protocol safety. Delegators are given no real voting power, and no meaningful role in the Protocol. + +The project addresses inefficiencies associated with the limits of what the Ethereum Protocol can detect and how it defends itself, in the context of delegated proof of stake: + +- The Protocol cannot see ETH delegations, so its reach and ability to control Validators is limited in that aspect. The project addresses this issue, helping the Protocol disambiguate the Validator role and "see" the staking scene actors. + + Ethereum Protocol's credibility comes from the control over the Validators that execute the protocol. But it can only control what it can see, so it's important to extend these limits, in order to allow for the Protocol to have the capacity to react with automated defense systems. + +- Currently, ETH delegators do not play a [meaningful role](https://epf.wiki/#/wiki/research/eODS?id=the-role-of-delegators) in the protocol, as they don't actively participate in Consensus. We can improve this by allowing the Protocol to identify delegated stake and incentivize the Delegator role selection. Delegators under eODS model do not contribute to the economic security of FFG, i.e. delegators do not partake in Finality, but they are able to surface discrepancies in the gadget’s functioning. Their services can be compensated by re-allocated aggregated issuance. + + Delegator role, under Operator-Delegator separation: + * The curation of operator set: Opinionated delegators may decide to choose between different operators based on e.g., fees or reliability. These criteria could be part of a Validator rating system developed either on CL clients side or in-protocol. + * The provision of non-FFG services: The delegators may be called upon to provide non-slashable yet critical services, like inputting their view into censorship-resistance gadgets such as inclusion lists or multiplicity gadgets. + + Allowing in-protocol delegations and having a meaningful role for delegators is a health indicator of any staking system. The current role principal providers play in delegated proof-of-stake is limited to voting within pools, which ultimately is just [a flawed type of voting](https://notes.ethereum.org/@vbuterin/staking_2023_10#Expanding-delegate-selection-powers). + +- Liquid staking centralization is a well known issue in the space and exploring solutions to it is one important topic of the protocol's [roadmap](https://epf.wiki/#/wiki/research/roadmap). + +The project proposes a solution to the long-term key question of "what’s the intended Etherean way for the large ETH holders that want return for their participation in protocol”. In a functional enshrined delegation mechanism, ETH holders will have a direct relation with their delegates, the validators (operators) executing the Protocol, possibly mitigating the "grip" liquid staking has over staking. + +**What area of the protocol will be affected?** + +Implementing the project implies changes to the Execution Layer (EL) and the Beacon Chain (CL) specifications. + +## Project description +My proposed solution is an implementation of eODS, implying a **separation** of the **Validator** role, implemented at protocol level: + +### Unbundling the Validator role between Operator and Delegator. + +This project proposes a way to enshrine the delegation process, in order to map in-protocol Principal-Agent relationship, in the context of ETH staking. + +It aims to solve the above inefficiencies by providing delegators, with an explicit mechanism to deposit / compound and delegate their principal. Capital providers will be able to delegate stake to another (possibly new) targeted validator (node operator), thus allowing them to be opinionated in their operators of choice. This all in-protocol, in particular not involving the deposit contract in a different way than a regular deposit is. + +The **Validator role** will be unbundled in two separate protocol entities: + +* Delegator - an optional protocol role for ETH holders that want to participate in a way that is lighter than a full staking operation, but still meaningful. + +* Operator - a protocol role equivalent to today's node operators, running consensus validators and executing the Protocol. Operators are accountable to Delegators in the context of delegated proof-of-stake. + +With eODS we will have two types of validators: +* heavy Validators (or Validators - for simplicity and correspondence with the current PoS) participating in protocol Finality +* light Validators participating in non-Finality (light)Protocol services providing. + + The actions set of Validators would be reduced by transferring the Censorship Resistance protocol services e.g. IL, and other non-FFG attributes to the light Validator's actions set. + +#### Actively Validated Service (AVS), as Delegator role selection + +The second part of the project consists of the conceptual design of a plug-and-play interface for future integration of light protocol services and an MVP specification of the interface, as minimal expected deliverables. + +The distinction between different types of protocol services, under eODS: + + * Consensus (Finality) services - FFG type + + * Censorship Resistant services - AVS type + + Delegators could use the *liability proof*, received after delegating towards operators participating in FFG, for "backing" operators participating in light protocol services i.e. CR services, committing to the provision of an “actively validated service” (AVS) and possibly receiving rewards for good service provision. + +Possible separation of protocol services(modeled upon ePBS): + +![Protocol Services](https://hackmd.io/_uploads/rkzjBG95A.png) + +#### Conceptual design of an interface for adding light protocol services: +* General design principle + * Design constraints + * Identify light & heavy operators and other stakeholders + * Identify services + * Finality gadget + * Censorship-resistance gadgets (e.g. Inclusion lists, Multiplicity gadgets) + * Economics of consensus services + * Economics of AVS + * MVI of the different protocol services +* Specification notes referencing: + * An adaptation of the slashing mechanism to account for partially slashable light services + * Liveness + * Protocol safety + +## Part 1 - eODS Specification +**How will you implement your solutions? Give details and more technical information on the project.** + +### What are the minimum set of requirements for eODS design? +- New entity in beacon state: Delegators as a new class, similar to validators but with different signature domain and participation flags indices +- Add state Delegator index & balances +- Mapping in-protocol Principal-Agent relationship by explicitating a way for Delegators to transfer ETH to Validators and introducing Validator *"liabilities"* towards Delegators +- Allow for delegator triggered `0x01` withdrawals. + +### Specification overview + +A sketch of the proposed **execution layer** changes is included below: + +#### Staking-deposit-cli + +Stakers deposit ETH in the protocol, provided `amount` >= `MIN_DEPOSIT_AMOUNT`. During [deposit](###Deposit), a forked staking-deposit-cli will allow depositors to set a boolean `is_delegator` field to `True` or `False`, alongside the address of a smart contract (delegation contract) that, when called, outputs the target validator's index and pubkey. The structure denoting the deposit operation on EL will also gain the two new fields, accordingly. + +#### Deposit contract +The deposit contract will gain the following arguments: `is_delegator`, and `delegation_contract`. The `DepositData` container will be extended accordingly. + +A sketch of the proposed **consensus layer** changes is included below: + +The eODS specification is to be built upon existing specifications of Ethereum components, i.e. [Electra consensus-specs.](../../electra/beacon_chain.md) + +- Add new beacon-chain `class Delegator` +- New `get_delegator_from_deposit` function +- Modified `apply_deposit` function to accommodate delegations +- Add `is_delegator == False` condition for new deposited validators to enter activation queue +- Add delegations to block processing: + - Constructing a delegator registry along side validator registry inside `BeaconState`. (`add_delegator_to_registry`) + - Get `process_deposit_request` to handle delegation deposits & `process_consolidation_request` to handle delegated validators consolidations +- Add mapping between `state.balances[index]` and `state.delegator_balances[index]` + - Add new `Domaintype` to sign delegation messages + - Modify `The beacon block body` to add a list of included delegation messages. + - Add `DelegationMessage` containing the pubkey and the withdrawal credentials of the delegate validator. + - Add `Delegation` consisting of the signed delegation message, the signature and an `epoch` parameter to set the valability of the delegation message. + - The function `process_operations` is modified to support all of the new functionality +- Enable Delegator triggerable exits (0x01 credentials). + +:::warning +During the implementation of the project some of these changes might be partially extended, get altered or be removed. +::: + +## Part 2 - Research Delegator role selection & incentivization + +Part 1 of the project opens the possibility to enshrine Delegations and allow Principal to be opinionated in the Agent (Validator) selection. + +Part 2 of this project will focus on defining actions set, or attributes for delegators. + +### What are the minimum set of requirements for Part 2 of the Project? + +- A conceptual design on what consensus role can delegators have, and how can the Protocol incentivise that role selection + +- The specification of this feature + +An eventual EIP resulting from my project will most likely have to be based on an ePBS fork. Intertwining eODS with eg. IL and ePBS ontop of the PoS mechanism is not trivial (maybe not even ideal), so abstracting the "discrepancies surfacing" type of protocol services in the Delegator's actions set, could ease some of the design around e.g. CR gadgets. + +*Possible* compatible role selection for Delegators as AVS providers: + +- Whistleblower + +- Sync committee + +- Validator scoring on light CL clients, operated by Delegators + +- Co-signing block proposals, attestations + + The staking public key for a Validator for a slot would be set to `validator_pubkey` $+$ `delegator_pubkey`. + Slashing would be adapted in this case to account for `delegator_pubkey` (two slashable messages could have different delegator keys, but they would have the same validator key) + +- Signing in for censorship-resistance gadgets, e.g. Inclusion Lists $Δ$ evaluation, multiplicity gadgets + +:::success +### DELIVERABLES +Specification notes for the eODS feature can be found [here](hackmd.io/gorondan/). + +The EL specification of the enshrined operator delegator separation feature can be found here: +- [deposit-contract](consensus-specs/specs/_features/eODS/deposit-contract.md) + +The CL specification of the enshrined operator delegator separation feature can be found here: +- [beacon-chain](consensus-specs/specs/_features/eODS/beacon-chain.md) +- [validator](consensus-specs/specs/_features/eODS/validator.md) +- [fork-choice](consensus-specs/specs/_features/eODS/fork-choice.md) +::: +## Roadmap + +*What is your proposed timeline?* + +The proposed timeline for the project is **6 months**, split in 2 work-packages as follows: + +*Outline parts of the project and insight on how much time it will take to execute them.* + +### I. Part 1 - eODS Specification notes + +1. Prototyping eODS in 8 weeks (**Week 6 - Week 13**) including getting feedback from mentors. + +2. Write case studies, and prototype the APIs of eODS defined protocol objects, including getting feedback from mentors in 4 weeks (**Week 14 - Week 17**). + +### II. Part 1 - Research Delegator role selection & incentivization + +1. I've done some of the work related to this phase in the weeks preceding EPF, especially during EPS, I plan to have the conceptual design for the integration of Delegators-provided protocol services done in in 4 weeks (**Week 17 - Week 21**) including getting feedback from mentors. +2. I plan to write the eODS specs, including getting feedback from mentors and case study tests in an additional 4-8 weeks window (**Week 21+**). I will continue past the EPF program time span for as long as it needs to finish up this feature. + +## Possible challenges + +What are the limitations and issues you may need to overcome? + +* Electra fork specs are in active development + +* Data complexity + :::warning + Memory cost of adding extra beacon-chain state elements + ::: + Consuming computations to consider: + + * signature verification + +* Integrating eODS with ongoing R&D on e.g. ePBS, ILs will most likely not be a trivial task + +* Defining attributes for delegators will have to take into account aspects like existing protocol incentives and maintaining PoS safety assumptions + +## Goal of the project + +*What does success look like? Describe the end goal of the project, scope, state and impact for the project to be considered finished and successful.* + +The end goal of this project is to fully specificate eODS. + +Expected impact/followup: +- eODS EIP + - Part 1 can be functional on its own + - Part 2 can be added later +- I would consider a success if my project would stand as a starting base for a future POC and client implementation for + - full node + - light client + +I see the following realistic scenario: +- Finalize Part 1, and the conceptual design of Part 2 and as much as possible of Part 2 specs, during EPF period. +- Finalize Part 2 specs in the months following the EPF if not done during the EPF project time span. +- Propose eODS EIP according to Part 1 specs +- Propose EIP according to Part 2 specs + +## Collaborators + +### Fellows + +At this moment, there are no other fellows working with me on this project. + +### Mentors + +[Barnabé Monnot](https://github.com/barnabemonnot) +[Potuz](https://github.com/potuz) +## Resources + +[Week 0 research notes](https://hackmd.io/@kboomro/SJmdOEmXR) + +[[1] Unbundling staking](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683) + +[[2] Protocol and staking pool changes that could improve decentralization and reduce consensus overhead](https://notes.ethereum.org/@vbuterin/staking_2023_10) + +[[3] Should Ethereum be okay with enshrining more things in the protocol?](https://vitalik.eth.limo/general/2023/09/30/enshrinement.html#what-do-we-learn-from-all-this) + +[[4] EIP-7215](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7251.md) + +[[5] EIP- 6110](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6110.md) + +[[7] Electra fork consensus specs](https://github.com/ethereum/consensus-specs/tree/dev/specs/electra) + +[[8] EPF.wiki eODS page](https://epf.wiki/#/wiki/research/eODS) + +[[9] Orbit SSF](https://ethresear.ch/t/orbit-ssf-solo-staking-friendly-validator-set-management-for-ssf/19928/1) + +Copyright and related rights waived via [CC0](../LICENSE.md). \ No newline at end of file diff --git a/projects/epbs-implementation-in-nimbus.md b/projects/epbs-implementation-in-nimbus.md index 357699e4..17980c10 100644 --- a/projects/epbs-implementation-in-nimbus.md +++ b/projects/epbs-implementation-in-nimbus.md @@ -49,6 +49,7 @@ The goal of the project is to have a working and well-tested implementation of e - @[Terrence](https://github.com/terencechain/) ## Resources +* [PR-Link](https://github.com/status-im/nimbus-eth2/pull/6443) * [eip-7732](https://eips.ethereum.org/EIPS/eip-7732#abstract) * [Ethereum Consensus Specs](https://github.com/ethereum/consensus-specs/tree/v1.3.0/#stable-specifications) * [Nim Manual](https://nim-lang.org/docs/manual.html) diff --git a/projects/evm-memory-repricing.md b/projects/evm-memory-repricing.md new file mode 100644 index 00000000..da76920a --- /dev/null +++ b/projects/evm-memory-repricing.md @@ -0,0 +1,53 @@ +# EVM memory repricing + +## Motivation + +Efficiency gains from hardware advancements, and client code optimizations warrants periodic repricing of gas costs. + +## Project description + +The EVM's memory is a **word-addressed byte array** that stores its **volatile state**. Accessing memory, like any instruction in the EVM, incurs fees in a unit called **gas**. + +Gas does not measure the direct cost of execution, but rather the _computational effort_ required by a node's hardware to execute EVM instructions. Transactors pay for per unit of gas at market value which ultimately determines the execution cost. + +This project focuses on analyzing the gas costs associated with EVM memory opcodes `MSTORE`, `MSTORE8`, and `MLOAD`. + +## Specification +TBD. + +## Roadmap +TBD. + +## Possible challenges + +Gas metering is an open problem in Ethereum given the spectrum of underlying hardware and software. It will be challenging to come up with a reliable analysis. + +## Goal of the project + +The goal of the project is provide data points to support repricing of memory usage in the EVM. + +## Collaborators + +### Fellows + +- @raxhvl + +### Mentors + +- @axic +- @chfast + +## Resources + +- 📄 Gavin W., [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) +- 📄 EPF Wiki, [EVM](https://epf.wiki/#/wiki/EL/evm) +- 📄 Eth Research, [On Block Sizes, Gas Limits and Scalability](https://ethresear.ch/t/on-block-sizes-gas-limits-and-scalability/18444) +- 📄 John A., [Wait, It's All Resource Pricing?](https://www.youtube.com/watch?v=YoWMLoeQGeI) +- 📄 John A., [Induced Demand from Blockchain Resource Pricing](https://www.youtube.com/watch?v=_6ctMrlhcO4) +- 📄 Martin H., [Gas benchmarks](https://github.com/ethereum/benchmarking/blob/master/constantinople/analysis2.md) +- 📜 Ipsilon, [EVM benchmarks](https://github.com/ipsilon/evm-benchmarks) +- 📄 Ethereum Research, [Gas Price Table](https://ethresear.ch/t/gas-price-table/67) +- 📄 Ipsilon et al., [EVM384 Update 5: First Gas Cost Estimates](https://notes.ethereum.org/@poemm/evm384-update5#Memory-Manipulation-Cost) +- 📜 Geth, [Protocol Params](https://github.com/ethereum/go-ethereum/blob/master/params/protocol_params.go) +- 📄 Eth Research,[EIP-1380: Reduced gas cost for call to self](https://ethereum-magicians.org/t/eip-1380-reduced-gas-cost-for-call-to-self/1242) +- 📄 Michael K., [A Scalable Method to Analyze Gas Costs, Loops and Related Security Vulnerabilities on the Ethereum Virtual Machine](https://raw.githubusercontent.com/wiki/usyd-blockchain/vandal/pubs/MKong17.pdf) diff --git a/projects/grandine-rust-kzg-library.md b/projects/grandine-rust-kzg-library.md new file mode 100644 index 00000000..6078c915 --- /dev/null +++ b/projects/grandine-rust-kzg-library.md @@ -0,0 +1,67 @@ +# DAS-Specific Crytpography in Grandine's Rust-KZG + +*The implementation of PeerDAS-related cryptography (eip-7594) in Grandine's rust-kzg library.* + +## Motivation + +My motivation for this project stems from the intriguing discussions about Ethereum's scalability, sharding, **DAS**, and cryptography. + +**DAS**: (Data Availability Sampling) allows nodes to verify block data availability without downloading the entire block, reducing resource usage and increasing throughput. This is crucial for scaling Ethereum as it lessens the data burden on individual nodes. + +However, DAS-specific cryptography is not currently implemented in Grandine. I want to address this gap, as it will help me (and hopefully) others develop a better understanding of DAS and its cryptography. + +## Project description + +The project involves implementing essential DAS cryptographic functions in the Rust-kzg library for seamless integration into the Grandine client. + +With DAS, validators can be confident that the blob data is available and correctly committed. Each validator only needs to randomly sample a few data points and generate a proof, eliminating the need to check the entire blob. If any data is missing, it will be detected quickly, and the blob will be rejected. + +## Specification + +The consensus specs, specifically the [EIP-7594 polynomial commitments](https://github.com/ethereum/consensus-specs/blob/dev/specs/_features/eip7594/polynomial-commitments-sampling.md), outline the requirements. These are mainly divided into 3 functions: + +`compute_cells_and_kzg_proofs`: Which helps compute all the cell proofs for an extended blob. +`verify_cell_kzg_proof_batch`: Which verify that a set of cells belong to their corresponding commitments. +`recover_cells_and_kzg_proofs`: Which given atleast 50% of cells for a blob, can recover all the cells and proofs. + +## Roadmap + +- First, deep-diving into the consensus specs docs on eip7594, extending the polynomial commitments with functions required for DAS. +- Referencing existing DAS implementations like that done on c-kzg. +- Implement DAS in rust-kzg +- Develop and implement testing plan +- Ensure compatibility with Grandine and other rust implementations of the consensus client network + + +## Possible challenges + +The biggest challenge is the knowledge gap, which I am currently bridging. Due to limited resources and documentation, I will rely on the specs as my primary reference. Additionally, thorough testing with clients and extensive debugging will be crucial and a challenge. + +## Goal of the project + +By the end of EPF-5, success for this project will be defined by: + +Seamlessly integrating optimized DAS cryptographic functions into the Rust-kzg library, significantly enhancing DAS operations. +Providing comprehensive documentation and benchmarks to demonstrate these enhancements. + + +## Collaborators + +### Fellows + +[Ifeoluwa Oderinde](https://github.com/owanikin) +[VillageFarmer](https://github.com/DeluxeRaph) + +### Mentors + +[Saulius Grigaitis](https://github.com/sauliusgrigaitis) + +## Resources + +- [PeerDAS Specification](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) +- [Rust-KZG Library Repository](https://github.com/ethereum/rust-kzg) +- [Danksharding Overview](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Polynomial Commitments Research](https://research.polytope.technology/polynomial-commitments) +- [KZG Polynomial Commitments Explanation](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) +- [Elliptic Curve Pairings by Vitalik Buterin](https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627) +- [MSM](https://hackmd.io/@tazAymRSQCGXTUKkbh1BAg/Sk27liTW9) \ No newline at end of file diff --git a/projects/grandine-windows-support.md b/projects/grandine-windows-support.md new file mode 100644 index 00000000..2062e9a0 --- /dev/null +++ b/projects/grandine-windows-support.md @@ -0,0 +1,79 @@ +# Grandine Windows Support + +To support building Grandine on Windows. + +If there is a suitable environment or hardware support, I also consider to add the support to other unimplemented systems or architectures, such as MacOS, BSD, ARM, RISC-V. + +## Motivation + +Grandine's developers mainly use Linux, so Grandine is tested only on Linux. However, there are many Windows and MacOS users that would benefit from better support. Furthermore, another Ethereum consensus client [Lighthouse](https://github.com/sigp/lighthouse) already supports Windows. + +## Project description + +The goal of this project is to extend support for building Grandine, an Ethereum consensus client, on Windows. While Grandine has been primarily developed and tested on Linux, expanding its compatibility to Windows will make it more accessible to a broader range of developers and users. + +This project seeks to ensure that Windows users can build, run, and/or contribute to Grandine without platform-specific issues. With another Ethereum consensus client, Lighthouse, already supporting Windows, this project will make Grandine to catch up with other clients in terms of cross-OS support. + +## Specification + +1. Initial Assessment: + + + Analyze the current Grandine codebase and identify the areas that require modifications for Windows compatibility. + +2. Development Phase: + + + Modify the build system to support Windows. + +3. Testing and Validation: + + + Ensure all or main (if not all are suitable) tests Grandine can be passed on Windows. + + Fix or add some tests for Windows platform if necessary. + +4. Finalization and Documentation: + + + Set up a Windows-based CI pipeline to automate testing. + + Add documentation for Windows related building and usage(if needed). + + Announce and support the Windows-compatible release of Grandine. + +## Roadmap + +I personally plan to complete all the tasks within two months, but the detailed timeline will be updated when the project idea is progressing. + +- Initial Assessment +- Development Phase +- Testing and Validation +- Finalization and Documentation + +## Possible challenges + +- Dependencies and toolings Handling: + + Some dependencies and toolings may be tightly coupled with Linux, requiring alternative solutions or adjustments to work on Windows. + +- Codes, Tests and CI Pipeline Fixing: + + Codes, tests and CI pipeline fixing for Windows might involve overcoming challenges related to the understanding with current code base and platform or code specific issues. This step may be complex or simple, depending on the actual code that needs to be modified and the experience of the person doing it. + +- Support other unimplemented systems or architectures: + + The support to other unimplemented systems or architectures may be hard to add because of barriers to accessing these environments. + +## Goal of the project + +By the end of EPF-5, success for this project will be defined by: + +The goal of this project is to successfully build Grandine on Windows at least and enable a CI pipeline for testing and release building. + +## Collaborators + +### Fellows + +[MJZK](https://github.com/mjzk) + +### Mentors + +[Saulius Grigaitis](https://github.com/sauliusgrigaitis) + +## Resources + +- [Lighthouse, an Ethereum consensus client](https://github.com/sigp/lighthouse) \ No newline at end of file diff --git a/projects/opcode-implementations-test-coverage-code-analysis-and-stats-il-evm-nethermind.md b/projects/opcode-implementations-test-coverage-code-analysis-and-stats-il-evm-nethermind.md index 285247f5..96c617bb 100644 --- a/projects/opcode-implementations-test-coverage-code-analysis-and-stats-il-evm-nethermind.md +++ b/projects/opcode-implementations-test-coverage-code-analysis-and-stats-il-evm-nethermind.md @@ -2,12 +2,12 @@ ## Motivations -There are many intrinsic and extrinsic motivations to work on an EVM optimization project. +There are many intrinsic and extrinsic motivations to work on an EVM optimization project. 1. **Personal Motivations**: I want to learn more about optimization and lower-level programming in general, and having a project to work on helps me achieve that goal. 2. **Technical Motivations**: Enhancing the performance of the EVM through optimization can result in quicker transaction processing, which in turn enhances the scalability of Layer 1 by increasing its capacity to handle a higher number of transactions per second. -3. **Environmental Motivations**: Optimizations result in improved resource utilization, meaning that resources are used more efficiently for a given task. Alternatively, optimizations reduce the amount of resources required to perform the same task. This results in a more environmentally friendly node. Optimizing the EVM, which is a resource-intensive component of the node, would significantly improve the efficiency of hardware utilization. -4. **Economic motivations**: The operational cost of the node can be reduced through optimisation, which can potentially lead to lowering the gas price +3. **Environmental Motivations**: Optimizations result in improved resource utilization, meaning that resources are used more efficiently for a given task. Alternatively, optimizations reduce the amount of resources required to perform the same task. This results in a more environmentally friendly node. Optimizing the EVM, which is a resource-intensive component of the node, would significantly improve the efficiency of hardware utilization. +4. **Economic motivations**: The operational cost of the node can be reduced through optimization, which can potentially lead to lowering the gas price ## Project description @@ -15,42 +15,44 @@ The objective of my project is to align with the immediate goals of IL-EVM, an o My project tasks in order of priority can be broken down into the following: -1. Implement LOG0, LOG1, LOG2, LOG3, LOG4 opcodes for the IL-EVM compiler: - - This involves learning the underlying IL code generation library, Sigil. - - Writing a working implementation. - - Optimise the implementation -2. Increase Test Coverage : +1. Implement LOG0, LOG1, LOG2, LOG3, LOG4 opcodes for the IL-EVM compiler: + - This involves learning the underlying IL code generation library, Sigil. + - Writing a working implementation. + - Optimize the implementation +2. Generate statistics for groups of 2-7 op code patterns + - Decide on a temporal pattern mining algorithm or strategy + - Use a script to retrieve stats earlier + - Augment the code analyzer with the ability to generate statistics for frequent 2,3,4,5,6 & 7 Op Code patterns that are being executed + - Optimize the implementation +3. Increase Test Coverage : - Write tests, which verify the implementation of all the OpCodes that are compiled by IL-EVM - Debug and fix implementation bugs if found - Other tests TBD -3. Generate statistics for which smart contracts are being executed and how frequently. - - Add code that helps us query the node for the statistics. +4. Generate statistics for which smart contracts are being executed and how frequently. + - Add code that helps us query the node for the statistics. - Sync the node and get the statistics -4. Generate statistics for groups of 2-7 op code patterns - - Decide on a temporal pattern mining algorithm or strategy - - Augment the code analyzer with the ability to generate statistics for frequent 2,3,4,5,6 & 7 Op Code patterns that are being executed - - Optimise the implementation -5. Implementation for groups of 2-7 op code patterns - - Select the most frequently called 2-7 op code patterns from the earlier task and create specific implementations for them - - Optimise the specific implementations. +5. Implementation for groups of 2-7 op code patterns + - Select the most frequently called 2-7 op code patterns from the earlier task and create specific implementations for them + - Optimize the specific implementations. 6. Benchmarking (optional: if other tasks are completed) - ## Roadmap -week 6-8 — Implement the 5 LOG0 - LOG4 instructions -week 8-10 — Start working on tests that verify the IL-EVM implementation of the op codes | Wrap up LOG Implementation -week 10-12 — Start working on smart contract execution stats | Increase test coverage -week 12-14 — Start working on op code stats | Smart contract stats, node sync & get stats | Test coverage -week 14-16 — 2-7 Op code stats | 2-7 Op code implementations | Test coverage -week 16-18 — 2-7 Op code implementations | 2-7 Op code stats | Test coverage -week 18-20 — Wrap Up pending tasks | Benchmarking -week 20-21+ — Devcon EPF project presentation | Benchmarking | Wrap up pending tasks +| Week | Task1 (40%) | Task2 (40%) | Task3 (20%) | +| ----------- | -------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------- | +| Week 6-8 | Implement the 5 LOG0 - LOG4 instructions | | | +| Week 8-10 | Start work on op code stats | Wrap up LOG | | +| Week 10-12 | Op code stats | Start working on tests that verify the IL-EVM implementation of the op codes | | +| Week 12-14 | Op code stats : get 2-7op code stats with a script | Test coverage | start work on Smart contract stats | +| Week 14-16 | Write 2 opcode implementations | Smart contract stats & 2 - 7 Op code stats | Test Coverage | +| Week 16-18 | 2-7 Op code stats | 2-7 op code implementation | Test Coverage | +| Week 18-20 | 2-7 Op code implementations & stats | Sync & wrap up pending tasks | Benchmarking | +| Week 20-21+ | Wrap up pending tasks | Benchmarking | Devcon EPF project presentation | ## Possible challenges -1. Lack of dotnet knowledge and c# skills. -2. First project dealing with optimization. +1. Lack of dotnet knowledge and c# skills. +2. First project dealing with optimization. ## Goal of the project @@ -60,11 +62,10 @@ Completing most of the tasks outlined above and making good progress on any left ### Mentors -* Szymon Kulec ([@sooletz](https://github.com/Scooletz)) -* Ayman Bouchareb ([@Demuirgos](https://github.com/Demuirgos)) +- Szymon Kulec ([@sooletz](https://github.com/Scooletz)) +- Ayman Bouchareb ([@Demuirgos](https://github.com/Demuirgos)) ## Resources [IL-EVM Issues](https://github.com/NethermindEth/IL-EVM/issues) [Feature : IL-Evm Optimization](https://github.com/NethermindEth/nethermind/pull/6985) - diff --git a/projects/samba-a-java-portal-client.md b/projects/samba-a-java-portal-client.md new file mode 100644 index 00000000..1fcd391f --- /dev/null +++ b/projects/samba-a-java-portal-client.md @@ -0,0 +1,99 @@ +# Samba: A Simple Portal Client in Java + +Implementation of the Portal Client Specifications as a separate focused component that is easy to understand and contribute leverage by already available libraries that could be freely used to speed development or used as references. + +Code: https://github.com/meldsun0/samba + +## Motivation + +Increase client diversity by having another Portal Client in this case in Java. Today we have the following clients: https://www.ethportal.net/clients + +## Project description + +Implement a proof of concept of the Execution History Network sub-protocol in a way that could later be extended to include other sub-protocols. The idea is to have a module with all the necessary code for basic operations and another module for each sub-protocol with specific needs. + +## Specification + +- Define domain object of the protocol-wire +- Research DHT and implement it. +- Check existence of UTP libraries and incorporate to the design. +- SSZ implementation +- Incorporate Netty +- Implement the following operations: + - Joining the network + - Finding Nodes + - Neighborhood Gossip + - Storing content + - Finding content +- Expose API according to the Execution History Network. +- Define storage +- Add monitoring +- Add metrics +- Add structure building process. +- Add documentation and a wiki page +- Implement integration test and validate different test vectors. + +## Roadmap + +### August + +- Define domain object of the protocol-wire +- Research DHT and implement it. +- SSZ implementation +- Incorporate Netty + +### September and October + +- Implement the following operations: + - Joining the network + - Finding Nodes + - Neighborhood Gossip + - Storing content + - Finding content +- Check existence of UTP libraries and incorporate to the design. +- Implement integration tests and validate different test vectors. +- Define storage + +### November and December + +- Expose API according to the Execution History Network. +- Add monitoring +- Add metrics +- Add structure building process. +- Add documentation and a wiki page + +## Possible challenges + +- I will be building the proof of concept while learning a lot of different things at the same time. + + +### Learning + +- I will get deeper in new libraries and low level stuff around the protocol and how it works. +- I will get familiar with DHT, SSZ, UTP and the portal protocol itself. + + +## Goal of the project + +Have a fully working proof of concept of the Execution History Network sub-protocol that could be easily extended to incorporate the next sub-protocols. It should be a starting point to attract more collaborators that are willing to focus on Portal. + + +## Collaborators + +- Coordinate with another member of the EPF that is also working on a similar project. + +### Mentors + +- There are currently no mentors. + + +## Resources + +https://www.ethportal.net/ +https://github.com/ethereum/portal-network-specs +https://github.com/hyperledger/besu +https://github.com/ethereum/devp2 +https://github.com/Consensys/discovery +https://www.ethportal.net/clients + + diff --git a/projects/securing-grandines-performance.md b/projects/securing-grandines-performance.md index 6b20d7b8..3e6e68aa 100644 --- a/projects/securing-grandines-performance.md +++ b/projects/securing-grandines-performance.md @@ -131,13 +131,15 @@ Success for this project will be defined by: Are there any fellows working with you on this project? -* [Merci Boma Naps Nkari](https://github.com/bomanaps) +* [Mercy Boma Naps Nkari](https://github.com/bomanaps) +* [ Chaoyuan Peng](https://github.com/ret2happy) ### Mentors Which mentors are helping you with the project? * [Saulius Grigaitis](https://github.com/sauliusgrigaitis) +* [David Theodore](https://github.com/infosecual/) ## Resources diff --git a/projects/ssf-consensus-research.md b/projects/ssf-consensus-research.md new file mode 100644 index 00000000..01858fa2 --- /dev/null +++ b/projects/ssf-consensus-research.md @@ -0,0 +1,75 @@ +# SSF Research + +A novel consensus mechanism to achieve single slot finality with dynamic availability + +## Motivation + +Ethereum currently uses the Gasper protocol as its consensus mechanism. It is a complicated and intervowen mechanism between LMD-GHOST that provides availabilty and Casper-FFG which is responsible for finality. This creates several issues like reorg related attacks and longer finality times. Hence, there is an active effort towards Single Slot Finality. + +BFT mechanisms like Tendermint already provide single slot finality but using such protocols is an issue because they can halt if a supermajority of nodes are not online. Ethereum prioritises dynamic availabilty at all costs which makes existing designs like Tendermint infeasible for Ethereum. + +There has been research into this field and the development of a simple Single Slot Finality protocol by Francesco D’Amato and Luca Zanolini. The core idea behind their approach is to add another voting phase in the slot for fast finality. The main problem behind this design is the practical limitations of signature aggregation for millions of validators. + +Ethereum would not prefer an increase in the 32ETH staking requirement or the hardware requirements for running validators nodes. As a result, there has been more research on committee based design to address the issues of the SSF protocol. There have been some alternate designs like 3SF and Orbit SSF as well to evaluate exactly how a new consensus protocol for Ethereum should be implemented. + +## Project Description + +There has been limited research done on dynamically available protocols. Most of the research around SSF has been on modifications to LMD-GHOST based architectures. A major question in consensus research is to find a way to have dynamic availability that works well with committee based architectures. + +My goal for this project is to do research around novel consensus mechanism to acheive single slot finality with dynamic availabilty. This involves extensively researching existing architectures, understanding problems in those architectures, looking for novel designs like DAG based protocols and keeping mind the practical limitations of signature aggregation. + +### Why work on a novel mecahnism when there are several SSF protocols? +- LMD-GHOST like protocols would require committee based architectures that don't work well for dynamic availability +- there are other problems that arise in GHOST like designs that may not be present in a novel protocol +- prevents tunnel view designs and provides a broad set of protocols to evaluate from + +## Specification + +The goal of the project would be to come up with a novel design and possibly publish it as an academic research paper. To achieve this, I must first continue going through existing literature and familiarize with research already done in this field. After gaining a deep understanding of consensus protocols, I will begin drawing out new designs that can provide finality with economic security within a single slot while also preserving dynamic availability. + +There has been relatively little research on dynamically available protocols so there must also be work done in that direction that can complement a novel protocol. Mostly the work done during the fellowship will comprise of reading academic research on all related topics and trying to come with new architectures. Occasional discussions and brainstorming sessions with subject experts can be very helpful. + +## Roadmap + +The project would comprise of three primary stages: +- Familiarising with existing research +- Brainstorming novel mechanisms +- Discussions and peer review for insights + +The first stage would involve reading academic papers and resources along with discussions with the mentors to gain a comprehensive understanding of the landscape. The following concepts would require high attention: +- LMD-GHOST and Gasper +- Dynamic Availability +- Other families of protocols +- DAG based protocols +- Existing SSF research + +This stage can take up 1-2 months to complete. + +The second and third stages would have a lot of back and forth and take a few months. It is possible that the final research may not be finished in time for the fellowship but I have developed a deep interest in consensus research and would ensure continued work on this project untill a valuable result can be provided. + +## Possible challenges + +The primary challenge of this project is of course the fact that coming up with a novel consensus mechanism is a huge task without any certainty of completion. I hope that with sincere dedication and some guidance from mentors, a note-worthy result is obtained from this fellowship. + +If despite my best efforts, a consensus mechanism could not be finalised, the existing domain knowledge would benefit greatly in contributing to other forms of research and even specification and prototyping for existing architectures. + +## Project Goal + +The end goal of a succesful completion of the project would be an academic paper that outlines a novel consensus mechanism that can potentially be considered to replace GAsper in its current form. +This mechanism would have the following properties: +- Single Slot Finality +- Dynamic Availability +- Practically feasible with high economic security +- Does not increase validator requirements significantly +- No drastic increases in slot times from 12 seconds + +## Collaborators + +### Fellows +N/A + +### Mentors +Francesco D'Amato + +## Resources +TODO diff --git a/projects/ssz-benchmarking-and-optimization.md b/projects/ssz-benchmarking-and-optimization.md index b2af668e..ca3c8523 100644 --- a/projects/ssz-benchmarking-and-optimization.md +++ b/projects/ssz-benchmarking-and-optimization.md @@ -16,23 +16,39 @@ First, I want to work on a new rust implementation of szz, which will hopefully #### Lockstep Encoding and Hashing Part of the end-to-end flow of serialization objects on Ethereum also includes a step afterwards where the serialized output is then Merkleized (i.e. hashed into a tree). Currently, there are libraries for pretty [fast encoding/decoding](https://github.com/protolambda/eth2.0-ssz?tab=readme-ov-file#implementations) and [fast tree hashing](https://github.com/prysmaticlabs/hashtree/tree/main) separately. I have a hunch that there could be additional gains to be had by considering both steps as a whole, and I want to explore an implementation that considers this. -Keccak256 belongs to a class of hash functions called Sponge hash functions. These sponge functions work by having an absorption phase where an input of any length is split into r-sized chunks and XOR-ed into some state S. Finally, once all the input chunks are consumed, the state S is squeezed into an output of desired length.

 I want to try absorbing the input as it gets encoded, passing in r-sized chunks whenever they’re ready to be absorbed.

This way we can encode and hash in one pass! Speeding this up even by a little is meaningful since we can expect to do this operation many times over the lifetime of the protocol. +Keccak256 belongs to a class of hash functions called Sponge hash functions. These sponge functions work by having an absorption phase where an input of any length is split into r-sized chunks and XOR-ed into some state S. Finally, once all the input chunks are consumed, the state S is squeezed into an output of desired length. + +I want to try absorbing the input as it gets encoded, passing in r-sized chunks whenever they’re ready to be absorbed. + +This way we can encode and hash in one pass! Speeding this up even by a little is meaningful since we can expect to do this operation many times over the lifetime of the protocol. ### Benchmarking Suite -Second, I want to build a ssz benchmarking suite to accuaretly assess performance of various ssz implementations and visually display how they perform against each other. I want to add nice plots and useful reports as well as differential flamegraphs to compare where in the encoding/decoding steps are certain packages lagging behind others. +Second, I want to build a ssz benchmarking suite to accurately assess performance of various ssz implementations and visually display how they perform against each other. I want to add nice plots and useful reports as well as differential flamegraphs to compare where in the encoding/decoding steps are certain packages lagging behind others. ## Roadmap ### Phase 1 +In the first phase, I will take my time running tests and benchmarking the current ecosystem of ssz implementations. It's a slow way to start but it should be worthwhile and remove a lot of the guesswork in optimizing my own implementation. +I will setup a workflow for: +- Obtaining real `BeaconBlock` and `BeaconState` data from mainnnet using [ethdo](https://github.com/wealdtech/ethdo) and +- Using said data in current benchmarks, which currently use consensus spec tests +- Profiling execution and memory allocations using [dhat](https://crates.io/crates/dhat). Allocation is the only real bottleneck in serialization since there are no expensive computations being done otherwise. +A benchmarking suite will emerge from the frequent testing I'll be doing as I begin streamlining my methodology. As such, I won't focus on building this suite from the getgo, but rather attempt to find optimizations first and then "productionize" my benchmarking flow. ### Phase 2 +In this phase, I will begin performance bug-hunting in various ssz crates (mainly lighthouse's). I'm hoping to make meaningful contributions and submit some PRs. This phase will inform whether pushing changes upstream will be more than enough for optimizing rust ssz crates, or whether a redesign can achieve sizeable improvements here. + ### Phase 3 +I will begin working on my optimized ssz implementation, or productionizing the benchmarking suite. + ### Phase 4 +Polishing the optimized ssz implementation and benchmarking suite. + ## Possible challenges ### Flamegraphs Incompatible For Comparisons Between Crates @@ -55,13 +71,13 @@ Any tooling to synchronize lockstep encoding & hashing might introduce some over ## Collaborators -### Fellows +### Fellows No. ### Mentors -I don't have one yet, but I'd like to ask Potuz to mentor me. +I don't have one yet, but I'd like to ask Potuz or someone from Lighthouse to mentor me. ## Resources