In this commit, we add the ChainArbitrator struct. The ChainArbitrator
is a special sub-system that will oversee the on-chain resolution of
all active channels, and also channels that are in the pending close
state. The ChainArbitrator maintains a set of ChannelArbitrators, one
for each channel that hasn’t yet been fully resolved.
Outside sub-systems should send new channels to the arbitrator once
they’ve opened. Additionally, they can also trigger manual
interventions to close out a channel on chain forcibly, or just to
signal that a channel has been closed cooperatively.
Finally, (for now) the ChainArbitrator should be notified once a fresh
set of signals for a channel becomes available. The ChannelArbitrator
for the channel will use these set of signals to be notified when an
on-chain event happens.
In this commit, we introduce a new interface, the ContractResolver. The
duty of a ContractResolver is to watch a contract on-chain, for all
possible transitions, and exit finally when the contract has been fully
resolved. Resolvers themselves can be recursive: meaning producing
another resolver to hand off the duties require to fully resolve a
contract.
Each resolver also has a ResolverKit which contains all the function
closures and interfaces that the resolver need to properly do its job.
The 5 types of resolvers are:
* outgoing HTLC timeout
* outgoing HTLC contested
* incoming HTLC know presage
* incoming HTLC contested (don’t yet know)
* commitment sweep
In the future, more advanced resolver types can be added as required.
In this commit, we add a new file: briefcase.go. The contents of this
file are the ArbitratorLog. This log will be used by the internal state
machine of each Channel Arbitrator to ensure that each state transition
is fully reflected on-disk, to ensure that the state machine is durable
and able to survive restarts.
This commit also adds a new implementation of the ArbitratorLog
interface backed by boltdb.
In this commit, we add the primary struct of the package with a full
implementation. The duty of the ChannelArbitrator is to watch the set
of active contracts on a comment transaction and act accordingly if any
of their redemption criteria have been met. Potential criteria include:
an HTLC about to time out, and HTLC about to time out that we know the
preiamge to, or the remote party going to chain (forcing us to resolve
all pending contracts on chain).
The primary goroutine of this struct implements a persistent state
machine in order to ensure that mid contract resolution, we’re able to
properly survive restarts without losing our place, or forgetting about
a pending contract.
A ChannelArbitrator will stay alive until all contracts have been fully
resolved. This means that outside sub-systems no longer need to worry
about remembering to mark a channel as fully resolved, as it’s the job
of the ChannelArbitrator to do this task.
