Implementation of Seath Network

[Luis-omega]

Once #24 is ready (or even before that), we must begin to implement it, this is a place to discuss how we are going to do it.

My current thoughts are towards using https://pursuit.purescript.org/packages/purescript-queue/8.0.2 to handle the pending request on both Leader and Users. I also think that we would send back-and-forth JSONs that could also be encoded in CBOR or something like that (some advice here is pretty appreciated).

The current task is split across the following tasks :

• 27

• 28

• 30

[Luis-omega]

For now, we are thinking of using a server and client in both the Leader and Users , some options for this are:

• use of purescript-httpure for servers and purescript-request for clients

• Same as before but using purescript-servant to bundle together client and server.

• As the last option but write our own servant module.

• Look for a package that already does all this and is updated, the more up-to-date (2 years ago) I found is purescript-payload

[Luis-omega]

Update:

We choose to use payload and queue for the work. I'm in the process of rewriting the interface, for that purpose I wrote this :

How Seath works

• The user sends a request to the Leader to perform an action. This request must have two kinds of information attached, one is the information used by the leader to process the action, currently named UserAction a, and the other one is the information for the server to send later responses, like IP and port. Also, the user put some information related in a pool of actions sent to the server.
• The Server immediately responds ok to the request and stores the UserAction a together with the information to reach later the user in a queue of pending processing actions.
• The leader who has a next round priority queue, takes the actions there and puts them in the currently processing array.
• The leader takes part of the pending actions after some time or after the queue gets a certain size and puts some of them in the currently processing array.
• The leader process all the actions it took before and builds a chain of transactions, we can have errors trying to process an action, in that case, we should find the information of the user that sent the action and notify the error (or maybe just discard the action and make the user the one that must contact leader?) . Then the remainder of the chain is built.
• The leader finds the info of the users of every transaction in the built chain and sends a request to every user, attaching information like the number of chains build until now or the index of the transaction in the chain. It gets an immediate response from the users with an empty body, otherwise, the leader would assume that the user is unreachable and the transaction is discarded and proceed with the recovering from errors in the chain protocol.
• The leader waits for every valid transaction in the chain to be signed for a time, and if part of the chain is already invalid, it would send that info to the users involved immediately and proceed with the recovering from errors in the chain protocol.
• The user signs the transaction and sends it to the Leader or sends the rejection to sign or just doesn't send anything to implicitly reject to sign. In any case, the user moves the action from the pool of pending to process, it can be just deleted or it can be moved to another pool of pending for confirmation in case the user accepts it.
• Once all valid transactions and signed are in the server or once we exceed some timeout, the leader would mark part of the chain as invalid if some transaction wasn't signed in time or was rejected and proceed to follow the recovering from errors in the chain protocol.
• Leader sends a confirmation of inclusion to every user whose transaction is in the remaining chain. And the leader submits the chain. If the submission fails in some transaction, the leader would send back the input to the user, discard its transaction and proceed with the recovering from errors in the chain protocol.
• Users receive the confirmation from the leader and if they want they query a Cardano node to know when its transaction is admitted. In any case, the user removes the corresponding action and transaction from its queues.
• The leader began its process again and the user is free to send a new action.

recovering from errors in the chain

If we have a chain [ .., a_n,...] built and some error makes invalid the a_n, we discard the a_n related info, then we query the original request of the rest of the chain a_(n+1), a_(n+2)... and put it in a next round priority queue.