Dankrad Feist

@dankrad

75 Following

14268 Followers

Daniel Fernandes pfp

Daniel Fernandes

It's time to #PumpTheGas pumpthegas.org https://x.com/dankrad/status/1863412876901306599?s=19

0 reply

1 recast

8 reactions

Dankrad Feist pfp

0 reply

0 recast

0 reaction

Dankrad Feist pfp

Yes. I guess if you want preconfirmations, then I feel it may be better to keep the centralized sequencer.

0 reply

0 recast

0 reaction

Dankrad Feist pfp

I'm more worried about integration with builders, special relations due to order flow, and proprietary software for processing (synchronous) transactions across different rollups.

0 reply

0 recast

3 reactions

Dankrad Feist pfp

Preconfirmations+composability are what worries me

1 reply

0 recast

0 reaction

Dankrad Feist pfp

That's why the sequencer blob would get priority.

0 reply

0 recast

1 reaction

Dankrad Feist pfp

Make them blobs as well

1 reply

0 recast

1 reaction

Dankrad Feist pfp

In this case, the sequencer can always give one blob worth of preconfirmations, after which they have to include the "based" forced tx. Worst case for based tx is to be included after 2 sequencer blobs. (We should also add a max space between sequencer blobs so they can't delay indefinitely)

1 reply

0 recast

5 reactions

Dankrad Feist pfp

Here is a possible design: - Forced inclusion blobs can be created by anyone (they are "based") - They have to be included after the next sequencer blob

1 reply

0 recast

8 reactions

Dankrad Feist pfp

An alternative proposal: Accept the centralized sequencer, but make forced inclusions super attractive (same price as normal rollup transactions, just no preconfirmations).

2 replies

0 recast

11 reactions

Dankrad Feist pfp

I'm starting to worry that based preconfirmations lead to too much centralization pressure, creating a small oligopoly of shared sequencers and provers. Is this really better than centralized sequencers (which can also give preconfirmations)? At least the centralization here is per rollup and not global.

4 replies

7 recasts

54 reactions

Dankrad Feist pfp

Staking isn't just the reward you get for participation -- you also have to believe in the asset. So indeed, most stakers don't directly think about "real yield = nominal yield - dilution", but they think about "how bullish am I about the base asset + nominal yield". The dilution gets baked into the former.

0 reply

0 recast

2 reactions

Dankrad Feist pfp

"Stakers don't care about real yield, they only look at nominal yields" Why don't we all stake with Celestia and Polkadot then?

2 replies

1 recast

13 reactions

Vitalik Buterin pfp

Vitalik Buterin

"Basic rollup scaling" milestone achieved! Next milestones are likely verkle trees and history expiry.

63 replies

544 recasts

2237 reactions

Dankrad Feist pfp

Amazing work on shipping Dencun! Can't believe how smooth it went. Great work by all Ethereum client teams!

2 replies

3 recasts

28 reactions

Dankrad Feist pfp

The plan is to migrate a few 1000 keys per block over a few weeks.

0 reply

0 recast

5 reactions

Dankrad Feist pfp

I think that would be a fair option if the transition could be done in <1 hour. However, as it takes over a day it's unfortunately not realistic to do this.

0 reply

0 recast

2 reactions

Dankrad Feist pfp

I would love to have more of a community call in addition to ACDs, where members can give their inputs on their priorities. I think this is completely missing at the moment. But just "extending the timelines" is precisely not what we should do.

0 reply

0 recast

1 reaction

Dankrad Feist pfp

I don't have an answer. But look at optimistic rollups with a typically 7 day fraud proof window. Current expectation is that in the face of a censorship attack, Ethereum could fix this and fork in that time span to recover. Requiring that an EIP needs "x week community consideration" seems wrong in this light.

1 reply

0 recast

0 reaction

Dankrad Feist pfp

I'm very sympathetic to the community having *much more* say in HF decisions, I really don't think that they should be left to core devs. OTOH, I also think that we need to be able to coordinate much quicker than we do today, on the order of days not weeks, in emergencies.

0 reply

0 recast

3 reactions