[CX-Marketplace] - Implement the AuctionResults trait within Sequencer

What is this task and why do we need to work on it?

After we define the trait in HotShot, we need to implement it in Sequencer to enable the state to be passed down and initialized. The Sequencer will need to implement a client type which facilitates the interaction, and gives a literal value to be sent to the HotShot initializer. The initial version of the type will be called something like EspressoSolverClient, and it’ll hold the requisite information needed to make a request to solver, handle errors, and configure things like timeouts. This type will formally exist in Sequencer, and it will implement AuctionResults.

#[derive(Debug)]
struct EspressoSolverClient<TYPES: NodeType> {
    sequencer_handle: URL or Active Cxn
    port: u64
    timeout: Duration,
    ...
}

This type is responsible for interacting with the solver and derives it’s information from the configuration files that exist within the Sequencer. It is the sole fetcher for the data from the Solver, and is responsible for deserializing the JSON payload from the Solver. This type will implement AuctionResults as the following:

#[async_trait]
impl AuctionResults<SeqTypes> for EspressoSolverClient {
        type AuctionSolverResult = SeqTypes::FullNetworkTx;

        async fn fetch_auction_result_urls(
            self, 
            view_number: ViewNumbr
        ) -> Result<Self::AuctionSolverResult> {
            self.make_http_request(self.sequencer_handle).await.timeout(self.timeout)?
        }
}

This will roughly complete the sequencer-side work. This type will be added to the SystemContext within hotshot on initialization. The type will be similar to existing shared data types (like the Storage trait).

pub struct SystemContext<TYPES: NodeType, I: NodeImplementation<TYPES>> {
    ...
    auction_results_client: Arc<RwLock<I::AuctionResults<TYPES>>,
}

From here, any downstream task can grab a copy of the results if HotShot decides to store them.

IMPORTANT: Sequencer has no state whatsoever about the fetched results. Each request is not a singleton and, as a result, HotShot’s storage mechanism will need to handle holding this information if it’s needed for longer than just the block construction. Due to the volume of the data, it is not suitable for event propagation and, instead, should be stored centrally.

Solver Failure Scenarios

The API for the solver within HotShot will have a 1 second timeout, after which HotShot will simply move on and propose an empty block. This will be configured in the struct.

What work will need to be done to complete this task?

No response

Are there any other details to include?

No response

What are the acceptance criteria to close this issue?

New and existing sequencer tests are passing.
Sequencer survives at least 1 weekly release.

Branch work will be merged to (if not the default branch)

No response

EspressoSystems / HotShot