Merge pull request #178 from dedis/d-voting_frontend_ghita

Changes all occurrence of "election" into "form"

Author: nkcr

README.md

@@ -73,9 +73,9 @@ This project was born in early 2021 and has been iteratively implemented by EPFL
 students under the supervision of DEDIS members.
 
 ⚠️ This project is still under development and should not be used for real
-elections.
+forms.
 
-Main properties of the system are the following: 
+Main properties of the system are the following:
 
 <div align="center">
     <img height="45px" src="docs/assets/spof-black.png#gh-light-mode-only">
@@ -89,7 +89,7 @@ side-protocols always distribute trust among nodes: The distributed key
 generation protocol (DKG) ensures that a threshold of honest node is needed to
 decrypt ballots, and the shuffling protocol needs at least one honest node to
 ensure privacy of voters. Only the identification and authorization mechanism
-make use of a central authority, but can accommodate to other solutions. 
+make use of a central authority, but can accommodate to other solutions.
 
 <div align="center">
     <img height="45px" src="docs/assets/privacy-black.png#gh-light-mode-only">
@@ -107,11 +107,11 @@ be linked to the original voter.
     <img height="50px" src="docs/assets/audit-white.png#gh-dark-mode-only">
 </div>
 
-**Transparency/Verifiability/Auditability** - The whole election process is
+**Transparency/Verifiability/Auditability** - The whole voting process is
 recorded on the blockchain and signed by a threshold of blockchain nodes. Anyone
 can read and verify the log of events stored on the blockchain. Malicious
 behavior can be detected, voters can check that ballots are cast as intended,
-and auditors can witness the election process.
+and auditors can witness the voting process.
 
 ## 🧩 Global architecture
 
@@ -120,12 +120,12 @@ The project has 4 main high-level components:
 **Proxy** - A proxy offers the mean for an external actor such as a website to
 interact with a blockchain node. It is a component of the blockchain node that
 exposes HTTP endpoints for external entities to send commands to the node. The
-proxy is notably used by the web clients to use the election system.
+proxy is notably used by the web clients to use the voting system.
 
 **Web frontend** - The web frontend is a web app built with React. It offers a
 view for end-users to use the D-Voting system. The app is meant to be used by
 voters and admins. Admins can perform administrative tasks such as creating an
-election, closing it, or revealing the results. Depending on the task, the web
+form, closing it, or revealing the results. Depending on the task, the web
 frontend will directly send HTTP requests to the proxy of a blockchain node, or
 to the web-backend.
 
@@ -137,7 +137,7 @@ web-backend has a local database to store configuration data such as
 authorizations. Admins use the web-frontend to perform updates.
 
 **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
+that runs on a host and participate in the voting 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
@@ -156,9 +156,9 @@ website](https://dedis.github.io/d-voting/#/).
 
 ## Workflow
 
-An election follows a specific workflow to ensure privacy of votes. Once an
-election is created and open, there are 4 main steps from the cast of a ballot
-to getting the result of the election:
+A form follows a specific workflow to ensure privacy of votes. Once an
+form is created and open, there are 4 main steps from the cast of a ballot
+to getting the result of the form:
 
 <div align="center">
     <img height="55px" src="docs/assets/encrypt-black.png#gh-light-mode-only">
@@ -186,7 +186,7 @@ associated to its voter on the blockchain.
     <img height="70px" src="docs/assets/shuffle-white.png#gh-dark-mode-only">
 </div>
 
-**3) Shuffle ballots** Once the election is closed by an admin, ballots are
+**3) Shuffle ballots** Once the form is closed by an admin, ballots are
 shuffled to ensure privacy of voters. This operation is done by a threshold of
 node that each perform their own shuffling. Each shuffling guarantees the
 integrity of ballots while re-encrypting and changing the order of ballots. At
@@ -200,7 +200,7 @@ this stage encrypted ballots cannot be linked back to their voters.
 **4) Reveal ballots** Once ballots have been shuffled, they are decrypted and
 revealed. This operation is done only if the previous step is correctly
 executed. The decryption is done by a threshold of nodes that must each provide
-a contribution to achieve the decryption. Once done, the result of the election
+a contribution to achieve the decryption. Once done, the result of the form
 is stored on the blockchain.
 
 For a more formal and in-depth overview of the workflow, see the
