Thought I could help you “get things going”, hopefully some of the wizards will be on soon to help you. All i know is that Parsec handles voting, from what I understand votes on new group members, votes on if dismiss members, malice handling and content validation.
I read the whitepaper the day it was released, and have been looking at the code and the example, watched Pierres video, and skimmed some discussions in the forum. I am not trying to understand the protocol at the level it’s creators (or any contributors) would (that would take a lot of time, skill and acquired knowledge in the area, I don’t have enough of either ), rather the context, it’s usage, how those parts will work.
Yes this is a primary purpose.
Also, secure message relay (along with data chains) and likely for changing data, such as safecoin transfers (still anonymous though).
Yip, the data chain
Yes, also in V1 (alpha4 and beyond actually), new peers will download all data and have to sign it.
Not quite sure what is being asked here, but each section has it’s own PARSEC if that helps.
Not currently pruned but these will be.
PARSEC does not want to know what some transactions are but does want to know about membership, so membership votes are visible,others do not need to be.
Yes, anything apart from membership changes really.
PARSEC does not care, it will only state this “thing” happened in this sequence.
Hope that helps.
This may be a bit off topic, but I’d like to ask how the purely mathematical proof for PARSEC is doing. I understand it was lacking a bit before and was criticized for it.
Thanks @dirvine, this helped materialize more of the framework of these concepts for me. My brain always try to handle too big picture and too many variables when not knowing basic frame, resulting in overload. So, now it can start exploring better
Ah, I suspected that they would have their own parsec. And so, if the blocks are stored in the data chain, is the datachain split and merged with the sections?
If for example parent 0 has blocks 0-99, child 1 has blocks 100-199 lets say and child 2 has same number of blocks 100-199 (distinct blocks from child 1 though of course). If network decreases in size so that child 1 and 2 merge, then parent 0 has blocks 0-299? (How is the order determined in a merge?)
It would be up to each application using parsec what part it wanted to prune, right?
Ah, of course! And it is comparing equality by the hash.
This is all great info.
Another question: How is the global datachain queried, or subscribed to? (Is that even a valid usecase?)
I have an implementation in mind which would use parsec, and I think I would need to subscribe to other sections’ parsecs… maybe that is an awkward way of looking at it?
The datachain is local to the section. Each section has its own datachain.
The datachain is for the section
I know, with global I mean the network state, i.e. all datachains of the network.
Maybe in SAFENetwork, there won’t be a reason to query datachains of other sections, but if there is, then I would be interested to know how that would be made.
Each section is is its own master and there isn’t a mechanism for another section to query its datachain.
Security is an issue, need to do consensus to agree to provide the data, what purpose is there considering the datachain is there to describe the order of events within the section.
What about the secure message relay and safecoin transfers and other data changes that David mentioned?
I would assume that other sections might be interested to know about it, since the flow is between sections. But even if not - how is that flow designed then, so that no other section need to know anything about these entries in the chain?
(The reason I am asking about it is because I am imagining a slightly different use, and if there was something thought out about the querying it would help me a bit further in that thinking. But I can see that it uncovers questions also for the case when it wouldn’t be queryable by other sections )
You are stretching my knowledge here. But arn’t these examples of signed messages and not using any of the datachain in the communications. All the datachain does in these is keep the order of consensus in order for the section to sign the message/request as valid. Its not keeping data for applications or some user database or (global) network wide database. The events in each section occur at different rates too.
Oh I’m out on the edge myself here
I just learned about these other uses for parsec with Davids response earlier in this topic (~8 hours ago).
Mm, I was thinking that datachains would maybe be a more significant long term storage of information, and as such it would presumably be interesting also outside of the specific sections. After all sharding is the practice of splitting up for example data [that you later want to retrieve] - and so if datachains was a component of the sharding, I was imagining that the information in the datachains was something that we later wanted to retrieve in some way. (Especially when the saying goes that “we don’t have blockchain, but instead datachains”).
OK, but then if this is not the case, yet another fragment is lit up a bit for me here, about the usage of parsec and datachains in the sections, but it sure makes other questions pop up when trying to wrap my head around it all . (splitting off from parsec topic a bit) Like:
- Exactly what is the nature of the data that goes into datachains?
- What is the lifecycle of that data?
- What is the relation to parsec, generally and in specific examples?
(But maybe the designers can shed more light on it.)
The thing is,besides from also wanting to understand all this, I got an idea for how parsec could be used in a slightly different framework, and I am trying to figure out if it would be possible. Might be bonkers but if not then it would be quite cool.
I will bow out and also am interested in the answers too.
I understand the benefits of anonymity but at some point, if this network becomes too successful and people start using it, they will want to keep a track of who they paid how much and when. i think sender/receiver and amount can be kept anonymous on the network but there should be some proof with the holder and receiver of what amount was sent/received to who/when - through/to which wallet ID. or something. Even better would be some technique where anonymity is a choice on wallet ID - that way some real legal transactions can also take place on Safenetwork and if someone wants it to be completely anonymous, they can keep it that way. i see some major use cases, where anonymity may not be a choice for legal reasons.
I like that especially - so if datachains was a component of the sharding, I was imagining that the information in the datachains was something that we later wanted to retrieve in some way.
David did say for SAFEcoins that the safecoin MD could be copied as a receipt for the one sending the coin. So that would give you a copy of the transaction. If Fraser’s idea is used then some other method would be needed
The data is like node ID left the section, or a vote on accepting a MD change was taken and the result is do it or not do it. Or 3 changes are requested and this is the order to do the changes in. Its really housekeeping stuff and not user data.
This is a great question and I don’t think it has been answered. In the merged section of this example, how are blocks 100-199 of child 1 ordered compared to those of child 2?
Why is ordering needed? A section is responsible for its (XOR) ID-range, so if you merge two sections you would merge two non-overlapping ID-ranges with their own non-overlapping data events. (edit: this is for the data events. All other network events, like joining and leaving, are also specific to the section, so no overlapping here as well)
edit: non-overlapping ranges imply, that there are no dependencies between the events of child 1 and child 2 sections, thus those can “exist” “concurrently” => no ordering needed.
The PARSEC chain (membership) restarts after each split/merge
I think you are talking about data here. Alhpa4 is not finalised, but in any case, the idea is all data is “merged”. So for any new node it must get all the data and supply its signatures for all the data to all peers (can be via PARSEC). The current members therefor have signed all of the data blocks at all times. This allows pruning to be very efficient and also gives us a resource proof (can a node store/get all data, sign it and send back the verifications).
So a split or a merge would be a very similar issue for data as a new node would.
Yes, it depends though, data and membership are different. Membership is not so easy to prune. An app using PARSEC though could certainly make its own rules for that.
Yes, this is closer to secure message relay or distant section proofs. As messages transfer across the network then each section is given a piece of the membership data chain. It traverses that until it finds a group it agrees with (membership) and then it can traverse up the chain (mathematically) to validate the particular transaction/message being sent. This part has not ben documented very well but has been coded and tested.
So no global chain, but there is a variable global state if that makes sense. Each section can be ahead or behind of others in respect to membership, but that is fine as we transmit the parts of the chain each neighbour section needs to come up to speed and validate a message as it traverses the network. As the chain is mathematically validatable from any known position (where you know the members to be true) then you can use that part as a genesis like block and traverse chain segments with certainty they are valid.
Now, we have the answer to this old question:
(and this solution seems sensible to me)