# 20230220 - Andrew Q&A

> hey Shelven, we are writing some follow up paper mostly focusing on new vuln disclosures in Secret but explaining some differences between Obscuro Phala Oasis also.

Hi there, good to chat again.

> I have a couple of follow up questions from last time basically!
> First - while Phala is an L2 for Ethereum, is it the case that the Phat Contracts are written in rust/wasm? Basically I'm trying to see if pruntime contains evm code or mainly only wasm
> wiki.phala.network/en-us/build/stateless/language-basic/ following with this basically

Phala is not an L2 for Ethereum, we are a parachain of Polkadot (and Khala is the parachain for Kusama). Our Phat Contract is running off-chain so technically it can serve any blockchain, and we say it's the missing computation unit for Ethereum smart contract for commercial reasons.

To write Phat Contract you will need to use [ink! language](https://github.com/paritytech/ink). It's a Rust-based DSL and is finally compiled to WASM.

There is no EVM code in Phala runtime (pRuntime in short, it's in SGX). We implement the WASM runtime in pRuntime which is mainly a migration of the [pallet-contracts](https://github.com/paritytech/substrate/tree/master/frame/contracts) from Substrate SDK. Of cource we replace the underlying implementation to the off-chain version, and we call it [pink](https://github.com/Phala-Network/phala-blockchain/tree/master/crates/pink) (Phala ink! runtime).

> mainly we're looking at;
> - how the TEE execution provides state consistency / ensure you can only execute transactions after > they've been committed/finalized?

In Dotsama ecosystem, actually a parachain does not provide blocks itself. The Polkadot/Kusama serves as the relaychain to produce blocks for all the parachains. And pRuntime only accepts the blocks that are already finialized (we implement a light client in pRuntime).

Also in Polkadot concensus, there is no revert after blocks are finalized.

> - how the TEE execution interacts with persistent storage like SSTORE/SLOAD in evm. Does it leak exactly which record is being accessed?

We don't support EVM so no SSTORE/SLOAD support either. But ink! contract also can read/write storage, and this is done through the [host functions](https://github.com/paritytech/substrate/blob/master/frame/contracts/src/wasm/runtime.rs#L1004-L1012) in ink! runtime.

The official ink! contract is running on-chain. To move it off-chain, we mainly replace its storage to a [TrieDB](https://github.com/Phala-Network/phala-blockchain/blob/master/crates/pink/src/storage.rs) in SGX memory. All these logic is in SGX so no leakage.

> - replay protection in the application state storage, like does it check a merkle trie on each read?

Yes, the merkel trie check happens at the first place when the block is synced to our pRuntime following the light client (implementation [here](https://github.com/Phala-Network/phala-blockchain/blob/master/crates/phactory/src/prpc_service.rs#L163-L287)).

> I see there's like a "get" method implemented in pink storage, i think this relates to this comment from whitepaper:
> "Contract states are encrypted and checkpointed on the blockchain with a symmetric key"
> How does this work, what happens if your contract state is really large, does it decrypt the entire thing at once? (I know the point isn't to have an ERC20 token implemented in phala contract but i guess thats what im asking about :p)

This may work in an undesired way.
- Only transactions are stored in blocks on-chain, not contract states. The latest contract states are only available in our off-chain workers (in SGX memory, so encrpypted) and are never written back to chain. Now we keep some checkpoints in local filesystem with SGX sealing as cache, but workers can always replay all the historical transactions on-chain from the start. FYI, the transactions to a contract are also end-to-end encrypted using ECDH with ContractKey.
- To get the states, you need to query the workers directly. The queries are also end-to-end encrypted using ECDH with WorkerKey.
- One missing part in our key rotation implementaion is the re-encryption of the contract states, since all the ContractKeys are changed with the MasterKey rotation. Now it's not a problem for the Phat Contract release since there is no historical contract states, but will be when we enable the regular key rotation after release. The general idea is to set a period of time for the workers to update the in-memory TrieDB to amortize the cost.