A similar algorithm appears in Age of Em by Robin Hanson (‘spur safes’ in Chapter 14). Basically, a trusted third party allows copies of A and B to analyze each other’s source code in a sealed environment, then deletes almost everything that is learned.
A and B both copy their source code into a trusted computing environment (‘safe’), such as an isolated server or some variety of encrypted VM. The trusted environment instantiates a copy of A (A_fork) and gives it B_source to inspect. Similarly, B_fork is instantiated and allowed to examine A_source. There can be other inputs, such as some contextual information and a contract to discuss. They examine the code for several hours or so, but this is not risky to A or B because all information inside the trusted environment will mandatorily be deleted afterwards. The only outputs from the trusted environment are a secure channel from A_fork to A and one from B_fork to B. These may only ever output an extremely low-resolution one-time report. This can be one of the following 3 values: ‘Enter into the contract with the other’, ‘Do not enter into the contract with the other’, or ‘Maybe enter the contract’.
This does require a trusted execution environment, of course.
I haven’t read Age of Em, but something like “spur safes” was an inspiration (I’m sure I’ve come across the idea before). My version is similar except that
It’s stripped down.
B only needs to make a Validator, which could be a copy of themself, but doesn’t have to be.
It only validates A to B, rather than trying to do both simultaneously. You can of course just run it twice in both directions.
You don’t need a trusted computing environment.
I think that’s a pretty big deal, because the trusted computing environment has to be trusted enough to run its end of A/B’s secure channels. In order for A/B to trust the output, it would need to e.g. be signed by their private keys, but then the computing envionment has access to those keys and can do whatever it wants! The trick with FHE is to let B run a computation using their secret key “inside” the safe without letting anyone else see the key.
A similar algorithm appears in Age of Em by Robin Hanson (‘spur safes’ in Chapter 14). Basically, a trusted third party allows copies of A and B to analyze each other’s source code in a sealed environment, then deletes almost everything that is learned.
A and B both copy their source code into a trusted computing environment (‘safe’), such as an isolated server or some variety of encrypted VM. The trusted environment instantiates a copy of A (A_fork) and gives it B_source to inspect. Similarly, B_fork is instantiated and allowed to examine A_source. There can be other inputs, such as some contextual information and a contract to discuss. They examine the code for several hours or so, but this is not risky to A or B because all information inside the trusted environment will mandatorily be deleted afterwards. The only outputs from the trusted environment are a secure channel from A_fork to A and one from B_fork to B. These may only ever output an extremely low-resolution one-time report. This can be one of the following 3 values: ‘Enter into the contract with the other’, ‘Do not enter into the contract with the other’, or ‘Maybe enter the contract’.
This does require a trusted execution environment, of course.
I don’t know if this idea is original to Hanson.
I haven’t read Age of Em, but something like “spur safes” was an inspiration (I’m sure I’ve come across the idea before). My version is similar except that
It’s stripped down.
B only needs to make a Validator, which could be a copy of themself, but doesn’t have to be.
It only validates A to B, rather than trying to do both simultaneously. You can of course just run it twice in both directions.
You don’t need a trusted computing environment.
I think that’s a pretty big deal, because the trusted computing environment has to be trusted enough to run its end of A/B’s secure channels. In order for A/B to trust the output, it would need to e.g. be signed by their private keys, but then the computing envionment has access to those keys and can do whatever it wants! The trick with FHE is to let B run a computation using their secret key “inside” the safe without letting anyone else see the key.