L1 Interop: A Path To Scaling Ethereum’s Liquidity
Unlock native Ethereum DeFi liquidity for ZKsync and ZK Stack chains with fast, trustless L1 interop.
ZKsync Blog > ZKsync Trusted Execution Envir...
Published Jan 13, 2025
ZKsync Trusted Execution Environment Proofs
This article explains Trusted Execution Environments (TEEs), focusing on Intel's Software Guard Extensions (SGX) and their uses in enhancing blockchain security on ZKsync Era. It covers the key features of TEEs, introduces SGX, and details ZKsync TEE proofs, which include cryptographic signatures and SGX attestation reports.
The article also provides instructions on how to verify these proofs using the verify-era-proof-attestation tool with Docker. The main takeaway is understanding how TEEs improve blockchain security through isolated, secure computations and how to verify these proofs programmatically.
What is a TEE?
A Trusted Execution Environment (TEE) is a secure area inside a hardware device to protect sensitive operations and data from external attacks or unauthorized access. It provides an isolated environment where encryption, decryption, authentication, and other security-critical functions can be executed while ensuring confidentiality and integrity.
Key features of TEEs include:
- Isolation: The TEE is isolated from the main operating system and applications running on it, making it more difficult for attackers to access or tamper with the data being processed within the TEE.
- Hardware-Based Security: Many TEE implementations leverage hardware security features such as Trusted Platform Modules (TPMs), secure enclaves, or hardware-based encryption accelerators to enhance security posture.
- Attestation: TEEs can provide attestation services, allowing other systems to verify certain TEEs ran the correct computation on the correct data.
- Confidential Computing: TEEs enable confidential computing by ensuring that data processed within the environment remains encrypted and protected from both software and hardware vulnerabilities outside the secure area.
- Secure Key Management: They facilitate secure management and storage of cryptographic keys, which are essential for encryption and decryption processes.
TEEs are widely used in various applications such as financial transactions, mobile payments, identity verification, IoT security, and more. TEEs help protect against data breaches, malware attacks, and other cybersecurity threats by providing a trusted environment for sensitive operations.
What is SGX?
Intel Software Guard Extensions (SGX) is a specific type of TEE built into modern Intel processors. SGX provides a way to isolate specific portions of memory on a device to create an enclave, which is a protected area of execution where code and data are secure and cannot be accessed by any process outside of the enclave. This includes even privileged processes like the operating system or hypervisor, offering a strong defense against many forms of security threats.
Why does ZKsync use TEEs?
ZKsync already uses ZK to prove the validity of the chain. Why do we also use TEEs? One reason is that TEEs can further verify the ZK computation. By using both ZK and TEE provers (multiprover architecture), the chain is even more secure. Another reason is that TEEs are faster than ZK Proofs, so TEEs can help make interoperability between ZK chains faster.
What are ZKsync TEE proofs?
Note*: This section is only meant for developers who want to run our attestation verification tool. If you are not a developer, you can skip to the end! *
The ZKsync TEE proof consist of a cryptographic signature of the block root hash in addition to a SGX attestation report, which contains the signing public key in its report user data. The signing key pair is created inside the TEE and changes every time the TEE starts up. The SGX attestation report is signed by the CPU, which is signed by Intel. The SGX attestation report contains the hash sum of the TEE, called mrenclave.
What are the mrenclave values?
The mrenclave hex strings represent a SHA sum. The initial state (memory, mode of operation, etc.) of the program loaded in the TEE (SGX enclave) is measured and a SHA sum is calculated. This SHA can be calculated beforehand from the executables and assets. So by rebuilding the TEE contents from source reproducibly and getting to the same hash, we can verify that the TEE was running the source.
What does the ZKsync TEE prover prove?
The TEE prover is given all input and the expected partial state merkle tree, which produces the block root hash. Now the TEE prover runs the transactions in its VM and checks at the end, that the same merkle tree was produced. If that was the case, it signs the root hash with its signature key.
Running the verify-era-proof-attestation tool
At the time of writing this, ZKsync Era has TEE proves from block 493218 on. To verify those programmatically, we use the verify-era-proof-attestation tool. For portability reasons, the tool is shipped as a docker container. Check with --help for more arguments.
The source code for this can be seen in the teepot repository and this document uses version v0.4.0.
The TEE prover from the zksync-era repo has mrenclave 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65 for version (https://github.com/matter-labs/zksync-era/tree/core-v25.0.0) core-v25.0.0 and 6fb19e47d72a381a9f3235c450f8c40f01428ce19a941f689389be3eac24f42a for core-v25.1.0.
Run this on an x86 Linux computer to verify all batches from 493218 to the current:
docker run --env RUST_LOG=INFO -i --rm matterlabsrobot/verify-era-proof-attestation:v0.4.0 \
--log-level=info \
--rpc https://mainnet.era.zksync.io \
--sgx-allowed-tcb-levels Ok,SwHardeningNeeded \
--mrenclaves 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65,6fb19e47d72a381a9f3235c450f8c40f01428ce19a941f689389be3eac24f42a \
--continuous 493218This should verify all blocks until at least block 494489:
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493218 signature=f7feaeba077215e9fe693a95ff484f373a64a237feb939966e4299c0cb5dadf720b29aa590b30fe3fcfba1208602186caa49c43418d88cb1f2e09fbbabbf8887
INFO verify_era_proof_attestation::verification: Quote verification result: SwHardeningNeeded: Software hardening is needed. mrsigner: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d, mrenclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65, reportdata: 02cf1142c91c34219560616ca7b51774bb34dab9108283c3c97b68a9d26b8c9e1400000000000000000000000000000000000000000000000000000000000000. Advisory IDs: INTEL-SA-00615.
INFO verify_era_proof_attestation: Verification succeeded. batch_no=493218 proof.proved_at="2024-11-13T11:04:39.202856Z" tee_type="SGX"
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493219 signature=c8c08c32fec52dc9f315e24c6710220a461da61bea78db690df416b1294a57b1492661e8ec539ee0a98b7bb9d1eb6bab92771694b6eccdf57e77e7208a9c7152
INFO verify_era_proof_attestation::verification: Quote verification result: SwHardeningNeeded: Software hardening is needed. mrsigner: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d, mrenclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65, reportdata: 02cf1142c91c34219560616ca7b51774bb34dab9108283c3c97b68a9d26b8c9e1400000000000000000000000000000000000000000000000000000000000000. Advisory IDs: INTEL-SA-00615.
INFO verify_era_proof_attestation: Verification succeeded. batch_no=493219 proof.proved_at="2024-11-13T11:05:16.664133Z" tee_type="SGX"
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493220 signature=e836d0b209bb35aea6b19480bdf4747670d3bbebeeadce5dd7cadb5d08e2d73d3a219a13158b9e3d3ee36004c79c391373f2f9ebebd6a18e0aabf98a65f04580
INFO verify_era_proof_attestation::verification: Quote verification result: SwHardeningNeeded: Software hardening is needed. mrsigner: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d, mrenclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65, reportdata: 02cf1142c91c34219560616ca7b51774bb34dab9108283c3c97b68a9d26b8c9e1400000000000000000000000000000000000000000000000000000000000000. Advisory IDs: INTEL-SA-00615.
INFO verify_era_proof_attestation: Verification succeeded. batch_no=493220 proof.proved_at="2024-11-13T11:05:54.828465Z" tee_type="SGX"
INFO verify_era_proof_attestation::verification: Signature verified successfully. batch_no=493221 signature=15a66df5c078cee10d9d8ee889730141cf2dbfa021f0ded22955e954ccd6917838b96a84d680b21a468c85c7d62a687af58e82e91d3defc846edac0e6478f576
(...)The next used mrenclave value for v25.2.0 is expected to be 2174b836363c1def6e6893b07839753351e10199fc0b489c2233b516e244ec9d.
How can I verify the mrenclave values?
On a fast x86 Linux system with docker installed, run:
git clone --recurse-submodules https://github.com/matter-labs/zksync-era.git
cd zksync-era
git switch --recurse-submodules -c b25.0.0 tags/core-v25.0.0
docker run --privileged -it -v .:/mnt nixos/nix:2.18.1Then run inside the container shell and answer all question with N.
echo 'experimental-features = nix-command flakes' >> /etc/nix/nix.conf
echo 'sandbox = true' >> /etc/nix/nix.conf
cd /mnt
nix build -L .#container-tee-prover-azure
cp result oci-image.tar.gzIt will run for a long time, and build a lot of software from source. After it is finished, don’t close the session, but switch to another terminal in the zksync-era directory and run:
export IMAGE_TAG=$(docker load -i oci-image.tar.gz | grep -Po 'Loaded image.*: \K.*')
docker run -i --rm $IMAGE_TAG "gramine-sgx-sigstruct-view app.sig"Which gives the following output:
Attributes:
mr_signer: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d
mr_enclave: 1b2374631bb2572a0e05b3be8b5cdd23c42e9d7551e1ef200351cae67c515a65
isv_prod_id: 0
isv_svn: 0
debug_enclave: FalseNow, let’s checkout tag core-v25.1.0 from the non-container/host shell:
git switch --recurse-submodules -c b25.1.0 tags/core-v25.1.0Back to the container shell and still answer any questions with N:
nix build -L .#container-tee-prover-azure
cp result oci-image.tar.gzThis build should be faster, due to most artifacts already built.
Back to the outside host shell:
export IMAGE_TAG=$(docker load -i oci-image.tar.gz | grep -Po 'Loaded image.*: \K.*')
docker run -i --rm $IMAGE_TAG "gramine-sgx-sigstruct-view app.sig"Which gives the following output:
Attributes:
mr_signer: c5591a72b8b86e0d8814d6e8750e3efe66aea2d102b8ba2405365559b858697d
mr_enclave: 6fb19e47d72a381a9f3235c450f8c40f01428ce19a941f689389be3eac24f42a
isv_prod_id: 0
isv_svn: 0
debug_enclave: FalseThose mr_enclave values should match those used previously in the verify-era-proof-attestation tool.
What’s next for ZKsync TEEs?
In 2025, you can look forward to TEEs helping with ZKsync’s interoperability, as well as acting as a security backup for ZK proofs.
If you’d like to get in touch, join our Discord.
Share the article
More from ZKsyncView all
From Individual Chains to Network Economies: $ZK Token Proposal, Part II
Introducing the ZK Stack's Atlas upgrade: beyond 15K TPS with one-second ZK finality
The ZKsync team is excited to share details of the Atlas upgrade for the ZK Stack, which provides a major step forward towards the vision of a network of sovereign chains, secured by cryptography and powering the global economy.