As a first draft of our chain agnostic design, we'll try to decouple the zeekoe implementation from the specific Tezos instantiation. We anticipate that closing will be similar for most chains, while establishing may be slightly to very different (e.g. depending on the number of operations required, whether it's efficient to batch establishing and funding, etc). However, we will start by just defining a trait that includes all the functions currently called for the TezosClient. Then, refactor the main body of zeekoe to use the trait instead of hardcoded Tezos calls.
Expected places that need changing:
all the chain operations
config file; maybe it'll need some additional structure to group the arbiter config items in a sub-element with defaults defined by the trait instantiation
database storage: we specifically hold the keys as blobs, but we might want to adjust the naming in order to be more generic.
This decision per discussion with @gijsvl, @indomitableSwan.
As a first draft of our chain agnostic design, we'll try to decouple the zeekoe implementation from the specific Tezos instantiation. We anticipate that closing will be similar for most chains, while establishing may be slightly to very different (e.g. depending on the number of operations required, whether it's efficient to batch establishing and funding, etc). However, we will start by just defining a trait that includes all the functions currently called for the
TezosClient. Then, refactor the main body of zeekoe to use the trait instead of hardcoded Tezos calls.Expected places that need changing:
This decision per discussion with @gijsvl, @indomitableSwan.