@@ -216,16 +216,16 @@ successful only if a consensus is reached. Additionally, transactions and their
 results are permanently recorded and signed on an append-only ledger, making any
 operations on the blockchain transparent and permanent.
 
-In the D-Voting system a single D-Voting smart contract handles the elections.
-The smart contract ensures that elections follow a correct workflow to
+In the D-Voting system a single D-Voting smart contract handles the forms.
+The smart contract ensures that forms follow a correct workflow to
 guarantees its desirable properties such as privacy. For example, the smart
 contract won't allow ballots to be decrypted if they haven't been previously
 shuffled by a threshold of nodes.
 
 ## Services
 
 Apart from executing smart contracts, blockchain nodes need additional side
-services to support an election. Side services can read from the global state
+services to support a form. Side services can read from the global state
 and send transactions to write to it via the D-Voting smart contract. They are
 used to perform specific protocol executions not directly related to blockchain
 protocols such as the distributed key generation (DKG) and verifiable shuffling
@@ -239,13 +239,13 @@ contribution of a threshold of participants. This makes it convenient to
 distribute trust on encrypted data. In the D-Voting project we use the Pedersen
 [[1]] version of DKG.
 
-The DKG service needs to be setup at the beginning of each new election, because
-we want each election to have its own key-pair. Doing the setup requires two
+The DKG service needs to be setup at the beginning of each new form, because
+we want each form to have its own key-pair. Doing the setup requires two
 steps: 1\) Initialization and 2\) Setup. The initialization creates new RPC
 endpoints on each node, which they can use to communicate with each other. The
 second step, the setup, must be executed on one of the node. The setup step
 starts the DKG protocol and generates the key-pair. Once done, the D-Voting
-smart contract can be called to open the election, which will retrieve the DKG
+smart contract can be called to open the form, which will retrieve the DKG
 public key and save it on the smart contract.
 
 [1]: https://dl.acm.org/doi/10.5555/1754868.1754929
@@ -256,10 +256,10 @@ The shuffling service ensures that encrypted votes can not be linked to the user
 who cast them. 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 the
 integrity of the elements is guarantee (i.e no elements have been modified,
-added, or removed), but one can't trace how elements have been re-ordered. 
+added, or removed), but one can't trace how elements have been re-ordered.
 
 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.
+a form is closed, an admin can trigger the shuffling steps from the nodes.
 During this phase, every node performs a shuffling on the current list of
 encrypted ballots and tries to submit it to the D-Voting smart contract. The
 smart contract will accept only one shuffling step per block in the blockchain.
@@ -326,7 +326,7 @@ results.
     <tr>
         <td>Fall 2021</td>
         <td>Students: Auguste Baum, Emilien Duc<br>Supervisor: Noémien Kocher</td>
-        <td>Adds a flexible election structure. Improves robustness and security.</td>
+        <td>Adds a flexible form structure. Improves robustness and security.</td>
         <td>
             <a href="https://www.epfl.ch/labs/dedis/wp-content/uploads/2022/02/report-2021-3-baum-auguste-Dvoting.pdf">Report</a>,
             <a href="https://www.epfl.ch/labs/dedis/wp-content/uploads/2022/02/presentation-2021-3-baum-auguste-dvoting.pdf">Presentation</a>
@@ -350,7 +350,7 @@ results.
     <tr>
         <td>Spring 2022</td>
         <td>Students: Badr Larhdir, Capucine Berger<br>Supervisor: Noémien Kocher</td>
-        <td>Major iteration over the frontend - design and functionalities: implements a flexible election form, nodes setup, and result page.</td>
+        <td>Major iteration over the frontend - design and functionalities: implements a flexible form form, nodes setup, and result page.</td>
         <td>
             <a href="https://www.epfl.ch/labs/dedis/wp-content/uploads/2022/07/report-2022-1-capucine-badr-d-voting-frontend.pdf">Report</a>,
             <a href="https://www.epfl.ch/labs/dedis/wp-content/uploads/2022/07/presentation-2022-1-capucine-badr-d-voting-frontend.pdf">Presentation</a>
@@ -378,10 +378,10 @@ added to you path (like with `export PATH=$PATH:/Users/david/go/bin`).
 # Setup a simple system with 3 nodes
 
 If you are using Windows and cannot use tmux, you need to do the actions of the
