Overview
This feature enables proof requests to be submitted permissionlessly by 3rd parties, that are authorized for payment by a smart contract. This is particularly useful for:- DAO-like entities that need to request proofs to drive protocol operations
- Service agreements where contracts authorize funding for proofs that meet specific criteria
How it Works
Entities
-
Request Builder
- Builds and submits proof requests to the market
- Fully permissionless role
- Incentivized outside of the Boundless protocol
-
Smart Contract Requestor
- ERC-1271 contract that authorizes proof requests
- Contains logic for validating requests
- Deposits funds to Boundless Market for fulfilling requests
-
Provers
- Regular market provers who fulfill requests by the deadline
Flow
Smart Contract Requestors use ERC-1271 signatures to authorize proof requests.- Request Builder constructs a request meeting the Smart Contract Requestor’s criteria
- Request Builder submits the request with:
- Smart Contract Requestor’s address as the client
- Signature encoding the data that the smart contract requestor needs to validate the request
- Boundless Market requests authorization of the request by calling
isValidSignatureon the Smart Contract Requestor - Smart Contract Requestor receives a hash of the submitted request, and the data provided by the Request Builder
- Smart Contract Requestor validates the request and returns the ERC-1271 magic value if it authorizes the request
- Boundless Market takes payment from the smart contract requestor, and provers fulfill the request
Considerations
Request ID
In Boundless, Request IDs are specified by the Request Builder. The Boundless Market contract ensures that only one payment will ever be issued for each request id. For Smart Contract Requestors, the Request ID is especially important as it acts as a nonce, ensuring the requestor does not pay twice for the same batch of work. It is important to design a nonce structure that maps each batch of work to a particular nonce value, and for the Smart Contract Requestor to validate that the work specified by the Request ID matches the work specified in the proof request.Signature Encoding
The signature encoding is used to encode the data that the smart contract requestor needs to validate the request. Boundless guarantees that it will callisValidSignature with a hash of the request that was submitted, so typically you would want to encode enough information to recreate the request hash and validate that it matches the hash provided by Boundless.
Example: Daily Echo Proof
The Smart Contract Requestor example demonstrates a contract that authorizes payment for one proof of the “Echo” guest program per day. It shows a simple example of how to design a Request ID nonce scheme, as well as how to encode the request data in the signature for the Smart Contract Requestor to validate. In this example, we use the Request ID to represent “days since epoch”. Our zkVM guest program outputs the input that it was called with, so we use this property to ensure that the program was run with the correct input for the day. First, we construct the Request ID. We use the index of the Request ID to represent each day since the unix epoch, ensuring that we will only ever pay for one request per day. Note we also set a flag to indicate that this request’s signature should be validated using ERC-1271’sisValidSignature function, and not a regular ECDSA recovery:
Requirement, with the predicate type DigestMatch, to ensure that the journal of the guest program matches the value we expect.
In this example we expect the input of the program to be the current day since epoch, so we validate that by creating a digest match predicate with days_since_epoch as the expected journal.
First we execute the guest program locally with our expected input, to generate the expected journal.
Requirement that the journal should match the expected journal.
SmartContractRequestor.sol
isValidSignature on the Smart Contract Requestor with the request hash and the signature. Here we walk through the logic of our example contract:
First, we decode the request from the signature.
SmartContractRequestor.sol
SmartContractRequestor.sol
SmartContractRequestor.sol
SmartContractRequestor.sol
SmartContractRequestor.sol
Relevant links: Smart Contract Requestor Example, ERC-1271