Aztec RPC server should block until an initial sync is done before allowing the user to send txs

[spalladino]

The aztec-rpc-server currently starts the Synchroniser and then becomes immediately available for the user to start sending txs. However, this means that the user could send txs without having the history of the nullifiers they have already consumed. We should perform an initial blocking sync to the tip of the chain, and only then allow users to send txs.

We have a few options here:

• Block the entire rpc-server should block during that initial sync (ie start does not return until that sync is done)
• The RPC server has a state "INITIAL_SYNCING" during which tx methods throw
• The RPC server has a state "INITIAL_SYNCING" during which tx methods block until the initial syncing finishes

We should also identify which methods need to be blocked. Is it just those related to sending txs? Or queries like getStorageAt should also be affected?

Original discussion here.

[iAmMichaelConnor]

Is this still an issue? :)

[spalladino]

Is this still an issue? :)

Totally missed this comment. I'm browsing through the code, and it seems like it is.

[PhilWindle]

Ugh! We have a function called initialSync that we await when the PXE starts. It sets the PXE's block number to the node's current block number and then doesn't do any synching. That seems very broken!

[alexghr]

Phil and I looked into this issue today and came to the conclussion that PXE's Synchronizer doesn't have any work to do in initialSync. It doesn't have any accounts to track so all it needs are the current tree roots and block height so its initialSync method is correct.

What we should do though is block (or offer a way to poll) when an account is added, until that account's note processor is fully caught up. This would have to happen in aztec.js and it would have to use a polling mechanism because of the JSON-RPC boundary between aztec.js and PXE/Synch.