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:
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.
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%join
s 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: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.