-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP Concept #11
Comments
Hi, thank you for reaching out. The reason I did not combine consensus and validation into one protocol is because not all nodes are interested in validating all blocks. Nodes only validate the ones that they are interested in and they are able to do this even if they are not the facilitator. Of course, you can combine the two protocols but I feel the performance may suffer. I do not know much about what Dfinity is doing unfortunately, so I can't comment much on that, maybe they have a way to validate everything without performance penalties. Your approach sounds good, but the devil is in the details. Reputation systems are difficult, you need a way to make sure it is fair for the majority of the people. For example, if it's PageRank, what will you use as the weight? If it's the amount of value transferred, how do you prevent sybils and collusion? Regarding shards, I think your idea is good. However, it might be tricky to do atomic inter-shard transactions. OmniLedger has a section (IV.C) about it, but I feel it's a bit complex and might be easy to implement it incorrectly. I hope this is helpful. |
Hi, Thank you for your quick response, This is really helpful, Regarding reputation system : node with ID will have more reputation than without ID, Regarding Shards, agree its hard to preform inter shard tx, but what if the infrastructure organized in a way that let the network act like shards, thats mean each shard will have two consensus alog one for domestic transactions and other will be executed only if there is international tx, and the facilitators in r+1 will collect international consensus results from all shards and input it to the bft consensus and come out with final consensus result for the previous r "round" Thank you for taking the time |
Hi Cong, Thank you for the impressive work.
from thesis pdf : "we randomly elect a set of nodes—called facilitators—to collect CP blocks from every other node and use those blocks as the input to the Byzantine consensus algorithm, and then run it.
After the algorithm completes, the facilitators output a set of CP blocks which we call the consensus result, which is then propagated to the network. Using the result, nodes are allowed to create new CP blocks, and then the next algorithm execution begins."
And in future work section you suggest to use a reputation mechanism
to select facilitators rather than simply selecting them randomly so that faulty nodes
are less likely to be selected.
What is the possibilities of mixing the consensus + validation into one protocol?
so the facilitators will collect and validate the CP blocks and then randomly select other facilitators group ; similar to dfinity; https://dfinity.org/pdf-viewer/pdfs/viewer?file=../library/intro-dfinity-crypto.pdf
https://dfinity.org/pdf-viewer/pdfs/viewer?file=../library/dfinity-consensus.pdf ,
here is a WIP blockchain approach using checkpoint consensus and randomness + sharding :
1 - Trusted nodes located in cities halls : those nodes will enable citizens and residents to get ID, why we need trusted nodes? there is a lot of reasons, like registering newborn baby, or to proof that there is a real person behind every public keys in the network.. this will help and feed the reputation system.
2 - Reputation mechanism using pagerank, wealth, misbehavior record.
3 - Shards : I know small shard size is likely to fail if the malicious nodes > 50%, but ;
each shard will represent a city, e.g, NY shard contain all the nodes in New York with local consensus,
and the facilitators will be randomly selected from the reputation system then they will collect CP blocks from all the nodes and reach consensus and validate the block(append old data structure, etc),
most the CP blocks will interact locally (like within the city ) but when a cross shard tx happen, first it should be validated from sender party locally as well should be validated in the receiving party side...
this way the domestic transactions will be confirmed in seconds because 99% of the nodes connected to the same tier 1 ISP and peered through same internet point exchange, and the international transactions will get confirmed in sub min.
the shard only share recent status of the cp blocks, that's mean thats mean there is no history log for the transactions..
so if node "A" need to keep all the history and record, then it must use the personal chain.
and if the Governments want to tax the citizens/residents , then they should keep records of the citizens,
this will enable Basic income (future work).
I look forward to hear your opinion,
Check : Winning the Caucus Race: Continuous Leader Election via Public Randomness
https://arxiv.org/pdf/1801.07965.pdf
Thank you
The text was updated successfully, but these errors were encountered: