Check and initiate double spending resolution on received network transactions

[gnulib]

Objective

A honest node should validate a received network transaction against any previously seen transaction from same submitter and sequence ID, so that double spending situation can be prevented.

Assumption

• a double spending transaction can only be “received” on the network (since on a honest node submission will reject a double spending transaction)
• a honest node should not be forwarding 2 different transactions with from same submitter and sequence
• hence a received double spending transaction from a honest peer means that peer does not know anything about local competing transaction (yet)

Acceptance Criteria

As per "A simple double spending resolution protocol" rules described in #30, a honest node should check a received network transaction if it has a sequence number matching another transaction from that submitter already known/recorded by DLT stack, and initiate double spending resolution for such cases as following:

Step 1: Check Current Sequence

• if Submitter history has a transaction with same submitter ID and Seq then:
  • if id of the local transaction is same as remote transaction then discard (seen transaction)
  • else, if shard id of the two transactions are same then trigger double spending alert (double spending)
  • else (i.e. shard id of the two transactions are different) then continue to next step (relaxed sequence requirement)
• else (i.e. submitter history does not have any transaction for submitter seq) then continue to next step

Step 2: Check Previous Sequence

• if Submitter history has a transaction with submitter ID and last Seq then:
  • if the id of the local last seq transaction is different from id of the received transaction's last submitter tx then:
  • if the shard id of the two transactions is different then trigger a submitter sync with the peer (submitter fork sync)
  • else (i.e. shard id is same) then its a diversion, reject and disconnect with peer (diverged peer)
    • Q: Is is possible for this situation to occur between honest nodes (e.g. just by n/w partitioning)?
    • A: To be confirmed... 'coz if this situation can occur in honest cases, then we have a thrashing and DoS vulnerability!!!
    • Based on "Step 1" check above, this condition should not happen between any two honest peers. When peers exchanged the parent TXs, it would have triggered the double spending alert and TX's would not have been added to history
  • else (i.e. id of local last seq tx and received transaction's last submitter tx is same) accept (all check pass)
• else (i.e. Submitter history does not have any transaction as last seq for the submitter)
  • trigger a submitter sync with the peer (submitter history sync)

---

Old

• if Submitter history has a transaction with same submitter ID and Seq then trigger double spending alert // double spending
• else, if Submitter history has a different transaction as last submitter transaction then trigger double spending alert // unknown ancestor
  • (Why?)
  • Option A: a different parent/last transaction from a submitter means this transaction came out-of-sequence from its parent, hence reject and drop connection (peer should not have sent out of sequence, let it reconnect and handshake, hoping that correct parent transaction will come through eventually)
  • Option B: a different parent/last transaction from a submitter means peers are already diverging, so better to initiate a submitter sync between peers (i.e. discard out of sync submitter transaction, but initiate submitter sync between peers)
• else, if Submitter history does not have any transaction as last seq for the submitter then reject transaction as out of sequence transaction // out of sequence
• else proceed with handling the transaction normally

[gnulib]

Relaxed Sequence Requirements

Q: When either an unknown ancestor transaction is received (i.e. last submitter seq tx on local node is different from peer's last submitter seq tx), or a double spending transaction is received (i.e. local submitter seq tx is different from peer's submitter seq tx) -- do we need to sync submitter history? What if the two shards are different?
A: Depends! The absolute MUST is that there must not be 2 different transactions with same submitter ID and Seq for same shard. So, if the shard ID for the 2 different transactions are different, we are safe to accept the transactions. This would basically be similar to submitter client maintaining separate sequences for each shard they work with. Our assumption for using a single sequence across all shards is a "stricter" requirement, to help simplify submitter implementation and implicitly provides more than enough protection.

This is being called relaxed sequence requirement

Do we really need to relax?

The only reason we are considering relaxation is to resolve a specific condition when:

• there are 2 different transactions from a submitter with same seq
  (ideally, should not happen, based on our requirement for submitters to maintain correct sequence)
• the two different transactions were intended for 2 different shards/applications
  (resource visibility is limited within a shard, so transactions cannot make changes across shards)
• transactions were submitted to two different nodes separated by network latency
• two transactions propagate across the network, resulting in a virtual network partition
• eventually two honest peers exchange the two differing transactions

With above condition, its non-deterministic to resolve the situation, since two transactions are intended for different shards. There is no good way to sync the two peers, since different shards are impacted. However, due to the fact that "resource visibility is shard specific", this situation does not results in double spending, since transactions cannot update same resource. Therefore, it is safe to let the transaction go through without requiring any of the shard to be flushed/re-synced.

Situation is resolvable when shard ID of the two transactions submitted across network is same. Since both transactions occur on same shard, it has double spending situation (both transactions can update same resource). Therefore, in this case when peers exchange the transactions a sync can be done deterministically for that single shard.

Impact of relaxed sequence requirement to Tx submission

Q: Is is possible to determine with accuracy whether a node accepted multiple transactions from a submitter for same seq?
A: We can check the "node id" in Tx anchor to determine whether same node accepted two different transaction from submitter for same seq across different shards.

Q: If we relax our sequence requirement, then why should we require the DLT stack to still check for uniqueness of submitter seq across all shards?
A: With relaxed requirement, it may not be necessary anymore to require DLT stack to impose uniqueness constraint across all shards. A node may choose to impose uniqueness for specific shard only. If in future we extend DLT stack to support multiple app registrations simultaneously, then it will be desirable for have node only enforce uniqueness within specific shard.

[gnulib]

Relax sequence check at endorser

Endorsement layer need to relax the sequence history check as following:

• DAG node key would continue to be "submitter id" + "seq"
• DAG would keep a "shard map" (shard id: tx id) of shard's that submitter has submitted a transaction to for same sequence
• sequence checks (for current tx as well as last submitter tx) will lookup the DAG node based on submitter/seq key, and then check for present of a transaction for matching shard

Relaxed requirements state that there must not be any 2 different (shard id: tx id) for same submitter/seq.

[gnulib]

Endorser validation for submitter's sequence

Following is the final logic for validating a requested anchor, submitted transaction's anchor, or network transaction's anchor:

• If anchor's submitter sequence is < 1 then
  • for anchor requests, anchor validation is skipped, since this can only come in from DLT stack controller for protocol specific messages (e.g. sync requests)
  • for transaction handler or submission approver methods, this results in a ERR_INVALID error
• else // i.e. sequence is 1+
  • if anchor's submitter sequence is > 1, then
    • submitter history is checked for submitter's last sequence as per anchor
    • if last sequence history does not have any transaction that matches anchor's last submitter transaction, this results in a ERR_ORPHAN error
  • submitter history is checked for submitter's current sequence as per anchor
  • if submitter history has any transaction for the "shard id" of the anchor, then
    • for anchor requests, this results in a ERR_DOUBLE_SPEND error
    • else // i.e. for tx approver or handler
      • if transaction IDs are same then this results in ERR_DUPLICATE error
      • else results in ERR_DOUBLE_SPEND error
• validation is SUCCESS

[gnulib]

Endorsement layer checks implemented for submitter sequence validation and report SUCCESS / ORPHAN / DOUBLE SPEND