Arka: A blockchain with monetary policy voting and data publishing

Features

• Arka monetary inflation is determined through stakeholder voting. Payment outputs are colored with votes that determine network parameter adjustments for each epoch. The blockchain is a sequence of Work blocks and Payment blocks. Every epoch (every 10,000 work blocks or about 1 week), the votes are collected from those blocks and the associated payment blocks, and the median for each network parameter is computed. The result determines the network parameters for the next epoch. The network parameters control the function of many features in Arka.
• To control the rate of inflation, you must first fairly measure time. target is the only network parameter that is voted on by minters instead of stakeholders. The miners are the time keepers, and are kept fair through proof of work voting. In a proof-of-work, the target number of times a computation has been ran can be proven, without counting the iterations. If you know approximately how long the computation takes, then you can fairly measure time. Each work block has an associated timestamp, microseconds since 1970-01-01. The timestamps in the epoch are collected and median voting determines the target for the next epoch. The timestamps for each block are evaluated by the network when the work block is published to the network. Each block is allowed a reward of block_reward. The computation used is keccak-800 digest of the work block.
• Offline minting can produce proof-of-work stamps that may be redeemed for arka coin. This is useful for sending memos in the Arka network without associating the memo to an any particular payment activity. It also provides a counterbalance to help stabilize the currency by providing a speculative asset that may be redeemed for the currency. The offline minters should receive a reduced rate of reward when compared to the block minters, as block minting is crucial to network operation. However, stamp_reward may be increased to reduce the rate of computation currently performed by the network and is used in conjuction with block_reward.
• Monetary supply may be deflated. Blockchain data users are charged a usage fee that is paid to no party. It is simply removed from the supply. The usage rate is provided by data_fee.
• Blocks in the blockchain are retired after an expiry number of epochs have passed. This means that old and unspendable coin is reclaimed by the network, and data can be discarded.

Blocks

---
# common to all blocks
height: int                             # block id, strictly increasing
timestamp: int                          # microseconds since UNIX epoch
prev_block: bytes                       # hash digest of most recent block in chain
uid: bytes                              # public key or truncated key hash digest of block creator
nonce: bytes                            # H(H({block} - {nonce}) | nonce) ~= 0

# exists only in epoch blocks (every 10000th block)
parameters:                             # Adjusted parameters for epoch (10000 blocks)
  target: (byte, byte)                  # difficulty to create a block (average # of hashes)
  block_reward: int                     # units created by block creator
  utxo_fee: int                         # rate of decay of UTXOs (age of UTXO * UTXO units)
  data_fee: int                         # units per byte in each transaction are to be destroyed

# each block includes a list of payments
payments:

- from:                                 # sources are non-expired UTXOs

  # spend a UTXO
  - index: (int, int, int)              # block index | payment index | output index
    uid: bytes                          # spender's public key that hashes to or matches UTXO uid
    signature: bytes                    # digital signature of H(index | uid | payment.to[]) using uid as key

  to:                                   # destinations are UTXOs

  # create a UTXO
  - uid: bytes                          # public key or truncated key hash digest of receipient
    units: int                          # 1 coin = 2**30 units
    memo: bytes                         # can be used for layer 2 protocols

    # optional vote to adjust parameters, weighted by units and aggregated across epoch (10000 blocks)
    vote:
      block_reward: int                     # units created by block creator
      utxo_fee: int                         # rate of decay of UTXOs (age of UTXO * UTXO units)
      data_fee: int                         # units per byte in each transaction are to be destroyed

  # commit data
  - memo: bytes                         # can be used for layer 2 protocols

Chain consensus with PoW

The block chain is a linked list which begins with a particular block that sets the parameters for the given chain followed by a sequence of blocks. Blocks provide a prev_block field, which is the hash digest of the most recent previous block, forming a linked list block chain. The chain is partitioned into subchains of 10,000 blocks that share the same parameters, as determined through voting.

Blocks are generated periodically by random peers performing computational work. If the hash digest of a valid block is a member of a relatively small set determined by the work target consensus parameter, then the hash represents a valid proof of work. The block adds a list of payments to the block chain. Miners, computational units aimed at generating blocks, should listen for blocks and payments and adjust their own blocks accordingly.

To compute the hash digest of a block, deterministicly represent the object, minus the nonce field, as a binary string. Hash the string with Keccak-f1600. Then, concatenate the that hash digest with the target and nonce and hash again with Keccak-f800. target consists of an 8-bit base and 8-bit exp such that difficulty == (base + 1) * (2 ** exp) - 1. The proof of work is valid if the first 8-bit byte of the final hash digest is numerically greater than or equal to base and is followed by at least exp number of zero bits.

The payment list defines from, a list of unspent transaction outputs from previous blocks that claim previous payment outputs, and redistributes the total balance, minus a data fee, to to a new list of payment outputs. Payment outputs are optionally associated to a list of votes which determine chain consensus parameters.