Spike: direct tx @ executor adapter #2536
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| # direct TX | ||
|
|
||
| - What format can we expect for the direct TX on the DA? some wrapper type would be useful to unpack and distinct from | ||
| random bytes | ||
| - Should we always include direct TX although they may be duplicates to mempool TX? spike: yes, first one wins. | ||
|
There was a problem hiding this comment. yes, first one wins. even if there's a duplicate, the duplicate would just fail automatically due to usual tx replay protections in state machines like nonces |
||
| - Should we fill the block space with directTX if possible or reserve space for mempool TX | ||
|
There was a problem hiding this comment. IIUC, this case is when there's a lot of direct txs and mempool txs at the same time, so there needs to be a decision on what to do here. We can limit the amount of direct txs in each evolve block to some fixed number (can be made dynamic later) which follows an inclusion window so that the sequencer's mempool txs are still the ones included in an evolve block the fastest. |
||
| - What should we do when a sequencer was not able to add a direct-TX within the time window? | ||
|
There was a problem hiding this comment. A sequencer following the rules of the network should be able to add a direct tx within the time window. If there's too many direct txs to include in a time window, then everyone can see that and those extra direct txs would just be ignored. This responsibility of telling a user if their direct tx will be included or not, or has be included can be passed on to the frontends. |
||
| - Do we need to trace the TX source chanel? There is currently no way to find out if a sequencer adds a direct TX "to | ||
|
There was a problem hiding this comment. No I don't think it's necessary to trace the source channel, maybe it's useful for the sequencer itself though. The sequencer has preferred execution rights in an evolve block so it can included whatever transactions it wants really since only valid txs will be actually executed. If the sequencer adds a direct tx, X, before it's even included in the DA layer, then every full node can see that that X was included already so that's perfectly valid. I do not see how this can be harmful to do. |
||
| early". Can be a duplicate from mempool as well. | ||
| - What is a good max size for a sequencer/fallback block? Should this be configurable or genesis? | ||
|
There was a problem hiding this comment. What do you mean a |
||
| - Do we need to track the sequencer DA activity? When it goes down with no direct TX on DA there are no state changes. | ||
|
There was a problem hiding this comment. Yes, in order to decide when to enter fallback mode, full nodes need to assess the liveness of the sequencer. The liveness of the sequencer is dependent on whether they're posting evolve blocks on the DA layer. Gossiping evolve blocks over P2P shouldn't be considered the way to check liveness since they're vulnerable to P2P split network attacks like eclipse attacks. Opting to listen over P2P is purely optional for a full node. So we should assume the case for a full node only listening to DA for evolve blocks |
||
| When it goes down and direct TX missed their time window, fullnodes switch to fallback mode anyway. | ||
| - How do we restore the chain from recovery mode? | ||
|
There was a problem hiding this comment. Assuming by recovery mode, you mean fallback mode here. There doesn't need to be socially coordinated fork necessarily. Let's say the original sequencer was just experiencing downtime and the rest of the network is in fallback mode. Now if the original sequencer comes back online, first it needs to sync to the rest of the network that's in fallback mode to get to the tip of the chain, and it can then signal by posting something to the DA layer that it's back online. Then, the rest of the network full nodes can see this signal and exit fallback mode. They can then wait for the original period of time that causes fallback mode for the sequencer to start posting Evolve blocks to the DA layer. The alternative if the original sequencer is forever down for some reason like its signing keys being lost or something, is introducing a socially coordinated fork like you suggested |
||
| => socially coordinated fork which nominates a new sequencer to continue to “normal” functionality | ||
|
|
||
| ## Smarter sequencer | ||
|
|
||
| - Flatten the batches from mempool to limit memory more efficiently | ||
| - `Executor.GetTxs` method should have a max byte size to limit the response size or pass via context | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,4 +8,4 @@ title: API Introduction | |
| import spec from '../src/openapi-rpc.json' | ||
| </script> | ||
|
|
||
| <OAIntroduction :spec="spec" /> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is an open design question. we could either set up some sort of frontend like optimism portal (https://docs.optimism.io/app-developers/tutorials/transactions/send-tx-from-eth#trigger-the-transaction) that allows users to directly submit direct TXs
or
just allow bake in this functionality of submitting a direct tx or set of a them from any full node which can publish a set of txs to the namespace in some format deserializable by the sequencer.