lukechilds
/
itchysats
mirror of https://github.com/lukechilds/itchysats.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1417 Commits
67 Branches
8 Tags
4.4 MiB
 
 
Tree: 9f45e37697
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '9f45e37697'
${ noResults }
itchysats/docs/VISION.md

3.0 KiB
Raw Blame History

Technical vision

In this document, I want to capture the mid term technical vision for the project. Hopefully, this will make it clearer why we are working on certain parts of the codebase and which direction we should be transitioning them into. This is a living document so check back regularly for updates!

Resilience

Always available UI

Ideally, starting the application is non-fallible and always present a UI to the user. The user should be able to see the "health" of certain subsystems (wallet, blockchain, maker-connection, database, ...) and potentially take action in fixing them or we take an automated action in attempting to fix them.

Self-healing

Our application should be self-healing. This means, if certain components fail (like the websocket connection to BitMex), we should be able to restart them. Starting and stopping is a first-class feature of actors. In an ideal world, we tie the lifetime of these processes to an actor and thus, restarting the actor will restart that subsystem. As a consequence, other actors need to properly deal with the fact that sending a message to another actor might yield the Disconnected error.

Network communication

Multiplexing

Our current network stack is solely built on top of TCP which does not support multiplexing. Some of the complexity in the codebase stems from this missing feature. For example, because we don't have any multiplexing, the connection::Actor needs to know, where to route messages for contract-setups, rollovers or collaborative settlements. If we had a network stack with multiplexing support, we could open a dedicated stream just for a single protocol and hand both ends of the stream to such an actor and the right messages would "magically" arrive at the right actor.

Model

Event sourcing

Use event-sourcing as the core building block for modelling the state changes to a CFD. Changes to a CFD are done by executing a command on the CFD. Executing a command will produce a Domain Event. A Domain Event represents a state change in the system. These events are sent to a dedicated actor which first persists them and then broadcasts them to other actors. Other actors can then react to this state change and

  • update the UI
  • interact with downstream systems (electrum, oracle, ...)

Image

Naming

Align all terminology in the codebase closer with financial terms. See also https://github.com/itchysats/itchysats/discussions/829. Current issues:

  • Order vs offer
  • "Settlement" interval
  • Interest vs funding rate

IO-free yet contained

The execution of the protocols for contract setup and rollover are IO-free. More details here: https://github.com/itchysats/itchysats/issues/698.