Dankrad Feist pfp

Dankrad Feist

@dankrad

74 Following
19126 Followers


Dankrad Feist pfp
Dankrad Feist
@dankrad
I think so.
0 reply
0 recast
0 reaction

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
Dankrad Feist
@dankrad
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
2 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
Preconfirmations+composability are what worries me
1 reply
0 recast
0 reaction

Dankrad Feist pfp
Dankrad Feist
@dankrad
That's why the sequencer blob would get priority.
0 reply
0 recast
1 reaction

Dankrad Feist pfp
Dankrad Feist
@dankrad
Make them blobs as well
1 reply
0 recast
1 reaction

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
6 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
9 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
12 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
4 recasts
62 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
Dankrad Feist
@dankrad
"Stakers don't care about real yield, they only look at nominal yields" Why don't we all stake with Celestia and Polkadot then?
3 replies
1 recast
11 reactions

Vitalik Buterin pfp
Vitalik Buterin
@vitalik.eth
"Basic rollup scaling" milestone achieved! Next milestones are likely verkle trees and history expiry.
93 replies
354 recasts
2503 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
Amazing work on shipping Dencun! Can't believe how smooth it went. Great work by all Ethereum client teams!
1 reply
3 recasts
23 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
The plan is to migrate a few 1000 keys per block over a few weeks.
0 reply
0 recast
5 reactions

Dankrad Feist pfp
Dankrad Feist
@dankrad
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
Dankrad Feist
@dankrad
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
Dankrad Feist
@dankrad
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
Dankrad Feist
@dankrad
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

Dankrad Feist pfp
Dankrad Feist
@dankrad
I think this is a very interesting question. I was very ambivalent about this EIP myself -- initially I was against it but changed my mind as it being the best thing to do right now, precisely because the hard fork process is very slow and drawn out.
2 replies
1 recast
4 reactions