Skip to content
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

Open
LuaiKam opened this issue Feb 18, 2018 · 2 comments
Open

WIP Concept #11

LuaiKam opened this issue Feb 18, 2018 · 2 comments

Comments

@LuaiKam
Copy link

LuaiKam commented Feb 18, 2018

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

@kc1212
Copy link
Owner

kc1212 commented Feb 19, 2018

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.

@LuaiKam
Copy link
Author

LuaiKam commented Feb 20, 2018

Hi, Thank you for your quick response,

This is really helpful,
Leaving the validation protocol to the nodes who are interested in, this will open a good path for feeless txs, somehow similar to IOTA where every tx refer other two tips(txs) and POW for spam resistance.

Regarding reputation system : node with ID will have more reputation than without ID,
PageRank will track how many times the nodes got visited, also the weight will be the amount of transferred value, am studying the bayesian network with micro detectors + netflow, hopefully the network will be able to rank nodes and detect possible attacks, check Bayesian approach to monitor Named data networking(NDA) and prevent CPA attacks : http://www.mallouli.com/recherche/publications/noms2018.pdf

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"
this mean the inter shard txs will have to go through two rounds to achieve consensus ..
Atomic cross chain : https://arxiv.org/abs/1801.09515

Thank you for taking the time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants