Trusted Execution Environments (TEEs) promise integrity and confidentiality of (remote) computationWe have become accustomed to the fact that we have to trust our IT  administrators. While these administrators used to be in-house employees  at our companies, today we often work on rented cloud platforms.These administrators can read and modify all the data processed on  any machine they manage. Unfortunately, this ability extends not only to  known administrators we trust but also to hackers who can obtain  administrator privileges. No company, no matter how qualified, is immune  to such attacks.
Enter TEEs.
You may envision a TEE as a co-processor that manages its own  cryptographic keys and only executes programs whose hash, or  fingerprint, corresponds to the original code. The manufacturer of the  processor guarantees, by the design of their hardware, that nobody has  access to the internal keys of the TEE or can read its memory. Moreover,  the manufacturer can authenticate each TEE and provide remote  attestation to a user to confirm that her program has not been tampered with and is actually  running on a genuine TEE, even if the machine is physically located in an off-site data center.Assuming we trust the integrity and design competence of TEE manufacturers,  TEEs allow us to execute any state update without sharing our data with the blockchain validator or other users. Private token transfers,  private smart contracts and private state channels thus become possible and relatively cheap.

There are two kinds of risks: A malicious TEE manufacturer could attest fake devices, introduce backdoors or suddenly refuse to remotely attest genuine devicesDesign flaws (Intel SGX: Foreshadow, Plundervolt, SGAxe)Various vulnerabilities have been found by white hat hackers and fixed by Intel by means of microcode patches. Integritee requires regular refreshing of remote attestation (around every 24h) to verify that the most recent patches have been applied.As always in cybersecurity: It’s a race against time. TEEs just add another layer of security on top of state-of-the art protection measures.

Our parachain, sidechains and off-chain workers continue to work. But they can’t refresh their remote attestation and no new SGX machines can join. If IAS is offline for a longer time, on-chain governance would have to ensure that all registered enclaves stay enabled even if they don’t refresh remote attestation.

In order to get a remote attestation quote signed by IAS, the operator of the SGX machine needs a production license with Intel. Such a license is free of charge, but will only be granted to legal entities.

Currently, Intel SGX is the only TEE technology which can be remotely attested. We are actively investigating alternatives and we aim to further open-source hardware initiatives like Keystone.

All these purely cryptographic approaches either generalize poorly or remain very academic. Moreover, the privacy they provide comes at the cost of scalability (bigger transaction sizes, longer processing times, more communication overhead). TEEs, on the other hand, are a production-ready commodity technology. We are following pure-crypto solutions with interest and are open to adopting them once they leave the lab and prove to be ready for scalable and generic application.

Our sidechains are validated by remotely attested TEEs, so there is no need for a communication-heavy consensus protocol. Sidechains work mostly like substrate blockchains and they are compatible with substrate runtime pallets.

Because validators are trusted TEEs, we only need a handful of validators per shard for availability and liveness.

A shard is a fraction of a sidechain’s state. A single sidechain validator can operate on multiple shards.

This depends on many factors, but we expect to be able to provide finality for over 1000 sidechain shards.

We expect that each sidechain shard can process 1000 TPS. For well-shardable use cases, we expect to reach 1,000,000 TPS over the entire Integritee platform.

Our sidechains are validated by remotely attested TEEs, so there is no need for a communication-heavy consensus protocol. Block times of less than a second are possible.

Intgeritee can interface with any REST, SOAP, RPC or similar API directly from its enclaves via secure websocket or https for authentication and encryption.
Integritee workers or sidechains can expose such APIs over wss ot https themselves, possibly including load balancing and DDoS protection.

All Polkadot/Kusama relay-/parachains can interface with Integritee workers or sidechains through XCMP.

Any light-client capable blockchain can be trustlessly bridged to Integritee by running their light client inside our enclaves. This way, Integritee workers or sidechains can read state of foreign blockchains, verify inclusion proofs or send transactions.  You can find a concept for an Integritee-based Ethereum bridge as a speculative web3 grant proposal.

They can be. GDPR-compliance depends on what the sidechain does with personal data. Our technology can build the basis of a GDPR-compliant application. But the purpose, the implementation and the operation processes of an application built on top of Intgeritee need to comply as well.