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

• {KVSReadRequest, KVSWrite}→Shards: In the course of evaluating the executor function, lazy reads are requested, and final writes are output.

• KVSReadRequest to Shard

• KVSWrite to Shard

Todo

make this precise :-/

KVSRead

• from Shard

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

• to Shard: KVSWrite for each value the TransactionExecutable outputs to write send a KVSWrite message to the appropriate Shard
• to Shard: KVSReadRequest for each lazy read the TransactionExecutable now requires, and each lazy read the TransactionExecutable hasn't read when it terminates: send a KVSReadRequest message to the appropriate Shard
• to Worker Engine: ExecutorFinished If TransactionExecutable has terminated then notify the curator specified in ExecuteTransaction

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

• Shard
• Worker Engine
• TransactionCandidate
• ExecuteTransaction
• Executor
• TransactionCandidate
• TransactionExecutable
• TransactionLabel
• TxFingerprint
• ExternalIdentity
• Worker Engine
• ExternalIdentity
• TransactionRequest
• Executor
• Worker Engine
• KVSAcquireLock
• Shard
• KVSRead
• Executor
• KVSReadRequest
• KVSWrite
• Shard
• KVSReadRequest
• Shard
• KVSWrite
• Shard
• KVSRead
• Shard
• Executor
• TransactionCandidate
• Shard
• TxFingerprint
• KVSRead
• Executor
• TxFingerprint
• KVSKey
• KVSDatum
• TxFingerprint
• TxFingerprint
• TransactionCandidate
• Executor
• TransactionExecutable
• TransactionExecutable
• KVSWrite
• Executor
• Shard
• KVSWrite
• TransactionExecutable
• KVSWrite
• Shard
• Shard
• KVSReadRequest
• TransactionExecutable
• TransactionExecutable
• KVSReadRequest
• Shard
• Worker Engine
• ExecutorFinished
• TransactionExecutable
• ExecuteTransaction
• ExecutorFinished
• ExecutionSummary
• TransactionRequest
• ExecutionSummary