993 commits this week Aug 13, 2019 - Aug 20, 2019

Merge #15

15: relay transactions Byron to Byron and Byron to/from Shelley r=avieth a=avieth

Design overview

The Mempool from nodeKernel is exposed, and used by withByronProxy in two ways:

  1. To back the cardano-sl KeyVal for transactions, which controls transaction relaying to/from Byron peers. This implements Byron -> Proxy -> Byron and Byron -> Proxy -> Shelley motion, since adding to the mempool will be observed by the Shelley side.
  2. To sendTx new transactions to Byron entering the mempool. This implements Shelley -> Proxy -> Byron motion. Note that transactions added from the Byron side may (and probably will) also trigger this sendTx, but this duplicate announcement is ok: peers which don’t want it won’t ask for it.

Item 2 is implemented by a thread which holds a TicketNo of the highest transaction so far sent. It blocks (retry) until there are transactions in the mempool higher than that ticket, sends them all, then continues with the new ticket number. sendTx blocks until a response is received, so it’s possible that some transactions will leave the mempool before being sent. That’s acceptable.

Item 1 requires an index on TxId ~ Hash Tx from cardano-sl to TicketNo, because the Byron-side API is completely hash based. That index is kept up by a thread which uses the mempool snapshot and STM to maintain a TVar (Map TxId TicketNo), which is used by the transaction KeyVal.

Conversion to/from Byron and Shelley transaction types are required. There are

toByronTxAux :: GenTx (Block cfg) -> CSL.TxAux

fromByronTxAux :: CSL.TxAux -> GenTx (Block cfg)

They’re implemented by way of “recoding”. toByronTxAux decodes the tx and witness individually from the annotations (GenTx (Block cfg) has ByteString annotations). fromByronTxAux encodes the Byron tx then decodes it to the Shelley tx. That’s needed because we must have the ByteString annotations.

Co-authored-by: Alexander Vieth [email protected]