Tracking the Pectra hard fork and any implications on the Marlin protocol, both as deployed and as in research or development.
While the Marlin protocol itself might be deployed on L2s, most Ethereum improvements eventually make it to L2s as well so the implications take this into account.
Pectra Meta EIP - EIP-7600: Hardfork Meta - Pectra
EIP-2537 - Precompile for BLS12-381 curve operations
Adds precompiles for BLS12-381 curves, used mainly in zk proofs and signature aggregation. It’s more secure than the commonly used BN254 curve (which already has a precompile) while still being performant enough for provers.
The signature aggregation side is important as well. It’s widely used across the space including the Ethereum consensus layer, ZCash, Filecoin (FVM), Chia, Algorand, etc.
Implications for Marlin:
Nothing too novel on the zk front, the tooling that is used currently might get updates, new tooling might pop up, etc.
On the aggregation front, it opens up better or even new cross-protocol communication and interoperability opportunities. It also makes it possible to include BLS signature aggregation in the Marlin protocol design itself (e.g. TEE committees, low-latency DA, etc).
There might be use cases and design opportunities around account abstraction that open up as well, especially when combined with EIP-7702.
EIP-2935 - Serve historical block hashes from state
Essentially extends the historical block hash window from 256 blocks to 8192 blocks.
Implications for Marlin:
Likely nothing. It amounts to more than a day on Ethereum, but probably only around an hour (which coincidentally is more or less the current history window on Ethereum) on an L2 like Arbitrum, hence seems of limited utility.
EIP-7685: General purpose execution layer requests
Creates a messaging channel from the execution layer to the consensus layer which lets the EL enforce some processing on the CL. It is an infrastructure EIP that exists to enable other EIPs by simply defining a basic messaging bus format.
Implications for Marlin:
Likely nothing.
EIP-6110: Supply validator deposits on chain
Execution layer blocks now contain validator deposit requests that match deposit events. Uses EIP-7685 above as the messaging channel. It lets the execution layer inject deposits directly into the CL rather than the consensus layer coming to consensus on what deposits to inject.
Implications for Marlin:
Likely nothing.
EIP-7002: Execution layer triggerable withdrawals
Withdrawal credentials (which ultimately own stake) can trigger withdrawals without the involvement of the active key (which does active validation). Uses EIP-7685 above as the messaging channel. It effectively enables secure delegation of validation responsibilities where the owner, which could be a contract, can unilaterally withdraw/exit the stake and void or reassign the validation responsibilities.
Implications for Marlin:
Likely nothing.
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
Increases the maximum stake per validator to 40 from 32 today. Minimum still remains 32. Also adds a consolidation mechanism to merge existing stake, which uses EIP-7685 above as the messaging channel.
Implications for Marlin:
Likely nothing.
EIP-7549: Move committee index outside Attestation
Changes internal CL structures to make it more efficient. More or less just implementation details.
Implications for Marlin:
Likely nothing.
EIP-7594: PeerDAS - Peer Data Availability Sampling
Provides DAS in Ethereum which should enable a large blobspace growth in the future.
Implications for Marlin:
Cheaper L2s in the future. Short-term impact on gas fees isn’t likely, blob gas fees are at rock bottom already.
EIP-7702: Set EOA account code
Provides DAS in Ethereum which should enable a large blobspace growth. Short-term impact on gas fees isn’t likely, blob gas fees are at rock bottom already.
Implications for Marlin:
Enables the usual account abstraction use cases for Marlin contracts without relying on other protocols. Beyond that, the protocol design could incorporate account abstraction at it’s core, for example, around managing enclave gas keys and such. Might also provide a way for directly incentivizing transaction inclusion for serverless gateways.
Access control might be another big design area where this is applicable. Different keys can have different privileges in terms of what they are allowed to do with an account which might be useful in the core protocol.
EIP-7692: EVM Object Format (EOFv1) Meta
Meta EIP which tracks EOF related EIPs (linked from within the above link).
The goal seems to be to have a well-defined contract bytecode format with better opcodes for control flow. In this sense, it’s similar to ELF or PE.
The primary lenses to look at this are
- if it makes specific use cases significantly cheaper in terms of gas
- if it makes entirely new use cases possible because of the sectioning
Implications for Marlin:
Most of the EIPs have no impact on Marlin except slightly more efficient contracts. Not a lot of new use cases either. IMO it feels like cleaning up technical debt in the EVM more than anything.
However, EOF seems to have the goal of removing gas observability from the EVM. This has severe consequences for our current contracts which use them for the following purposes.
- Process gas refunds based on real gas usage
- Restrict gas available to third party contract calls
It is unclear if workarounds exist for these use cases beyond calling from/out to legacy contracts. Even then, what the tooling would look like for such a hybrid deployment is a hard question.
Of course, existing deployments will continue to work as is until legacy contracts/opcodes are fully removed (if ever).