What kind of latency does the system require?
I think latency will be good (likely good enough) as
- During the decryption process, only the parts of the private message-keys of transactions in the block need to be sent over the network - no bigger data junks. One DKG decryption should be pretty fast and lean and the specification requires “only” 1 DKG private key generate per tx included in the block. And since DKG works with thresholds, only a certain percentage of the network needs to act fast and publish their secrets on time, such that the decryption can start on time. (If there is a small percentage of malicious DKG nodes that want to delay something, they can’t, if the threshold is reached without them).
- the encyrpted orderflow can be continuously be published (the tx-sender can even encrypt the tx themselves with the public DKG key and send it to all builders. )
Yes, the DKG/DOFD nodes must ensure data availablity for the signatures. Otherwise, as you are saying, there would be a risk of liveness failure.
llllvvuu:
The reason is that if you add these slashing conditions then you get to a point where you must censor to win the most MEV without being slashed.
It could be that this is true for some transactions. But if someone pays a bigger eip1559 tip to be included, it’s very unlikely that the best solution would have to censor this person(assuming the tip is big enough). Or am I missing something?