-scripts in point *1* and *2* manually: open 3 terminal sessions and run the
-commands from the section *Run the nodes* below (1 command LLVL=info memcoin etc.
+scripts in point _1_ and _2_ manually: open 3 terminal sessions and run the
+commands from the section _Run the nodes_ below (1 command LLVL=info memcoin etc.
 per terminal and then launch the setup script in another terminal). You can then
-follow the instructions below starting from point *3*.
+follow the instructions below starting from point _3_.
 
 1: Run 3 nodes
 
@@ -401,7 +401,6 @@ From the first terminal sessions, run:
 ./setupnNode.sh -n 3
 ```
 
-
 3: Launch the web backend
 
 From a new terminal session, run:
@@ -425,7 +424,7 @@ REACT_APP_PROXY=http://localhost:9081 REACT_APP_NOMOCK=on npm start
 Note that you need to be on EPFL's network to login with Tequila. Additionally,
 once logged with Tequila, update the redirect URL and replace
 `dvoting-dev.dedis.ch` with `localhost`. Once logged, you can create an
-election.
+form.
 
 5: Stop nodes
 
@@ -435,7 +434,7 @@ election.
 
 6: Troubleshoot
 
-If while running 
+If while running
 
 ```sh
 npm start
@@ -453,11 +452,13 @@ then run this instead:
 PORT=4000 npm start
 #or any other available port
 ```
+
 and in the web/frontend/src/setupProxy.js file, change :
 
 ```sh
 target: 'http://localhost:5000',
 ```
+
 with
 
 ```sh
@@ -486,11 +487,12 @@ Then you should be able to run the setup script:
 ```sh
 ./setup.sh
 ```
+
 With this other script using tmux you can choose the number of nodes that you
 want to set up:
 
 ```sh
-./setupnNode.sh -n 3 
+./setupnNode.sh -n 3
 ```
 
 This script will setup the nodes and services. If you restart do not forget to
@@ -506,14 +508,13 @@ rm -rf /tmp/node{1,2,3}
 
 If you have `tmux` installed, you can start a `tmux` session that will
 execute the above setup by running in the project root `./runNode.sh -n 3`.
-This command takes as argument the number of nodes. 
+This command takes as argument the number of nodes.
 Once the session is started, you can move around the panes with
 `Ctrl+B` followed by arrow keys or by `N`. You can also have an overview of the
 windows with `Ctrl+B` followed by `S`.
 
-
 To end the session, run `./kill_test.sh`,
-which will kill each window then the `tmux` session (which you can do manually 
+which will kill each window then the `tmux` session (which you can do manually
 with `Ctrl+D`), then delete the node data (i.e. the files `/tmp/node{1,2,3}`).
 
 ## Run the scenario test
@@ -528,18 +529,19 @@ LLVL=info memcoin --config /tmp/node1 e-voting scenarioTest --secretkey $sk
 
 You can also run scenario_test.go, by running in the integration folder this
 command:
+
 ```sh
 NNODES=3 go test -v scenario_test.go
 ```
 
-
 For reference, here is a hex-encoded kyber Ed25519 keypair:
 
 Public key: `adbacd10fdb9822c71025d6d00092b8a4abb5ebcb673d28d863f7c7c5adaddf3`
 
 Secret key: `28912721dfd507e198b31602fb67824856eb5a674c021d49fdccbe52f0234409`
 
-## Run the scenario test with docker 
+## Run the scenario test with docker
+
 Use the following commands to launch and set up nodes, and start the scenario
 test with user defined number of nodes.
 
@@ -554,21 +556,21 @@ Afterwards use the following commands, replace 4 by the desired nb of nodes :
 NNODES=4 KILLNODE=true go test -v -run ^TestScenario$ github.com/dedis/d-voting/integration -count=1
 ```
 
-Here we set KILLNODE=true or false to decide whether kill and restart a node 
-during the election process. By default, it's set to false.
+Here we set KILLNODE=true or false to decide whether kill and restart a node
+during the voting process. By default, it's set to false.
 
 To end the session, run `./kill_test.sh`.
 
 To launch multiple test and get statistics, run `./autotest.sh -n 10 -r 15`.
 
 N.B. run following commands to get help
+
 ```sh
 ./runNode.sh -h
 ./setupnNode.sh -h
 ./autotest.sh -h
 ```
 
-
 # Use the frontend
 
 See README in `web/`.