POC - Iteration 4.1 - mining reward for the mining node account

[gnulib]

Requirement

As specified in #18, a successfully mined block on canonical block chain should award 1 unit of mining reward to the mining node account.

Acceptance Criteria

Implementation should accomplish the following:

• a "trust net" specific application be defined that manages miner node accounts
• a mining reward transaction is defined by the "trust net" app
• the first transaction in any block should be a mining reward transaction of the "trust net" app
• successfully mined block should result in 1 unit of reward token allocation to miner node account
• CLI is extended to query token balance for node account

[gnulib]

Trustee App

We are abstracting the mining reward management into an "app" instead of directly implementing this functionality into network protocol layer. This will be a special app, acting as "Trustee" of the mining reward on behalf of the mining node. This model allows flexibility to expand token management by adding new APIs to the app directly.

Network protocol layer should be able to provide a reference to the app, so that higher level applications can make use of the token management APIs exposed by the trustee app.

Multi-stack Apps

Our DLT stack model allows Native DAPP to work with multiple DLT stacks (multi-ledgers). How will that model work, if trustee app is instantiated and "managed" by the network layer (stack) itself? Does this mean there will be multiple mining rewards, one for each DLT stack/ledger? What about cases when a particular DAPP does not need mining rewards? Also, we want all identity transactions to deduct transaction fee from submitter node's balance -- how will that happen with trustee node model?

We'll need following:

• one trustee app per DLT stack will be initialized by the DLT stack layer, whenever PowApprover parameter is non-nil
  (a non-nil PowApprover parameter implies that application requires mining effort, and hence there will be mining reward associated, regardless of whether application layer ends up using it or not)
• Whenever there is mining involved (i.e. PowApprover is non-nil), the first transaction in the block would be mining reward transaction obtained from the trustee app, and during block validation the first transaction will be sent to trustee app for processing
• Mining rewards can only be used within the context of a specific DLT stack instance
  (Since our DLT stack model allows an application to work simultaneously with multiple different DLT stacks, hence we cannot let the mining reward balance visibility and operations be across multiple DLT stacks -- applications are not expected to be running the exact same suite of DLT stacks, and hence any visibility across two different DLT stacks is not guaranteed to work with all applications)
• TrustNet Identity management would be implemented as one core application shipped with the TrustNet, and will expose APIs to access/manage identities. Other applications can choose to work with trust net identity application, or implement their own identity solution over their own custom DLT stack
  (Identity core app will maintain its own DLT stack, and use mining rewards from the underlying trustee app to pay for identity transactions. Similar model can be used by other native DApps, to use their DLT stack's trustee app to manage reward balance within the context of the DLT stack)

[gnulib]

Variety of Transactions

Q: How can a native DApp support multiple types of transactions?
A: When a native DApp receives a payload, that payload is simply a byte array. We need a way for application to deserialize that byte array into different transaction types (i.e. transaction op_code and their respective parameters). For this, we may have to use following json schema for transactions:

    [
        {
            "op_code" : {
                "type": "string",
                "description": "an application defined op code for transaction"
            },
            "params": {
                "type": [
                    "name": {
                        "type" : "string",
                        "description": "one named parameter and its value"
                    }
                ],
                "description": "an array of parameter name/value"
            }
        }
    ]

And an example transaction payload to do following:

1. debit "1.0" from account 0xaaaaa
   • only account owner can submit debit transaction (account need to match submitter's identity public key)
   • this op will debit specified amount from specified account and put it in application's stack
2. credit "0.5" into account 0xbbbbb
   • this op will credit specific amount to specified account deducting from application's stack
   • if there is not enough amount in application's stack (i.e. debit earlier) then transaction will fail
3. credit "0.5" into account 0xcccccc
   • this op will credit specific amount to specified account deducting from application's stack
   • if there is not enough amount in application's stack (i.e. debit earlier) then transaction will fail

[
    {
        "op_code": "debit",
        "params": [
            "from": "0xaaaaaaaa....",
            "amount": "1.00"
        ]
    },
    {
        "op_code": "credit",
        "params": [
            "to": "0xbbbbb...",
            "amount": "0.50"
        ]
    },
    {
        "op_code": "credit",
        "params": [
            "to": "0xccccc...",
            "amount": "0.50"
        ]
    }
]

[gnulib]

ECDSA Public Key as Node ID (65 bytes)

In order to use ECDSA public key as miner's account, that same value has to be set as the node ID (since that is what is sent as p2p address). Hence, we need to change the current implementation of consensus layer and protocol layer as following:

• ECDSA public key serializes into 65 byte array (1 byte prefix + 2 x 32 bytes for key), which does not fit into core.Byte64 type
• change all node ID or miner ID types in consensus layer and platform layer to use generic byte arrays (so that later can change the public key schema, without needing a change into underlying consensus and protocol layers)

[gnulib]

Reward Units

Due to floating point roundoff error, we do not want to use float for reward amount. Hence, we'll use uint64, and will define reward units as following:

• Mining Reward: 1000000
• Uncle Reward: 200000
• Smallest unit: 1 (1 millionth of mining reward unit)

Basically, lowest unit of 1 is treated as the smallest fraction of award in our system (similar to ethereum), and then regular 1 unit is equivalent to 1 million of those smallest units.

Incentivizing Transaction Processing

One of the key guiding principle for TrustNet is to prevent mining reward from becoming a run-away speculation vehicle. We want to restrict mining reward as a "right of use" for the network. Hence, our initial transaction model had proposed a transaction fee "burning" out of the node account of the block submitting node. However, this proposal would severely dis-incentivize a block miner to include transactions (since it will have to pay for those transactions). We need a scheme that actually incentivizes transaction inclusion. Hence, a better approach is as following:

• A valid block needs to have at-least 1 application submitted transaction (mining reward transaction does not count). DLT stack will reject blocks that only have a mining reward transaction.
• Reward balance can be transferred from mining node's account to another valid identity account or node account
• Transaction fee WILL NOT be paid by the block miner, and instead it will be a DAPP application logic thing, and will be managed by the application's transaction processing methods
• Transaction submitter (i.e. either an identity owner submitting identity attribute transaction, or any other DAPP specific account owner submitting a transaction) will need to pay the transaction fee, as per DAPP's business logic

[gnulib]

Exposing Trustee from Consensus Platform

Consensus platform interface will be extended to provide reference to Trustee app, allowing application to make use of API exposed by trustee app for reward balance management. Since our trustee implementation is open source, and schema for node account balance management is exposed, its entirely possible for the application to update node account balances independent of trustee app via an application submitted transaction. However, our consensus model will ensure that all transactions are serialized, ~and hence ACIDity of account balances is maintained~ and integrity of account balances is maintained.

DLT does not meed Durability of ACID, since upon rebalancing a transaction may not be applicable. It offers "eventual" consistency, but strong integrity. Atomicity is implied by serialized processing of transactions. Durability is not gauranteed in any form.

Q: Do we need to prevent application from directly submitting transactions that "modify" reward balances of the node account?
A: If we had a common/shared DLT stack for all different DAPP shards, then we'd have a vulnerability where someone could write a simple DAPP that makes unauthorized updates to common/shared stack's node account. However, our DLT stack model instantiates a unique stack for each DAPP shard, and the reward balance scope is limited to each stack instance. Hence, even if DAPP tries to update the node account balance -- that update would only be applicable to DAPP shard, and will not have access to node accounts on other DAPP shards.