Design Goals and Principles

Goals

We want to make the SwiftCloud Blockchain Platformfexible.extensible.scalable secure. and better faultisolated. Here is what we mean:

flexible. It should be easy to modify system pa-rameters to accommodate different deploymentscenarios (e.g..constraints on ParaTime nodes)

extensible. The system should be reasonably casyto extend by adding new components to implement different functionality/semantics (eg.. different ParaTimes or different confidential computing technigues].

scalable. The total transaction throughput of thesystem should increase with the total number ofnodes.ideally in a linear fashion.even for complextransaction.Scalability is a form of efficiency atscale, since it allows the system to grow withoutincurring buge expenses and driving up the per-transaction costs.

secure.The system should be able to enforcesecurity policies that are impossible for earlierblockchain systems, allowing a greater breadthof applications.In particular.in addition to thesupporting verifiable computations,the systemalso supports the ability to perform those computations in private, using confidential state / inputs.Furthermore. our system architecture andimplementation should make design choices in favor of sinplicity when feasible: this makes carefuldlesipn reviews and implementation audits morepractical and effective fault-isolated.Fault isolation is a basic component of fault tolerance. We want our system tobe fault tolerant both in terms of security faultisolation, so that a security vulnerability in onecomponent should not compromise the security ofanother component, and in terms of performancefault isolation so that performance problems inone comnponent does not unduly affect the performance in the rest of the system.

The combination of fexibility and extensibility allowsthe development of additional ParaTimes with different security,performance, or usability trade-offsIn particular, the support for confidential smart contracts and improved isolation properties provides bothdevelopers and users more choices in the types of applications that can be built using the SwiftCloud Blockchain Platform.

Principles

We wanted to follow the principle of deriving the simplest and most flexible design possible, while still meeting our goals.The functional decomposition shouldexpose simnple,orthogonal inter-component interfacesExpanding these ideas in our system design resultedin the following: Modular Architecture: We have desiened and implemented a. clear separation between the consensus laver and an independent ParaTime smartcontract execution layer. Simple Consensus Layer: The consensus laver iskept as simple as possible.The consensus component only handles validator committee management operations such as token balance transfer,staking, delegation, debonding; etc; ParaTimecommittee scheduling: and commits of valuesfrom ParaTimes. This helps increase security andefficiency, since (complex) smart contract executions are isolated from consensus operations,comparing well with Layer 2 solutions. Independent ParaTimes: Independent ParaTimesoffer fexibility, since it is easy to incorporate different runtimes for different needs. e.g.: Security requirements. Different ParaTimescan be optimized for confidential smart contracts versuis integrity-only smart contractsPerformance requirements.The referenceParaTime implementation offers no explicit concurrency for smart contract exe-cution.However,multiple instances can berun simultaneously. achieving simple concurrency via explicit separate-world parallelism.Other ParaTimes developed later bythe community can offer greater parallelismusing more advanced techniqucs. Non-technical / external requirements. Forexample, enterprises may require that theit private ParaTimes execute only on a specific designated set, of server nodes, so thatthey run on-premise or within particular le-gal jurisdictions.

SwiftCloud Blockchain Platform Architecture

If a ParaTime is unable to handle its transactionload or fails for whatever reason, the impact onthe rest of system is simply that no state updateswill be submitted from that ParaTime to be com-mitted to the consensus layer. Other ParaTimesare not affected. A ParaTimne cannot subiit toomany values or otherwise spam the consensuslayer, since each ParaTime must pay consensuslayer transaction fees. This provides us with en-capsulation and fault isolation: ParaTimes arcdistinct entities and cannot affect nor interferewith each other. The explicated partitioning between componentsprovides a clear verifiable computing interface. Thisconsensus-ParaTime interface is extensible, though obviously adding interfaces (especially if multiple extantinterfaces can interact/interfere with cach other) canincrease complexity and auditing effort. The reference ParaTime implementation uses discrepancy detectionfor verifable computing, with the detection occurring at the consensus node's ParaTime interface. The use of discrepancy detection enablesa lower replication factor in common fast-path execution,making the verifiable computing immplementa-tion much more efficient and cost effective.