Builder Solidity

Verifiable logic, private data

Block builders currently have no incentive to share the algorithms by which they build blocks, and searchers depend on builders to ensure their bundles are included. This trust-dependency results in block builder centralization, irrespective of architecture or consensus mechanism.

Builder solidity enables anyone to create contracts that specify exactly how they will order sensitive data sent to them. There are many potential incentives for creating such contracts in the open:

1. The credible neutrality of an open marketplace in which many parties share their views, strategies, and opinions gives SUAVE an information advantage on centralized builders.
2. There are efficiency gains when aggregating and clearing user preferences inside the same auction. More users means more oderflow means more likelihood of landing blocks, or settling auctions, successfully.
3. Block builders who only operate on a single domain will find themselves increasingly disadvantaged due to cross-domain MEV. Builder solidity on SUAVE should decrease the cost (and complexity) of building blocks for many different blockchains.
4. Enabling computation on sensitive data in a permissionless setting is hard. By solving it once, builder solidity contracts amortize the cost across the ecosystem and provide better solutions more cheaply than any individual participant could.

Open to All

Builder solidity is not just for block builders, though.

Builder solidity contracts are a uniform programming model for implementing every component of the transaction supply network, such that we can ensure that any value created is distributed well. An auction for blockspace is not very different from an auction for solving user preferences. We expect that mechanisms which work well for either will translate into many different use cases.

The result should be continuous improvement of mechanisms which compete for sensitive data, and do so by virtue of the efficiency of their implementation combined with the guarantees their contracts make about how they will distribute value arising from the aggregation of such data.

Our intention is to create a viable environment for keeping power decentralized.

Builder Solidity

Builder solidity looks something like this [🔗 source]:

pragma solidity ^0.8.8;

import "../libraries/Suave.sol";

contract AnyBidContract {

    event BidEvent(
        Suave.BidId bidId,
        uint64 decryptionCondition,
        address[] allowedPeekers
    );

    function fetchBidConfidentialBundleData() public returns (bytes memory) {
        require(Suave.isConfidential());

        bytes memory confidentialInputs = Suave.confidentialInputs();
        return abi.decode(confidentialInputs, (bytes));
    }

    function emitBid(Suave.Bid calldata bid) public {
        emit BidEvent(bid.id, bid.decryptionCondition, bid.allowedPeekers);
    }
}

Builder solidity contracts are used to define the public logic that is used for confidential computation. Using a precompile like confidentialInputs allows SUAVE Kettles to access encrypted data from users, do stuff with it privately and only reveal the results, not the inputs.

This ensures confidentiality and improves efficiency, enabling computation that is not possible on blockchains like Ethereum.

Confidential Computation

TODO:

1. Explain view functions and how we use those for execution of confidentialComputeRequests
2. An example of a very simple request and response object on a view function to show how it all works with data points
3. A more in-depth data flow

Further context

We recommend this early research talk from Andrew Miller to get a sense of the ideas from which builder solidity has grown.

Please note that the pseudo code Andrew shows is now outdated and you are better off learning from our how to create contracts guide above, or looking directly at our list of available precompiles. That said, the framework used in this talk and the background provided should still prove useful when writing your own builder solidity contracts.