tiller-tolbus / chain

An Urbit-native L1 blockchain that implements a cryptocurrency $TOKEN
MIT License
30 stars 3 forks source link

Shared state cannot be derived solely from blocks #9

Closed tiller-tolbus closed 10 months ago

tiller-tolbus commented 11 months ago

We cannot have the full shared-state of the chain derived solely from blocks with the current model. The initial shared state must be known and agreed upon by the network.

We could aim to remedy this with some special case transactions that only get used at the beginning, such as a %claim transaction for stars to claim their airdrop one time. Or we could instate a rule that the first time a star %joins the network as a validator, it receives its token allocation.

Another thing would be to simply attest to the (relatively simple) Hoon code for the airdrop in the text field of the genesis block:

++  bootstrap-state
  ^-  shared-state  :+  
  ::  ledger: initial airdrop to stars
  ^-  (map @p @udtoken)  
  %-  molt
  %+  turn  (gulf ~marzod ~fipfes)
    |=  p=@
    ^-  [@p @udtoken]
    [p (mul (bex 16) token-scale)]
  ::  validators: genesis block author
  ^-  (set @p)
  (silt ~[~woldeg])  
  ::  blacklist: stars in time-out (initially empty)
  ^-  (map @p @ud)  ~

This requires some human understanding to attest to the initial shared state, but it is verifiable, and could be treated as a part of the protocol. For computer verification, we could hash this value and include it as the prev hash of the Genesis block.

The ugliness is that shared-state is never solely derived from the chain. Rather than:

f(chain) -> shared-state

Which is more typical in blockchains, you would have something more like:

f(shared-state, chain) -> new-shared-state

Whether or not to attempt to remedy this is a design decision and should be discussed at least a little.

tiller-tolbus commented 10 months ago

$TOKEN rewards now fit this model as of new design plan described in https://tiller-tolbus.redhorizon.com/blog/tokenomics