kc1212 / checo Goto Github PK

After running on Ubuntu:

XPS13:~/GITHUB/consensus-thesis-code>python -m src.node 12347 4 1 --test mo14 --value 1 -o logs/node3.log --debug
Traceback (most recent call last):
  File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit
    msg = self.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 734, in format
    return fmt.format(record)
  File "/usr/lib/python2.7/logging/__init__.py", line 465, in format
    record.message = record.getMessage()
  File "/usr/lib/python2.7/logging/__init__.py", line 329, in getMessage
    msg = msg % self.args
TypeError: not all arguments converted during string formatting
Logged from file mo14.py, line 175

Hi,

I tried running pytest on Mac and Linux but on both I get this error :

==================================== ERRORS ====================================
__________________ ERROR collecting tests/test_trustchain.py ___________________
tests/test_trustchain.py:4: in
from src.trustchain import *
src/trustchain/init.py:1: in
from trustchain import *
src/trustchain/trustchain.py:1: in
import libnacl
/usr/local/lib/python2.7/dist-packages/libnacl/init.py:83: in
nacl = _get_nacl()
/usr/local/lib/python2.7/dist-packages/libnacl/init.py:81: in _get_nacl
raise OSError(msg)
E OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.18, libsodium.so.17, libsodium.so.13, libsodium.so.10, libsodium.so.5, libsodium.so.4,
!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!
=========================== 1 error in 0.41 seconds ============================

Have you an idea how to solve this issue ?

Best Regards,

Add to docs, the install magic. (or pip install -r requirements.txt)

sudo apt-get install python-pytest python-jsonpickle
pip install typing

To start an experiment:
python -m src.discovery
python -m src.node 12345 4 1 --test mo14 --value 1 -o logs/node1.log --debug
python -m src.node 12346 4 1 --test mo14 --value 1 -o logs/node2.log --debug
etc.

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

Hi. I've been trying to really dig into this protocol. I've read your thesis and I just stumbled upon this: https://tools.ietf.org/id/draft-pouwelse-trustchain-00.html . I noticed you are making a few changes over on cothority too... I assume to test a CHECO implementation?

Are you doing any work to convert this protocol into golang, then? Is there a good place to discuss trustchain and checo?

I have a couple of (probably naive) ideas on how one could simplify the protocol given the addition of a BFT consensus that I'd love to discuss.

I'm also wondering what the licensing is? Tribler seems GNU, this is MIT and the link above is BSD. any ideas for licensing moving forward?