The Parsec paper described reaching consensus about an ordered series of blocks. We’ve seen presentations describing the use of Parsec to assist section membership and it’s history. Maybe I’ve missed it, but is the plan to use Parsec to record a history of all PUTs stored by each section in the network? Is this the data chain? Any further clarity on the topic or links to more details / code much appreciated.
6 Likes
Yes, you can think PARSEC provides the order and signatures (authority) and that is recorded in a data chain type structure. That is the 10000 mile view. You will see the code in the vault crate developing right now. That will held the data, but PARSEC is in routing.
10 Likes
A few ways to ask the same underlying question:
-
Are there two types of chains- One to hold section membership info /routing tables and another for user PUTs/chunks? Or, is everything l lumped together?
-
Where does Parsec store the data it generates? In a vault like client data?
5 Likes
Yes there is a membership chain, with BLS this becomes a chain of section public keys. So won’t specifically identify members, but the consensus group… That then spills into a membership chain of ED25519 keys (members) which will be used for node identification and relocations etc.
Ah I see what you are saying here. So think PARSEC is a graph of votes, the graph grows fast. So we extract the decisions there to individual chains. So some data items like appendable data, sequenced etc. are like mini chains themselves and held in vaults. Safeoin balances are similar where PARSEC identifies the balance change and all the honest nodes use this new balance. If people ask for a balance check then we again use PARSEC to agree the exact balance at the time they ask (which is also through PARSEC to ensure we give the correct balance in the correct order of the request).
tl;dr PARSEC is a run time thing that creates a sequece of agreements. Those agreements are recroded by honest nodes and used to respond to any user request.
The request though goes through PARSEC so that all honest nodes can see changes (which may be fast) and then when the request has consensus they can see what the state of the data/balance is at that point in the order and be all able to respond with the correct state at the point the request is agreed.
11 Likes
When you say ‘any user request’, are you also referring in general to PUT and GET requests? For example, nodes reach consensus that a valid PUT request was placed, and record that this particular PUT was sent to its close group within the section. Likewise, the section might reach consensus that a particular GET request was received, and the corresponding chunk was passed back through routing…
Perhaps another way ask the question is: will sections record an ordered (via consensus) record of all PUT and GET requests? Or do you consider this type of logging to be just too much meta data?
I’d think that as part of node aging there’d need to be consensus on which vaults served the data that they were supposed to. That way vaults that didn’t properly service GETs can be punished by the section.
2 Likes
On the latest SAFE Crossroads podcast at around 47:00 in, it is described that in vaults phase 2, client requests and the responses to them will go through PARSEC. This is to ensure that the proper data is returned to the client.
3 Likes