the pectra megafork is coming and you're fading ethereum?
a shallow dive into every upgrade included in pectra, and what it means for ethereum 📚
TL;DR: simpler and faster
1/12
a shallow dive into every upgrade included in pectra, and what it means for ethereum 📚
TL;DR: simpler and faster
1/12
EVM Object Format: a whole set of sweeping changes to the EVM. it will:
- allow optimizers to find better optimizations (reducing gas costs for users)
- remove "stack too deep" errors (devs hate these errors so much it's so damn annoying)
- allow easier JIT compilation, speeding up the EVM more
- overall increased developer experience
2/12
- allow optimizers to find better optimizations (reducing gas costs for users)
- remove "stack too deep" errors (devs hate these errors so much it's so damn annoying)
- allow easier JIT compilation, speeding up the EVM more
- overall increased developer experience
2/12
PeerDAS: the next stage of data availability for ethereum. if EIP-4844 gave us this (see chart below), PeerDAS will bring even more throughput to blobs by sharding them across nodes.
EVEN LOWER gas fees for L2s 🔥
3/12
EVEN LOWER gas fees for L2s 🔥
3/12
BLS12-381 curve precompile: BLS signatures are a signature algorithm providing shorter signatures, no malleability, and aggregation
...wat? well,
- the lack of malleability means it'll be less of a pain in the ass for devs
- shorter signatures means lower gas costs
- you can add up all of the signatures of a whole group and prove that everyone signed (good for big multisigs)
BLS is used also in the consensus layer to aggregate validator signatures. this could be useful for proving that stuff on the execution layer!
4/12
...wat? well,
- the lack of malleability means it'll be less of a pain in the ass for devs
- shorter signatures means lower gas costs
- you can add up all of the signatures of a whole group and prove that everyone signed (good for big multisigs)
BLS is used also in the consensus layer to aggregate validator signatures. this could be useful for proving that stuff on the execution layer!
4/12
Historical block hashes in state: a crucial thing needed for statelessness (verifying an Ethereum transaction without needing all the blockchain data)
the overall push to statelessness means light clients become more secure and nodes become easier to run, increasing decentralization
5/12
the overall push to statelessness means light clients become more secure and nodes become easier to run, increasing decentralization
5/12
Shifting validator deposit inclusion to execution layer: back in the ancient times before the Merge, Mainnet and the Beacon Chain were separate.
they had to build their own complicated rube goldberg system based on proposer voting to track deposits on mainnet
now, validator deposits will be tracked by the execution layer instead, removing a lot of that complexity.
impatient solo staker? well, now the deposit delay is reduced (from ~12 hours to ~13 minutes). waow
6/12
they had to build their own complicated rube goldberg system based on proposer voting to track deposits on mainnet
now, validator deposits will be tracked by the execution layer instead, removing a lot of that complexity.
impatient solo staker? well, now the deposit delay is reduced (from ~12 hours to ~13 minutes). waow
6/12
Execution layer validator exits: smart contracts can now force-withdraw funds from validators on the consensus layer.
this means decentralized staking protocols like rocketpool can now force their validators to withdraw when necessary, making them more resilient
7/12
this means decentralized staking protocols like rocketpool can now force their validators to withdraw when necessary, making them more resilient
7/12
Increase MAX_EFFECTIVE_BALANCE: there's a lot of big validator companies. they run a shitload of validators.
rn it makes literally 0 sense to force them to split up their stakes into little chunks! it doesn't make ethereum more secure and it puts a toll on the network
changing the cap from 32 ETH to 2048 ETH per validator means they can consolidate into less validators, reducing the load
smaller validators also win: they now get compounding and can stake in more flexible increments (32 ETH, 40 ETH 69 ETH...)
8/12
rn it makes literally 0 sense to force them to split up their stakes into little chunks! it doesn't make ethereum more secure and it puts a toll on the network
changing the cap from 32 ETH to 2048 ETH per validator means they can consolidate into less validators, reducing the load
smaller validators also win: they now get compounding and can stake in more flexible increments (32 ETH, 40 ETH 69 ETH...)
8/12
Move committee index outside Attestation: bit of a technical one, but here goes.
ethereum consensus works by voting: proposers vote on the block history to achieve consensus.
on a network with 262,144 indexes, you have to verify 1366 attestations to reach a 2/3 threshold.
removing the commitee index from the message means now you only need 22 attestations, a factor of 62.
this is especially good for ZK light clients trying to prove consensus!
9/12
ethereum consensus works by voting: proposers vote on the block history to achieve consensus.
on a network with 262,144 indexes, you have to verify 1366 attestations to reach a 2/3 threshold.
removing the commitee index from the message means now you only need 22 attestations, a factor of 62.
this is especially good for ZK light clients trying to prove consensus!
9/12
General purpose execution layer requests: there are some smart contract-controlled validators that want to send more messages to the consensus layer.
this proposal provides a barebones structure for future proposals to be built on top, allowing smart contracts in the future to do loads of other stuff with their validators!
10/12
this proposal provides a barebones structure for future proposals to be built on top, allowing smart contracts in the future to do loads of other stuff with their validators!
10/12
Set EOA account code: a way for existing wallets to get some of the powers of smart contracts.
right now, wallets can't:
- send batched transactions
- sponsor other wallets' transactions
- create sub-keys with limits
- etc etc
but now they can, isn't that cool? imagine setting up a trading bot under your account and only giving it access to certain protocols, or doing an approval and swap, all in the same transaction!
now it does pose some security risks, but in practice you shouldn't be authorizing random contracts to take over your whole account
another goodie: it's easily forwards-compatible with future account abstraction proposals, meaning no gross incompatible technical debt
11/12
right now, wallets can't:
- send batched transactions
- sponsor other wallets' transactions
- create sub-keys with limits
- etc etc
but now they can, isn't that cool? imagine setting up a trading bot under your account and only giving it access to certain protocols, or doing an approval and swap, all in the same transaction!
now it does pose some security risks, but in practice you shouldn't be authorizing random contracts to take over your whole account
another goodie: it's easily forwards-compatible with future account abstraction proposals, meaning no gross incompatible technical debt
11/12
aaand that's a wrap! all the EIPs were covered (EOF was consolidated all into one, because otherwise the thread would get boring fast)
hoping this brings you joy in your life
buy more eth and have a good day!
12/12
hoping this brings you joy in your life
buy more eth and have a good day!
12/12
• • •
Missing some Tweet in this thread? You can try to
force a refresh
