Skip to content

Executor / Executor Process

Conceptually, Executors run the executor function in order to compute transaction outputs, including state updates (see here for more on the executor function). Executors may be co-located with shards, or with mempool workers. The Execution Engines might keep a pool of Executors, or spin a new one up with each TransactionCandidate.

Executor Incoming Messages

To specify the Executor interface, here are all the messages the Executor needs to be able to receive.

ExecuteTransaction

  • from Mempool

Purpose

The mempool engines instruct the Executor that a new TransactionCandidate has been recorded, its locks are being acquired, and will eventually need to be executed.

Structure

Field Type Description
executable TransactionExecutable "code" to be executed post-ordering
label TransactionLabel information about keys that the transaction can rightfully access
timestamp TxFingerprint (partial) ordering information (sufficient for V1)
curator ExternalIdentity the Worker Engine to be informed when execution completes (e.g. for logs)
issuer ExternalIdentity the ID of the sender of the TransactionRequest

Effects

This message is sent to an Executor that is already running. Concurrently, when the Worker Engine sends a KVSAcquireLock to Shards, they can include eager reads, which will result in KVSReads sent to this Executor.

Triggers

Todo

make this precise :-/

KVSRead

Purpose

Executors have to read data from keys to execute TransactionCandidates. When a Shard has determined what the value read is at the appropriate timestamp, it sends a KVSRead to the appropriate Executor.

Structure

Field Type Description
timestamp TxFingerprint the timestamp at which the datum was read
key KVSKey the key from which the datum is read
data KVSDatum the datum read

The timestamp should match the timestamp of the TransactionCandidate for this Executor.

Effects

These read values are input for the TransactionExecutable. Some may be lazy inputs, and some may never be used, but they're all inputs. If this lets us finish the TransactionExecutable, it may trigger KVSWrites (outputs of the executable), and shutting down the Executor entirely.

Triggers

that the transaction is done with an ExecutorFinished. - to User,Solver: ExecutionSummary The issuer of the transaction request is always provided with the ExecutionSummary

(Wiki) links on this page