# Proposed API Changes for Vote Extensions
This document covers changes I think the Comet team should make to the ABCI++ interface regarding Vote Extensions. As a disclaimer, I'm recommending these as changes that we implement in a future version of the API -- unless they are extremely trivial to build now.

The reasons I prefer delaying to a future release are that:
1. I find the existing API workable (Our team has already successfully built multiple prototypes on top of the existing API)
2. I know that dYdX and Skip both want to see Vote Extensions available ASAP in production because VEs offer crucial censorship resistance that limits the proposing validator's ability to manipulate oracles and blockspace auctions. Even a 1 month delay would be very costly for both of our teams (maybe others)

### Prepare / ProcessProposal
*Change:* Add proposing validator's ExtendedCommitInfo to the block and make it available to the other validators in RequestProcessProposal

(This could be implemented by returning the VEs from PrepareProposal or just by pulling them directly from the consensus engine)

*Reasoning*:
1. **VE data should go in blocks:** Almost all uses of VEs require the proposer to perform some trusted aggregation over VE data. Often, the proposer has an incentive to manipulate the data or the results, so the other validators need access to the VEs to verify this hasn't been done. Currently, we reuse the first tx slot to do this, which feels inappropriate and will break block explorers, indexers, etc...
2. **There's redundant validity work that the application is doing that should be passed to the consensus engine:** To verify that the proposal is valid, the application currently verifying that VE data included in the proposal has VEs from 2/3rds + 1 stake weighted proposers and that the signatures are correct.

*Considerations:*
1. **Header breaking?:** Including VEs in a block requires modifying the header, which could break IBC. (Or it just reduces to Tendermint inheriting the tx overloading hack, instead of application developers doing it, which seems worse)
2. **Inclusion in block should be optional** There may be applications of VEs that do not require VE data being shared with non-proposing validators and do not involve the proposer doing some kind of trusted aggregation computation. Developers of these applications should be able to opt out of VEs going in their blocks

### FinalizeBlock
*Change:* Add `local_last_commit: ExtendedCommitInfo` to `RequestFinalizeBlock`. In other words, give the application access to the vote extensions from the final round of height `h` in `FinalizeBlock` of height `h`

*Reasoning:* This allows the application to use unfinalized VE data earlier, in cases where it is safe to do so. Specifically, this is useful when the application is going to compute a function that should be deterministic over any quorum of valid vote extensions (e.g. constructing a decryption key from shards)

This is specifically useful in MEV auction when we want to run an auction that is:
1. Censorship-resistant: The proposer can't arbitrarily exclude bids
2. MEV-stealing proof: The proposer can't copy the strategy of the most profitable searchers and replace the searcher txs with their own transactions.

In this setting, we would construct our VEs to contain two pieces of data:
1. `Bid`: A top-of-block bid + encrypted transaction(s) to execute top of h+1
1. `DecryptKey`: A decryption key shard for a key that can decrypt the encrypted transaction from the VE of the previous height

In PrepareProposal, the proposer will insert the tx from VEs with the highest bid at the top of the block (along with the other VEs to prove to other vals the auction was run correctly) -- ignoring `DecryptKey`

In FinalizeBlock, the proposer will construct the full decryption key from the `DecryptKey` of each VE.

If we did not have access to VEs of the current height in FinalizeBlock, we would have to choose between the following options:
1. Use DecryptKey to decrypt the txs / bids submitted at the current height, which would give the proposer to decrypt the other submissions to their block and modify their block / their own VE based on the result
2. Delay the execution of decrypted transactions until h+2, which makes the whole system very high latency