Skip to content

Simple Head and Tail

Matthias Fitzi edited this page Mar 18, 2021 · 25 revisions

Simple Head-Protocol Variant

The solution described in the FC21 paper and on ePrint allows for concurrent transaction confirmation in the head. This allows for better throughput and/or latency but implies some serious complications of the protocol as listed below.

Conflict Resolution

Handling of Time Constraints

Tail-Protocol Vision

In contrast (and as the main difference) to the head protocol, the tail protocol is asymmetric in the sense that there is one central server and a potentially large number of clients who delegate the maintenance of the ledger to the server.

The server is always online and computationally powerful whereas the clients may be lightweight and may only connect every now and then. When a client reconnects, the server updates him about 'missed' updates such that the client is up to date and can submit transaction to be executed in the tail. Furthermore, all parties in the head protocol (attempt to) share the same full state while, in the tail protocol, a clilent may only be interested in a small portion of the operations, and thus, the clients may maintain only partial state of the full tail.

Unlike the head protocol that can be unilaterally terminated, the tail is guaranteed to persist over a long time range (e.g., per an expiry date). In particular, detected misbehavior (by server or clients) must be resolved on-chain in a 'non-terminating' way, such that the tail can continue to operate off-chain.

In terms of blockchain lingo, the tail can be seen as sort of a 'non-custodial chain' while the head is a 'classical' multi-party state channel.

The main distinguishing properties thus are:

  • offline-tolerance of clients
    • possibly large messages required from the server to update a reconnecting client.
    • possible impact on message queuing?
  • asymmetric operations
    • asymmetric resource requirements for the nodes (server versus client).
    • message broadcast is likely not suitable as messages are typically only of interest to a small amount of participants.
  • faulty behavior has to be repeatedly corrected without the possibility for early abort
    • more chain interaction than in the head protocol
Clone this wiki locally