Deterministic parallel execution of applications
The blockchain consensus depends on deterministic (reproducible) behavior. This means that all parallel executions should be free of mutual exclusions or other blocking primitives. In the absence of locks, there must be some way to ensure that all accounts can only read and write their own private databases. This also means that each account processes messages sequentially and that parallelism will be at the account level.
In COFFE Multichain, the tasks of the block producer include organizing the delivery of Action to independent streams so that they can be evaluated in parallel.
The status of each account depends only on the Actions delivered to it. Transaction planning is the output of the block producer, it will be deterministic but the planning process does not have to be deterministic. This means that block producers can use parallel transaction scheduling algorithms.
The parallel execution part means that when the script generates a new Action, it is not delivered instantly instead its delivery is scheduled for the next cycle. The reason it can't be delivered immediately is because the receiver can actively change its own state in another stream.
Minimizing communication delay
The delay is the time during which one account sends an action to another account and then receives a response. The goal is to allow two accounts to perform a two-way exchange of Actions within the same block without waiting 0.5 seconds between each action. For this purpose, COFFE Multichain divides each block into cycles. Each cycle is divided into streams and each stream contains a list of transactions. Each transaction contains a set of Actions that will be delivered. This structure can be represented as a tree, where alternating layers are processed sequentially and in parallel.
- Cycles (sequential)
- Streams (sequential)
- Transactions (sequential)
- Messages (sequential)
- Recipient and notified accounts (parallel)
Transactions made in one cycle can be delivered in any subsequent cycle or block. Block producers will add cycles to the block until the real time expires or until new transactions are no longer created for delivery.
You can use static block analysis to make sure that there are no two streams in a given cycle containing transactions that change the same account. As long as this invariance is maintained, the block can be processed by running all streams in parallel.
Read-Only event handlers
Some accounts may be able to process an Action on a "passed / failed" basis without changing its internal status. In this case, these handlers can be executed in parallel, provided that only read-only event handlers for a specific account are included in one or more segments within a certain cycle.
Atomic transactions with multiple accounts
Sometimes it is desirable to make sure that Actions are delivered and accepted by multiple accounts atomically. In this case, Actions are placed in the same transaction and both accounts will be assigned to the same stream and Actions are applied sequentially.
Partial assessment of the blockchain status
For the blockchain technology to scale, it is necessary that the components are modular. It is not necessary to run all the services in a row, especially if you need to use only some of them.
COFFE Multichain allows any full node to select any subgroup of applications to work with. Actions delivered to other applications are quietly ignored because the application status is completely taken from the Actions delivered to it.
Subjective scheduling of the best results
COFFE Multichain cannot oblige block producers to deliver any Action for any other account. Each block producer conducts its own subjective measurement of the computational complexity and time required to process a transaction. This applies both to transactions created by the user and to transactions created automatically by a smart contract.
COFFE Multichain provides that at the network level, all transactions are paid for with a fixed cost of bandwidth, regardless of whether they take up execution .01 ms or a full 10 ms. However, each block producer can calculate resource consumption using its own algorithm and measurements. When a block producer concludes that a transaction or account consumes a disproportionate amount of computing power, it simply refuses the transaction when it produces its own block; however, it will still process the transaction if other block producers consider it valid.
In general, as long as at least 1 block producer considers the transaction valid and does not exceed the resource usage limits, then all other producers will also accept it, but the search for such a producer by a transaction can take up to 1 minute of time.
In some cases, the producer can create a block that includes transactions that exceed the permissible limits by an order of magnitude. In this case, the next block producer may decide to reject the block and an equal score will be violated by the third producer. This is no different from what happens when a large block causes network delays. The community would notice the abuse and eventually remove their votes for the fraudulent producer.
This subjective assessment of computational costs frees the blockchain from the need to clearly and deterministically determine how long something will run.