Audit & Test Batching of `TxIn` Array

The observer sends TxIn transactions for the Statechain, for each Binance transaction observed, as well as each Binance Block.

(BChain Blocks are 300ms, so if Statechain blocks are 3 seconds then there should be 10 blocks observed. Each block will generate 0, 1 or 2+ transactions. (most likely 0, occasionally 1).

Here are three Binance Chain blocks, with empty, single and multiple transactions observed. These transaction arrays will sit in state for the Observer, until it receives a commitment hash from the statechain, when it will log them as finalised, since its job is done.

Each block is reported on for 100% coverage, and each transaction includes block height, and transaction count. In this way we can track and audit coverage.

{"blockHeight": 121
 "count": 2
"txArray":     [{ "tx" : XXXX     
              "Amount": "XX"
               "MEMO" : "XXXX"
              "Token": "SYM"}
}
{"blockHeight": 121
 "count": 2
"txArray":     [{ "tx" : XXXX     
              "Amount": "XX"
               "MEMO" : "XXXX"
              "Token": "SYM"}
}
{"blockHeight": 122
 "count": 1
"txArray":     [{ "tx" : XXXX     
              "Amount": "XX"
               "MEMO" : "XXXX"
              "Token": "SYM"}
}
{"blockHeight": 123
"count": 0
"txArray":     []
}

We now now we have 100% coverage of 3 Binance Chain blocks, and the transactions in them. The 2 transactions in block 121 are to be expected, because the count for that block was 2.

These 4 transactions are sitting in the StateChain validator mempool. (they are rapidly propagated, so assume for 4 nodes, all 4 mempools are 100% synced all the time).

The Block Proposer (as part of Tendermint) will be selecting from the mempool and placing into the StateChain, in whatever order it wants. Assuming first-in-first-out, then the order at which the observer reports them should be the order at which they are processed by the validator.

Unique transactions are guaranteed since the TX Hash is always compared.

Exception handling:

  • If a transaction hash exists already and the tx data sent in is identical, then return a message saying it was a duplicate and processed already.
  • If a transaction hash exists already and the tx data sent in is different, then return a message saying it was a duplicate and ignored.

Note: this is the foundation for building Observation Consensus later

Valid transactions are now processed for swaps and staking etc. As each transaction is processed, the final outgoing transaction is built up into the TxOut array (covered here: https://gitlab.com/thorchain/bepswap/statechain/issues/31)

Edited by JP