Implement bonds for fortification

[joshua-kim]

Implements bonds by maintaining state of an account's pending + max bond balance

[aaronbuchwald]

Could we make it clear when mutable is a local view of the chunk builder vs. operating on the network wide chain state (merkle trie)?

It's not completely clear to me from this in BuildChunk and Accept what state we're operating on.

We need to set the max balance in the chain state, so that each chunk builder has an agreed on view of what the max balance is for each potential tx issuer at the start of an epoch. Each chunk builder must maintain up to date pending balances, so that it can correctly limit transactions if they exceed their cap and needs to maintain a separate state/database for this (cannot write to the network wide state from its own local view).

Should we maintain a database in fdsmr so that we can keep the pending balances up to date rather than leaving this to the caller to supply?

[joshua-kim]

Should we maintain a database in fdsmr so that we can keep the pending balances up to date rather than leaving this to the caller to supply?

Why would the database live in fdsmr? Is this because you want to commit all of the unbond balance updates in a single batch? If so I think this is simpler to implement by just making Unbond idempotent

[aaronbuchwald]

It seems simpler that fdsmr maintaining responsibility for its own state is simpler than pushing it to the caller.

We just need to maintain that fdsmr can restart correctly and know the outstanding balances of any chunks that it has produced in a given epoch and is therefore responsible for.

Another alternative would be that on restart, we iterate over any pending chunks that we've created (which should include all chunks that could still be included in a block both produced by us and otherwise) and refresh our pending balances from this.

[aaronbuchwald]

LGTM

Summarizing my understanding of how we'll break down the state here:

• max balance will be included in the chain state (state replicated across the network)
• chunk builders locally maintain a database of pending transactions to ensure they never allow an account to spend more than their max balance

When we pass state.Mutable into fdsmr here, I think that we will need to ensure that the max balance cannot decrease within an epoch.

We want to ensure that chunk builders can guarantee they never replicate more data for an account than what the account can pay for (ie. the account bond). If an account bond can be decreased within an epoch, then the chunk builder can end up in a situation where they have outstanding replicated transactions that cost 100 units and the account bond can be decreased below that threshold, which can generate non-fee paying transactions.

[aaronbuchwald]

(optional for this PR / followup) Since we have an auth mock in the chain package, could we move this under auth/authtest/ so that we can re-use instead of creating it in each place we need?

[aaronbuchwald]

(no action necessary) feeRate = 0 should probably be invalid

[aaronbuchwald]

I'm not sure that writing txs by hash will be performant enough here, but think this is fine for now.