Test driver to show double spending submission

Objective

Write a test driver that can attempt to submit double spending transaction, either on same node, or on two different nodes across the network, so that I can validate the double spending resolution protocol described in #30

Acceptance Criteria

Test driver should provide following capabilities:

Initialize submitter's identity from a private key
CLI and transaction OP to create a resource owned by the submitter, with some initial value
Tracking of resource ownership by submitter identities
CLI and transaction OP to transfer out value to another identity from a resource owned by the identity, and checks to prevent transfer out values from resource not owned by identity
CLI to publish current value for a resource

Assumption

DLT stack has implemented library interface to provide submitter sequence and transaction parent parameters as part of submit operation
DLT stack has implemented library interface to save/update resource values during app's transaction processing
DLT stack has implemented library interface to query current value for specific resource

Application Shard Specs

We'll run the test driver application on the shared trust-net network, where all other application (e.g. network counter) are running. This test driver application will register with DLT stack using following specs:

shard id: []byte("test-driver-for-double-spending")
name: "test-driver-for-double-spending"

Application Transactions

Test driver will implement "ops" that will be submitted via transaction and processed by the application's registered transaction handlers. Following Ops specs will be used to submit as serialized and signed payload:

type Ops struct {
  // op code
  Code uint64
  // serialized arguments
  Args []byte
}

In above structure, application will define a unique value for Code for each specific operation defined below. Also, application will define a corresponding structure of arguments that will be stored as a serialized blob with Args.

Transaction Ops

Resource Creation Op

Driver will provide CLI to create a resource with initial value:

CLI> create <resource name> <initial value>

Above command will submit an Ops with following values:

`Code` value

0x01

`Args` structure

type ArgsCreate struct {
  // resource name
  Name string
  // initial value
  Value  int64
}

Rules of processing

there must not be a resource with that same name present
resource will the created with submitter's ID as owner of the resource
initial value must be an integer (for simplicity we are not dealing with fractions)

Value Transfer Op

Driver will provide CLI to transfer value from owned resource to another resource:

CLI> xfer <owned resource name> <xfer value> <recipient resource name>

Above command will submit an Ops with following values:

`Code` value

0x02

`Args` structure

type ArgsXfer struct {
  // xfer source name
  Source string
  // xfer destination name
  Destination string
  // xfer value
  Value  int64
}

Rules of processing

source of transfer resource must be owned by the submitter
xfer value cannot be greater that the current value for resource
xfer value cannot be less that 1 (i.e. cannot be zero or negative)
xfer value must be a positive integer (for simplicity we are not dealing with fractions)
operation will result in xfer value deducted from source resource and added to destination resource

Local Double Spending Transactions

Shard Sibling Double Spend

Test driver will implement a new CLI command that can be used to submit two double spending transactions as following:

CLI> dupe <owned resource name> <xfer value> <recipient 1 resource name> <recipient 2 resource name>

Above command will submit 2 value transfer transactions with two Anchors from same tip (i.e., same shard seq) using the same submitter seq on both anchors.

Shard Descendent Double Spend

Test driver will implement a new CLI command that can be used to submit two double spending transactions as following:

CLI> double <owned resource name> <xfer value> <recipient 1 resource name> <recipient 2 resource name>

Above command will submit 2 value transfer transactions in succession (i.e., sequential shard seq) using the same submitter seq on both anchors.

Remote Double Spending Transactions

Submitting remote double spending transactions

In order to submit double spending transactions across different nodes, we'll extend the test driver application to instantiate multiple DLT stacks listening on different ports. This way the CLI can submit transactions to those different instances of the stack, each of which is effectively a separate node.

Cross Submit Transaction

Test driver will implement a new CLI command that can be used to submit a transaction that has anchor from one node, but is submitted to another nodeas following:

CLI> xover <owned resource name> <xfer value> <recipient resource name>

Above command will get anchor from first node, but sumit transaction to second node, which should fail due to anchor signature validation.

Multiple Node Submission

Test driver will implement a new CLI command that can be used to submit a redundant transactions on two different nodes, so that even if one fails there is a redundancy and another submission passes.

CLI> multi <owned resource name> <xfer value> <recipient resource name>

Above command will submit same value transfer operation using 2 different transactions in parallel to two different nodes using the same submitter seq, using the anchors fetched from respective nodes. Network should only accept 1 of the two transactions, while the other transaction should be rejected as double spending.

Split Shard Submission

Test driver will implement a new CLI command that can be used to submit two double spending transactions on two different nodes to transfer same value to different recipients. Goal is to try and split the shard across network by submitting conflicting/double spending transaction on different nodes.

CLI> usage: split <owned resource name> <xfer value> <recipient 1> <recipient 2>

Above command will submit 2 different value transfer operations as 2 separate transactions in parallel to two different nodes using the same submitter seq, using the anchors fetched from respective nodes. Network should eventually detect this double spending attempt and consistently converge on only one of the value transfer operation while rejecting the other operation on all nodes. World state on all nodes should show consistent and correct values for all recipients.

trust-net / dag-lib-go