Meeting Time: Friday, August 15, 2025 at 14:00 UTC (60 minutes)
The meeting began with technical discussions about recording setup and connectivity issues before transitioning to main topics of sampling for PTC and payload commitments. The team explored various technical solutions for proposal boosting mechanisms, including bug fixes and handling of blocks and attestation, while also discussing changes to deadlines and cryptographic proposals. The conversation ended with discussions about removing data column sidecar code and setting a target release date for the 0-devnet by the end of October.
The meeting began with Potuz experiencing connectivity issues but managed to join. Akash mentioned assisting with the stream and confirmed readiness to start recording once the meeting began. Potuz noted the need to wait for additional participants, particularly Francesco, who was expected to join soon. Justin suggested creating a specific tag for Glancer, similar to one used for Free Soccer, and mentioned that Barnabas had been working on this. An unknown participant offered to create a tag as a moderator. The conversation ended with Potuz and Akash agreeing to start recording once Francesco arrived.
The team discussed two main topics: sampling for PTC and payload commitments. They agreed to sample validators by stake proportionally, with individual votes counting as one and a 50% threshold, though this might change for DA. Regarding payload commitments, they decided to remove the state root commitment while keeping the hash commitment, as committing to the full envelope could cause future issues with slot auctions. They also briefly touched on changes to proposal boosting to better handle rectification, which Francesco was scheduled to explain further.
Francesco discussed a bug in the proposal boost mechanism that allows an attacker to update proposer boost by presenting a block from a forgotten branch, even if it’s not a descendant of the finalized chain. While the issue is not critical as it requires both controlling a validator and managing a fictional proposer, Francesco suggested fixing it sooner rather than later, potentially coordinating a release with the first VPO after Fushaka. Potuz confirmed that Prysm is also affected by this bug but noted that it can only be triggered in a forked scenario, as Brisbane won’t attempt to sync such blocks.
Francesco and Potuz discussed handling blocks and attestation, focusing on preventing bugs rather than attacks. They agreed that the fix for handling blocks would be simple, involving just a few lines of code. Francesco raised concerns about the potential for late equivocations to trick builders, and they discussed the need to treat early equivocations in a specific way using a new deadline for the PTC. The conversation concluded with Francesco noting that further discussion about these issues might be needed offline.
Francesco explained a technical issue with proposal boosting and reorganization rules, where 40% weight rules could be exploited through weak equivocation blocks. He described a proposed solution involving a proposal relocation check and changes to tester behavior, where testers would punish proposers who violate the rules by refusing to attest to their proposals. Potuz clarified that testers would check for reorgs of weak heads without seeing equivocation, and would only attester if all statements were true.
Francesco explained the rules for applying proposer boosts, focusing on how they only apply to weak blocks from the previous slot when there are equivocations. He emphasized that this feature is meant to be non-optional to prevent potential attacks against proposers, particularly for clients like Fossil. Potuz noted that this implementation might force clients to use the honest reorg feature, while Stefan mentioned he would double-check if this was already implemented. The discussion also covered the importance of considering only early equivocations to protect proposers, ensuring they had the chance to see and respond to potential issues.
Francesco and Potuz discussed a bug fix for proposer boost, which Potuz noted was already implemented and could be backported to Phase 0. They debated whether the fix needed client coordination, with Justin suggesting it might be necessary for fork choice tests. The team also touched on enforcing non-zero bids for builders that are not self-building, which Potuz explained would simplify the code and address state changes during block synchronization.
The team discussed the handling of zero-value bids in the protocol, with Potuz explaining that while zero-value bids could be useful for off-protocol activities, the group agreed to enforce a non-zero value requirement for bids. They decided to add assertions to ensure bids have a non-zero value, which would make tests more robust and simplify tasks. The discussion also touched on the importance of maintaining zero-value bids for self-building and the potential for proposers to go off-protocol by pretending to self-build.
The team discussed implementing asymmetric payment penalties for builders whose payloads are not included, with Potuz proposing a system where builders would pay a different amount (e.g., 7 instead of 5) when their payload is not included. Bruno shared preliminary research findings indicating that a simple proportion of the bid might not be effective, and suggested exploring alternative approaches including penalties based on previous rounds of information and setting targets for when the free option should not be used. The team agreed that more experimentation and data collection was needed, particularly regarding PTC commitment timelines and the extent of the “free option” problem, before making any final decisions on implementation.
The team discussed implementing refund mechanisms for the free option problem in blockchains. Potuz explained that any function could be implemented as a refund mechanism, but emphasized the importance of maintaining a pure state transition function that doesn’t depend on previous data. Bruno asked about using missed slots as data points to define the function, and Potuz suggested adding necessary information to the Beacon State. The team debated the trade-offs between economic incentives for roll-ups and missing blocks due to the free option problem. Potuz concluded that the solution would involve finding a balance between these factors, but had no personal opinion on the matter.
The team discussed potential changes to deadlines and explored a new cryptographic proposal involving threshold encryption for payload reconstruction, though this concept was not previously discussed. Potuz explained a new inclusion proof system that avoids duplicate signature checks and allows for efficient blob synchronization, suggesting that this overhead might be unnecessary for EPBs due to guaranteed block synchronization. The team agreed to remove Merkle proofs and beacon block headers from column sidecars, simplifying the verification process while maintaining security through existing block commitments.
The team discussed removing data column sidecar code, with Terence and Francesco agreeing it would be good to remove it, though they noted timeline considerations for cell-based gossiping. Potuz raised concerns about KCG commitments no longer being included in beacon blocks, which could impact implementation complexity and P2P stack performance. The team agreed to target a 0-devnet release by the end of October, with Stefan emphasizing the importance of working on the master branch rather than creating a separate branch.
GJc*Z0mo)GJc*Z0mo)YouTube Stream Links: