When gauging the security of a system in computer science, we often assess it from several angles - theoretical security, hardware, and software engineering. While the current Zero-Knowledge (ZK) solution is secure theoretically, but still does not guarantee system-wide bug-free operation, especially from an engineering perspective, remains challenging due to the complexity of ZK implementation.

To hedge the bugs in ZK implementation, a hardware solution, Trusted Execution Environment (TEE), can be used as a 2-factor verifier to offer double security to zk-Rollups. Inspired by Vitalik Buterin's presentation and a recent post by Justin Drake, based on Phala's decentralized TEE network, we build Phala SGX-Prover- a novel TEE-based multi-proof system designed to enhance both security and performance for zk-Rollups.

TEE-based prover can bring several benefits to zk-Rollups:

• Hardware-grade safety: The TEE prover merely supplements ZKP. In the worst-case scenario, zk-Rollup's security is robust.

• Unstoppable: We deploy 'N' provers, requiring just 1-of-N approval on L1 and incentivizing the TEE provers appropriately.

• Low cost: Gas consumption is minimal, requiring just an ECDSA verification. The L1 contracts experience minimal changes, and the Prover is uncomplicated: simple state transition function execution in TEE.

The Architecture and Design Consideration

Our goal is to provide a secondary security guarantee for zk-Rollups without any finality delay. Hence, the design should not have any invasion of the existing zk-Rollups verification system. Based on this, we introduce TEE-Proof which is a piece of proof data blob produced by an off-chain module we called sgx-prover after running the state transition program, the TEE-Proof will then be submitted to the on-chain sgx-verifier, the sgx-verifier will then verify the signature of the prover, and the return result attached in the proof data.

Now the only change to zk-Rollups' finalization and settlement is dual-checking results returned by both sgx-verifier and zk-verifier. Note the TEE-Proof acts merely as a 2FA check, driving the verification logic to be:

• If the zk-verifier returns false, regardless of what the sgx-verifier returns, the state should be rejected.

• If both the zk-verifier and the sgx-verifier return true, the state should be accepted.

• If the zk-verifier returns true, but the sgx-verifier returns false, the state should not be accepted; we need to manually handle this situation.

The last situation is where our solution truly comes into play. In such an instance, we are uncertain whether there is a bug/hack from the sgx-prover side or the zk-prover side, as had happened with the zkSync Era. If the zk-prover side had an unseen soundness bug, even though it returned true, the state transition might already have been manipulated by malicious hackers.

How do we manage the risks of SGX?

People generally harbor two types of concerns regarding SGX:

• Intel is centralized and regulated, holding the master key of all SGX devices.

• SGX hardware is not bug-free, and Intel typically has slow reactions.

We employ combined technical and economic methods to mitigate impacts in worst-case-scenarios:

• Multiple roles exist in our TEE network. The most significant two are the Gatekeeper and Worker. The Gatekeeper, elected by PHA token holders via NPoS, manages the network's secrets and oversees the tokenomic model. Workers run on SGX hardware machines. By incorporating the key rotation mechanism for Gatekeepers, we can ensure the TEE network's security. Find more details in the documentation.

• We incorporate PHA, the native token of the Phala blockchain, as a Supply-end Tokenomic, incentivizing high-quality service from the workers. More details about tokenomics can be found here

How can we enhance simplicity and ensure constant availability?

The initial setup for SGX is complicated, but we handle all of that for you - and it's a one-shot deal. In our implementation, SGX provers must be registered on L1 before they can verify TEE proofs. After being deployed to Intel SGX, a prover can generate a Remote Attestation Report. We can verify the report to ensure: that (1) the prover is running the correct code inside Intel SGX, and (2) a key pair (pk, sk) was generated by the correct code.

Verifying the report in EVM can be tricky because the report is large (about 20kb), and its verification involves JSON parsing and unsupported cryptography (secp256r1, sha256, etc.). To solve that problem, we propose building the report verifier in ZK. Check out our reference implementation in Risc0.

Another problem arises in having a single prover: we cannot ensure high availability if we are just running the prover (especially the zk-prover) on a single node. In our solution, every sgx-prover will be deployed on a worker cluster. Every worker in the same cluster will hold a copy of the deployed code and will sync the execution state via the Phala blockchain. See here to understand how the cluster works.

The Powerful TEE Network Making It Happen

Phala Network aims to serve as the co-processor of blockchain by leveraging TEE technology and Zero-Knowledge Proofs, addressing privacy and scalability problems in the ecosystem. Compared to other TEE-based multi-proof solutions, we operate the largest decentralized TEE network, with over 30k devices registered and run by people worldwide. We have built an infrastructure called Phat Contract that allows developers to build TEE-based applications, seamlessly interacting with any EVM-compatible chains.

As per the research by Andrew Miller, we are the top secure TEE projects. Check this blog we posted for more details about how we design our protocol to make it secure and reliable.

What's Next

• Searching the possibility of TEE-based fast finality

Under the multi-proof mechanism, zk-prover and TEE-prover can produce proof in parallel. Usually, TEE proof will be submitted ahead of ZK proof because it has less overlap. It's theoretically possible that we can bring fast finality based on TEE-proof, only providing ZK proof when possible.

• Tailoring the blend of ZK-Proof and TEE-Proof based on specific needs

We can combine the ZK-proof and TEE-proof according to demand. Not all use cases are sensitive to high security, For those scenarios that can tolerate low security, we can allocate more percentage for TEE-proof and less for ZK-proof (e.g. Taiko zk-Rollups has 99% TEE only, and 1% ZK + TEE proof).