Architecture refactoring for heterogeneous swaps

[stark-3k]

As mentioned in #694 currently we support only one type of protocol for every hop in a swap i.e. a v1 swap will only have P2WSH hops and a v2 swap will only have P2TR contracts.

Moving forward we want the swaps to be heterogeneous supporting different types of hops in a single swap. To achieve that, we need to significantly refactor our current architecture and messages.

Here's a proposal for a new architecture:

Protocol Abstraction

We are going to create an abstraction by defining two new traits: IncomingHopProtocol and OutgoingHopProtocol.

They will look something like:

trait IncomingHopProtocol {                                                                                                                            
      fn protocol_id -> ProtocolId;                                                                                                                                                                                                                          
      fn requires_receiver_presigning -> bool;                                                                                                                                                                                                                                              
      fn verify_contract  -> bool;                                                                                                                                                                                                                                                                                                                                                                        
      fn sign_as_receiver -> ...;                                                                                                                                                                                                                                                                                                                                                                                                                                    
      fn spend_hashlock -> ...;                                                                                                                                                                                                                             
      fn spend_cooperative -> ...;                   
      ...                                                                                           
  }          

trait OutgoingHopProtocol {                                                                                                                            
      fn protocol_id -> ProtocolId;                                                                                                                                                                                                                                                                             
      fn requires_sender_presigning -> bool;                                                                                                                                                                                                                                                          
      fn create_contract -> Contract;                                                                                                                                                                                                                               
      fn sign_as_sender -> ...;                                                                                                                                                                                                                                                         
      fn verify_receiver_signature -> ...;                                                                                                                                                                                                                                                                               
      fn spend_timelock -> ...;                                                                                                                                                                                                                            
      fn spend_cooperative -> ...;                                                                                                                                                                                                                                          
      fn extract_preimage -> ...;                                                                                                                               
      ...                                                                              
  } 

The taker is going to keep track of individual hops while co-ordinating the swap. The swaps will happen in three phases:

1. Offer fetching and maker selection — Here, the messages will be independent of the hop protocols but communicate the incoming and outgoing protocol type to every maker.
2. Contract establishment - Messages in this phase for every maker will depend on the incoming and outgoing protocols. Every protocol is going to have enums associated with the Incoming and Outgoing messages for the individual protocol which is also going to determine how the taker co-ordinates the swap during this phase for every hop.
3. Settlement - This will be done by a single PrivateKeyHandover for the current protocols but might be protocol dependent in the future(arguably we can count hash-preimage propagation as settlement)

Once we re-rearchitect with unified messages and handlers, we can have a single maker server and a rpc server, a single api interface for the taker and a single swapcoin module. The differences will only lie in the implementation of protocol critical stuff.

This is a high level overview. A lot more details will be decided and discussed on the go. The goal with this architecture should be to get idiomatic by abstracting what we can and remove all redundancy.

[mojoX911]

Ack. Sounds like a plan.

My suggestion is to try the unification first. It will reduce the current code surface and help identify the key protocol flows for the current P2WSH and Taproot protocols.

Once those are clear, we can use clever design with generics and traits to turn it into an "interface". This could be easily integrated into existing Maker and Taker APIs without any additional changes.

From a single maker's perspective, all protocols will follow this common flow. Only the messages and their handling details will differ.

• Get ready to accept a swap.
• Establish incoming swap.
• Establish outgoing swap.
• Settle and sweep the swap.

This concept can be generalized with a clever design using traits, generics, and associated types. It's not straightforward, but it should be achievable.

The final goal of the design should be:

• A clear, simple template that all protocols can implement.
• Adding a new protocol means creating the identifying struct, adding the messages, and implementing handlers for each. The handlers can access a &mut Wallet for wallet-related operations.
• No changes are needed in the maker/taker code to add the protocol.
• The maker/taker can track inside the swap state for incoming and outgoing protocols and handle the messages accordingly.

[stark-3k]

Sounds good, we can work on unifying most of the non-protocol code first and then revamp the protocol to have the multi-protocol swaps