Enclaves provide integrity, isolation, data sealing, and authentication functions, with trusted parties relying solely on CPU hardware and code running within enclaves. Cloud computing vendors and enclave instance administrators cannot manipulate or preview execution within an enclave.
Blockchains implement "code is the law" through consensus algorithms, while enclaves implement "code is the law" on CPU hardware. The similarity between them shows that it is possible to improve the security, privacy and efficiency of blockchain applications in enclaves.
In the age of cloud computing, vendors still need to ensure that the hardware and software stack is secure and reliable. But their customers want more: even if vendors are bad or their cloud infrastructure is weak, computing capabilities and containers are still reliable.
That's why today's confidential computing solutions start at the center of the hardware software stack, not at the bottom. Large server CPU manufacturers, ie Intel and AMD, choose different options:
AMD's SEV technology enables enclaves over hypervisors with OS cores and application programs.
Intel SGX technology allows enclaves over operating systems with only (part of) one program and one process (multithreaded processing).
Integrity: the enclave program implements exactly what is in its source code, no party can block it, not even the hypervisor and / or OS under it. A privileged hacker or malicious administrator cannot change the way code runs.
Exclusions: The program (s) performing the context (registry status and DRAM status) cannot be viewed or modified by another party, not even the hypervisor and / or operating system below.
Data sealing: data written in the continuous storage of programs in the enclave is encrypted and can be decrypted later in the enclave.
Verification: After running the hardware assistant measurement program in the enclave, the measurement hash digest is signed with a key stored in the hardware to make sure that the trusted parties are a predefined trusted program.
Many applications use direct block hashes as a random source. Using block hashes is cheap because there is always a hash in each block and no calculation is required. But hash blocks are easy to handle. Blockchain can try different sets of transactions and choose the blockchain that is most useful. In PoW chains, this testing process can delay the design of a successful block mine, so there are some potential sanctions. In the PoS chain, there is almost no risk for the design to try different hash blocks.
The enclave can act as an honest party: it will act exactly as stated in the source code, and will never reveal anything that should remain secret, including the VRF's private key. If the DApp needs a random number that matches a block, it asks the enclave for a VRF result and proof, and then verifies it in a string against the VRF public key and the hash block, that is, the VRF input. If the check continues, the DApp is convinced that this random number has not been manipulated.
The idea of CoinJoin is simple: a UTXO-based transaction has multiple inputs and multiple outputs; By combining the inputs and outputs of what could be separate transactions, in a jumbo transaction, the matching of the inputs and outputs of the original transaction is obscured. Simply let your UTXO set through several levels of such jumbo transactions and the external browser will not match the resulting UTXO set you own with the original UTXO set.
CoinJoin uses a client-server model. The servers coordinate which users are shaking and know who has what inputs / outputs. This is a privacy risk because servers can leak their information. How to reduce this risk? Dash coin is used to coordinate multiple master nodes and CashShuffle has decentralized servers. If you distribute several levels of jumbo transactions between servers (master nodes), your UTXOs will not be fully monitored if any of these servers are honest. The more levels and servers you use, the harder it is to track your actions.
We generalize such a scenario to any pure function. The pure function has no side effects and the outputs depend only on its inputs. We have:
Predefined specification of pure function without ambiguities
Some public input arguments for this pure function that anyone can publish
Some specific input arguments for this pure function that no one but their owner knows
enclave can also implement such blockboxes. Isolation ensures that enclaves do not triple the arguments for private entry, while evidence ensures that enclaves count as specified in the source code.
Compared to zero-knowledge technologies, enclaves are very weak in the trust model: we only have to rely on math to use zero knowledge, but we have to rely on CPU vendors to use enclaves. However, enclaves are easier to use: the source code of the pure function can be applied directly to the enclaves. There are no circumferential constructions and endless loops are allowed. Out-of-chain enclaves can easily interact with the smart contract in the chain. The enclave can be identified by the public key stored in the string. With the private key draws the pure function 'public input arguments and outputs. On-chain logic verifies the signature using the public key and receives outputs.
it is inevitable that cross-bridges will rely on certain witnesses to provide the state with information about another chain. The problem of collusion witnesses threatens all chain bridges. For some bridges, the set of witnesses is the same set of validators, and status information is the Merkle root of the entire state tree, leading to a somewhat safer design, but not yet preventing collusion.
The witness operates the entire customer node in chain A and publishes his status in chain B with his signature. If this turns out to be bad, all information about string B can be published, regardless of the actual state of string A. Even if a trusted organization witnesses, the machine operator may still be bribed and the private key for creating B string signatures may be stolen.
