Conversation
Pull Request Test Coverage Report for Build 2747335540
💛 - Coveralls |
671021e to
557b8b9
Compare
557b8b9 to
24b2b58
Compare
- matches Github's font color for light themes
README.md
Outdated
| <img height="45px" src="docs/assets/spof-white.png#gh-dark-mode-only"> | ||
| </div> | ||
|
|
||
| **No single point of failure** The system is supported by a decentralized |
There was a problem hiding this comment.
Here and elsewhere, this would help readability:
| **No single point of failure** The system is supported by a decentralized | |
| **No single point of failure -** The system is supported by a decentralized |
README.md
Outdated
| **Blockchain node** A blockchain node is the wide definition of the program that | ||
| runs on a host and participate in the election logic. The blockchain node is | ||
| built on top of Dela with an additional d-voting smart contract, proxy, and two | ||
| services: DKG and verifiable Shuffling. The blockchain node is more accurately a | ||
| subsystem, as it wraps many other components. Blockchain nodes communicate | ||
| through gRPC with the [minogrpc][minogrpc] network overlay. We sometimes refer | ||
| to the blockchain node simply as a "node". |
There was a problem hiding this comment.
This paragraph is very confusing. It introduces many terms that a novice would not yet be familiar with.
README.md
Outdated
| through gRPC with the [minogrpc][minogrpc] network overlay. We sometimes refer | ||
| to the blockchain node simply as a "node". | ||
|
|
||
| **Proxy** A proxy enables external interactions on a blockchain node. It is a |
There was a problem hiding this comment.
"external" from what ? I'm being a bit picky here, but this could be clearer.
README.md
Outdated
| the web-backend. The web backend checks the requests and signs messages before | ||
| relaying them to the blockchain node, which trusts the web-backend. The | ||
| web-backend has a local database to store configuration data such as | ||
| authorizations. Admins use the web-frontend to perform update. |
There was a problem hiding this comment.
| authorizations. Admins use the web-frontend to perform update. | |
| authorizations. Admins use the web-frontend to perform updates. |
|
|
||
| ## 🧩 Global architecture | ||
|
|
||
| The project has 4 main high-level components: |
There was a problem hiding this comment.
I was wondering if it'd make it easier to follow by starting with the web interface (that everyone understands), then moving on to the web backend, the proxy (as the interface between non-blockchain and blockchain environments) and finally introducing the blockchain node itself.
README.md
Outdated
| The shuffling service ensures that encrypted votes can not be linked to their | ||
| voters. Once the service is setup, each node can perform what we call a |
There was a problem hiding this comment.
| The shuffling service ensures that encrypted votes can not be linked to their | |
| voters. Once the service is setup, each node can perform what we call a | |
| The shuffling service ensures that encrypted ballots can not be linked to the user who cast them. | |
| Once the service is setup, each node can perform what we call a |
| The shuffling service ensures that encrypted votes can not be linked to their | ||
| voters. Once the service is setup, each node can perform what we call a | ||
| "shuffling step". A shuffling step re-orders an array of elements such that | ||
| integrity of the elements is guarantee (i.e no elements have been modified, |
There was a problem hiding this comment.
| integrity of the elements is guarantee (i.e no elements have been modified, | |
| the integrity of the elements is guaranteed (i.e no elements have been modified, |
README.md
Outdated
|
|
||
| In D-Voting we use the Neff [[2]] implementation of verifiable shuffling. Once | ||
| an election is closed, an admin can trigger the shuffling steps from the nodes. | ||
| During this phase, every node perform a shuffling on the current list of |
There was a problem hiding this comment.
| During this phase, every node perform a shuffling on the current list of | |
| During this phase, every node performs a shuffling on the current list of |
README.md
Outdated
| In D-Voting we use the Neff [[2]] implementation of verifiable shuffling. Once | ||
| an election is closed, an admin can trigger the shuffling steps from the nodes. | ||
| During this phase, every node perform a shuffling on the current list of | ||
| encrypted ballots and try to submit it to the D-Voting smart contract. The smart |
There was a problem hiding this comment.
| encrypted ballots and try to submit it to the D-Voting smart contract. The smart | |
| encrypted ballots and tries to submit it to the D-Voting smart contract. The smart |
README.md
Outdated
| contract will accept only one shuffling step per block, and nodes repeat their | ||
| shuffling step with the latest shuffled list until their shuffling step has been | ||
| accepted or a threshold of nodes successfully submitted their shuffling steps. |
There was a problem hiding this comment.
| contract will accept only one shuffling step per block, and nodes repeat their | |
| shuffling step with the latest shuffled list until their shuffling step has been | |
| accepted or a threshold of nodes successfully submitted their shuffling steps. | |
| contract will accept only one shuffling operation per block in the blockchain, | |
| and nodes re-try to shuffle the ballots, using the latest shuffled list in the blockchain, until the result of their shuffling has been committed to the blockchain or a threshold of nodes successfully submitted their own shuffling results. |
000e3ef to
14e301e
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
Fix French language: at most -> au plus








No description provided.