In PR #779 the support for interaction with the SputnikDAO was added. However, the current implementation supposes that after LightClientUpdate is sent, the relayer waits (in a blocking way) for the status change of Proposal (to something that is not InProgress status). This prevents the relay from doing anything else, e.g. submitting execution hash blocks.
To mitigate this, the possible ways would be:
When the proposal is submitted, the relayer resets some timer for light client updates sending and returns back to its normal operation. When the timer is up, the relayer tries to submit a new proposal once again (if needed).
The relayer fetches and tracks the proposals from the SputnikDAO account and verifies, whether it's required to submit some blocks again. So after submitting an update, the relayer continues its normal operation and occasionally checks the status of his proposal and whether there are any other proposals so it doesn't need to send an update.
In PR #779 the support for interaction with the SputnikDAO was added. However, the current implementation supposes that after
LightClientUpdateis sent, the relayer waits (in a blocking way) for the status change ofProposal(to something that is notInProgressstatus). This prevents the relay from doing anything else, e.g. submitting execution hash blocks.To mitigate this, the possible ways would be: