Skip to main content

Table of Contents

Prerequisites

Before implementing vote extensions to mitigate front-running, ensure you have a module ready to implement the vote extensions with. If you need to create or reference a similar module, see x/auction for guidance. In this section, we will discuss the steps to mitigate front-running using vote extensions. We will introduce new types within the abci/types.go file. These types will be used to handle the process of preparing proposals, processing proposals, and handling vote extensions.

Implementing Structs for Vote Extensions

First, copy the following structs into the abci/types.go file. Each of these structs serves a specific purpose in the process of mitigating front-running using vote extensions:
The PrepareProposalHandler struct is used to handle the preparation of a proposal in the consensus process. It contains several fields: logger for logging information and errors, txConfig for transaction configuration, cdc (Codec) for encoding and decoding transactions, mempool for referencing the set of unconfirmed transactions, txProvider for building the proposal with transactions, keyname for the name of the key used for signing transactions, and runProvider, a boolean flag indicating whether the provider should be run to build the proposal.
After the proposal has been prepared and vote extensions have been included, the ProcessProposalHandler is used to process the proposal. This includes validating the proposal and the included vote extensions. The ProcessProposalHandler allows you to access the transaction configuration and codec, which are necessary for processing the vote extensions.
This struct is used to handle vote extensions. It contains a logger for logging events, the current block number, a mempool for storing transactions, and a codec for encoding and decoding. Vote extensions are a key part of the process to mitigate front-running, as they allow for additional information to be included with each vote.
These structs are used to handle injected vote extensions. They include the signer of the vote extension and the bids associated with the vote extension. Each byte array in Bids is a serialized form of a bid transaction. Injected vote extensions are used to add additional information to a vote after it has been created, which can be useful for adding context or additional data to a vote. The serialized bid transactions provide a way to include complex transaction data in a compact, efficient format.
This struct is used for application vote extensions. It includes the height of the block and the bids associated with the vote extension. Application vote extensions are used to add additional information to a vote at the application level, which can be useful for adding context or additional data to a vote that is specific to the application.
This struct is used for special transactions. It includes the height of the block and the bids associated with the transaction. Special transactions are used for transactions that need to be handled differently from regular transactions, such as transactions that are part of the process to mitigate front-running.

Implementing Handlers and Configuring Handlers

To establish the VoteExtensionHandler, follow these steps:
  1. Navigate to the abci/proposal.go file. This is where we will implement the VoteExtensionHandler.
  2. Implement the NewVoteExtensionHandler function. This function is a constructor for the VoteExtHandler struct. It takes a logger, a mempool, and a codec as parameters and returns a new instance of VoteExtHandler.
  1. Implement the ExtendVoteHandler() method. This method should handle the logic of extending votes, including inspecting the mempool and submitting a list of all pending bids. This will allow you to access the list of unconfirmed transactions in abci.RequestPrepareProposal during the ensuing block.
  1. Configure the handler in app/app.go as shown below
To give a bit of context on what is happening above, we first create a new instance of VoteExtensionHandler with the necessary dependencies (logger, mempool, and codec). Then, we set this handler as the ExtendVoteHandler for our application. This means that whenever a vote needs to be extended, our custom ExtendVoteHandler() method will be called. To test if vote extensions have been propagated, add the following to the PrepareProposalHandler:
This is how the whole function should look:
As mentioned above, to check if vote extensions have been propagated, you can do this by checking the logs for any relevant messages such as :: Get vote extensions:. If the logs do not provide enough information, you can also reinitialize your local testing environment by running the ./scripts/single_node/setup.sh script again.
  1. Implement the ProcessProposalHandler(). This function is responsible for processing the proposal. It should handle the logic of processing vote extensions, including inspecting the proposal and validating the bids.
  1. Implement the ProcessVoteExtensions() function. This function should handle the logic of processing vote extensions, including validating the bids.
  1. Configure the ProcessProposalHandler() in app/app.go:
This sets the ProcessProposalHandler() for our application. This means that whenever a proposal needs to be processed, our custom ProcessProposalHandler() method will be called. To test if the proposal processing and vote extensions are working correctly, you can check the logs for any relevant messages. If the logs do not provide enough information, you can also reinitialize your local testing environment by running the ./scripts/single_node/setup.sh script.