There is no programmatic safeguard to restart the chain if the bridge cannot be started (audit issue #17)

[james-chf]

This was finding 17 from the audit of eth-bridge-integration branch (commit 57fc202)

Severity: Informational
To bootstrap the bridge the chain needs to halt. If that halt lasts longer than the epoch period, there is a risk that time sync or epochs may be lost. In the current implementation, there is no programmatic guarantee that the bootstrapping of the bridge will not cause problems with epoch time sync.
Recommendation
We recommend bootstrapping the bridge at the beginning of an epoch to maximize the time available to coordinate the resumption of operations. We also recommend developing and communicating a fallback plan for the unlikely case that bootstrapping will not be finished in time.

[james-chf]

What to do in the case that the bridge cannot be launched is not currently specified (except that it must be possible).

namada/documentation/specs/src/interoperability/ethereum-bridge/bootstrapping.md

Lines 60 to 65 in a307a4c

	### Backing out of Ethereum bridge launch
	If for some reason the validity of the smart contract deployment cannot be
	agreed upon by the validators who will responsible for restarting Namada, it
	must remain possible to restart the chain with the Ethereum bridge still not
	enabled.

We should explicitly lay out the fallback plan. Most likely, the chain can just be restarted without any genesis ethereum_bridge_params specified (as are being added in #575), and it will act just as before.

[batconjurer]

Epoch must meet both a minimum amount of time and a minimum number of blocks must be processed. So it is not possible to for a the bridge to take longer than an epoch to sync since validators cannot start producing new blocks until their bridge is activated.