The client sends a transaction on a service that requires consensus and may write to state. The transaction is limited in execution to a time window. This is to avoid duplication (will not execute twice) and to kill transactions that are pending execution for too long.
The response is synchronous, so if the node takes a short while to figure out the response, the client blocks. Processing requires an active subscription on the virtual chain.
Transaction is processed under consensus (this is part of the continuous block creation flow as this flow ends when the transaction has been added to the pending pool and propagated to all nodes). Transactions are performed serially since their side effects can influence one another.
-
Client
ClientSdk
-
Gateway node
PublicApiTransactionPoolVirtualMachineProcessorStateStorageCrosschainConnectorGossip
-
All other nodes
GossipTransactionPool
- No assumptions on synchronization.
-
ClientSdksends request toPublicApi. -
PublicApiof gateway node:-
Adds the transaction as pending to
TransactionPool. -
TransactionPoolof gateway node:-
Executes pre order checks by calling
VirtualMachine. -
VirtualMachineof gateway node:- Executes the subscription check smart contract on the native
Processor. - Depending on contract code may reads state from
StateStorageorCrosschainConnector.
- Executes the subscription check smart contract on the native
-
Adds transaction to pending transaction pool.
-
Prepares a batch of transactions for gossip and signs them as their gateway.
-
Broadcasts the batch to all nodes with
Gossip. -
TransactionPoolof all nodes:- Checks the batch signature of the gateway and adds transactions to pending pool.
- Waits until the transaction is committed to the blockchain under consensus (added to a new block).
- This is part of the continuous block creation flow.
- This process may take a few seconds.
- After it is committed, it's moved from the pending pool to the committed pool in all nodes.
-
Returns the result to
PublicApi.
-
-
Responds to the client.
-
