You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Permissionless batch submission is an important part of our pitch, especially when it comes to escape hatches. The changes to the sequencer for Cortado will make batch submission possible, since the sequencer has no optionality: for every time window, there is a unique valid L2 batch induced by the output of the Espresso Sequencer during that time. However, batch submission will not be permissionless automatically: the calldata source in the derive pipeline still checks that the sender of a channel frame is the trusted batcher.
Naively removing this check may lead to some attacks. An adversary cannot get an invalid batch accepted, since the downstream stages of the derivation pipeline will detect any deviation from the HotShot block stream. But they might get a valid batch rejected by inserting some malicious frames into a channel started by somebody else. We need to, at least, ensure that only the sender that initiated a channel can send frames to that channel, even though there may be multiple channels open at the same time, and whichever one closes first with the unique valid batch will be accepted.
This work may overlap with some of the RFP work, so we should wait for that before pursuing this.
The text was updated successfully, but these errors were encountered:
Permissionless batch submission is an important part of our pitch, especially when it comes to escape hatches. The changes to the sequencer for Cortado will make batch submission possible, since the sequencer has no optionality: for every time window, there is a unique valid L2 batch induced by the output of the Espresso Sequencer during that time. However, batch submission will not be permissionless automatically: the calldata source in the derive pipeline still checks that the sender of a channel frame is the trusted batcher.
Naively removing this check may lead to some attacks. An adversary cannot get an invalid batch accepted, since the downstream stages of the derivation pipeline will detect any deviation from the HotShot block stream. But they might get a valid batch rejected by inserting some malicious frames into a channel started by somebody else. We need to, at least, ensure that only the sender that initiated a channel can send frames to that channel, even though there may be multiple channels open at the same time, and whichever one closes first with the unique valid batch will be accepted.
This work may overlap with some of the RFP work, so we should wait for that before pursuing this.
The text was updated successfully, but these errors were encountered: