@bharat_usd EIP-4844 was a win, it slashed L2 fees and drove real adoption. Token prices don't change that. As Ethereum scales, people will understand that ETH is money.
@dumbnamenumbers I agree that forcing aggregation isn't great.
But we also shouldn't require people to build every pERC20 with a proxy and upgrade key.
Both options have clear downsides.
Requiring every pERC20 to ship with a proxy + upgrade key creates governance risks over the privacy pool.
What do you think about going the other way: building pERC20 with STARKs + aggregation from the start? This would allow the contract to stay fully immutable while already being post-quantum secure.
With aggregated or recursive STARKs, multiple transfers could be batched into fewer on-chain verifications. It would be more expensive initially, but it avoids needing any proxy or governance mechanism. As STARK tooling improves and with potential protocol optimizations, the costs could become more reasonable without requiring changes to already-deployed contracts.
@dumbnamenumbers so if I deploy a pERC20 pre-PQ hardfork, does it automatically get the post-quantum verifier after the EIP-8182 bytecode swap? Or do pERC20s still need a proxy/upgrade?
@camelfinance@missnatoshi If you don’t know, don’t write about Ethereum.
Bitcoin security will be at serious risk in a couple more halvings and it's already far less secure than Ethereum