Bonsol Implementation of Verifiable http requests #31
Labels
question
Further information is requested
Comments
|
Let me analyze this systematically:
First Stage - Expired Claims Infrastructure: // Add to ClaimStateV1
pub struct ClaimStateV1 {
pub claimer: Pubkey,
pub claimed_at: u64,
pub block_commitment: u64,
pub retry_count: u8, // Track retries
pub last_attempt: u64, // Track last attempt time
pub execution_value: u64, // Track economic value
}This foundation would help:
Second Stage - Input Resolution Framework: pub enum InputSource {
Direct(Vec<u8>), // Direct input
Http {
url: String,
method: String,
headers: HashMap<String, String>,
verification_data: Option<HttpVerificationData>,
},
// Future: Add more source types
}
pub struct HttpVerificationData {
timestamp: u64,
server_cert: Vec<u8>,
proof_data: Vec<u8>, // Extensible for different proof types
}This would:
Third Stage - Hybrid Approach:
pub enum InputResolutionMode {
ServerSide, // Prover fetches
ClientPush, // Client pushes to prover
Hybrid { // Both allowed
preferred: InputResolutionPreference,
timeout: u64,
}
}
pub trait VerificationProof {
fn verify(&self) -> Result<(), VerificationError>;
fn to_risc0_assumption(&self) -> Result<Vec<u8>, ProofError>;
}
// Can implement different proof types:
pub struct TlsNotaryProof(/* ... */);
pub struct DirectPushProof(/* ... */);
pub struct MpcTlsProof(/* ... */);Benefits of this incremental approach:
Would you like me to elaborate on any of these aspects or explore a specific part of the implementation in more detail? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As developers onboard to bonsol, one common usecase appears. "Verifiable http". At first I assumed developers would want to integrate it themselves and leverage proof composition for privacy, but many developers want to remove the layer of trust between the prover and even public and hashable sources. This is because dynamic data sources may change fro the time the execution request is sent to the time the prover pulls the inputs. This makes hashing ahead of time not valid and since the hash committed by the provers zkvm will not match it will force the developer to remove that check in bonsol. This will mean they must implement some further checks on the committed hash later if they want to validate that the data was correctly pulled by the untrusted prover .Instead of forcing developers to build this for themselves bonsol should seek to implement verifiable http by default. This is not straightforward and many companies with much more resources than the bonsol open source community make this their sole aim.
Verifiable http is tricky for a few reasons.
Quick overview of tls (1.3) in the most normal case
Why its tricky
In tls since the server and client both have the symmetric sending and receiving keys, there is not currently a way just within the tls protocol to tell who encrypted the message. Since the client(in this case bonsol prover) could have forged it. If all http servers had an identity and as a part of the http protocol they signed the response payload with a private key and the public key was at a .well-known location then this would be less tricky. That is not the case and currently tls does not offer a way to to identify the client/server when looking at the payload.
The leading schools of thought agree that in order to do this correctly there must be a way to commit to the payload before the client gets the decryption key, and this would require some form of multy party key handling.
Since bonsol provers run on a server and are supposed to be untrusted entities, this further complicates the matter. While some verifiable web data solutions are geared toward the browser user publishing a claim to some web data, we must prove to the blockchain that the prover called the right url and downloaded and committed to content from that url.
What we are after
In the most ideal case, bonsol input resolution would have a low overhead way to request the inputs and prove to the solana program within the same proof of execution that the inputs were downloaded from the right source.
In order to do this the proofs must be compatible with risc0 stark construction. The most ideal case would be that the proofs would be risc0 succinct receipts that can be fed into the zkvm as assumptions and verified.
Existing protocols around mpc and tls
Attempts using risc0
I have only seen the following https://github.com/mrnerdhair/crunch which seems like a very early prototype.
Possible Solutions In no specific order
Remove the notion of server side input resolution but instead change bonsol nodes to expect the requester to send the data to them directly at a location of the provers choosing after they have claimed.
This has some pros, the nodes dont have to worry about reaching out to the net to get any inputs which can make the nodes simpler and remove some async management. But with the large cons that devs will need to run more infrastructure to post execution data upon a successful claim. Another con is it complicates the security landscape for provers since now they need to have some open ports to receive the data.
Implement an integration with an existing mpc-tls solution. A major pro here is that the hard work of implementing mpc and tls session verification. Cons include the friction of needing to handle those protocols tokens or web2 pricing models. In the former, there may just not be a suitable bridge, in the latter we would add the burden of managing web2 api keys to the node.
Build this soup to nuts. Major pros here are total control, the ability to pick solid libraries to accelerate development. Major cons are well.... needing to build this.
The text was updated successfully, but these errors were encountered: