Skip to content
Snippets Preprocessor error 

    [Errno 2] No such file or directory: 'worker/executor_finished.md'

Worker

Purpose

Workers are one of the mempool engines and, in V2, they are the only one and there is only a single worker.

The worker receives transaction requests from users and solvers and batches these transaction requests, assigning a unique TxFingerprint to every new transaction. Each transaction candidate will be sent to an Executor inside an ExecuteTransaction message. Once the worker has received a KVSLockAcquired for every part of the transaction request's label (from the shards of the same Anoma validator in response to KVSAcquireLock-messages), it knows that this transaction candidate has been "seen" by all Shards, which implies that all shards are prepared to process lock requests from execution processes (see KVSReadRequest and KVSWrite for details). This information about locks being recorded is distributed to all shards via UpdateSeenAll messages, which contain the most recent TxFingerprint for which it is certain that all Shards have "seen" this transaction candidate and all previous ones from the same worker (and they are thus prepared to grant locks). Note that if shards receive transaction candidates in a different order than the final total order of transactions, UpdateSeenAll messages are necessary to avoid that shards grant locks before all locks of previous transaction executions have been served.

Workers also are in charge of collecting and curating logs of transaction execution. Success is equivalent to all reads and writes being successful and an ExecutorFinished-message from the executor that was spawned to execute the message.

State

Each worker keeps track of

  • the current batch number (consecutively numbered)
  • a unique TxFingerprint for each transaction candidate, at least in previous batches

There is no precise state representation described by the V2 specs.

Todo

the following almost certainly are not the template we want -->

ExecutorFinished

--8<-- "worker/executor_finished.md:blurp"

Details

--8<-- "worker/executor_finished.md:details"

TransactionRequest

--8<-- "worker/transaction_request.md:blurp"

Details

--8<-- "worker/transaction_request.md:details"

ExecutorPIDAssigned

--8<-- "worker/executor_pid_assigned.md:blurp"

Details

--8<-- "worker/executor_pid_assigned.md:details"

KVSLockAcquired

--8<-- "worker/kvs_lock_acquired.md:blurb"

Details

--8<-- "worker/kvs_lock_acquired.md:details"

RequestLogs

--8<-- "worker/request_logs.md:blurb"

Details

--8<-- "worker/request_logs.md:details"

Todo

we need to find better places for these footnotes

  1. It might be too expensive to check from genesis; transaction requests could have a parameter for how long the duplicate check is active. ↩

  2. This condidtion can be added to avoid too many waiting/idling executor processes. (This comes at the price of a sliver of additional latencey for the first transactions in a batch.) Note that this cannot lead to deadlocks as the lock acquisition messages (KVSAcquireLock,KVSLockAcquired,UpdateSeenAll) are completely independent of spawning transactions. In more detail, if we were missing a KVSAcquireLock message for a transaction, the executor could not start operating (even if it is spawned). ↩

  3. This can be done by use of a executor process supervisor in the implementation. ↩

  4. In all future versions of Anoma, workers will be organized around primaries; however, in V2, we can omit primaries as they do not serve any purpose. In V2, there is only a single worker, which can be though of as featuring also as its primary. ↩

  5. In future versions, IO is output of results from the responsible workers (and their fellow/mirror workers) to some fixed address. Inputs may allow for non-trivial validator inputs, according to a orthogonal protocol (an may fail deterministically). ↩

  6. In V2, we report all the data about a single transaction back to the submitter as part of execution. --> ↩