nixorokish: app developers can test Glamsterdam on devnet-7 before Sepolia/Hoodi
21:28.
ACDE #241 and the Glamsterdam timeline
EIP-8081: list EIP-7862 delayed state root as PFI
(nixorokish), submitted and merged; EIP-8081: propose EIP-8298 for inclusion, merged; EIP-8081: add EIP-8304 as PFI (zsfelfoldi), submitted.
EIP-8081: propose EIP-8298 for inclusion
EIP-8081: list EIP-7862 delayed state root as PFI (nixorokish), submitted and merged; EIP-8081: propose EIP-8298 for inclusion, merged; EIP-8081: add EIP-8304 as PFI (zsfelfoldi), submitted.
EIP-8081: add EIP-8304 as PFI
EIP-8081: list EIP-7862 delayed state root as PFI (nixorokish), submitted and merged; EIP-8081: propose EIP-8298 for inclusion, merged; EIP-8081: add EIP-8304 as PFI (zsfelfoldi), submitted.
New EIP: Partial Execution Payload Commitments
(nerolation), submitted; per Ethereal news #31 it is numbered EIP-8341. It is an alternative to EIP-7862 that avoids a delayed state root on the execution layer while still giving builders and provers more time.
EIP-8141 spec clarifications
pin the SECP256K1 signature encoding (recovery id and low-s)
Svlachakis submitted several clarifications at once: pin the SECP256K1 signature encoding (recovery id and low-s), since `validate_signature` passed signatures straight into `ecrecover` without defining `v` or requiring a canonical `s`; note that execution approval authorizes all subsequent sender frames, because `sender_approved` is a transaction-scoped flag, not scoped to a frame or target; specify EIP-3529 storage refund accounting for frames; apply the EIP-7623 calldata floor to frame and signature data, since the transaction's gas was never floored; define the Receipts message encoding for frame transaction receipts; and the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY.
note that execution approval authorizes all subsequent sender frames
Svlachakis submitted several clarifications at once: pin the SECP256K1 signature encoding (recovery id and low-s), since `validate_signature` passed signatures straight into `ecrecover` without defining `v` or requiring a canonical `s`; note that execution approval authorizes all subsequent sender frames, because `sender_approved` is a transaction-scoped flag, not scoped to a frame or target; specify EIP-3529 storage refund accounting for frames; apply the EIP-7623 calldata floor to frame and signature data, since the transaction's gas was never floored; define the Receipts message encoding for frame transaction receipts; and the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY.
specify EIP-3529 storage refund accounting for frames
Svlachakis submitted several clarifications at once: pin the SECP256K1 signature encoding (recovery id and low-s), since `validate_signature` passed signatures straight into `ecrecover` without defining `v` or requiring a canonical `s`; note that execution approval authorizes all subsequent sender frames, because `sender_approved` is a transaction-scoped flag, not scoped to a frame or target; specify EIP-3529 storage refund accounting for frames; apply the EIP-7623 calldata floor to frame and signature data, since the transaction's gas was never floored; define the Receipts message encoding for frame transaction receipts; and the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY.
apply the EIP-7623 calldata floor to frame and signature data
Svlachakis submitted several clarifications at once: pin the SECP256K1 signature encoding (recovery id and low-s), since `validate_signature` passed signatures straight into `ecrecover` without defining `v` or requiring a canonical `s`; note that execution approval authorizes all subsequent sender frames, because `sender_approved` is a transaction-scoped flag, not scoped to a frame or target; specify EIP-3529 storage refund accounting for frames; apply the EIP-7623 calldata floor to frame and signature data, since the transaction's gas was never floored; define the Receipts message encoding for frame transaction receipts; and the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY.
define the Receipts message encoding for frame transaction receipts
Svlachakis submitted several clarifications at once: pin the SECP256K1 signature encoding (recovery id and low-s), since `validate_signature` passed signatures straight into `ecrecover` without defining `v` or requiring a canonical `s`; note that execution approval authorizes all subsequent sender frames, because `sender_approved` is a transaction-scoped flag, not scoped to a frame or target; specify EIP-3529 storage refund accounting for frames; apply the EIP-7623 calldata floor to frame and signature data, since the transaction's gas was never floored; define the Receipts message encoding for frame transaction receipts; and the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY.
the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY
Svlachakis submitted several clarifications at once: pin the SECP256K1 signature encoding (recovery id and low-s), since `validate_signature` passed signatures straight into `ecrecover` without defining `v` or requiring a canonical `s`; note that execution approval authorizes all subsequent sender frames, because `sender_approved` is a transaction-scoped flag, not scoped to a frame or target; specify EIP-3529 storage refund accounting for frames; apply the EIP-7623 calldata floor to frame and signature data, since the transaction's gas was never floored; define the Receipts message encoding for frame transaction receipts; and the stack operand order for FRAMEDATALOAD/FRAMEDATACOPY.
Bounding the signatures list with MAX_SIGNATURES
Was also proposed: `signatures` is the only variable-length list in the frame transaction family without an explicit bound, limited only implicitly by `tx_gas_limit`, which allows thousands of entries.
8130 metadata and confirmation
ERC-8340: Transaction Metadata Encoding
(chunter-cb), submitted, with forum discussion at 06:08. EIP-8130's AA transaction has an optional opaque `metadata` field; this ERC defines it as a deterministic CBOR value (memo, commitment digest, a map of reserved keys, or an array of these), with keys compatible with ERC-8021 schema 2. Any value can be replaced by a salted commitment for selective disclosure, and the ERC specifies an offchain proof package and ERC-5792 integration.
forum discussion
ERC-8340: Transaction Metadata Encoding (chunter-cb), submitted, with forum discussion at 06:08. EIP-8130's AA transaction has an optional opaque `metadata` field; this ERC defines it as a deterministic CBOR value (memo, commitment digest, a map of reserved keys, or an array of these), with keys compatible with ERC-8021 schema 2. Any value can be replaced by a salted commitment for selective disclosure, and the ERC specifies an offchain proof package and ERC-5792 integration.
Francesco is joining
Ethlabs announced that Francesco is joining, 19:59; per Ethereal news #31 he is moving from the EF. fradamt: the goal is fast finality asap, but fast confirmation is already here, giving a very strong confirmation in seconds, 98% faster than finality, now on Glamsterdam devnets, 21:21. Ben Edgington: confirmation is for peacetime, finality is for wartime, 21:36.
fradamt: the goal is fast finality asap, but fast confirmation is already here, giving a very strong confirmation in seconds, 98% faster than finality, now on Glamsterdam devnets
Ethlabs announced that Francesco is joining, 19:59; per Ethereal news #31 he is moving from the EF. fradamt: the goal is fast finality asap, but fast confirmation is already here, giving a very strong confirmation in seconds, 98% faster than finality, now on Glamsterdam devnets, 21:21. Ben Edgington: confirmation is for peacetime, finality is for wartime, 21:36.
Ben Edgington: confirmation is for peacetime, finality is for wartime
Ethlabs announced that Francesco is joining, 19:59; per Ethereal news #31 he is moving from the EF. fradamt: the goal is fast finality asap, but fast confirmation is already here, giving a very strong confirmation in seconds, 98% faster than finality, now on Glamsterdam devnets, 21:21. Ben Edgington: confirmation is for peacetime, finality is for wartime, 21:36.
Other updates
Nethermind: Stellar Private Payments, a shielded pool with KYC gating, freezing and audit disclosure inside the protocol
19:11, live on testnet.
Eli Ben-Sasson: DeFi privacy is not yes or no but a range
20:00.
EIP-7723: update the upgrade Meta EIP handling process
Merged, clarifying the DFI process.
ACDT #88 agenda
11:05.
Community
Barnabé: on kubimensah's piece about MEV, allocation and user security
16:03.