Table of Contents
- Prerequisites
- Implementing Structs for Vote Extensions
- Implementing Handlers and Configuring Handlers
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, seex/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 theabci/types.go
and each of these structs serves a specific purpose in the process of mitigating front-running using vote extensions:
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.
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.
Implementing Handlers and Configuring Handlers
To establish theVoteExtensionHandler
, follow these steps:
-
Navigate to the
abci/proposal.go
file. This is where we will implement the `VoteExtensionHandler“. -
Implement the
NewVoteExtensionHandler
function. This function is a constructor for theVoteExtHandler
struct. It takes a logger, a mempool, and a codec as parameters and returns a new instance ofVoteExtHandler
.
- 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 the abci.RequestPrepareProposal
during the ensuing block.
- Configure the handler in
app/app.go
as shown below
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
:
🛠️ :: Get vote extensions:
. If the logs do not provide enough information, you can also reinitialise your local testing environment by running the ./scripts/single_node/setup.sh
script again.
- 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.
- Implement the
ProcessVoteExtensions()
function. This function should handle the logic of processing vote extensions, including validating the bids.
- Configure the
ProcessProposalHandler()
in app/app.go:
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 ./scripts/single_node/setup.sh
script.