docs: RFC for Optimistic Execution

[facundomedica]

Description

See rendered

TODO:

• understand why it's not possible to do OE during an upgrade (I have a very rough idea, but would like to be able to explain it)
• understand what would happen if we allow OE during round > 0.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[facundomedica]

understand why it's not possible to do OE during an upgrade (I have a very rough idea, but would like to be able to explain it)

Normally when panicking in FinalizeBlock the app panics because there's no recovery. On other ABCI methods there is a panic recovery, like in ProcessProposal. So because we call FinalizeBlock from ProcessProposal, any panic will get recovered.

[alexanderbez]

@facundomedica should we sync on this?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tac0turtle]

@facundomedica we should wrap this up so we dont lose the information

[alexanderbez]

Nice work! Left a few minor comments.

One thing I'd like to see is actual design/code around goroutine management. I.e. spawning them, ensuring only 1 exists at a time, canceling one and waiting for completion.

[tac0turtle]

overall looks good. making it optional for now, via a variable on by the developers not by the node operators would be good. In the worst case it would be good to allow a coordinated override, but this could be done with a new binary as the change is not consensus breaking

[tac0turtle]

LGTM