Tx Origination

Origination of transactions

In the current implementation of Lachesis, transactions are first sent into a transaction pool (tx pool). This implementation choice is just like the one being used in conventional blockchains (like Bitcoin or Ethereum).

Transaction is called originated when it's included into an event block, check out consensus algorithm. The node that creates the event block containing the transaction is called the transaction's originator.

Conflicting transactions

Unlike conventional blockchains, nodes in Lachesis don't create nor exchange blocks (of the final chain) directly. Instead, transactions are packed into blocks independently based on calculation from events. When a transaction is being originated (included), the validator doesn't yet know exactly the final order which this transaction and some of its previous transactions will be assigned. The final order will be determined by Lachesis consensus engine.

Due to the nature of asynchrony, some originated transactions may fail some checks after they are confirmed, for example, if they conflicted with other transactions from the same sender, or because of occupying tx nonce or insufficient fund for fee+value. If a confirmed transaction is failed, then transaction is called skipped. Skipped transactions are stored within events but don't get indexed - it's impossible to retrieve them from API, just like if they never were originated. Skipped transactions don't consume sender's fee, but do consume originator's gas power as a penalty for originating a conflicting transaction.

Protection from conflicting transactions

Alice is a transaction (tx) sender, Bob is a validator (originator).

• Alice sends her transaction into transaction pool (txpool), exactly as she would do it in the eth62 protocol. The transaction is propagated to all the nodes within period << TxTurnPeriod. Practically, tx is propagated within ~300ms.
• When Bob receives the transaction from his txpool, he memorizes the time when he received the transaction as tx arrival time.
  • Since tx is within Bob's txpool, then tx has already passed the checks within txpool. It means that tx may be executed correctly on top of last finalized block (known by Bob). It is worth noting that tx will get confirmed not in a next block after a "last finalized block", but not less than after 2 blocks (it's not guaranteed when it'll be confirmed due to asynchrony).
• Bob calculates transaction's turn hash = sha3(Alice's address, tx.nonce/TxTurnNonces, current epoch number)
• Bob calculates a deterministic (weighted by stake) permutation of validators against turn hash. The permutation defines the order, in which validators are assigned to originate this tx.
• Bob calculates his turn index = ((now - tx arrival time) / TxTurnPeriod) % number of validators
• If it's Bob's turn (i.e. permutated validators[turn index] == Bob)
  • If Bob doesn't know any unconfirmed (but originated) tx from Alice
    • then Bob originates the tx

Mainnet constants:

• TxTurnNonces = 8
• TxTurnPeriod = 4 seconds

This algorithm implies that Alice's transactions capacity is limited by TxTurnNonces / TTF. If Alice has to send more transactions per second, then she has to send them from multiple addresses.

The chance of originating a conflicting transaction is reasonably low, though it's still possible. As an example, 3.17% of transactions were skipped up to mainnet block 68370.

The clocks on different validators don't need to match, because relative local time (now - tx arrival time) is used, instead of absolute time.

Reasoning of tx pool

The current Lachesis implementation uses transaction pool (txpool), because it has several advantages over direct submission of transactions into a validator (such method is used by some other DAG aBFT protocols):

• User (or wallet client) doesn't need to choose a validator, the validators will decide themselves. It makes wallet's implementation simpler.
• User doesn't need to know validator's IP to submit the transaction. It allows validator to hide his IP behind sentry nodes as a DoS protection.
• User doesn't need to re-submit the transaction if chosen validator is offline or failed to originate the transaction. The network itself will assign a different validator after TxTurnPeriod. Hence it improves availability of the network.
• User has no opportunity to secretly send conflicting transactions to multiple validators simultaneously, provoking them to originate conflicting transactions.