[TEAM2-380] Use "safe" Commitment Level over "latest"

[derHowie]

What changed (plus any additional context for devs)

DRAFT PR: testing post-merge

Screen recordings / screenshots

What to test

Final checklist

• [ ] Assigned individual reviewers?
• [ ] Added labels? (team1/team2, critical path, release, dev QA)
• [ ] Did you test both iOS and Android?
• [ ] If your changes are visual, did you check both the light and dark themes?
• [ ] Added e2e tests? If not, please specify why
• [ ] If you added new critical path files, did you update the CODEOWNERS file?
• [ ] If no dev QA label, did you add the PR to the QA Queue?

[linear[bot]]

TEAM2-380 Use "safe" Commitment Level over "latest"

Via: https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/

"Under proof of work there is always the potential for reorgs. Applications usually wait for several blocks to be mined on top of a new head before treating it as unlikely to be removed from the canonical chain, or “confirmed”. After The Merge, we instead have the concepts of finalized and safe head blocks. These blocks can be used even more reliably than the “confirmed” proof of work blocks but require a shift in understanding to use correctly.

A finalized block is one which has been accepted as canonical by >2/3 of validators. To create a conflicting block, an attacker would have to burn at least 1/3 of the total stake. At the time of this writing, this represents over $10 billion (or >2.5 million ETH) on Ethereum.

A safe head block is one which, under normal network conditions, we expect to be included in the canonical chain. Assuming network delays of less than 4 seconds, an honest majority of validators and no attacks on the fork-choice rule, the safe head will never be orphaned. A presentation detailing how the safe head is calculated under various scenarios is available here. Additionally, the assumptions and guarantees of safe head are being formally defined and analysed in an upcoming paper.

Post-merge, execution layer APIs (e.g. JSON RPC) will expose the safe head using a safe tag. Under normal network conditions the safe head and the actual tip of the chain will be equivalent (with safe head trailing only by a few seconds). Safe heads will be less likely to be reorged than the current proof of work latest blocks.

Finalized blocks will also be exposed via JSON RPC, via a new finalized flag. These can then serve as a stronger substitute for proof of work confirmations."

@christopher's comments on the above: Relying on safe rather than latest is an easy win and does not require a lot of dev effort. There are only 3 instances currently in the app where we request the latest block.

• pending transaction watcher
• getSwapGasLimitWithFakeApproval
• useEnsRegistrationStepHandler

[derHowie]

Going to close this until I can hop off of swaps to address e2e issues.