Make transcript of protocols

[omershlo]

@amanusk I think you might started something like this with your log file. We need to have a way for the server to produce a transcript that will record all messages in the protocol

[utkarsh5k]

@omershlo just for clarity, are we talking about logging the status of a single node at various points, or something like a global snapshot algorithm among trusted nodes?

[omershlo]

I guess that writing a spec is part of this issue :)
My original thought was that since we are dealing with SMR : basically add a functionality that will save the state to disk.
To be more concrete: in what is implemented at the moment we have a single server that maintains "hash table" that all parties can read and write from. This hash table should be saved to disk at the end of the computation in some format that will enable to replay the protocol given all secret inputs from the parties. One example where this can be helpful is for accountability: lets say we use white city for digital signature and the signing fails: an accuser i will accuse party j. party j will open its inputs and using the transcript will prove it acted honestly. If it fails to prove - party j will be removed, if it managed to prove the accuser party i will be removed. A concrete example would be nice :)

In the future: I think that this can be expended. Right now we don't have authentication but once we do we will have to let the parties sign each message they send.

cc: @amanusk

[utkarsh5k]

Sounds reasonable. A per-node checkpointing is good enough even if you're scaling up, since even large scale systems like Google Pregel use worker checkpointing via persistent storage for fault tolerance.

I am afraid I don't have enough knowledge about the current protocol, so bear with my silly doubts :)

1. Is there a co-ordinator (or master) in the protocol?
2. If so, lets say when you're running on multiple nodes, and one node fails, does the protocol allow for a new node (which is free and not already acting on anyone's behalf) to be spun up and take charge of the work that the previous node was doing on behalf of party J?
3. If the answer to 1 and 2 is yes, then would we prefer to have a 'stateless' design where a node upon being started reading the hash table for the last known state (this may be the node that had failed recovering, or a new node being started up)? Even if a new node cannot take responsibility, how much overhead would be to simply read from the hash table upon kicking off a recovery protocol?

No. 3 of-course relies on the assumption that a newly started node will not be malicious (if that is not known then it is not an option anyway).

[omershlo]

Nice. First we need to have common definitions:
In the current system there are two roles: you can be either a "party" or a "coordinator". There's one coordinator in a protocol so all comms goes through him. The parties each holds a secret data and wish to compute some function over the secret data.
We started to formally define those in https://github.com/KZen-networks/white-city/blob/master/RelayProofsOfConcept/Formal-spec/TLA%2B/RelayServer.pdf.
I will add that what @amanusk is working on is to replace to coordinator with some BFT

What is a "node" in your terminology?
I am not really sure how to answer your questions. maybe lets do a short call?

[utkarsh5k]

By node I mean a peer in the whole P2P system, which I think is same as the "party" in this context.

Sure, let me first read the specs and then I'll ping you on telegram, and we can set up a call at any time that works. Thanks for the info!

[omershlo]

Thanks for clarifying!
cool, lets move the discussion to TG.

[omershlo]

https://eprint.iacr.org/2016/611.pdf @utkarsh5k