YouTube recording available: https://youtu.be/wwlsrljZr84
No summary overview available
Thomas provided updates on the upcoming Fossil session during the Berlin IETF in June, including confirmed speakers and topics. He mentioned progress on the interaction between fossil delayed execution and block access lists, which simplifies static validation of blocks. Thomas also highlighted the local node favoring delta to the scaling roadmap and encouraged participants to engage in discussions on the future of fossil and its interaction with EIPs. Kubi then presented on relay inclusion lists, thanking everyone for their feedback and encouraging further discussion on the EIP research page.
Kubi presented the goals and design of relay inclusion lists, emphasizing their immediate impact on censorship resistance without introducing new protocol complexities or trust assumptions. The design aims to prepare the block production pipeline for future in-protocol inclusion, ensuring sustainability by preserving relay competitiveness and block value. Kubi outlined the three-step process: setup, inclusion list creation, and validation, highlighting the importance of deterministic inclusion rules and API endpoints for builders.
Kubi presented two options for calculating inclusion scores: a multiplicative approach (option 1) and a normalized additive approach (option 2). Option 1 multiplies waiting time and priority fee, while option 2 adds them after normalization. Both methods compare transactions and adjust scores based on total gas paid or transaction byte size. Kubi noted that option 1 is leaner and more elegant, but both approaches are appropriate. The team aims to finalize the decision with stakeholders. Kubi also discussed the importance of sizing the inclusion list to avoid negatively impacting block value, which decreases with increased latency.
Kubi presented on relay inclusion lists, explaining how they provide an advantage over proposal-driven inclusion lists by not being constrained by proposal bandwidth, allowing for larger sizes as relay adoption increases. He outlined future directions including multi-relay inclusion lists for improved censorship resistance and reduced redundancy, as well as blob type transactions and larger relay inclusion lists. The discussion addressed concerns about potential centralization risks and interaction with proposal build item separation, with Kubi clarifying that the design is built to fit the current PBS supply chain. The group also discussed transaction size considerations and the potential deprecation of relay inclusion lists once included in the protocol.
The team discussed progress on implementation and testing of clients. Jacob reported on PRs for execution specs and test fixtures, emphasizing the need to merge the IP-related PR soon. Jihoon shared updates on consensus specs and tests, aiming for the next release in two weeks. The group also addressed a discrepancy between the overview picture and text in the EIP, which Jochem Brouwer pointed out. Mercy mentioned working on the frontend of a transaction visualizer. The team agreed to follow up with the Lighthouse client team separately.