trstovall / arka

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Arka: A private and scalable transaction chain with monetary policy voting

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, strictly increasing
prev_block: bytes                       # 32-byte digest of most recent block in chain
worker: bytes                           # ed25519 public key of block worker
nonce: bytes                            # H(H({block} - {nonce}) | parameters.target | nonce) ~= 0

# exists only in epoch links (every 10000th block link)
parameters:                             # Adjusted parameters for epoch (10000 blocks)
  target: (byte, byte)                  # difficulty to mint a block link (average # of hashes)
  block_reward: bytes                   # 1000 coin minted by block link
  stamp_reward: bytes                   # reward = (stamp_reward * stamp.target) / target
  data_fee: bytes                       # units per byte in each transaction is to be destroyed
  expiry: bytes                         # forget blocks older than expiry number of epochs

# each block includes a list of payments
payments:

- from:                                 # sources are non-expired UTXOs and workstamps

  # spend a UTXO
  - digest: bytes                       # block digest or H(link digest | payment index | output index)
    key: bytes                          # Present key that hashes to output address
    signature: bytes                    # 64-byte result of ed25519-sign of block digest by work block worker

  # spend a work stamp
  - worker: 32 bytes                    # ed25519 public key used to spend work stamp
    target: (byte, byte)                # 2-byte float from 0 to 2**256-1
    nonce: 32 bytes                     # H(worker | target | nonce) ~= 0, unique
    signature: 64 bytes                 # 64-byte result of ed25519-sign of block digest by stamp worker

  to:                                   # destinations are UTXOs

  # create a UTXO
  - uid_hash: bytes                     # keccak-800 digest of receipient's public ed25519 key
    units: bytes                        # 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                 # [-128:127] integer corresponding to +/- 10% adjustment
      stamp_reward: int                 # [-128:127] integer corresponding to +/- 10% adjustment
      data_fee: int                     # [-128:127] integer corresponding to +/- 10% adjustment
      expiry: int                       # [-128:127] integer corresponding to +/- 10% adjustment

  # 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.

About

License:MIT License


Languages

Language:C 91.3%Language:Python 8.6%Language:Dockerfile 0.1%