Currently, when payload is sent off to be built using forkchoiceUpdate, there is a delay until it becomes visible in getPayload. This confuses op-node a great deal so much so that it significantly impacts the performance of the chain to the extend that it continuously takes longer for transactions to get through until they never get in, making the chain unusable. The consequences of this are therefore critical.
To compensate for the inability to make op-node wait for pending payload, there is a sophisticated system implemented to make the query respond immediatelly, effectively breaking eventual consistency paradigm that is currently set anywhere else. This solution is a sophisticated hack.
Since this is effectively a client issue, we should solve it a layer up. So how to accomplish this in the API layer?
The in-memory stateful pending payload service can live completely in the API layer, outside of the Application - the Application does not know or care that it exist, it's the API's problem.
When sending off a payload to be built into a block, the API can also add it's ID into the pending payload service directly, no cross interaction needed.
The remaining problem is how to clear the pending payload service from the payloads that became built. Here the event system comes into play. Every time the payload is done processing, the application sends out a notification that payload with certain ID is built. On the other side, the API registers a subscriber to this event that, upon receiving this event, removes the said payload from the pending payload service.
The event system effectively supersedes the simple callback system that is currently implemented and used for some things. The event-based system should also replace the callbacks.
Currently, when payload is sent off to be built using
forkchoiceUpdate, there is a delay until it becomes visible ingetPayload. This confusesop-nodea great deal so much so that it significantly impacts the performance of the chain to the extend that it continuously takes longer for transactions to get through until they never get in, making the chain unusable. The consequences of this are therefore critical.To compensate for the inability to make
op-nodewait for pending payload, there is a sophisticated system implemented to make the query respond immediatelly, effectively breaking eventual consistency paradigm that is currently set anywhere else. This solution is a sophisticated hack.Since this is effectively a client issue, we should solve it a layer up. So how to accomplish this in the API layer?
The in-memory stateful pending payload service can live completely in the API layer, outside of the
Application- theApplicationdoes not know or care that it exist, it's the API's problem.When sending off a payload to be built into a block, the API can also add it's ID into the pending payload service directly, no cross interaction needed.
The remaining problem is how to clear the pending payload service from the payloads that became built. Here the event system comes into play. Every time the payload is done processing, the application sends out a notification that payload with certain ID is built. On the other side, the API registers a subscriber to this event that, upon receiving this event, removes the said payload from the pending payload service.
The event system effectively supersedes the simple callback system that is currently implemented and used for some things. The event-based system should also replace the callbacks.