# Why PREDA

In the realm of Bitcoin and Ethereum networks, the transactions per second (TPS) are capped at a reasonable threshold, as each smart contract executes on a sequential ‘virtual machine’. **The EVM executes transactions one by one.** It doesn't execute other transactions until the execution of the current transaction is completed and the resulting state is computed.

However, could the tasks be distributed across multiple virtual machines to surge the overall TPS?

This is where state-of-the-art [multi-chain networks](https://coinmarketcap.com/alexandria/glossary/multi-chain) emerge. They lay claim to elevating TPS through the collaborative processing capacity of multiple chains. Here, a smart contract executes on a single dedicated VM, allowing the distribution of transactions involving multiple smart contracts across multiple VMs based on their multi-chain architecture.

Now, the question is, are transactions involving each smart contract evenly distributed? The answer is negative.

**In reality, a significant portion of transactions are executed by a limited number of contracts,** constraining the processing capacity of a single smart contract, even when dealing with a substantial transaction volume, to a sequential virtual machine.

<figure><img src="https://3142435605-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZTe9DaPXLrFy1CRilHQU%2Fuploads%2F81Aq3iOkJHF3XtF2rP9Z%2Fimage.png?alt=media&#x26;token=07e4ec88-541f-4a53-a0df-05bff674a60f" alt=""><figcaption></figcaption></figure>

Existing multi-chain networks, therefore, have not fully addressed the issue.

Meet PREDA, the revolutionary programming model that allows transactions, even those involving a single smart contract, to be divided and processed using an array of independent VMs, harnessing the total processing power of the entire network.

Let's consider how a transaction is executed in PREDA.

A smart contract is an object which has some _storage_ and _behavior_. In PREDA, the smart contract states include _address, balance,_ and others. When executing a transaction, it follows the pattern below:

* By default, smart contract states are automatically divided by address.
* When needed, developers are provided with the flexilibity to customize the dividing scheme of states in a smart contract. The divided states are distributed across an array of independent Dioxide virtual machines with no overlap.
* something happens (the most common situation is that a contract gets a bunch of transactions)
* A contract handles the transaction by executing its code
* If the logic flow of execution depends on the states maintained in another virtual machine, a functional relay is triggered. The execution continues by moving the execution logic to the other virtual machine.
* contract states are modified (address, balance, and others)
* A bunch of transactions follow a similar pattern, executing in parallel, as described above.

#### PREDA Key Features[​](https://docs.dioxide.network/doc/Introduction/Why%20PREDA#preda-key-features) <a href="#preda-key-features" id="preda-key-features"></a>

**The Preda model introduces two pivotal features, "Programmable Scopes" for smart contract state division and "Functional Relay" for handling asynchronous calls dealing with data dependency.**

**‘Programmable Scopes’ describes the dividing scheme of smart contract states into non-overlapping independent parts.**

In PREDA, the divided smart contract states are maintained across distinct Virtual Machines (VM) independently. When transactions execute on one VM, they never access to the states residing on other VMs. As a result, independent VMs can be deployed on different computers with dedicated network and computing resources. The expansion of computers translates to increased processing power.

In blockchain, even the execution of a simple transfer may depend on different parts of the contract states. However, when the contract state is divided into multiple parts and executed as several independent state machines, none of the individual state machines maintain all the contract state parts required for that particular execution.

**This is where the new challenge arises: handling the logic coupling between smart contract code and contract states. In PREDA, this hurdle is addressed by the "Functional Relay" mechanism.**

In conventional multi-chain blockchain systems, attempts to move and lock required data between independent state machines have failed. PREDA takes a different approach, it moves the logic flow of execution around based on data dependencies, meaning the logic flow of execution is relayed across different independent state machines with the underlying blockchain to efficiently schedule the "Relay-Execute" process. In this process, PREDA limits a code segment's access to a ‘state scope’, ensuring its data dependencies align with an independent state machine's capabilities.

PREDA's programming model facilitates a distributed array of independent state machines, where "Programmable Scopes" for state division and "Functional Relay" for handling asynchronous calls dealing with data dependency.

At the underlying blockchain layer, multiple independent transaction execution units, like chains or parachains, are essential. Each independent state machine remains oblivious to the contents maintained in other machines, enabling their deployment on different physical computers or even data centres located in diverse geographical regions.
