Architecture Overview

The main components:

• Consensus laver.The consensus layer accepts yal-ues from its clicnts (the ParaTjmes) and writesthese values into the next block in our blockchain.The consensus layer also includes the necessar)machinery for yalidator and ParaTime commit.tee selection,and for handling the consensus-]ayeror “native” token operations, which are noexledfor its own managernent.The meaning of thevalues generated by a ParaTime is entirely defined by that ParaTime.so a ParaTime could bebuilt that only supports Bitcoin-like transactionsor even document timestamping.Note thathere we are mainly concerned with ParaTimesthat support smart contract exccution and willnot discuss these other uses below.

• ParaTimes.ParaTimes are where smart contractexecution occurs.Each ParaTime defines its ownsmnart contract execution environment and the semantics for the interfaces it exposes, and choose!the mechanisin and associated parameters (e.g.the degree of server replication] used to verify results of contract execution.Al ParaTimeswill support some notion of event scquencingtypically transactionssince ParaTimes commitvalues to the consensus layer. While they are possible. we do not consider non-transactional. nonverifiable computing ParaTirme designs below.A ParaTime may include:

-Kev managers.ey manarers are onlyneeded forTEE-based confidential ParaTimes,since the TEE-based ParaTime compute nodes store encrypted contract state;key managers are not needed for FHE-basedconfidential ParaTimes or non-confidentialParaTimes.

-Committee selection pool criteria.e.g..whenthe ParaTime uses a totating set of Compute nodes for replicated computation,what requirements are there fornodes to qualify beyond simple stake thresholds?

The consensus layer provides only a specific set oconsensis-backed services and no direct support forconfidential computing. These services are (1) nativetoken operations such as transfer, staking.delegationetc;(2) validator committee selection; (3) ParaTimecomtnittee selection:(4 ParaTime results yerificationand (5) commitment of werified ParaTime results to ablockchainIn particular.this means that native tokenaccount balances and transfers are not confidentialThe native token is used for staking and commitmentbrocessine fees.

Verifiable comnputing is implemented at the consensls node's ParaTime interface. The only verification mechanism that is currently implemented isdiscrepancy detection. It is generic in that multipleParaTimes can use it,with a separate instance otthe mechanismm for each ParaTimewith ParaTimespecific interface endpoints. The replicated ParaTimenodes are where smart contract execution occurs; theyaluc delivered to the consensus-ParaTime interfaccis the Nerkle hash of the new ParaTime state thatresulted fom contract execution.The discrepancydetector can either accept a result to pass onto theblockchain codde for consensus processing, or reject results as unverified signaling the ParaTime layer toperform exception,“slow-path” processing.

Confidentinlity for smart contract execution is inplemented solely within ParaTimes. For ParaTimesthat use techniques such as FHE.an observer of thecontract state cnnot determine what it is doing unless the observer has the cryptographic keys that en-crypted the input values for the FHE contract. ForParaTimes that use TEE-based computation, contractexecution occurs within the TEE environment.andcontract state is encrypted before being stored. Because of this.both the ParaTime compute nodes andthe key manager are jointly responsible for contractstate confidentiality. and mutual authentication viaTEE-based remote attestation is critical. Regardlexsof the confidentiality technique used, the value passedto the consensus layer is a Merkle hash of the encrypted ParaTime state, and thus leaks no information as long as the state encryption leaks no information.

The reference confidential ParaTime implementa-tion uses the TEE-based approach to achieve rensonable performance.Smart contract developers canchoose amnong the availahle ParaTimes based on whichof them satisfies their application's security needs, andif none suffices, they can propose their own ParaTimeas a ParaTime developer.