Merge branch 'master' into master

notes/arkenan.md

@@ -10,12 +10,14 @@ I'm joined by Martin Paulucci, Tomás Grüner and Paul-Henry Kajfasz in building
 
 ## Update links:
 
-- [Week 2](https://hackmd.io/@ft-mkp6jQ5egGIMYqmACGA/SJBdp9So2)
-- [Week 3](https://hackmd.io/6x43ZTkmSL2YKxdZe5E9KQ)
-- [Week 5](https://hackmd.io/ElVH25hKTuKxMjMMrFRbNQ)
-- [Week 6](https://hackmd.io/Upv0iycJQAyDjcB2CF9q1Q)
-- [Week 7](https://hackmd.io/WiTgsZqWTlSOXP8WX6kPkA)
-- [Week 8](https://hackmd.io/4ho8pWYRSpa4QKkAi0wJ-w)
-- [Week 9](https://hackmd.io/VS1ZoNvXQQi60g65vxlW6A)
-- [Week 10](https://hackmd.io/zDJ6OTARQMeT9ZMlgN_GYw)
-- [Week 11](https://hackmd.io/Apee8YsqRBa9c9NyRX75zw)
+- [Week 3](https://hackmd.io/@ft-mkp6jQ5egGIMYqmACGA/SJBdp9So2)
+- [Week 4](https://hackmd.io/6x43ZTkmSL2YKxdZe5E9KQ)
+- [Week 6](https://hackmd.io/ElVH25hKTuKxMjMMrFRbNQ)
+- [Week 7](https://hackmd.io/Upv0iycJQAyDjcB2CF9q1Q)
+- [Week 8](https://hackmd.io/WiTgsZqWTlSOXP8WX6kPkA)
+- [Week 9](https://hackmd.io/4ho8pWYRSpa4QKkAi0wJ-w)
+- [Week 10](https://hackmd.io/VS1ZoNvXQQi60g65vxlW6A)
+- [Week 11](https://hackmd.io/zDJ6OTARQMeT9ZMlgN_GYw)
+- [Week 12](https://hackmd.io/Apee8YsqRBa9c9NyRX75zw)
+- [Week 14](https://hackmd.io/Apee8YsqRBa9c9NyRX75zw)
+- [Week 15](https://hackmd.io/9TKEKvptRwm8nEksuAkmPg)

notes/danielrachi/danielrachi.md

@@ -8,4 +8,4 @@
 - [Trin Architecture](https://hackmd.io/@danielrachi/r1mn3fx3n)
 - [Flashbots Architecture](https://hackmd.io/@danielrachi/HJxXjUwC2)
 - [Lighthouse Startup](https://hackmd.io/@danielrachi/S1u2Veflp)
-
+- [Engine API](https://hackmd.io/@danielrachi/engine_api)

notes/eenagy.md

@@ -33,4 +33,18 @@
 ### Week 10 - 11
 
 [Debcrafter documentation](https://hackmd.io/@eenagy/H1j6sV4gp)
-[Actual debcrafter documentation](https://hackmd.io/AMlJV4gQQQe1T_KJU51yog) 
+[Actual debcrafter documentation](https://hackmd.io/AMlJV4gQQQe1T_KJU51yog)
+
+### Week 12-15
+
+[Build system](https://hackmd.io/@eenagy/Hkrnfaem6)
+
+### Week 13-14
+
+[Package building](https://hackmd.io/@eenagy/ry7KeR7zT)
+[Eth-deb repo](https://github.com/eenagy/eth-deb)
+
+### Final update
+
+Nothing here, yet.
+[Final update]()

notes/kaydenML.md

@@ -31,25 +31,22 @@ I’m interested on working hard on Glados because I believe that it suits my sk
 - [Week 10](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/S1iIpQ61a)
 - [Week 11](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/SJK8N0Sga)
 - [Week 12](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/S1KdrvgWT)
+- [Week 13](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/rkobPsYWp)
+- [Week 14](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/H10DvymMa)
+- [Week 15](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/H1aQpKhM6)
+- [Week 16](https://hackmd.io/@v8QYUEqNQI-q90vwuMaJaw/SygvXIH7T)
 
-- After my graph is implemented the next task I'm going to be tackling is implementing a Nav bar for Glados.
+### Working on Next and Continuing to work on
 
+- Now that I have finished my second graph and finished the Navbar implementation, going into these last few weeks of the cohort I'm going to be working on implementing my third graph of the program.
 
-- After Piper reviewed my segmental control PR he felt it would be better to just implement it in bootstrap instead of me using my javascript because it's not trivial to maintain or test over the longevity of a project. Here's the bootstrap of how I would go about approaching this sort of thing.
-    - https://getbootstrap.com/docs/5.2/utilities/visibility/
-
-
-- Continue UI improvements where needed.
-
-
-- Look into more ethereum/portal/network resources to increase my knowledge of ethereum, portal network and Glados over all.
 
+- Continuing to write and refine my Project Presentation and practise my project presentation
 
-- Writing Tests for bugs that I may find or may come up along the way.
 
+- Continue UI improvements where needed.
 
-- begin implementing my third graph.
-
+- 
 ## Links And Resources
 
 **Glados Github:**
@@ -83,4 +80,8 @@ I’m interested on working hard on Glados because I believe that it suits my sk
 
 - https://github.com/ethereum/glados/pull/136
 
-- https://github.com/ethereum/glados/pull/165
+- https://github.com/ethereum/glados/pull/165
+
+- https://github.com/ethereum/glados/pull/188
+
+- https://github.com/ethereum/glados/pull/176

notes/mohas.md

@@ -30,6 +30,7 @@ I think the idea submited by mentor Frederik is a great idea , i'm very interest
 - [Week 10](https://hackmd.io/@Mohas/SJ3sQQsy6)
 - [Week 11](https://hackmd.io/@Mohas/H1BCo7ugp)
 - [Week 12](https://hackmd.io/@Mohas/HJhrLqxZ6)
+- [Week 13 + 14](https://hackmd.io/@Mohas/SJ9wqp7za)
 
 ## Recommandations / informations / tips
 

projects/EIP-x_effcient_stateless_execution.md → projects/EIP-x-efficient-stateless-execution.md

@@ -1,54 +1,61 @@
 
-##EIP-x 
- Stateless LC That Consumes ZKP 
+# EIP-x 
 
+Stateless Light Client (LC) That Consumes ZKP 
 
 ## Motivation
-In the dynamic landscape of blockchain technology, addressing the limitations of traditional light clients is paramount for the widespread adoption and efficient functioning of the Ethereum network. Conventionally, light clients have burdened full nodes by incrementally requesting block state, posing challenges to network scalability. The integration of Verkle trees has provided a significant step forward, facilitating smoother transitions for lightweight clients between blocks. However, a lingering concern lies in the assurance of accurate state root confirmation, highlighting the need for further advancements. The inability of light clients to handle zero-knowledge proofs compounds the complexity. Moreover, portal nodes, a crucial bridge in this ecosystem, face the challenge of effectively prioritizing essential information for streamlined and swift stateless light client operations. Overcoming these obstacles is central to empowering light clients and optimizing the Ethereum network for a seamless and inclusive decentralized future.
+In the dynamic landscape of blockchain technology, addressing the limitations of traditional light clients is paramount for the widespread adoption and efficient functioning of the Ethereum network. Conventionally, light clients have burdened full nodes by incrementally requesting block state, posing challenges to network scalability. The integration of Verkle trees has provided a significant step forward, facilitating smoother transitions for lightweight clients between blocks. However, a lingering concern lies in the assurance of accurate state root confirmation, highlighting the need for further advancements. The inability of light clients to handle zero-knowledge proofs (ZKPs) compounds the complexity. Moreover, portal nodes, a crucial bridge in this ecosystem, face the challenge of effectively prioritizing essential information for streamlined and swift stateless light client operations. Overcoming these obstacles is central to empowering light clients and optimizing the Ethereum network for a seamless and inclusive decentralized future.
 
 # Project Description
 Project Description:
 
-Our endeavor,EIP-x, embodies a thoughtful exploration of Helios light clients' capabilities to transform the way we access and validate blockchain data. At its core, the State Provider entity operates as a conduit to access the most recent block state of a block in a manner that fosters trust without reliance on intermediaries. This process entails the extraction of a cryptographic witness, which in turn serves as the foundation for the creation of zero-knowledge proofs (ZKPs). These ZKPs, integral to our approach, are subsequently disseminated to all participating lightweight client (LC) nodes across the network.
+Our endeavor, EIP-x, embodies a thoughtful exploration of Helios light clients' capabilities to transform the way we access and validate blockchain data. At its core, the State Provider entity operates as a conduit to access the most recent block state of a block in a manner that fosters trust without reliance on intermediaries. This process entails the extraction of a cryptographic witness, which in turn serves as the foundation for the creation of zero-knowledge proofs (ZKPs). These ZKPs, integral to our approach, are subsequently disseminated to all participating lightweight client (LC) nodes across the network.
 
 In the context of the Portal Network, Our approach centers on empowering Trin clients to efficiently incorporate ZKPs into their operations, coupled with the implementation of a dedicated cache mechanism. This cache mechanism offers the flexibility to select portions of proofs that align with individual requirements, thereby optimizing the overall performance.
 
-The collaboration between the State Provider and stateless LC consuming zkp within the Portal Network establishes a dynamic partnership, fostering robust data validation. In cases where cache-related inconsistencies or failures may surface, participants can confidently resort to the ZK proofs of the latest state. These cryptographic proofs serve as a dependable means to verify the integrity of cached data fragments, reinforcing trust and reliability within the system. The State Provider project endeavors to significantly enhance the efficiency, security, and accessibility of blockchain data for stateless light clients, contributing to the ongoing evolution of decentralized technologies.
+The collaboration between the State Provider and stateless LC consuming ZKP within the Portal Network establishes a dynamic partnership, fostering robust data validation. In cases where cache-related inconsistencies or failures may surface, participants can confidently resort to the ZK proofs of the latest state. These cryptographic proofs serve as a dependable means to verify the integrity of cached data fragments, reinforcing trust and reliability within the system. The State Provider project endeavors to significantly enhance the efficiency, security, and accessibility of blockchain data for stateless light clients, contributing to the ongoing evolution of decentralized technologies.
 
 ## Roadmap
-POC of the eniter EIP-X 
-testing 
-evovling the implement5ation to improve the capabilites 
+- POC of the entire EIP-X
+- Testing
+- Evolving the implementation to improve the capabilites
 
 
 ## Goal of the project
 
-##Important Use-case1: 
+### Important Use-case 1
+
 Being stateless Node for Flashbot
-Problem: 
-Flashbots' 0 gas price transactions, paying miners via smart contracts, risk a Denial-of-Service (DOS) vector. Miners must simulate transactions to assess profitability, making them vulnerable to spam attacks without cost. This differs from regular Ethereum transactions with inherent fees and node-based mempool filtering.
 
-Potential Solution with EIP-X: Stateless clients, which can consume  zkps, have the potential to mitigate the problem above
+#### Problem
+
+Flashbots' 0 gas price transactions, which pay miners via smart contracts, face the risk of a Denial-of-Service (DOS) vector. Miners must simulate transactions to assess profitability, making them vulnerable to spam attacks without cost. This differs from regular Ethereum transactions with inherent fees and node-based mempool filtering.
+
+#### Potential Solution
 
-1. Efficient Profitability Validation: They enable miners to determine transaction profitability using zkps, reducing resource consumption.Since zkps can verify transaction validity without executing them, miners can filter out spammy transactions more effectively, as they can identify them without the need for costly simulation.
+Use EIP-X Stateless clients, which can consume ZKPs, offers the potential to mitigate the problem above as follows:
 
-2. Protection from Spam:Stateless nodes can defend against spam by verifying transaction validity without execution, enhancing spam filtering.
+1. Efficient Profitability Validation: They enable miners to determine transaction profitability using ZKPs, reducing resource consumption.Since ZKPs can verify transaction validity without executing them, miners can filter out spammy transactions more effectively, as they can identify them without the need for costly simulation.
+
+2. Protection from Spam: Stateless nodes can defend against spam by verifying transaction validity without execution, enhancing spam filtering.
 
 3. Privacy and Permissionlessness: They maintain privacy by validating transactions without revealing sensitive data and achieve permissionlessness in Flashbots transactions.
 
-##Important Use-case 2: 
+### Important Use-case 2
+
 Being stateless Relayer for Flashbot
 
-Problem: 
-In the Flashbot ecosystem, the absence of costs for failed bids allows for potential network spam via invalid bundles, leading to denial of service (DoS) threats. Malicious actors can send miners invalid bundles, causing wasted computational resources. Relayers are crucial for DoS mitigation. Flashbots' mev-relay addresses this, but trust-based concerns exist. 
+#### Problem
+
+In the Flashbot ecosystem, the absence of costs for failed bids allows for potential network spam via invalid bundles, leading to denial of service (DoS) threats. Malicious actors can send miners invalid bundles, causing wasted computational resources. Relayers are crucial for DoS mitigation. Flashbots' Maximal Extractable Value (MEV)-relay addresses this, but trust-based concerns exist. 
 
 
-Solution: 
-stateless light client with ZKPs to efficiently verify bundle validity and payment status, preventing invalid bundles from reaching miners and enhancing network security. Our EIP-x can solve Flashbot in three ways:
+#### Solution
+Stateless light client with ZKPs to efficiently verify bundle validity and payment status, preventing invalid bundles from reaching miners and enhancing network security. Our EIP-x can solve the above Flashbot problem in three ways:
 
-1- according to the flow, relayer consumes the Ethereum state(what we provide is a fir here, zkp of last block state) 
-2- we can provide a zk of payment proof by bundlers if they have payed to the  miner : 1- it will reduce resource usage to compute if bundler has paid 
-3-preventing Relayers to have full access to the contents of all bundles and could easily reorder or steal or censor them!
+1. According to the flow, MEV-relayer consumes the Ethereum state (what we provide is a first here, ZKP of latest block state) 
+2. We can provide a ZK of payment proof by bundlers if they have paid to the miner. It will reduce resource usage to compute if bundler has paid 
+3. Preventing Relayers from having full access to the contents of all bundles, as they could easily reorder or steal or censor them!
 
 
 

projects/LambdaClass-Ethereum-Elixir-Consensus-Client.md

@@ -166,6 +166,7 @@ Our benchmark for success is clear and ambitious. By the culmination of the fell
 In github username alphabetical order.
 
 - Tomás Arjovsky (@arkenan)
+- Godspower Eze (@Godspower-Eze)
 - Tomás Grüner (@megaredhand)
 - Martín Paulucci (@mpaulucci)
 - Paul-Henry Kajfasz (@phklive)

projects/mev-rs.md

@@ -0,0 +1,58 @@
+# EPF Project Proposal - chirag-bgh
+
+## Project: reth based relay
+
+A relay for the mev-boost network built on top of reth execution client.
+
+## Motivation
+
+Apart from implementation diversity, performance improvements building on top of reth gives ability to extend on reth while receiving upstream changes. Traditionally, forks of geth (such as flashbot’s builder) would fork out a couple day’s worth of engineering time just to merge in upstream changes from Geth. With reth that is completely eliminated.
+
+## Specification
+
+`mev-relay-rs`  
+
+A relay performs two high-level functions: supports the `mev-boost` auction for proposers and `mev-boost` auction for builders
+
+#### Auction for proposers
+
+This half of the design corresponds to implementing the [builder-specs](https://github.com/ethereum/builder-specs) APIs.
+
+##### Components:
+
+- Validator registrations
+- Beacon Block Processor
+- Auctioneer
+
+#### Auction for builder
+
+This half of the design corresponds to implementing the [relay-specs](https://flashbots.github.io/relay-specs/) APIs.
+
+##### Components: 
+- Proposer scheduler
+- Builder registry
+- Builder submissions manager
+- Payload Validator 
+    - eth_validatePayload
+    - EOB payment verification
+
+
+### Payload validator 
+
+Bids recieved from buidlers must be validated before forwarding it to the proposer. This is performed using reth as the local EL client. For this a custom API endpoint `eth_validatePayload` is installed to serve the block validaiton and proposer payment verification.
+
+### Future work: 
+- Support optimistic relay
+
+### Fellows 
+
+- [chirag-bgh](https://github.com/chirag-bgh)
+
+### Mentors
+
+- [Alex Stokes](https://github.com/ralexstokes)
+
+### Resources
+
+[mev-rs](https://github.com/ralexstokes/mev-rs)\
+[reth-based-relay issue description](https://github.com/ralexstokes/mev-rs/issues/129)