I’ve finally started to look a bit at it, and have a few questions.
There’s so much I still don’t know, so bare with me, I’ll just have to start somewhere.
There’s a lot of material on the inner working of parsec, but I’m missing the higher levels; How is it supposed to be used? What is MaidSafe planning to use it for? How does this usage look like?
So, here goes:
1. Is parsec being used for section membership in SAFENetwork? 2. What is parsec (planned to be) used for except for section membership? 3. Where are the stable blocks stored? (the datachain?) 4. Do new peers download the list of stable blocks? 5. Are the stable blocks split up and merged with the sections? 6. Will there be any pruning of the stable blocks, or will they grow in eternity? 7. What is the use of OpaquePayload(T)? 8. When using parsec in another application, is OpaquePayload(T) supposed to used for application specific
votes? 9. How can any decisions be made with OpaquePayload(T), how is it known what is decided upon?
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.
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?
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 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.
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.