diff --git a/.gitignore b/.gitignore
index 3c3629e6..80bf70b5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,3 @@
node_modules
+.DS_Store
+src/.vuepress/dist
diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 00000000..9f10ae9a
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,8 @@
+{
+ "cSpell.words": [
+ "acvbc",
+ "asdgc",
+ "wedfg"
+ ],
+ "cSpell.enabled": true
+}
\ No newline at end of file
diff --git a/LICENSE b/LICENSE
deleted file mode 100644
index 0a041280..00000000
--- a/LICENSE
+++ /dev/null
@@ -1,165 +0,0 @@
- GNU LESSER GENERAL PUBLIC LICENSE
- Version 3, 29 June 2007
-
- Copyright (C) 2007 Free Software Foundation, Inc.
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-
- This version of the GNU Lesser General Public License incorporates
-the terms and conditions of version 3 of the GNU General Public
-License, supplemented by the additional permissions listed below.
-
- 0. Additional Definitions.
-
- As used herein, "this License" refers to version 3 of the GNU Lesser
-General Public License, and the "GNU GPL" refers to version 3 of the GNU
-General Public License.
-
- "The Library" refers to a covered work governed by this License,
-other than an Application or a Combined Work as defined below.
-
- An "Application" is any work that makes use of an interface provided
-by the Library, but which is not otherwise based on the Library.
-Defining a subclass of a class defined by the Library is deemed a mode
-of using an interface provided by the Library.
-
- A "Combined Work" is a work produced by combining or linking an
-Application with the Library. The particular version of the Library
-with which the Combined Work was made is also called the "Linked
-Version".
-
- The "Minimal Corresponding Source" for a Combined Work means the
-Corresponding Source for the Combined Work, excluding any source code
-for portions of the Combined Work that, considered in isolation, are
-based on the Application, and not on the Linked Version.
-
- The "Corresponding Application Code" for a Combined Work means the
-object code and/or source code for the Application, including any data
-and utility programs needed for reproducing the Combined Work from the
-Application, but excluding the System Libraries of the Combined Work.
-
- 1. Exception to Section 3 of the GNU GPL.
-
- You may convey a covered work under sections 3 and 4 of this License
-without being bound by section 3 of the GNU GPL.
-
- 2. Conveying Modified Versions.
-
- If you modify a copy of the Library, and, in your modifications, a
-facility refers to a function or data to be supplied by an Application
-that uses the facility (other than as an argument passed when the
-facility is invoked), then you may convey a copy of the modified
-version:
-
- a) under this License, provided that you make a good faith effort to
- ensure that, in the event an Application does not supply the
- function or data, the facility still operates, and performs
- whatever part of its purpose remains meaningful, or
-
- b) under the GNU GPL, with none of the additional permissions of
- this License applicable to that copy.
-
- 3. Object Code Incorporating Material from Library Header Files.
-
- The object code form of an Application may incorporate material from
-a header file that is part of the Library. You may convey such object
-code under terms of your choice, provided that, if the incorporated
-material is not limited to numerical parameters, data structure
-layouts and accessors, or small macros, inline functions and templates
-(ten or fewer lines in length), you do both of the following:
-
- a) Give prominent notice with each copy of the object code that the
- Library is used in it and that the Library and its use are
- covered by this License.
-
- b) Accompany the object code with a copy of the GNU GPL and this license
- document.
-
- 4. Combined Works.
-
- You may convey a Combined Work under terms of your choice that,
-taken together, effectively do not restrict modification of the
-portions of the Library contained in the Combined Work and reverse
-engineering for debugging such modifications, if you also do each of
-the following:
-
- a) Give prominent notice with each copy of the Combined Work that
- the Library is used in it and that the Library and its use are
- covered by this License.
-
- b) Accompany the Combined Work with a copy of the GNU GPL and this license
- document.
-
- c) For a Combined Work that displays copyright notices during
- execution, include the copyright notice for the Library among
- these notices, as well as a reference directing the user to the
- copies of the GNU GPL and this license document.
-
- d) Do one of the following:
-
- 0) Convey the Minimal Corresponding Source under the terms of this
- License, and the Corresponding Application Code in a form
- suitable for, and under terms that permit, the user to
- recombine or relink the Application with a modified version of
- the Linked Version to produce a modified Combined Work, in the
- manner specified by section 6 of the GNU GPL for conveying
- Corresponding Source.
-
- 1) Use a suitable shared library mechanism for linking with the
- Library. A suitable mechanism is one that (a) uses at run time
- a copy of the Library already present on the user's computer
- system, and (b) will operate properly with a modified version
- of the Library that is interface-compatible with the Linked
- Version.
-
- e) Provide Installation Information, but only if you would otherwise
- be required to provide such information under section 6 of the
- GNU GPL, and only to the extent that such information is
- necessary to install and execute a modified version of the
- Combined Work produced by recombining or relinking the
- Application with a modified version of the Linked Version. (If
- you use option 4d0, the Installation Information must accompany
- the Minimal Corresponding Source and Corresponding Application
- Code. If you use option 4d1, you must provide the Installation
- Information in the manner specified by section 6 of the GNU GPL
- for conveying Corresponding Source.)
-
- 5. Combined Libraries.
-
- You may place library facilities that are a work based on the
-Library side by side in a single library together with other library
-facilities that are not Applications and are not covered by this
-License, and convey such a combined library under terms of your
-choice, if you do both of the following:
-
- a) Accompany the combined library with a copy of the same work based
- on the Library, uncombined with any other library facilities,
- conveyed under the terms of this License.
-
- b) Give prominent notice with the combined library that part of it
- is a work based on the Library, and explaining where to find the
- accompanying uncombined form of the same work.
-
- 6. Revised Versions of the GNU Lesser General Public License.
-
- The Free Software Foundation may publish revised and/or new versions
-of the GNU Lesser General Public License from time to time. Such new
-versions will be similar in spirit to the present version, but may
-differ in detail to address new problems or concerns.
-
- Each version is given a distinguishing version number. If the
-Library as you received it specifies that a certain numbered version
-of the GNU Lesser General Public License "or any later version"
-applies to it, you have the option of following the terms and
-conditions either of that published version or of any later version
-published by the Free Software Foundation. If the Library as you
-received it does not specify a version number of the GNU Lesser
-General Public License, you may choose any version of the GNU Lesser
-General Public License ever published by the Free Software Foundation.
-
- If the Library as you received it specifies that a proxy can decide
-whether future versions of the GNU Lesser General Public License shall
-apply, that proxy's public statement of acceptance of any version is
-permanent authorization for you to choose that version for the
-Library.
diff --git a/README.md b/README.md
deleted file mode 100644
index a24765c8..00000000
--- a/README.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Vocdoni
-
-All of the content in this repository can be viewed on the [Documentation page](https://vocdoni.io/docs).
diff --git a/docs/.nojekyll b/docs/.nojekyll
deleted file mode 100644
index e69de29b..00000000
diff --git a/docs/CNAME b/docs/CNAME
deleted file mode 100644
index fce362ea..00000000
--- a/docs/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-docs.vocdoni.io
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
deleted file mode 100644
index d66c2af2..00000000
--- a/docs/README.md
+++ /dev/null
@@ -1,52 +0,0 @@
-## A decentralized self sovereign governance system
-
-Vocdoni is a universally verifiable, censorship-resistant and anonymous governance system, designed to be scalable and easy to use on modest devices. The goal is to provide the foundation to run national elections, general shareholders meetings, assemblies, etc.
-
-Our main aim is a trustless voting system, where people can speak their voice and everything can be audited. We are engineering the building blocks for a permissionless, private and censorship-resistant democracy.
-
-The algorithms, systems and software that we build are intended to be a contribution toward making _violence in these cryptonetworks impossible by protecting users privacy with cryptography_. In particular, our aim is to provide the tools for the political will of network participants to translate outwardly into real political capital, without sacrificing privacy.
-
-## Architecture overview
-
-- **Data integrity** is provided by a programmable Blockchain like [Ethereum](https://ethereum.org/en/), using [Smart Contracts](https://ethereum.org/en/learn/#smart-contracts)
-- **Data availability** is provided by decentralized file transfer system like [IPFS](https://ipfs.io/)
-- **Messaging** is implemented using a decentralized pool of Gateways, that anyone can run
-- **Voting** is handled by a custom blockchain made on top of [Tendermint](https://tendermint.com/)
-
-**Client** apps or browsers do not need to join decentralized networks themselves. They can connect to any of the discoverable Gateways and retrieve data from the smart contracts, IPFS and the voting blockchain, without the need to open P2P connections on their own.
-
-
-
-
-
-### Election components
-Organizations maintain a list of public keys from their community, either in a database or in a public ledger.
-The organizer of an election selects the group of people who are eligible to vote. Their public keys are hashed using a [ZK-Snark](https://z.cash/technology/zksnarks/) friendly function (_Mimc7_ or _Poseidon_), added to a **[Merkle Tree](https://en.wikipedia.org/wiki/Merkle_tree)** and distributed through a decentralized file system (_IPFS_).
-
-The _Merkle Tree_ is used as the **[Census](/architecture/census-overview)** of the voting process. The [Process Metadata](/architecture/data-schemes/process) is the subject on which people can vote, and it is also distributed through IPFS.
-
-The census and metadata pointers are submitted to the [Voting smart contract](/architecture/smart-contracts/process?id=smart-contract) and the parameters of the new vote become carved in stone on the Ethereum blockchain.
-
-### Voting process
-Once the process has begun, users can start submitting their votes to the [Voting blockchain](/architecture/services/vochain). In order to enforce uniqueness and anonymity, users wrap their ballot in an envelope using a [Zero-Knowledge Proof (ZK-Snark)](/architecture/protocol/franchise-proof).
-
-The ZK-Snark proof (or Franchise proof) is an easy-to-verify way of proving that a voter belongs to the census Merkle Tree, without revealing the underlying identity. It also allows to prove to any third party that the user has not voted twice.
-
-The custom [Tendermint based blockchain](/architecture/services/vochain) validates the vote envelope and its franchise proof. It stores all valid votes on the public ledger and allows any third party to fetch it and verify its correctness. It is referred to as the Voting Chain (_Vochain_).
-
-A [ballot](/architecture/smart-contracts/process?id=vote-envelope) contains mainly three parts:
-
-1. Election ID
-2. Vote values (encrypted or unencrypted)
-3. ZK-proof
-
-Users can submit their ballots to any [Gateway or fullnode](/architecture/services/gateway) on the Voting blockchain, which will broadcast it to the mempool for further validation and eventual inclusion.
-
-This approach allows for future integration with public blockchains via [Substrate](https://substrate.dev/) or [Cosmos](https://cosmos.network/), and thereby enables binding smart contracts to election results.
-
-
----
-
-### Coming next
-
-Get started by checking the [Global Architecture](/architecture/general) section.
diff --git a/docs/_coverpage.md b/docs/_coverpage.md
deleted file mode 100644
index e69de29b..00000000
diff --git a/docs/_sidebar.md b/docs/_sidebar.md
deleted file mode 100644
index d0ac94d8..00000000
--- a/docs/_sidebar.md
+++ /dev/null
@@ -1,58 +0,0 @@
-
-
-- Architecture
- - [General](/architecture/general.md)
- - [Process overview](/architecture/process-overview.md)
- - [Census overview](/architecture/census-overview.md)
- - [Component overview](/architecture/components.md)
- - [User stories](/architecture/user-stories.md)
- - Smart Contracts
- - [Entity Resolver](/architecture/smart-contracts/entity-resolver.md)
- - [Process](/architecture/smart-contracts/process.md)
- - [Genesis](/architecture/smart-contracts/genesis.md)
- - [Namespace](/architecture/smart-contracts/namespace.md)
- - [Results](/architecture/smart-contracts/results.md)
- - [Storage Proofs](/architecture/smart-contracts/storage-proofs.md)
- - Services
- - [Gateway](/architecture/services/gateway.md)
- - [Vochain](/architecture/services/vochain.md)
- - [Scrutinizer](/architecture/services/vochain/scrutinizer.md)
- - [Census Service](/architecture/services/census-service.md)
- - [Boot node](/architecture/services/bootnode.md)
- - Data schemes
- - [Entity metadata](/architecture/data-schemes/entity-metadata.md)
- - [Process](/architecture/data-schemes/process.md)
- - [Ballot protocol](/architecture/data-schemes/ballot-protocol.md)
- - Protocol
- - [JSON API](/architecture/protocol/json-api.md)
- - [Franchise proof](/architecture/protocol/franchise-proof.md)
- - [Data origins](/architecture/protocol/data-origins.md)
-
- - [Sequence diagrams](/architecture/sequence-diagrams.md)
- - [Libraries and tooling](/architecture/libraries-tooling.md)
-- Organization Manager
- - [Overview](/manager/overview.md)
- - [Manager API](/manager/manager-api.md)
- - [Registry API](/manager/registry-api.md)
- - [Push Notifications API](/manager/push-notifications-api.md)
-- Integration
- - [Overview](/integration/overview.md)
- - [Voting as a Service](/integration/voting-as-a-service.md)
- - [Registry backend](/integration/registry-token-api.md)
-
-
-
-- Deployment
- - [Gateway](/deployment/gateway.md)
- - [Miner](/deployment/miner.md)
- - [Oracle](/deployment/oracle.md)
-
-- About
-
-
-
- - [How we work](/about-us/how-we-work.md)
- - [Vision](/about-us/vision.md)
-
-
diff --git a/docs/about-us/how-we-work.md b/docs/about-us/how-we-work.md
deleted file mode 100644
index d0243ac1..00000000
--- a/docs/about-us/how-we-work.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# How we work
-
-## Ideals
-
-We share very strong ideals among us
-
-- We want **effective** change in how civil society organizes **itself**
-- Decentralization is the way to change, but we're aware that its a bumpy and long road, taking straight paths is sometimes needed.
-- Transparency above anything
-- Trust before hierarchies
-- We believe in an open-source approach to creation
-- We don't sell, nor over-promise. Instead, we communicate things as we see them. With its pros and cons.
-
-## Balance
-
-We want a sustainable work-life balance
-
-- We encourage the use of working hours for learning related stuff to your work and our collective mission.
-- We encourage a balanced lifestyle and we suggest a daily average of 7 working hours
-- We adapt to everyone's needs and motivations
-
-## Coordination
-
-- We are fully autonomous and responsible individuals, therefore, nothing mandates days, schedules, or hours that you work
-- We don't like process, but we're not afraid of it if is needed.
-- We are a fully remote team. We have a bi-monthly retreat for team building
-
-## Development practices
-
-- Open-source everything
-- Test-driven development
-- Integration and unit testing
-- Well documented and maintained APIs
-- Well documented reasoning behind decisions
-
-## Join us
-
-If you think you can help us to fullfill our mission, drop us an [e-mail](mailto:xavi@vocdoni.io).
diff --git a/docs/architecture/data-schemes/entity-metadata.md b/docs/architecture/data-schemes/entity-metadata.md
deleted file mode 100644
index 73dc5dd5..00000000
--- a/docs/architecture/data-schemes/entity-metadata.md
+++ /dev/null
@@ -1,361 +0,0 @@
-# Entity Metadata
-
-The metadata of an entity is represented as a [JSON file](#json-schema) that conforms to a specific schema. This data is typically retrieved using a P2P storage system like IPFS.
-
-The metadata of an entity provides human readable content, featuring names, descriptions, images, the list of available processes and more.
-
-- [JSON schema](#json-schema)
-- [Gateway boot node](#gateway-boot-node)
-- [Gateway update](#gateway-update)
-- [News Feed](#news-feed)
-- [Entity Actions](#entity-actions)
-- [Action visibility](#action-visibility)
-
-## JSON schema
-
-To fetch the metadata of an entity, client applications are expected to fetch the value of the [ENS Text Record](/architecture/smart-contracts/entity-resolver?id=text-record-storage) `vnd.vocdoni.meta`, which contains a [Content URI](/architecture/protocol/data-origins?id=content-uri).
-
-The [Content URI](/architecture/protocol/data-origins?id=content-uri) is expected to point to a JSON file, conforming to the following schema:
-
-```json
-{
- "version": "1.0",
- // The first language in the list is the default one
- // Use "default" or https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
- "languages": ["en", "fr"],
- "name": {
- "en": "Free Republic of Liberland",
- "fr": "République Livre de Liberland"
- },
- "description": {
- "en": "In a sovereign state...",
- "fr": "Dans un état souverain..."
- },
- "votingProcesses": {
- "active":["0x987...","0x876..."], // Process ID of the active votes
- "ended":["0x887...","0x886..."] // Process ID of the ended votes
- },
- "newsFeed": { // See News Feed below
- "en": "ipfs://34567,https://hipsterpixel.co/feed.json",
- "fr": "ipfs://23456,https://feed2json.org/convert?url=http://www.intertwingly.net/blog/index.atom"
- },
- "media": {
- "avatar": "https://liberland.org/logo.png,ipfs://12345,ipfs://12345",
- "header": "https://liberland.org/header.png,ipfs://12345,ipfs://12345",
- },
-
- "actions": [ , ... ], // See Entity Actions below
-
- "bootEntities": [ , ... ], // See Entity Reference below
-
- "fallbackBootNodeEntities": [ , ... ], // See Entity Reference below
-
- "trustedEntities": [ , ... ], // See Entity Reference below
-
- "censusServiceManagedEntities": [ , ... ] // See Entity Reference below
-}
-```
-
-**Sequence diagrams:**
-
-- [Set Entity metadata](/architecture/sequence-diagrams?id=set-entity-metadata)
-- [Entity subscription](/architecture/sequence-diagrams?id=entity-subscription)
-
-
-
-### News Feed
-
-A News Feed serves the purpose of having a uni-directional censorship-resistant communication channel between entities and users. They are referenced with [Content URIs](/architecture/protocol/data-origins?id=content-uri) pointed from the `newsFeed` field of the Entity Metadata.
-
-News feeds are expected to conform to the specs of the JSON feed specification
-
-- https://jsonfeed.org/version/1
-
-### Entity Actions
-
-Entity Actions are requests that users may be prompted to send to private services. Their definition is stored within the [JSON metadata](#json-metadata).
-
-#### Register
-
-Open a register form within the client app.
-
-```json
-{
- "type": "register",
- "actionKey": "sign-up", // The name you give to identify the action
-
- "name": {
- "default": "Register",
- "fr": "S'inscrire"
- },
-
- // The URL to POST the provided data to.
- // See the format below.
- "url": "https://census-registry.cloud/lambda/actions/",
-
- // Endpoint to query for the visibility (if dynamic).
- // Returning true will show the action and hide it otherwise.
- // See Action Visibility below.
- "visible": "https://census-registry.cloud/lambda/actions/"
-
- // "visible": "always" (or make it always visible)
-}
-```
-
-The body of the POST request submitted to `url` will contain a JSON body like:
-
-```json
-{
- "request": {
- "method": "register",
- "actionKey": "sign-up",
- "entityId": "0xaabbccdd...",
- "firstName": "John",
- "lastName:": "Snow",
- "dateOfBirth": "2020-02-19T10:09:19.738Z",
- "email": "john@snow.me",
- "phone": "+1235678838",
- "timestamp": 1556110671
- },
- "signature": "0x1234..." // The public key will be extracted from the signature
-̣}
-```
-
-As it happens with all [Gateway requests](/architecture/protocol/json-api?id=authentication), `signature` is computed from the stringified JSON of `request`, where its keys are sorted alphabetically.
-
-The response from the backend should be like:
-
-```json
-{
- "response": {
- "ok": true,
- // "error": "Something went wrong", // Only if `ok` == false
- "timestamp": 1556110671
- },
- "signature": "" // Empty until registry public keys are available
-}
-```
-
-
-
-### Action visibility
-
-The visibility of entity actions can be static or dynamic.
-
-- Actions that should always be visible are declared with `"visible": "always"`.
-- If the visibility is dynamic, `"visible"` contains the URL endpoint to which the client will perform a POST request.
-
-The body should contain:
-
-```json
-{
- "request": {
- "method": "getVisibility",
- "actionKey": "sign-up",
- "entityId": "0xaabbccdd...",
- "timestamp": 1556110671
- },
- "signature": "0x1234..." // The public key will be extracted from the signature
-̣}
-```
-
-The public key for which the visibility is queried will be recovered from the `signature`. The `signature` is computed from `sign({"method":"getVisibility","timestamp":1581673325384}, privateKey)`.
-- This prevents spam requests to leak knowledge about a certain account
-- For UX reasons, a precomputed signature is cached when users unlock an account within the app
-- Since it is not feasible to precompute all potential signatures for every possible entity, the `entityId` and `actionKey` fields are omitted on the signature
-- Signing the timestamp allows backends to only accept queries for a reasonable period of time, until the user unlocks the account again
-- A neater approach is in the works
-
-The response from the backend should be like:
-
-```json
-{
- "response": {
- "ok": true,
- "visible": true // or false // only if `ok` == true
- // "error": "Something went wrong", // Only if `ok` == false
- "timestamp": 1556110671
- },
- "signature": "" // Empty until registry public keys are available
-}
-```
-
-
-
-### Coming next
-
-See the [Process Data Schemes](/architecture/data-schemes/process) section.
diff --git a/docs/architecture/general.md b/docs/architecture/general.md
deleted file mode 100644
index cd39601a..00000000
--- a/docs/architecture/general.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# Global architecture
-
-Digital voting processes represent a great social and tech challenge. An official binding vote with standard requirements should at least be able to:
-
-+ Enforce vote anonimity
-+ Rely on an opensource platform
-+ Be 100% transparent, auditable and verifiable
-+ Use uncensorable communication channels
-+ Ensure that voters from a census can only vote once without revealing anyone's identity
-+ Handle tenths of thousands of transactions per minute
-
-Vocdoni defines an open architecture and the protocols to empower large communities to exercise full democracy with the aforementioned guarantees.
-
-A functional implementation of Vocdoni will typically involve two types of services.
-
-**Decentralized**: A public Ethereum blockchain, Gateways, Census Service, voting blockchain Miners, Oracles, and decentralized storage systems
-**Private**: Private custom services so that Entities can maintain a census of users (with personal data that should not be disclosed)
-
-## Service architecture
-
-To provide resilence and avoid any kind of censorship, the network architecture should accomplish the following requirements:
-
-+ Do not depend on any specific company or cloud infrastructure
-+ Do not depend on specific IPs
-+ Do not rely on DNS
-+ Use P2P network connections when possible
-+ Use static web pages, so they can be replicated
-+ Allow third parties to contribute to the infrastructure
-
-### Key components
-A voting process makes use of the following components:
-
-
-
-
-
-- Mobile app users create a key pair (identity) an sign up to the Registry DB of an organization
-- The Registry DB creates a Merkle Tree with a snapshot of the census and publishes it through IPFS
-- Voting processes are declared on an Ethereum Smart Contract
- - It acts as the source of truth and contains pointers to the metadata, census root and parameters defining how a process should behave
-- Metadata is obtained from distributed filesystems like IPFS or similar
- - If at least one peer of the network has the requested data, everybody can have access to it
-- Requests and P2P messaging are handled by Gateways
- - They provide access to Web3, File, Census and Vote operations on HTTP/WS
- - Any third party can run an instance of his own
-- Mobile or web clients
- - Can interact with P2P services without joining the network as a peer
- - Can interact with (private) organizations to sign up and be part of its census
-- Election processes are handled in a Proof-of-Authority Blockchain
- - Voting anonymity is achieved using ZK-Snarks
- - Multiple voting is prevented using deterministic nullifiers
-- Gateways are a neutral piece, since cryptography is used on the peer side
- - The only intent of a Gateway is to act as a P2P proxy for clients that can't open sockets by themselves (web browsers)
-
----
-
-### Coming next
-
-See the [Process overview](/architecture/process-overview) section.
diff --git a/docs/architecture/services/vochain/scrutinizer.md b/docs/architecture/services/vochain/scrutinizer.md
deleted file mode 100644
index cc10ba4e..00000000
--- a/docs/architecture/services/vochain/scrutinizer.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# Scrutinizer
-
-## Overall
-
-The scrutinizer is the component that tallies and decode/decrypt (if needed) each vote stored in the voting blockchain for each process of each entity.
-
-The way the scrutinizer works is defined by the process vote type and the process mode eligible configurations.
-
-
-## Core components
-
-The scrutinizer needs to be connected with a full **Vochain node** in order to access the latest state accurately. The state is for retrieving votes, processes and other useful info for computing the results for each process.
-
-It also maintains three pools and an internal database for data persistence:
-
-### Vote pool
-
- Used for computing processes with real-time results.
-
- Each pool item contains a single vote with the following fields:
-
- - Encryption key indexes
- - Height
- - Nullifier
- - Process Id
- - Vote package
-
-### Process pool
-
- Used for storing processes and look at each new block if the results can be computed.
-
- Live processes results are computed in parallel every new Vochain bloc and the results of encrypted or non live processes are scheduled for the tally when the end block of a process is reached or when the keys of a processes are published.
-
- Each pool item contains a single process with the following fields:
-
- - Process Id
- - Entity Id (Organization identifier)
-
-### Results pool
-
- The results pool are used to compute the results of the processes whose:
-
- - End block is reached
- - Encryption keys are revealed
- - Results need to be computed on real time
-
- Each item pool contains a process Id and the entity Id associated to the process.
-
-
-The **internal scrutinizer database** is used for storing the results, processes useful info for the tally, non finalized processes and votes. Storing data linked to the Vochain state changes adds safety and data correctness in front of numerous failures.
-
-
-
-
-
-
-
-## How it works
-
-The scrutinizer is very tied to the Vochain, this is because its functionality relies on state changes on the Vochain application state.
-
-There are some functions that change the Vochain state that are associated to one or more **callback functions** and can be used for other processes in order to do some side logic. One of the components using this feature is the scrutinizer.
-
-### Votes
-
-Each time a vote is added into the Vochain (`addVote`), if the process is meant to have the results available in real-time, the vote is added to the vote pool and processed.
-
-### Processes
-
-Each time a process is added into the Vochain (`addProcess`) it is stored into the scrutinizer database and added into the process pool.
-
-### Process keys
-
-Each time the process keys are revealed (`revealProcessKeys`), the process is added to the results pool in order to process the results.
-
-
-### Commit
-
-When the `Commit` function is called on the Vochain, a signal is triggered in order to inform the scrutinizer that the latests changes are finalized and persistent.
-
-In the commit stage all the pools are iterated in order compute the results of each process that is meant to be tallied. As said, there are different situations in which the scrutinizer must compute the results of a process:
-
-- If the process is real time, the votes on the vote pool are fetched in order to be computed at the given Vochain height.
-- If the process keys are revealed.
-- The process end block is reached.
-
-### Rollback
-
-If the `Rollback` function is called on the Vochain, the current non persisted changes will be discarded.
-
-
-
-
-
-
-### Coming next
-
-See the [Census Service](/architecture/services/census-service) section.
diff --git a/docs/index.html b/docs/index.html
deleted file mode 100644
index cfd42a31..00000000
--- a/docs/index.html
+++ /dev/null
@@ -1,64 +0,0 @@
-
-
-
-
-
- Vocdoni docs
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/styles.css b/docs/styles.css
deleted file mode 100644
index 0fc5b1f7..00000000
--- a/docs/styles.css
+++ /dev/null
@@ -1,171 +0,0 @@
-body {
- color: #444;
- font-family: "Open Sans", sans-serif, sans-serif;
- /* background-color: #F3F0ED; */
- background-color: white;
- font-weight: 300;
-}
-
-.anchor span {
- color:#444;
- line-height: 1.2em;
-}
-
-.markdown-section {
- letter-spacing: -0.02rem;
- line-height: 1.2rem;
- max-width: 800px;
- padding:40px;
- padding-top:64px;
-}
-
-.markdown-section a {
- color: #789;
- font-weight: 400;
- line-height: 1.2rem;
- text-decoration: none;
- text-decoration-color: rgba(0, 0, 0, 0.3);
-}
-
-.markdown-section a:hover {
- font-weight: 400;
- color: #789;
- text-decoration: underline;
- text-decoration-color:#789
-}
-
-.markdown-section h1 {
- font-weight: 400;
- font-size: 2.2em;
-
-}
-
-.markdown-section h2 {
- font-weight: 400;
- font-size: 1.9em;
-
-}
-
-.markdown-section h3 {
- font-weight: 400;
- font-size: 1.6em;
-}
-
-.markdown-section h4 {
- font-weight: 400;
- font-size: 1.3em;
- margin-bottom: -0.6em;
-}
-
-.markdown-section pre {
- line-height: 1.2rem;
-}
-
-.markdown-section blockquote {
- border-left: 3px solid #444;
- color: #444;
- font-family: "Open Sans", sans-serif, sans-serif;
- font-weight: 400;
-}
-
-.markdown-section em {
- color: #444;
- font-weight: 400;
-}
-
-.markdown-section blockquote p {
- font-weight: inherit;
-}
-
-.markdown-section table {
- font-weight: inherit;
- word-break: break-word;
- font-size: 0.85em;
-
-}
-
-.markdown-section td, .markdown-section th {
- border: 1px solid #F3F0ED;
- padding: 10px 10px;
-}
-
-.markdown-section code, .markdown-section pre {
- color:#444;
- font-family: monospace;
-}
-section tr:nth-child(2n) {
- background-color: #00000005;
-}
-
-
-.sidebar {
- border: 1px;
- padding:18px 48px;
- /* background-color: #F3F0ED; */
- background-color: #f8f8f8;
- padding-right: 0px;
-}
-
-.sidebar ul li.active>a {
- color: #789;
- font-weight: 900;
- text-decoration: none;
-}
-
-.sidebar-toggle {
- background-color: #f8f8f8;
- bottom: inherit;
- border-radius: 26px;
- margin: 10px;
- width: 52px;
- height: 52px;
- align-items: center;
- padding: 10px;
-}
-
-.sidebar-toggle span {
- background-color: #444;
-}
-
-
-body.close .sidebar-toggle {
- background-color: #f3f0ede8;
- width:52px;
- transition: background-color 1s;
-}
-
-
-
-/* MERMAID CUSTOM FLOW CHARTS */
-
-.mermaid span.edgeLabel, .mermaid span>center {
- background-color: #f7f7f7 !important;
-}
-
-.mermaid g.node>rect {
- stroke: #9b9c9a !important;
- fill: #effff9 !important;
-}
-
-.mermaid g>foreignObject {
- color: #2d3e31;
-}
-
-.app-nav.no-badge {
- margin: 0px;
- /* margin-right: 25px; */
- padding-top: 48px;
- padding-left: 80px;
- padding-right:80px;
-}
-
-.app-nav a.active, .app-nav a:hover {
- color:#000;
- border:none;
- font-size:16px;
-
-}
-
-.sidebar-toggle-button {
- padding: 8px;
-}
diff --git a/old-content/Considerations.md b/old-content/Considerations.md
deleted file mode 100644
index 88a454d7..00000000
--- a/old-content/Considerations.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# Considerations
-
-## Relay network
-+ How can we minimize IP address/vote mapping?
- + Multiple encryption with `relay` keys?
- + Use [I2P](https://en.wikipedia.org/wiki/I2P)
- + Use [Tor](https://en.wikipedia.org/wiki/Tor_(anonymity_network))
-
-+ How does the `relay` pool look like? Is it a blockchain?
-+ Do we need a `relay` market?
-+ How does a `relay` compite with another `relay` pricing? Where are prices announced?
-+ What is the prize of a `process` based on? Number of necessary transactions(not known before-hand)?
-+ How to check `relay` bad behaviour?
- + Who checks it? (the `organization?`)
- + Time limits for an un-returned hash?
- + Relay censoring a package
-
-+ How to choose which relay to encrypt the `vote package` with? How can it be randomized?
-+ How a `User` chooses which relay connects to?
-+ How does a `user` confirms that her `vote-package` has been added into the blockchain?
- + Does it need to keep downloading every new hash of aggregated `vote packages`?
-
-## Results publishing
-+ Current design required the organization to publish the final results "manually" to the `voting smart-contract`.
-+ While everyone can still validate the results on its own the "oficial" results could be prone to errors or modifications.
-+ We would like a way to publish the final results without relying on a trusted actor.
-
-## Merit based census
-+ Current design requires that the organization has access to an existing census
-+ This pretty much implies that only entities with an existing user base can create `processes`
-+ We would like a system that could generate the census based on a claim selection
-+ This would allow any identity to create a `process` using any set of claims by other third parties
diff --git a/old-content/DataStructures.md b/old-content/DataStructures.md
deleted file mode 100644
index 5f871e30..00000000
--- a/old-content/DataStructures.md
+++ /dev/null
@@ -1,70 +0,0 @@
-### Vote data structures
-
-All in JSON format
-
-#### Vote Package
-
-Vote packages are created by the clients/voters and sent to the relay pool.
-
-```
-{
-"type": "votePackage",
- "processID": b64String,
- "nullifier": hexString,
- "vote": hexString,
- "franchise": hexString
-}
-```
-
-+ **processID:** string identifying the election/process
-+ **nullifier:** hash(clientPrivateKey+ProcessID)
-+ **vote:** pubkey encrypted serialized vote
-+ **franchise:** serialized franchise proof
-
-
-They are sent inside a *Vote Envelope*
-
-#### Vote Envelope
-
-```
-{
- "type": "voteEnvelope",
- "timestamp": uint,
- "keyProof": hexString,
- "nonce": uint64,
- "package": hexString
-}
-```
-
-+ **unix_timestamp:** UNIX time of the exact moment of sending packet
- + if timestamp < current_time, packet is discarted
- + if timestamp > current_time + relay_patience, packet is discarted
- + else packet is processed
-+ **keyProof:** encrypted(8BytesTrunkedHash(package)) String of small size encrypted with relay pubKey, is used to let relays quickly know if the votePackage is for him. No padding.
-+ **nonce:** Proof-of-Work nonce
- hashing the whole data structure should accomplish difficulty. if PoW does not accomplish target difficulty, packet is discarted
-+ **package:** the Vote package as encrypted serialized Hexadecimal string
-
-#### Vote Batches
-
-Batches are sent by Relays once they registered a batch/set of votes to the BlockChain and make them available in the distributed filesystem.
-
-Clients can identify when their vote has been registered once they find the nullifier inside a Batch packet.
-
-```
-{
- "type": "voteBatch",
- "nullifiers": [hexString1,hexString2,...],
- "url" : b64String,
- "txid": hexString,
- "nonce": uint64,
- "signature": hexString
-}
-```
-
-+ **nullifiers**: list of hexString nullifiers included in the batch
-+ **url**: URL where to find the batch package data (such as ipfs-hash)
-+ **txid**: Ethereum transaction ID
-+ **nonce**: Proof-of-Work nonce
-+ **signature**: Relay signature of concatenated nullifiers + url + txid
-
diff --git a/old-content/Interface.md b/old-content/Interface.md
deleted file mode 100644
index 1fef5bee..00000000
--- a/old-content/Interface.md
+++ /dev/null
@@ -1,90 +0,0 @@
-
-# Smart contracts
-
-## Voting contract
-+ getProcessLength(organizationAddress) : int
-+ getProcessByIndex(organizationAddress, index): processId
-+ getProcessMetadataById(organizationAddress, processId): processMetadata
-
----
-
-# Data structs
-
-## ProcessMetadata
-+ censusUrl // Where is the census Merkle-tree
-+ censusRoot // Merkle-root of census
-+ votingOptions // string that has an inmutable reference to the voting options
-+ startTime // block timestamp as seconds since unix epoch
-+ endTime // block timestamp as seconds since unix epoch
-+ voteEncryptionKeys
-+ status
-+ trustedGateways
-
-## VotingPackage
-+ FranchiseProof
-+ EncryptedVote
-+ Nullifier
-+ ProcessID
-
----
-
-# Modules
-
-## Indentity
-+ getVotingPublicKey(): Public Key
-+ getVotingPrivateKey: Private key
-
-## Franchise
-+ getNullifier(privateKey, processId) : nullifierHash
-+ generateProof(privateKey, censusProof, censusRoot, nullifier, processId, encryptedVoteHash) :franchiseProof
-
-## Census
-+ getCensus()
-+ getCensusProof(votingPublicKey)
-
-## Data
-+ getExternalData(url)
-
-## Blockchain
-+ getProcessById(): processMetadata
-+ getOpenProcess(): [processIds]
-+ getRegisterdRelays(): [relayPublicKeys]
-+ batchExists(voteBatchHash): bool
-
-## Relay
-+ generatePOW(votingPackage): powNonce
-+ encryptVotingPackage(votingPakage, relayPublicKey)
-+ sendVote(gatewayIP, votingPackage, powNonce)
-+ getVotesBatchHashByNullifier(nullifier)
-
-## Vote
-+ getOptions()
-+ getEncryptedVote(selectedVoteOptions, voteEncryptionKeys)
-+ getHash(encryptedVoteHash)
-+ getVotingPackage(franchiseProof, processId, encryptedVote, nullifier) : votingPackage
-
----
-
-# Flow
-
-## Vote Manager
-
-1. `Blockchain` --> getProcessById()
-2. `Vote` --> getOptions()
-3. ``
-4. `Vote` --> getEncryptedVote()
-5. `Vote` --> getEncryptedVoteHash()
-6. `Identity` --> getVotingKey()
-7. `Census` --> getCensusProof() `Data` --> getExternalData()
-8. `Identity` --> getVotingPrivateKey()
-9. `Franchise` --> generateFranchiseProof()
-10. `Franchise` --> getNullifier()
-11. `Relay` --> generatePOW()
-12. `Vote` --> getVotingPackage()
-13. `Blockchain` --> getRegisterdRelays()
-14. `Relay` --> encryptVotingPackage()
-15. `Relay` --> sendVote()
-16. `Relay` --> getVotesBatchHashByNullifier():votesBatchHash
-17. `Data` --> getExternalData(voteBatchHash)
-18. `Blockchain` --> batchExists(voteBatchHash)
-
diff --git a/old-content/Prototype1.md b/old-content/Prototype1.md
deleted file mode 100644
index 7ebfbe11..00000000
--- a/old-content/Prototype1.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# Prototype 1
-
-Basic voting implementation with the next restrictions:
-
- - No decentralized relay
- - Very basic client interface
- - No organizer user interface
- - No identities (just keys)
- - Unit testing not required
- - Documentation not required
- - No optimizations
-
----
-
-## Flow
-
-#### Vote Manager
-
-1. `Blockchain` --> getProcessById()
-2. `Vote` --> getOptions()
-3. ``
-4. `Vote` --> getEncryptedVote()
-5. `Vote` --> getEncryptedVoteHash()
-6. `Identity` --> getVotingKey()
-7. `Census` --> getCensusProof() `Data` --> getExternalData()
-8. `Identity` --> getVotingPrivateKey()
-9. `Franchise` --> generateFranchiseProof()
-10. `Franchise` --> getNullifier()
-11. `Relay` --> generatePOW()
-12. `Vote` --> getVotingPackage()
-13. `Blockchain` --> getRegisterdRelays()
-14. `Relay` --> encryptVotingPackage()
-15. `Relay` --> sendVote()
-16. `Relay` --> getVotesBatchHashByNullifier():votesBatchHash
-17. `Data` --> getExternalData(voteBatchHash)
-18. `Blockchain` --> batchExists(voteBatchHash)
-
----
-
-## Interface Calls
-
-+ Local Auth
- - Import @ledfusion's flow
-
-
-+ Census register
- - **App**: HTTP POST ...../register/0x123445678901234567891234567
- - **Process Manager**: Handle HTTP POST and add the pubkey to the census DB
-
-
-+ Process creation
- - **Process Manager**: Get census and generate Merkle tree
- - **dvote-process**: Merkle tree generation (create tree, verify proof)
- - **dvote-process**: Web3 implementation/integration
- - **Process Manager**: Generate priv/pub key for the process (stored locally)
- - **Process Manager**: Publish Merkle Tree (IPFS)
- - **Process Manager**: Generate Process Meta Data (given the name, start block, end block, voting encryption public key and gateway/relay's IP+pubkey)
- - **Process Manager**: Sending creation transaction to the SContract (with Merkle tree root, IPFS Merkle tree hash, meta data)
- - **Smart Contract**: Process creation transaction
-
-
-+ Vote metadata retrieval
- - **App**: fetch process meta data
- - **dvote-client**: Web3 call getProcessMetadata(id)
- - **App**: Display metadata and options
-
-
-+ Voting
- - **App**: Request lock pattern and decrypt the private key
- - **App**: Prepare the vote package
- - **dvote-client**: encryptVote(vote, votePubKey)
- - **dvote-client**: hashEncryptedVote(_, privKey)
- - **dvote-client**: generateProof(aboveData)
- - **dvote-client**: getNullifier(privKey, id)
- - **dvote-client**: generatePOW()
- - **dvote-client**: getVotingPackage()
- - **dvote-client**: getRelays()
- - **dvote-client**: encryptRelayPackage(_)
- - **dvote-client**: sendPackage(...)
- - **Relay**: Listen to incoming vote packages
- - **Relay**: Ignore invalid Proofs of work
- - **dvote-relay**: checkPOW()
- - **Relay**: Get the census
- - **dvote-relay**: decryptVote()
- - **dvote-relay**: checkProof()
- - **Relay**: Batch votes
- - **dvote-relay**: batchVotes([...])
- - **Relay**: Publish batch (IPFS)
- - **Relay**: Send tx to SContract to register the votes batch
- - **dvote-relay**: registerVoteBatch(...)
-
-
-+ Individual vote verification
- - **App**: Ask for a batch containing the vote
- - **dvote-client**: getVotesBatchHashById() (IPFS)
- - **dvote-client**: getExternalData()
- - **dvote-client**: batchExists(nullifier)
- - **App**: Confirm voting status
-
-
-+ Voting ends + Results
- - **Process Manager**: Send a vote closing transaction
- - **dvote-process**: closeVote > Call SContract
- - **Smart Contract**: implement closeVote(privateKey)
- - **Process Manager**: Compute official results
- - **dvote-process**: getResultsFromVote(...)
-
-
-
-
diff --git a/old-content/README.md b/old-content/README.md
deleted file mode 100644
index adb4ef2b..00000000
--- a/old-content/README.md
+++ /dev/null
@@ -1,263 +0,0 @@
-# Voĉdoni
-
-### A fully verifiable decentralized anonymous voting system
-
-_This document is a work in progress and subject to change_
-
-
-Cryptography and distributed p2p systems have given rise to a new, revolutionary digital technology which might change the way society organizes: blockchain. Among many other applications, it can allow for secure, transparent, distributed and resilient decision making.
-
-In this document, we propose the system architecture of a decentralized anonymous voting platform.
-
-## Design overview
-
-We want to bring decentralized voting to mass adoption. This requires a solution that has a user experience at least on par with current, centralized solutions.
-
-We achieve this by externalizing the heavy lifting to a `relay` network - thereby allowing for lightweight end-user clients. This fundamental architectural choice has the following implications:
-
-+ Minimizes transactions to the blockchain. Can potentially be used in the Ethereum Mainnet
-+ `Voter` does not write, only reads from the blockchain
-+ `Voter` can participate with an light-client (static web/app)
-+ Secure vote anonymization using zk-SNARK
-+ Data integrity via content-addressed storage (IPFS)
-+ Economically incentivized, `relay` network performs actions not possible by light-clients
-+ The whole `process` is verifiable by any external observer
-
-
-
-## Definitions
-_The following concepts are referenced extensively throughout the document_
-
-### Actors
-`Voter`
-+ A `voter` is the end user that will vote
-+ Its digital representation is called an `identity`
-+ Inside the voting `process`, and `identity` is represented by a `public key`
-+ Can manage all interactions through a `light-client` (web/app)
-
-`Organizer`
-+ The entity that creates and manages a specific voting `process`
-+ Needs to interact with the blockchain
-+ Needs to add and retrieve data to IPFS
-+ Pays for the costs of a `process` (`relay` transactions and rewards)
-+ Has the highest interest for the `process` to succeed
-+ Knows the census beforehand (list of `voters` that are authorized to participate in a specific `process`)
-
-`Relay`
-+ Is used as a proxy between the `voter` and the blockchain
-+ Is a selfish actor. Good behaviour is ensured through economic incentives
-+ It may have to be split into several `relay` types
-+ Performs functions that would not be possible on a `light-client`
- - Relays `vote packages` to other `relays`
- - Aggregates `vote packages` into a `votes batch`
- - Pins the `votes batch` to IPFS and adds its hash to the blockchain
- - Validates `franchise proofs`
- - Validates anti-spam proof-of-work nonce
- - Ensures data availability on IPFS
- - Is responsible for the data availability of the `vote packages` it has added (will lose stake if those are not available)
- - Exposes an IPFS proxy for the `light-clients`
- - Provides `census` Merkle-proofs to `voter`
- - Exposes an RPC end-point to the blockchain for the `light-client`
- - It should run a full Ethereum node
-
-### Elements
-
-`Process`
-+ It is an specific instance of a voting process
-+ Each `process` is identified by a `ProcessId`
-
-`ProcessId`
-+ A unique identifier for each `process`
-+ Generated by the `Voting smart-contract` when a new process is created
-
-`Light-client`
-+ The client which `voters` will use to vote
-+ Could be an app or static website running on a smart-phone
-+ Provides UI for easy interaction
-+ Runs some moderate computational processes, such as the `franchise proof` and the relay anti-spam proof-of-work generation
-
-`Census`
-+ A Merkle-tree made of the `public keys` of all the `voters`
-+ The Merkle-root is hosted in the blockchain as a proof of the census
-+ The tree needs to be publicly available (IPFS, DAT) for everyone to verify it.
-+ The `zk-SNARK circuit` will use its Merkle-root to validate if a `voter` `public key` is part of it
-
-`Franchise proof`
-+ Leverages zk-SNARK technology
-+ Used to prove two things without revealing critical data
- 1. `Voter` is the owner of the `private key` corresponding to the `public key`
- 2. `Voter`'s `public key` is included in the `census`
-+ Generated in the `user` light-client
-+ Is a CPU and memory intensive process
-+ Is validated by the `relays` before adding the `voting package` in the blockchain
-+ It is validated by the `organizer` once the `process` ends
-
-`zk-SNARK circuit`
-+ Used by the `voter` to generate the `franchise proof`
-+ Used by the `relay` and `organizer` to validate the `franchise proof`
-+ The same circuit can be use for any `process`
-+ It requires a trusted setup to be generated
-
-`Voting smart-contract`
-+ The `process metadata` required by a `process` is published here when a new `process` is created
-+ The `voter` light client retrieves the `process metadata` from here
-+ `Votes batches` hashes are added here
-+ It keeps a list of available relays
-+ It holds the funds used to pay the `relays`
-+ It holds the funds that the `relays` need to stake to ensure their good behaviour
-+ When a `process` is successfully finished it transfers the funds to the `relays`
-
-`Process metadata`
-+ Is the metadata that needs to be public before a `process` starts
- - Merkle Root of the `census` Merkle tree
- - `Vote encryption key`
- - Available `voting options`
- - `Process` start time (block number)
- - `Process` end time (block number)
-
-`Vote package`
-+ Is the set of data sent by the `Voter` to the `relay` in order to vote
-+ Includes:
- - Franchise proof
- - Encrypted vote: encrypt(selected `vote options` + random nonce)
- - `Nullifier` : hash( `ProcessId` + `Voter` `private key` )
- - `ProcessId`
-- Together with the package an anti-spam proof of work is sent
-
-`Votes batch`
-+ `Relays` aggregate multiple `Vote Packages` into a single `Votes batch` in order to minmize blockchain transactions
-+ Its hash is added into the blockchain and pinned into IPFS
-
-
-`Vote encryption key`
-+ Provided by `organizer`
-+ The public key used by the `Voters` to encrypt their vote
-+ Its private key needs to be made public at the end of the process, for everyone to decrypt the votes
-+ Multiple `vote encryption keys` can be used to ensure that no one has access to the results before the `process` is finished
-+ Entities providing the `vote encryption key` could be required to put some stake to ensure key publishing
-
-`Voting options`
-+ A potential option for the user to choose when they vote
-+ They are published when a `process` is created
-+ They could be exclusive or not
-
----
-
-## Voting process chronology
-
-### 0. `Identity` creation
- + Before the process in itself starts `voters` must have their digital `identity` already created.
- + The unique requirement for those `identities` is that they need to be represented by a `public key`.
- + The system is agnostic to the identity system used, but further systems may require additional work to fully integrate.
-
-### 1. The `organizer` generates a census
- + Presently assumes that the `organizer` has a list of all the `voters` that can participate
- + It aggregates all the `public keys` of the `voters` and generates the `census` Merkle tree from them.
-
-### 2. The `organizer` publishes a new voting process.
- + Via a user interface, it provides the required `process metadata` regarding a voting process.
- + Sends a transaction to the `voting smart-contract`
- - It includes the `process metadata`, so is public for the other players
- - The funds sent in the transaction will be used to pay the `relays`
- - The amount sent is proportional to the needs of the `process` (number of participants, relay redundancy...)
- + In parallel it also publishes the `census` to IPFS, to make it available to everyone else.
-
-### 3. `Voter` generates vote
-
-#### Selects `voting options`
- + Gets the `process metadata` from the `voting smart-contract`
- + Gets the `census` Merkle-proof from a `relay`
- + Verifies her `public key` is in the published `census` Merkle tree
- + Selects the desired `voting options` from the `process metadata`
-
-#### Generates vote
-+ Encrypts the selected `voting options` and a random nonce with the `vote encryption keys`
- ```
- encrypted_vote = encrypt( selected_voting_options + random_nonce )
- ```
-+ Generates the nullifier
-```
-nullifier = hash( process_id + user_private_key )
-```
-#### Franchise proof generation
-The `franchise proof` is generated by running the `zk-SNARK voting cicuit` with several inputs.
-
-+ **private input:** Private Key, census Merkle-proof
-+ **public input:** census Merkle-root, Nullifier, ProcessId, Hash(encrypted vote)
-+ **output:** Franchise proof
-
-
-
-
-
-#### Vote package creation
-
-+ The `Vote package` is made of:
- - Franchise proof
- - Encrypted vote
- - Nullifier
- - ProcessID
-
-+ Potentially the `vote package` can be encrypted with one or more `relay` `public keys` in order to choose the relay chain and minimize IP mapping
-
-+ proof-of-Work nonce (to avoid relay node spamming) must be attached to the package. If the PoW is not correct, the relay pool will discard the package.
-
-+ The `vote package` and the nonce are sent to the `relay` pool
-
-
-
-
-
-
-### 4. `Relays` validate and add the `vote package` into the blockchain
- + The `relay` pool receives the `vote package` from the `user`
- + A `relay` verifies the proof-of-work and the `franchise proof`. If either is invalid, the `vote package` is discarded.
- + Chooses a set of pending `vote packages` and compiles them into a `votes batch`.
- + Adds the `votes batch` into IPFS
- + Uploads the `votes batch` hash to the blockchain
-
-### 5. Finalizing the `process`
- + The owners of the `vote encryption keys` publish the corresponding `private keys`, so the votes and proofs can be decrypted
- + The `organizer` gets the hashes the `votes batch` from the blockchain
- + The `organizer` downloads the `votes batch` from IPFS
- + The `organizer` iterates over all the `vote packages`
- - It decrypts the `encrypted vote` with the published private key of the `voting encryption keys`
- - It runs the `franchise proof` through the `zk-SNARK circuit` and discards invalid proofs
- - It discards `vote-packages` with repeated `nullifier` (double votes)
- - It computes the final results
- + The `organizer` signals bad `relays`
- + The `organizer` makes the `process` closing transaction, uploading the results
- + `Relays` are rewarded according to their contribution
-
-
-
-
----
-## Aditional notes
-### Known Weaknesses
-- Zk-SNARK trusted setup
-- IP/vote mapping
-- Most of the unresolved details are around creating a fully decentralized relay network. Multiple alternatives exist.
-- A centralized trusted `relay` is a very valid option in a certain context
-
-### Identity
-The system is agnostic to the identity scheme used.
-
-We are developing our implementation using [Iden3](https://iden3.io),for its balance of decentralization and scalability.
-
-Other identity schemes could eventually be integrated.
-
-## Light-client
-
-The `light-client` website/app will allow users and organizers interact with the whole system.
-
-This piece must be as static as possible, thus non dependent on any dynamic database. This allows for multiple ways to access the frontend, for instance via IPFS or ZeroNet, making censorship very hard or even impossible.
-
-Being static makes it easier to checksum it and therefore minimizing atac vectors.
-
-The `light-client` needs to interact with different service providers such as Web3 RPC, IPFS gateway or TOR proxy. However the user must be able to choose its own provider.
-
-
)
@@ -32,7 +37,7 @@ PM --> |Export Merkle tree|CS
PM -.- |Pin metadata and census|DATA
PM --> |Declare voting process|BP
-subgraph
+subgraph Decentralized storage
BP
DATA
end
@@ -47,8 +52,8 @@ The client submits a Vote envelope (containing the ZK-Proof and the voting choic
The Vochain nodes and miners validate the Zero Knowledge proof. If valid, the vote package is added to the next block and becomes available for computing the results.
```mermaid
-graph TD
+graph TD
APP(
App user
)
DATA[
P2P Filesystem
]
GW[
Gateway
]
@@ -57,9 +62,9 @@ CS[
Census Service
Vochain node
]
VM[
Vochain Miner
]
-APP --> |
0 Fetch entity open processes
| GW
+APP --> |
0 Fetch entity's open processes
| GW
APP -->|
1 Fetch process metadata 2 Get census proof 3 Generate Zero Knowledge 4 Submit voting package
| GW
-GW -->|
Get metadata
|DATA
+GW -->|Get metadata|DATA
GW -.- PSS
PSS -.-|Get/check merkle proof|CS
PSS -.-|Relay voting package|VN
@@ -112,9 +117,3 @@ end
```
**Note**: The ZK-Rollups functionality may need heavy computation resources and development time until it is available. For this reason, intermediary approaches like Optimistic Rollups may be implemented first and iterated later.
-
----
-
-### Coming next
-
-See the [Census overview](/architecture/census-overview) section.
diff --git a/docs/architecture/protocol/data-origins.md b/src/architecture/protocol/data-origins.md
similarity index 89%
rename from docs/architecture/protocol/data-origins.md
rename to src/architecture/protocol/data-origins.md
index 6e81abd8..4dadadcf 100644
--- a/docs/architecture/protocol/data-origins.md
+++ b/src/architecture/protocol/data-origins.md
@@ -2,11 +2,11 @@
Most of the metadata schemes discussed in the documentation need to point to external data that may be available through various channels.
-To overcome delays or data unavailability, a prioritized list of URI's and fallbacks is used. Depending on the type of resource, **Content URI's** or **Messaging URI's** are used.
+To overcome delays or data unavailability, a prioritized list of URIs and fallbacks is used. Depending on the type of resource, **Content URIs** or **Messaging URIs** are used.
## Content URI
-Transfering data files may be done through IPFS and http/s (Swarm and Swarm Feeds may be supported in the future). In order to use an ordered list of origins and fallbacks, Vocdoni defines data origins in a single field by using a **comma separated list of URI's** like the examples below:
+Transfering data files may be done through IPFS and http/s (Swarm and Swarm Feeds may be supported in the future). In order to use an ordered list of origins and fallbacks, Vocdoni defines data origins in a single field by using a **comma separated list of URIs** like the examples below:
- `ipfs://,https://cloudflare-ipfs.com/ipfs/your-ipfs-hash`
- First, try to fetch the given <content-hash> from IPFS
@@ -19,8 +19,6 @@ Supported protocols:
- `ipfs://`
- `https:///`
-
-
URI order matters:
- Clients are expected to try using URI's from left to right
@@ -62,6 +60,4 @@ Where protocols like PSS or Whisper allow for pseudo anonymous communication, hi
In this case, Vocdoni proposes the use of [Nym](https://nymtech.net/) as a mixing infrastructure for anonymous voting submission that cannot be correlated to an IP address.
-### Coming next
-See the [Sequence Diagrams](/architecture/sequence-diagrams) section.
diff --git a/docs/architecture/protocol/franchise-proof.md b/src/architecture/protocol/franchise-proof.md
similarity index 92%
rename from docs/architecture/protocol/franchise-proof.md
rename to src/architecture/protocol/franchise-proof.md
index 98e460de..f42640c9 100644
--- a/docs/architecture/protocol/franchise-proof.md
+++ b/src/architecture/protocol/franchise-proof.md
@@ -2,7 +2,7 @@
The franchise proof enables user privacy and allows anonymous voting.
-The starting point is a [Merkle Proof](/architecture/census-overview?id=the-census), which efficiently proves that a public key belongs to a Merkle Tree (census). However, using this proof alone would allow the organizer to correlate the vote envelopes with the public key on the database, so that votes wouldn't be secret.
+The starting point is a [Merkle Proof](/architecture/census-overview.html#the-census), which efficiently proves that a public key belongs to a Merkle Tree (census). However, using this proof alone would allow the organizer to correlate the vote envelopes with the public key on the database, so that votes wouldn't be secret.
To this end, Vocdoni achieves voting anonymity by the use of ZK-Snarks.
@@ -33,7 +33,7 @@ Data that could reveal the identity of the voter are kept private (gray boxes in
#### Proof generation
-The franchise proof is generated by running the ZK-SNARK cicuit.
+The franchise proof is generated by running the ZK-SNARK circuit.
+ **Private inputs:** Private Key, Census Merkle-proof, Vote-signature
+ **Public inputs:** Census Merkle-root, Nullifier, ProcessId, Vote
@@ -77,7 +77,7 @@ Under this proposal, voters submit their encrypted vote envelopes using the same
The new ZK-Proof and the results aggregate is what will be stored in a public blockchain, such as the Vochain or Ethereum.
In this scenario voters are able to verify that their vote has been processed. No outsider, however, can determine what choices were selected by a specific voter.
-At the same time, the election's traceability and transparency properties are preserverd.
+At the same time, the election's traceability and transparency properties are preserved.
@@ -106,7 +106,7 @@ Unlike ZK Snarks, **LRS do not rely on a trusted setup**.
**Academic papers**
- https://eprint.iacr.org/2018/379.pdf
-- https://dl.acm.org/citation.cfm?id=2103015
+- https://dl.acm.org/citation.cfm.html#2103015
**Libraries**
- Go implementation: https://github.com/noot/ring-go (linkable branch)
@@ -117,7 +117,7 @@ Unlike ZK Snarks, **LRS do not rely on a trusted setup**.
#### 1. Registration to an organization
-First, the Voters need to send their public keys to the Census organization service (each organization can choose which method to use for veryfing and identity). This is done just once so the same public key can be used for multiple elections.
+First, the Voters need to send their public keys to the Census organization service (each organization can choose which method to use for verifying an identity). This is done just once so the same public key can be used for multiple elections.
```mermaid
graph TD;
@@ -135,17 +135,17 @@ The usage of LRS requires the census to be published, so Voters can create their
+ If Census > 1000, census must be split on several groups of keys
+ the organizer will publish a number (N) which will be used by the voters to know to which group of keys are they assigned by using the following formula:
`GroupNumber = VoterPubKey % N`
- + before publishing N the census must pre-compute all the keys to check that if accomplish the minimum size grup of keys. So in case N generates a group with too few, that number must be discarted and try a new one
+ + before publishing N the census must pre-compute all the keys to check that if accomplish the minimum size group of keys. So in case N generates a group with too few, that number must be discarted and try a new one
#### 3. Derivate election keys
-In addition to `N`, the Organizer will publish a uniq ID that will identify the election (`processID`). This ID will be used by both parties (Voter and Organizer) to derivate the temporary election pulic keys using the following mechanism:
+In addition to `N`, the Organizer will publish a uniq ID that will identify the election (`processID`). This ID will be used by both parties (Voter and Organizer) to derivate the temporary election public keys using the following mechanism:
-+ On ECDSA the PubKey derivates from the PrivKey as follows:
++ On ECDSA the PubKey deviates from the PrivKey as follows:
`PubKeyVoter = PrivKeyVoter * G`
+ The Organizer derivate the new temporary PublicKey for each voter this way:
`PubKeyElectionVoter = PubKeyVoter + G*Hash(ElectionID)`
-+ Each voter derivates its new Private Key this way:
++ Each voter deviates their new Private Key this way:
`PrivKeyElectionVoter = PrivKeyVoter + Hash(ElectionID)`
@@ -165,7 +165,7 @@ C-.->Pub3["PubKey V3 + electionID"]
R[Linkable Ring Signature]
V1-.->Priv1["Privkey V1 + electionID"]
-Priv1-- >|create election signatre| R
+Priv1-- >|create election signature| R
subgraph
Pub1-.-R
@@ -393,11 +393,9 @@ true
Time and size scales linearly.
* 100 ring size signature needs 0.8s to be signed and have a size of 19kBytes
-* 1000 ring size signaure needs 7s to be signed and have a size of 193kBytes
-* 5000 ring size signaure needs 38s to be signed and have a size of 964kBytes
+* 1000 ring size signature needs 7s to be signed and have a size of 193kBytes
+* 5000 ring size signature needs 38s to be signed and have a size of 964kBytes
-->
-### Coming next
-See the [Data origins](/architecture/protocol/data-origins) section.
diff --git a/docs/architecture/protocol/json-api.md b/src/architecture/protocol/json-api.md
similarity index 94%
rename from docs/architecture/protocol/json-api.md
rename to src/architecture/protocol/json-api.md
index 76b0937e..e7f8982f 100644
--- a/docs/architecture/protocol/json-api.md
+++ b/src/architecture/protocol/json-api.md
@@ -107,7 +107,7 @@ Then:
`payload.signature` = `ECDSA.SIGN` ( `keccak256` ( `stringify` ( `payload.request` ) ) )
-The verificator will verify the signature, extract the ECDSA public key from the signature, convert it to Ethereum like address and finally compare it with the list of allowed addresses.
+The verifier will verify the signature, extract the ECDSA public key from the signature, convert it to Ethereum like address and finally compare it with the list of allowed addresses.
**Important**: To avoid signature mismatches, the stringified data of the `request` has to be computed always the JSON fields **sorted alphabetically**.
@@ -152,6 +152,4 @@ Where:
-### Coming next
-See the [Franchise proof](/architecture/protocol/franchise-proof) section.
diff --git a/docs/architecture/sequence-diagrams.md b/src/architecture/sequence-diagrams.md
similarity index 59%
rename from docs/architecture/sequence-diagrams.md
rename to src/architecture/sequence-diagrams.md
index 8ea75d36..4a725b66 100644
--- a/docs/architecture/sequence-diagrams.md
+++ b/src/architecture/sequence-diagrams.md
@@ -1,26 +1,26 @@
# Sequence diagrams
-Traditional systems like API's present simple scenarios, in which a centralized service define how data should be encoded. However, decentralized ecosystems like a distributed vote system need much stronger work on defining every interaction between any two peers on the network.
-
-- [Prior to voting](#prior-to-voting)
- - [Initial Gateway discovery](#initial-gateway-discovery)
- - [Set Entity metadata](#set-entity-metadata)
-- [Voting](#voting)
- - [Voting process creation](#voting-process-creation)
- - [Voting process retrieval](#voting-process-retrieval)
- - [Check census inclusion](#check-census-inclusion)
- - [Casting a vote](#casting-a-vote)
-- [After voting](#after-voting)
- - [Checking a Vote Envelope](#checking-a-vote-envelope)
- - [Closing a Voting Process](#closing-a-voting-process)
- - [Vote Scrutiny](#vote-scrutiny)
+Traditional systems like APIs present simple scenarios, in which a centralized service define how data should be encoded. However, decentralized ecosystems like a distributed vote system need much stronger work on defining every interaction between any two peers on the network.
+
+- [Sequence diagrams](#sequence-diagrams)
+ - [Prior to voting](#prior-to-voting)
+ - [Initial Gateway discovery](#initial-gateway-discovery)
+ - [Set Entity metadata](#set-entity-metadata)
+ - [Adding users to a census](#adding-users-to-a-census)
+ - [Voting](#voting)
+ - [Voting process creation](#voting-process-creation)
+ - [Voting process retrieval](#voting-process-retrieval)
+ - [Check census inclusion](#check-census-inclusion)
+ - [Casting a vote](#casting-a-vote)
+ - [After voting](#after-voting)
+ - [Checking a Vote Envelope](#checking-a-vote-envelope)
+ - [Closing a Voting Process](#closing-a-voting-process)
+ - [Vote Scrutiny](#vote-scrutiny)
---
## Prior to voting
----
-
### Initial Gateway discovery
The app wants to get initial connectivity with the available gateways.
@@ -32,16 +32,17 @@ The app wants to get initial connectivity with the available gateways.
- From one of the boot nodes, we get a list of Gateways provided by Vocdoni
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant Client
participant DV as DVote
- participant ER as Entity Resolver contract
+ participant ER as Entity Resolver contract
participant BN as BootNode
- Client->>DV: Gateway.getActive(ethGateway, resolverAddress, entityId)
- DV->>ER: EntityResolver.list(resolverAddress, entityId, "vnd.vocdoni.boot")
+ Client->>DV: Gateway.getActive(ethGateway, resolverAddress, entityId)
+ DV->>ER: EntityResolver.list(resolverAddress, entityId, "vnd.vocdoni.boot")
ER-->>DV: bootNodeUrl[]
DV->>BN: GET /gateways.json
@@ -54,15 +55,16 @@ Eventually:
- One of Vocdoni's Gateways is used to query the ENS resolver of a certain Entity
### Set Entity metadata
-An Entity starts existing at the moment it has certain metadata stored on the [Entity Resolver](/architecture/smart-contracts/entity-resolver?id=entityresolver) smart contract.
+An Entity starts existing at the moment it has certain metadata stored on the [Entity Resolver](/architecture/smart-contracts/entity-resolver.html#entityresolver) smart contract.
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
- participant EM as Entity Manager
+ participant EM as Entity Manager
participant DV as DVote
- participant GW as Gateway/Web3
- participant ER as Entity Resolver contract
+ participant GW as Gateway/ Web3
+ participant ER as Entity Resolver contract
participant IPFS
EM->>DV: getEntityId(entityAddress)
@@ -75,15 +77,15 @@ sequenceDiagram
EM->>+DV: addFile(json)
DV->>GW: addFile(json)
- GW->>IPFS: #60; uri #62;
+ GW->>IPFS: uri
IPFS-->>GW:
GW-->>DV:
DV-->>-EM:
EM->>+DV: setMetadata(entityId, uri)
- DV->>GW: setText(entityId, "vnd.vocdoni.boot", uri)
- GW->>ER: #60; transaction #62;
+ DV->>GW: setText(entityId, "vnd.vocdoni.boot", uri)
+ GW->>ER: transaction;
ER-->>GW:
GW-->>DV:
DV-->>-EM:
@@ -98,24 +100,25 @@ sequenceDiagram
Depending on the activity of users, an **Entity** may decide to add public keys to one or more census.
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
- participant PM as Entity Manager
- participant DB as Internal Database
+ participant PM as Entity Manager
+ participant DB as Internal Database
participant DV as DVote
- participant GW as Gateway/Web3
- participant CS as Census Service
+ participant GW as Gateway/ Web3
+ participant CS as Census Service
- PM->>DB: getUsers({ pending: true })
+ PM->>DB: getUsers( { pending: true })
DB-->>PM: pendingUsers
loop pendingUsers
- PM->>DV: Census.addClaim(censusId, censusMessagingURI, claimData, web3Provider)
+ PM->>DV: Census.addClaim(censusId, censusMessagingURI, claimData, web3Provider)
activate DV
- DV->>DV: signRequestPayload(payload, web3Provider)
+ DV->>DV: signRequestPayload( payload, web3Provider)
deactivate DV
- DV->>GW: addCensusClaim(addClaimPayload)
- GW->>CS: addClaim(claimPayload)
+ DV->>GW: addCensusClaim( addClaimPayload)
+ GW->>CS: addClaim( claimPayload)
CS-->>GW: success
GW-->>DV: success
DV-->>PM: success
@@ -124,8 +127,8 @@ sequenceDiagram
**Used schemas:**
-- [Census Service addClaim](/architecture/services/census-service?id=addclaim)
-- [Census Service addClaimBulk](/architecture/services/census-service?id=addclaimbulk)
+- [Census Service addClaim](/architecture/services/census-service.html#addclaim)
+- [Census Service addClaimBulk](/architecture/services/census-service.html#addclaimbulk)
---
@@ -134,23 +137,24 @@ sequenceDiagram
### Voting process creation
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
- participant PM as Entity Manager
+ participant PM as Entity Manager
participant DV as DVote
- participant GW as Gateway/Web3
- participant CS as Census Service
+ participant GW as Gateway/ Web3
+ participant CS as Census Service
participant IPFS as IPFS
participant BC as Blockchain
- PM->>+DV: Process.create(processDetails)
+ PM->>+DV: Process.create( processDetails)
- DV->>+GW: censusDump(censusId, signature)
+ DV->>+GW: censusDump( censusId, signature)
GW->>+CS: dump(censusId, signature)
CS-->>-GW: merkleTree
GW-->>-DV: merkleTree
- DV-->>GW: addFile(merkleTree) : merkleTreeHash
- GW-->IPFS: IPFS.put(merkleTree) : merkleTreeHash
+ DV-->>GW: addFile(merkleTree) : merkleTreeHash
+ GW-->IPFS: IPFS.put(merkleTree): merkleTreeHash
GW-->>DV:
DV->>+GW: getCensusRoot(censusId)
@@ -158,12 +162,12 @@ sequenceDiagram
CS-->>-GW: rootHash
GW-->>-DV: rootHash
- DV-->>GW: addFile(processMetadata) : metadataHash
+ DV-->>GW: addFile(processMetadata) : metadataHash
GW-->IPFS: IPFS.put(processMetadata) : metadataHash
GW-->>DV:
- DV->>+GW: Process.create(name, metadataContentUri, params)
- GW->>+BC: #60; transaction #62;
+ DV->>+GW: Process.create(name, metadataContentUri, params)
+ GW->>+BC: transaction;
BC-->>-GW: txId
GW-->>-DV: txId
@@ -171,7 +175,7 @@ sequenceDiagram
GW-->BC: IPFS.put(newJsonMetadata)
GW-->>-DV: jsonHash
- DV->>+GW: EntityResolver.set(entityId, 'vnd.vocdoni.meta', metadataContentUri)
+ DV->>+GW: EntityResolver.set( entityId, 'vnd.vocdoni.meta', metadataContentUri)
GW-->>-DV: txId
DV-->>-PM: success
@@ -179,16 +183,17 @@ sequenceDiagram
**Used schemas:**
-- [Process Metadata](/architecture/data-schemes/process?id=process-metadata)
-- [Census Service addClaimBulk](/architecture/services/census-service?id=addclaimbulk)
-- [Census Service getRoot](/architecture/services/census-service?id=getroot)
-- [Census Service dump](/architecture/services/census-service?id=dump)
+- [Process Metadata](/architecture/data-schemes/process.html#process-metadata)
+- [Census Service addClaimBulk](/architecture/services/census-service.html#addclaimbulk)
+- [Census Service getRoot](/architecture/services/census-service.html#getroot)
+- [Census Service dump](/architecture/services/census-service.html#dump)
### Voting process retrieval
A user wants to retrieve the voting processes of a given Entity
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant App as App user
participant DV as DVote
@@ -196,9 +201,9 @@ sequenceDiagram
participant BC as Blockchain
participant IPFS as IPFS
- App->>+DV: Process.fetchByEntity(entityAddress, resolver)
+ App->>+DV: Process.fetchByEntity( entityAddress, resolver)
- DV->>GW: EntityResolver.text(entityId, "vnd.vocdoni.meta")
+ DV->>GW: EntityResolver.text( entityId, "vnd.vocdoni.meta")
GW->>BC: text(entityId, "vnd.vocdoni.meta")
BC-->>GW: contentUri
GW-->>DV: contentUri
@@ -211,8 +216,8 @@ sequenceDiagram
DV->>GW: getMetadata(processId)
GW->>BC: getMetadata(processId)
- BC-->>GW: (metadata, merkleRoot, params)
- GW-->>DV: (metadata, merkleRoot, params)
+ BC-->>GW: (metadata, merkleRoot, params)
+ GW-->>DV: (metadata, merkleRoot, params)
alt Process is active or in the future
DV->>GW: fetchFile(metadataHash)
@@ -227,13 +232,14 @@ sequenceDiagram
**Used schemas:**
-- [Process Metadata](/architecture/data-schemes/process?id=process-metadata)
+- [Process Metadata](/architecture/data-schemes/process.html#process-metadata)
### Check census inclusion
A user wants to know whether he/she belongs in the census of a process or not.
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant App as App user
participant DV as DVote
@@ -252,7 +258,7 @@ sequenceDiagram
**Used schemas:**
-- [Census Service generateProof](/architecture/services/census-service?id=generateproof)
+- [Census Service generateProof](/architecture/services/census-service.html#generateproof)
**Notes:**
@@ -264,6 +270,7 @@ sequenceDiagram
A user wants to submit a vote for a given governance process.
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant App
@@ -274,7 +281,7 @@ sequenceDiagram
App->>+DV: Process.castVote(vote, processMetadata, merkleProof?)
- DV->>+GW: genProof(processMetadata.census.id, publicKey)
+ DV->>+GW: genProof( processMetadata.census.id, publicKey)
GW->>+CS: genProof(publicKeyHash)
CS-->>-GW: merkleProof
@@ -284,18 +291,18 @@ sequenceDiagram
DV->>DV: computeNullifier()
alt Encrypted process
- DV->>DV: encrypt(vote, processMetadata.publicKey)
+ DV->>DV: encrypt(vote, processMetadata.publicKey)
end
alt Anonymous vote
- DV->>DV: generateZkProof(provingK, verificationK, signals)
+ DV->>DV: generateZkProof(provingK, verificationK, signals)
end
alt Encrypted process
- DV->>DV: encryptVotePackage(votePackage)
+ DV->>DV: encryptVotePackage( votePackage)
end
- DV->>GW: submitVoteEnvelope(voteEnvelope)
+ DV->>GW: submitVoteEnvelope( voteEnvelope)
GW->>MP: addEnvelope(voteEnvelope)
MP-->>GW: ACK
@@ -307,9 +314,9 @@ sequenceDiagram
**Used schemas:**
-- [Process Metadata](/architecture/data-schemes/process?id=process-metadata)
-- [Census Service generateProof](/architecture/services/census-service?id=generateproof)
-- [Vote Package](/architecture/smart-contracts/process?id=vote-package)
+- [Process Metadata](/architecture/data-schemes/process.html#process-metadata)
+- [Census Service generateProof](/architecture/services/census-service.html#generateproof)
+- [Vote Package](/architecture/smart-contracts/process.html#vote-package)
**Notes:**
- The Merkle Proof could be retrieved and stored beforehand
@@ -321,6 +328,7 @@ sequenceDiagram
A user wants to check the status of an envelope by its nullifier.
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant App
participant DV as DVote
@@ -331,9 +339,9 @@ sequenceDiagram
DV->>DV: computeNullifier()
- DV->>+GW: getEnvelopeStatus(processId, nullifier)
+ DV->>+GW: getEnvelopeStatus( processId, nullifier)
- GW-->>VN: getEnvelopeStatus(processId, nullifier)
+ GW-->>VN: getEnvelopeStatus( processId, nullifier)
VN-->>GW: status
GW-->>-DV: status
@@ -344,16 +352,17 @@ sequenceDiagram
### Closing a Voting Process
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant PM as Entity Manager
participant DV as DVote
participant GW as Gateway/Web3
participant BC as Blockchain Process
- PM->>DV: Process.endProcess(processId)
+ PM->>DV: Process.endProcess( processId)
- DV->>+GW: Process.setStatus(processId, "ENDED")
- GW->>+BC: setStatus(processId, "ENDED")
+ DV->>+GW: Process.setStatus( processId, "ENDED")
+ GW->>+BC: setStatus( processId, "ENDED")
BC-->>-GW: success
GW-->>-DV: success
@@ -365,6 +374,7 @@ sequenceDiagram
Anyone with network access can compute the scrutiny of a given processId. The node can even compute a ZK Rollup proof to let the contract verify the correctness of the provided results on-chain.
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant SC as Scrutinizer
participant DV as DVote
@@ -376,10 +386,10 @@ sequenceDiagram
DV->>+GW: Process.get(processId)
GW->>+BC: Process.get(processId)
- BC-->>-GW: (name, metadataContentUri, privateKey)
- GW-->>-DV: (name, metadataContentUri, privateKey)
+ BC-->>-GW: (name, metadataContentUri, privateKey)
+ GW-->>-DV: (name, metadataContentUri, privateKey)
- DV-->>-SC: (name, metadataContentUri)
+ DV-->>-SC: (name, metadataContentUri)
SC->>+DV: IPFS.get(metadataHash)
@@ -390,10 +400,10 @@ sequenceDiagram
DV-->>-SC: processMetadata
- SC->>+DV: getEnvelopeNullifiers(processId)
+ SC->>+DV: getEnvelopeNullifiers( processId)
loop
- DV->>+GW: Process.getEnvelopeList(processId)
- GW->>+BC: Process.getEnvelopeList(processId)
+ DV->>+GW: Process.getEnvelopeList( processId)
+ GW->>+BC: Process.getEnvelopeList( processId)
BC-->>-GW: nullifiers[]
GW-->>-DV: nullifiers[]
end
@@ -401,16 +411,16 @@ sequenceDiagram
SC->>+DV: getEnvelopes(nullifiers[])
loop
- DV->>+GW: Process.getEnvelope(nullifier)
- GW->>+BC: Process.getEnvelope(nullifier)
+ DV->>+GW: Process.getEnvelope( nullifier)
+ GW->>+BC: Process.getEnvelope( nullifier)
BC-->>-GW: envelope
GW-->>-DV: envelope
end
DV-->>-SC: envelopes[]
- SC->>SC: sort(merge(filterValid(envelopes)))
- SC->>SC: resolveDuplicates(validEnvelopes)
+ SC->>SC: sort(merge( filterValid(envelopes)))
+ SC->>SC: resolveDuplicates( validEnvelopes)
loop uniqueVotePackages
@@ -426,15 +436,15 @@ sequenceDiagram
DV-->>-SC: voteValue
end
- SC->>SC: updateVoteCount(voteValue)
+ SC->>SC: updateVoteCount( voteValue)
end
alt
- SC->>+DV: setResults(processId, voteCounts)
- DV->>DV: computeZkRollup(voteCount, params)
+ SC->>+DV: setResults( processId, voteCounts)
+ DV->>DV: computeZkRollup( voteCount, params)
- DV->>+GW: Process.setResults(processId, results, voteCount, proof)
- GW->>+BC: setResults(processId, results, voteCount, proof)
+ DV->>+GW: Process.setResults( processId, results, voteCount, proof)
+ GW->>+BC: setResults( processId, results, voteCount, proof)
BC->>BC: verify(proof)
BC-->>-GW: success
GW-->>DV: success
@@ -445,9 +455,7 @@ sequenceDiagram
**Used schemas:**
-- [Process Metadata](/architecture/data-schemes/process?id=process-metadata)
-- [Vote Package](/architecture/smart-contracts/process?id=vote-package)
+- [Process Metadata](/architecture/data-schemes/process.html#process-metadata)
+- [Vote Package](/architecture/smart-contracts/process.html#vote-package)
-### Coming next
-See the [Libraries and Tooling](/architecture/libraries-tooling) section.
diff --git a/docs/architecture/services/bootnode.md b/src/architecture/services/bootnode.md
similarity index 93%
rename from docs/architecture/services/bootnode.md
rename to src/architecture/services/bootnode.md
index 0f9afcf2..8d33ee55 100644
--- a/docs/architecture/services/bootnode.md
+++ b/src/architecture/services/bootnode.md
@@ -35,6 +35,4 @@ The data schema used to define a set of boot nodes is a JSON file like the examp
}
```
-### Coming next
-See the [Entity Metadata](/architecture/data-schemes/entity-metadata) section.
diff --git a/docs/architecture/services/census-service.md b/src/architecture/services/census-service.md
similarity index 96%
rename from docs/architecture/services/census-service.md
rename to src/architecture/services/census-service.md
index 1dcff28b..994eab6d 100644
--- a/docs/architecture/services/census-service.md
+++ b/src/architecture/services/census-service.md
@@ -97,7 +97,7 @@ Adds a payload to the census Merkle Tree and returns the updated Root Hash
**Used in:**
-- [Adding users to a census](/architecture/sequence-diagrams?id=adding-users-to-a-census)
+- [Adding users to a census](/architecture/sequence-diagrams.html#adding-users-to-a-census)
### Add Claim Bulk
@@ -215,7 +215,7 @@ Adds a set of payloads to the census Merkle Tree and returns the updated Root Ha
"method": "genProof",
"censusId": "0x123456789", // Merkle Root of the census for which the claim siblings are requested
"censusKey": "base64-string", // the leaf for which the proof is requested (base64 encoded)
- "censusValue": "hexString", // if weigthed census, the hexadecimal representation of the numeric big num weight
+ "censusValue": "hexString", // if weighted census, the hexadecimal representation of the numeric big num weight
"digested": false, // is the key digested? the backend should do it if not
"rootHash": "optional-hexString" // from a specific version
},
@@ -247,7 +247,7 @@ Adds a set of payloads to the census Merkle Tree and returns the updated Root Ha
"censusId": "0x123456789", // Merkle Root of the census for which the Merkle Tree's claim will be checked
"censusKey": "base64-string", // the leaf for which data is requested
"censusValue": "hexString", // if weighted census, the hexadecimal representation of the weight big num
- "proofData": "hexString", // the siblings, same format obtainet in genProof
+ "proofData": "hexString", // the siblings, same format obtained in genProof
"digested": false, // is the claim digested? the backend should do it if not
"rootHash": "optional-hexString" // from a specific version
},
@@ -269,7 +269,7 @@ Adds a set of payloads to the census Merkle Tree and returns the updated Root Ha
### Census Dump
-Dumps the entire content of the census as an array of hexStrings rady to be imported to another census service.
+Dumps the entire content of the census as an array of hexStrings ready to be imported to another census service.
**Private Method**
@@ -340,7 +340,7 @@ Dumps the content of the census in base64 format. The dump cannot be used afterw
### Census Import Local Dump
-Only works with specific merkletree format used by `dump` method. To add a list of plain claims use `addClaimBulk` instead.
+Only works with specific merkle tree format used by `dump` method. To add a list of plain claims use `addClaimBulk` instead.
**Private Method**
@@ -429,6 +429,4 @@ Import a previously published remote census. Only valid URIs accepted (depends o
}
```
-### Coming next
-See the [Boot node](/architecture/services/bootnode) section.
diff --git a/docs/architecture/services/gateway.md b/src/architecture/services/gateway.md
similarity index 89%
rename from docs/architecture/services/gateway.md
rename to src/architecture/services/gateway.md
index 571b8a20..d494d4f9 100644
--- a/docs/architecture/services/gateway.md
+++ b/src/architecture/services/gateway.md
@@ -10,10 +10,14 @@ The following diagram shows the gateway's overall architecture and components.
### Discovery mechanism
-A Gateway is a neutral piece of the ecosystem which can be contributed by any third party. Any kind of organization might run Gateway instances to improve network access and increase resilence against potential attacks.
+A Gateway is a neutral piece of the ecosystem which can be hosted by any third party. Any kind of organization might run Gateway instances to improve network access and increase resilience against potential attacks.
To this end, Gateways use an automatic discovery system through a P2P messaging network so that Bootnodes know of their existence. Clients make requests to Bootnodes and fetch a fresh list of working Gateways.
+
+
+
+
```mermaid
graph TD
GW1(
Gateway
)
@@ -30,7 +34,7 @@ MS-->BO2
## API definition
-A Gateway exposes APIs that enable accesing peer-to-peer networks. The currently supported API schemes are the following:
+A Gateway exposes APIs that enable accessing peer-to-peer networks. The currently supported API schemes are the following:
+ `Info API`: details about the gateway
+ `Census API` access to the Census Service
@@ -46,7 +50,7 @@ The API methods below follow the [JSON API](/architecture/protocol/json-api) spe
## Info API
### Get Gateway Info
-Get an overview wabout the own gateway: available APIs, health and whether private methods are available or not.
+Get an overview of the gateway status: available APIs, health and whether private methods are available or not.
```json
{
@@ -74,13 +78,13 @@ Get an overview wabout the own gateway: available APIs, health and whether priva
## Census API
-The Census API methods can be found on the [Census Service section](/architecture/services/census-service?id=json-api).
+The Census API methods can be found on the [Census Service section](/architecture/services/census-service.html#json-api).
## Vote API
### Submit Raw Vochain Transaction
-Send a [Vote Envelope](/architecture/smart-contracts/process?id=vote-envelope) to the mempool of the [Vochain](/architecture/services/vochain).
+Send a [Vote Envelope](/architecture/smart-contracts/process.html#vote-envelope) to the mempool of the [Vochain](/architecture/services/vochain).
```json
{
@@ -108,7 +112,7 @@ Send a [Vote Envelope](/architecture/smart-contracts/process?id=vote-envelope) t
### Submit Envelope
-Send a [Vote Envelope](/architecture/smart-contracts/process?id=vote-envelope) to the mempool of the [Vochain](/architecture/services/vochain).
+Send a [Vote Envelope](/architecture/smart-contracts/process.html#vote-envelope) to the mempool of the [Vochain](/architecture/services/vochain).
```json
{
@@ -135,11 +139,11 @@ Send a [Vote Envelope](/architecture/smart-contracts/process?id=vote-envelope) t
```
**Used in:**
-- [Casting a vote](https://docs.vocdoni.io/#/architecture/sequence-diagrams?id=casting-a-vote)
+- [Casting a vote](https://docs.vocdoni.io/#/architecture/sequence-diagrams.html#casting-a-vote)
### Get Envelope Status
-Check the status of an already submited [Vote Envelope](/architecture/smart-contracts/process?id=vote-envelope). The envelope is identified by the voter's nullifier.
+Check the status of an already submitted [Vote Envelope](/architecture/smart-contracts/process.html#vote-envelope). The envelope is identified by the voter's nullifier.
```json
{
@@ -167,7 +171,7 @@ Check the status of an already submited [Vote Envelope](/architecture/smart-cont
}
```
**Used in:**
-- [Checking a Vote Envelope](https://docs.vocdoni.io/#/architecture/sequence-diagrams?id=checking-a-vote-envelope)
+- [Checking a Vote Envelope](https://docs.vocdoni.io/#/architecture/sequence-diagrams.html#checking-a-vote-envelope)
### Get Envelope Height
@@ -231,7 +235,7 @@ Get the available encryption keys for the given process ID.
If the process has encrypted votes and it is on-going, `encryptionPubkeys` and `commitmentKeys` should be available. Once the process has ended, `encryptionPrivKeys` and `revealKeys` will be also be available.
-[Vote Package](/architecture/smart-contracts/process?id=vote-package) encryption and decryption it is expected to use these keys following the order of their indexes. Smaller indexes are used first and it's important to note that indexes might not be consecutive.
+[Vote Package](/architecture/smart-contracts/process.html#vote-package) encryption and decryption keys are expected to follow the order of their indexes. Smaller indexes are used first and it's important to note that indexes might not be consecutive.
```json
{
@@ -260,7 +264,7 @@ If the process has encrypted votes and it is on-going, `encryptionPubkeys` and `
```
**Used in:**
-- [Checking a Vote Envelope](https://docs.vocdoni.io/#/architecture/sequence-diagrams?id=checking-a-vote-envelope)
+- [Checking a Vote Envelope](https://docs.vocdoni.io/#/architecture/sequence-diagrams.html#checking-a-vote-envelope)
### Get Block Status
@@ -499,7 +503,7 @@ The following query filters can be used:
Get the results of the given processId, as indexed by the scrutinizer. If the process doesn't have encrypted votes but it has already started, then the gateway returns the **partial results**. The results can only be considered final if `final` is true.
-The results of an election are represented in [the following format](/architecture/smart-contracts/process?id=results).
+The results of an election are represented in [the following format](/architecture/smart-contracts/process.html#results).
```json
{
@@ -645,7 +649,7 @@ Returns the number of entities registered on the [Vochain](/architecture/service
### Get Envelope
-Get the content of an existing [Vote Envelope](/architecture/smart-contracts/process?id=vote-envelope). The envelope is identified by the nullifier. `height` and `txIndex` refer to the block height and the index on that block, respectively, of the transaction containing this vote envelope. These fields can be used with [Get Tx](/architecture/services/gateway?id=get-tx) to fetch this transaction.
+Get the content of an existing [Vote Envelope](/architecture/smart-contracts/process.html#vote-envelope). The envelope is identified by the nullifier. `height` and `txIndex` refer to the block height and the index on that block, respectively, of the transaction containing this vote envelope. These fields can be used with [Get Tx](/architecture/services/gateway.html#get-tx) to fetch this transaction.
```json
{
@@ -722,6 +726,7 @@ Get general information & statistics about the current [Vochain](/architecture/s
"genesis_time_stamp": "2021-04-30T11:43:28.668436552Z",
"process_count": 19,
"syncing": false,
+ "transaction_count": 861,
"validator_count": 4
},
"timestamp": 1620059835
@@ -789,7 +794,7 @@ The `fromId` field works the same as in [Get Process List](#get-process-list).
### Get Block
-Get the metadata for a single block on the [Vochain](/architecture/services/vochain) by its height. `num_txs` contains the number of transactions contained in this block. In order to access these transactions (the contents of the block), use [Get Tx List for Block](/architecture/services/gateway?id=get-tx-list-for-block).
+Get the metadata for a single block on the [Vochain](/architecture/services/vochain) by its height. `num_txs` contains the number of transactions contained in this block. In order to access these transactions (the contents of the block), use [Get Tx List for Block](/architecture/services/gateway.html#get-tx-list-for-block).
```json
{
@@ -823,7 +828,7 @@ Get the metadata for a single block on the [Vochain](/architecture/services/voch
### Get Block By Hash
-Get the metadata for a single block on the [Vochain](/architecture/services/vochain) by its hash. `num_txs` contains the number of transactions contained in this block. In order to access these transactions (the contents of the block), use [Get Tx List for Block](/architecture/services/gateway?id=get-tx-list-for-block).
+Get the metadata for a single block on the [Vochain](/architecture/services/vochain) by its hash. `num_txs` contains the number of transactions contained in this block. In order to access these transactions (the contents of the block), use [Get Tx List for Block](/architecture/services/gateway.html#get-tx-list-for-block).
```json
{
@@ -927,10 +932,9 @@ Get a single tx from the [Vochain](/architecture/services/vochain). `height` is
"request": "632",
"timestamp": 1620068626,
"tx": {
- "Hash": "hexString",
- "Index": 2,
- "Signature": "hexString",
- "Tx": "base64String",
+ "hash": "hexString",
+ "signature": "hexString",
+ "tx": "base64String",
}
},
"id": "632",
@@ -938,6 +942,41 @@ Get a single tx from the [Vochain](/architecture/services/vochain). `height` is
}
```
+### Get Tx By Height
+
+Get a single tx from the [Vochain](/architecture/services/vochain). `height` is that transaction's height on the vochain as a whole, and each height value references a unique transaction. Transaction height corresponds to the order in which that transaction was mined.
+
+```json
+{
+ "request": {
+ "height": 851,
+ "method": "getTxByHeight",
+ "timestamp": 1625063686
+ },
+ "id": "137",
+ "signature": "hexString"
+}
+```
+
+```json
+{
+ "response": {
+ "ok": true,
+ "request": "137",
+ "timestamp": 1625063686,
+ "tx": {
+ "block_height": 354792,
+ "hash": "hexString",
+ "height": 851,
+ "signature": "hexString",
+ "tx": "base64String"
+ }
+ },
+ "id": "137",
+ "signature": "hexString"
+}
+```
+
### Get Validator List
Get the list of all addresses currently validating blocks on the [Vochain](/architecture/services/vochain).
@@ -1059,7 +1098,7 @@ you should see a response:
}
```
-now we know that the gateway hosted at gw1.vocdoni.net enables the file, [vote](/architecture/services/gateway?id=vote-api), [results](/architecture/services/gateway?id=results-api), and [indexer](/architecture/services/gateway?id=indexer-api) apis.
+now we know that the gateway hosted at gw1.vocdoni.net enables the file, [vote](/architecture/services/gateway.html#vote-api), [results](/architecture/services/gateway.html#results-api), and [indexer](/architecture/services/gateway.html#indexer-api) apis.
Let's do some simple requests to learn more about the state of the Vochain.
diff --git a/docs/architecture/services/vochain.md b/src/architecture/services/vochain.md
similarity index 89%
rename from docs/architecture/services/vochain.md
rename to src/architecture/services/vochain.md
index cef06d5d..cf7f3df1 100644
--- a/docs/architecture/services/vochain.md
+++ b/src/architecture/services/vochain.md
@@ -1,8 +1,8 @@
# Vochain
-Vochain is a *Proof-of-Authorithy* blockchain network that uses [Tendermint](https://tendermint.com/) as its consensus algorithm. The main purpose of Vochain is to register polls, votes, and backing processes in a decentralized and verifiable way.
+Vochain is a *Proof-of-Authority* blockchain network that uses [Tendermint](https://tendermint.com/) as its consensus algorithm. The main purpose of Vochain is to register polls, votes, and backing processes in a decentralized and verifiable way.
-You can think of Vochain as a specifig purpose blockchain for voting. Vochain needs no cryptocurrency, gas or smart contract interactions; it just has the core logic represented as a state machine that any participation process needs to follow.
+You can think of Vochain as a specific purpose blockchain for voting. Vochain needs no cryptocurrency, gas or smart contract interactions; it just has the core logic represented as a state machine that any participation process needs to follow.
## Overall
@@ -144,7 +144,7 @@ However all nodes of the network (miners or not) will execute the same transacti
Currently as Vochain is proof-of-authority, only a set of nodes will be able to propose and include new blocks on the blockchain. These nodes (identified by a public key) are listed in the genesis file (the initial set) and later the list can be modified by executing the required transactions for doing so.
-In the future, miners would get reward for validating new blocks and they would also be required to keep an economic stake on Ethereum in order to demonstrate its commitment for good behaviour.
+In the future, miners would get reward for validating new blocks and they would also be required to keep an economic stake on Ethereum in order to demonstrate its commitment for good behavior.
### Oracle
@@ -178,13 +178,11 @@ See the [Scrutinizer](/architecture/services/vochain/scrutinizer) section.
## Transaction lifecycle
-In the following diagram the vote transaction lifecycle is shown. ChecTX, DeliverTX and Commit are the main steps of the Vochain. The first decides if a new transaction should be included in the mempool (and broadcasted to other peers), the second decides if a transaction that is going to be included in the next block is valid and the last makes the changes permanent and updates the state.
+In the following diagram the vote transaction lifecycle is shown. CheckTX, DeliverTX and Commit are the main steps of the Vochain. The first decides if a new transaction should be included in the mempool (and broadcasted to other peers), the second decides if a transaction that is going to be included in the next block is valid and the last makes the changes permanent and updates the state.
-
+
-### Coming next
-See the [Scrutinizer](/architecture/services/vochain/scrutinizer) section.
diff --git a/src/architecture/services/vochain/indexer.md b/src/architecture/services/vochain/indexer.md
new file mode 100644
index 00000000..6b8ea3af
--- /dev/null
+++ b/src/architecture/services/vochain/indexer.md
@@ -0,0 +1,147 @@
+# Indexer
+
+## Overall
+
+The indexer is the component that tallies and decode/decrypt (if needed) each vote stored in the voting blockchain for each process of each entity.
+
+The way the indexer works is defined by the process vote type and the process mode eligible configurations.
+
+The **internal indexer database** is used for storing the results, processes, references to votes and transactions, and information about the number of items in the Vochain state. Storing data linked to the Vochain state changes adds safety and data correctness in front of numerous failures and provides much more powerful access to querying the Vochain.
+
+## Core components
+
+The indexer needs to be attached to a full **Vochain node** in order to access the latest state accurately. The state is for retrieving votes, processes, transactions, and other useful info for computing the results for each process.
+
+It also maintains six pools and an internal database for data persistence:
+
+### Vote pool
+
+ Used for computing processes with real-time results. Votes are added to the results storage for the given process ID.
+
+ Each pool item contains a single vote with the following fields:
+
+ - Height
+ - Nullifier
+ - Process ID
+ - Vote package
+ - Encryption key indexes
+ - Weight
+
+### Vote Index pool
+
+ Used for storing all votes along with their transaction indexes, including those without live results. A reference to the vote's transaction is stored in the indexer database/
+
+ Each pool item contains a single vote & index with the following fields:
+
+ - Vote
+ - Height
+ - Nullifier
+ - Process ID
+ - Vote package
+ - Encryption key indexes
+ - Weight
+ - TxIndex
+
+
+### New Process pool
+
+ Used for initially storing processes to the indexer database.
+
+ Each pool item contains a single process with the following fields:
+
+ - Process Id
+ - Entity Id (Organization identifier)
+
+### Update Process pool
+
+ Used for signifying which processes may need to be updated in the indexer database. Each process in the pool is updated according to the current Vochain state, and final results are computed if applicable.
+
+ Live processes results are computed in parallel every new Vochain block and the results of encrypted or non live processes are scheduled for the tally when the end block of a process is reached or when the keys of a processes are published.
+
+ Each pool item contains a byte array representing the identifier for a process which needs to be updated.
+
+### New Tx pool
+
+ Used for storing a reference to each new transaction on the Vochain and updating the total count of transactions. Transaction references can then be used to easily access transactions directly from the Vochain state.
+
+ Each pool item contains a single transaction reference with the following fields:
+
+ - Index *(the transaction's height on the Vochain)*
+ - BlockIndex *(The index of the block containing the transaction)*
+ - TxBlockIndex *(The transaction's index on the block containing it)*
+
+### Results pool
+
+ The results pool is used to signal which processes need to have results computed and finalized when either:
+
+ - The end block is reached
+ - The encryption keys are revealed
+ - The results need to be computed in real time
+
+ Each pool item contains a single process with the following fields:
+
+ - Process Id
+ - Entity Id (Organization identifier)
+
+
+
+
+
+
+
+## How it works
+
+The indexer is very tied to the Vochain, this is because its functionality relies on state changes on the Vochain application state.
+
+There are some functions that change the Vochain state that are associated to one or more **callback functions** and can be used for other processes in order to do some side logic. One of the components using this feature is the indexer.
+
+### Commit
+
+When the `Commit` function is called on the Vochain, a signal is triggered in order to inform the indexer that the latest changes are finalized and persistent.
+
+In the commit stage all the pools are iterated in order compute the results of each process that is meant to be tallied. As said, there are different situations in which the indexer must compute the results of a process:
+
+- The process keys are revealed.
+- The process end block is reached.
+- The process is real time (in this case, the votes on the vote pool are fetched in order to be computed live at the given Vochain height).
+
+### Rollback
+
+If the `Rollback` function is called on the Vochain, the current non persisted changes will be discarded.
+
+### OnProcess
+
+When a new process is created, it is added to the New Process pool to be stored on the indexer database.
+
+### OnVote
+
+When a new vote is registered, it is added to the Vote Index pool so the vote transaction can be referenced from the indexer. If the vote belongs to a process with live results, it is also added to the Vote pool so that the results stored by the indexer can count the new vote.
+
+### OnCancel
+
+When a process is cancelled, its ID is added to the Update Process pool.
+
+### OnProcessKeys
+
+When a process' keys are added, its ID is added to the Update Process pool.
+
+### OnProcessStatusChange
+
+When a process' status is changed, its ID is added to the Update Process pool. If the process changes to the `ended` status and its votes are not encrypted, it is also added to the Results pool to compute final results.
+
+### OnRevealKeys
+
+When a process' keys are revealed, its ID is added to the Update Process pool. It is also added to the Results pool to decrypt the votes and compute final results.
+
+### OnProcessResults
+
+When the Vochain signals that a process' results are available, the results are checked for validity and then the process ID is added to the Update Process pool.
+
+
+
+
+
+
+
+
+
diff --git a/docs/architecture/smart-contracts/entity-resolver.md b/src/architecture/smart-contracts/entity-resolver.md
similarity index 78%
rename from docs/architecture/smart-contracts/entity-resolver.md
rename to src/architecture/smart-contracts/entity-resolver.md
index 7c5c20d8..fb2515ac 100644
--- a/docs/architecture/smart-contracts/entity-resolver.md
+++ b/src/architecture/smart-contracts/entity-resolver.md
@@ -4,15 +4,9 @@ Voters may want to access an index of the available elections. The best way to o
In Vocdoni, entities publish [human readable metadata](/architecture/data-schemes/entity-metadata), but such metadata needs to be securely indexed on a Smart Contract.
-The ENS Resolver Smart Contract allows entities to register and set the [Content URI](/architecture/protocol/data-origins?id=content-uri) that points to the actual [JSON metadata](/architecture/data-schemes/entity-metadata).
+The ENS Resolver Smart Contract allows entities to register and set the [Content URI](/architecture/protocol/data-origins.html#content-uri) that points to the actual [JSON metadata](/architecture/data-schemes/entity-metadata).
-## Index
-
-- [Text Record storage](#text-record-storage)
-- [Text List Record storage](#text-list-record-storage)
-- [Resolver keys](#resolver-keys)
-
----
+--
## Entity Resolver
@@ -26,21 +20,21 @@ The `entityId` is the unique identifier of each entity, being a hash of its Ethe
bytes32 entityId = keccak256 (entityAddress);
```
-### Text Record storage
+## Text Record storage
We make use of [EIP 634: Storage of Text records in ENS](https://eips.ethereum.org/EIPS/eip-634). It is a convenient way to store arbitrary data as a string following a key-value store model.
[Implementation](https://github.com/vocdoni/dvote-solidity/blob/master/contracts/profiles/TextResolver.sol)
-### Supported Text Record keys
+## Supported Text Record keys
Entities may define the following Text Records:
| Key | Example | Description |
| ----------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
-| `vnd.vocdoni.meta` | 'ipfs://12345,https://server/json' | [Content URI](/architecture/protocol/data-origins?id=content-uri) to fetch the Entity's JSON metadata. See [JSON schema](#meta). |
-| `vnd.vocdoni.boot-nodes` | 'ipfs://12345,https://server/gw.json' | [Content URI](/architecture/protocol/data-origins?id=content-uri) to fetch a set of Gateways for the Entity. See [Gateway Boot Nodes](#gateway-boot-nodes) below. |
-| `vnd.vocdoni.gateway-heartbeat` | 'wss://host/path' | [Messaging URI](/architecture/protocol/data-origins?id=messaging-uri) where the Gateways of the entity should report their health status. |
+| `vnd.vocdoni.meta` | 'ipfs://12345,https://server/json' | [Content URI](/architecture/protocol/data-origins.html#content-uri) to fetch the Entity's JSON metadata. See [JSON schema](#meta). |
+| `vnd.vocdoni.boot-nodes` | 'ipfs://12345,https://server/gw.json' | [Content URI](/architecture/protocol/data-origins.html#content-uri) to fetch a set of Gateways for the Entity. See [Gateway Boot Nodes](#gateway-boot-nodes) below. |
+| `vnd.vocdoni.gateway-heartbeat` | 'wss://host/path' | [Messaging URI](/architecture/protocol/data-origins.html#messaging-uri) where the Gateways of the entity should report their health status. |
- Required
- `vnd.vocdoni.meta`
@@ -50,7 +44,7 @@ Entities may define the following Text Records:
#### JSON Metadata
-See [Entity Metadata](/architecture/data-schemes/entity-metadata?id=json-schema).
+See [Entity Metadata](/architecture/data-schemes/entity-metadata.html#json-schema).
#### Gateway boot nodes
@@ -58,6 +52,4 @@ Client apps may not be able to join P2P networks by themselves, so Vocdoni makes
By default, Vocdoni (as an Entity) provides its own set of Voting and Web3 Gateways. However, entities may want to use their own infrastructure. To this end, the Entity's ENS Text Record `vnd.vocdoni.boot-nodes` can be set to the Content URI of a [BootNodes JSON file](/architecture/services/bootnode) defining some of them.
-### Coming next
-See the [Process Contract](/architecture/smart-contracts/process) section.
diff --git a/docs/architecture/smart-contracts/genesis.md b/src/architecture/smart-contracts/genesis.md
similarity index 93%
rename from docs/architecture/smart-contracts/genesis.md
rename to src/architecture/smart-contracts/genesis.md
index 93d13b0a..ccce5183 100644
--- a/docs/architecture/smart-contracts/genesis.md
+++ b/src/architecture/smart-contracts/genesis.md
@@ -26,6 +26,4 @@ Chains are indexed by the `chainId`, which is unique.
Note: The `oracles` field may progressively be deprecated as the platform evolves toward a trustless oracles model. When oracles become trustless, any participant from the network could signal events on-chain, relay signed transactions or publish results following an optimistic rollup approach.
-### Coming next
-See the [Namespace Contract](/architecture/smart-contracts/namespace) section.
diff --git a/docs/architecture/smart-contracts/namespace.md b/src/architecture/smart-contracts/namespace.md
similarity index 90%
rename from docs/architecture/smart-contracts/namespace.md
rename to src/architecture/smart-contracts/namespace.md
index 405ca51f..8f30400d 100644
--- a/docs/architecture/smart-contracts/namespace.md
+++ b/src/architecture/smart-contracts/namespace.md
@@ -19,6 +19,4 @@ uint32 public namespaceCount;
- `register()` is called by process contracts upon deployment. They receive a unique `namespaceId` and are registered as the contract assigned to this index.
-### Coming next
-See the [Results Contract](/architecture/smart-contracts/results) section.
diff --git a/docs/architecture/smart-contracts/process.md b/src/architecture/smart-contracts/process.md
similarity index 93%
rename from docs/architecture/smart-contracts/process.md
rename to src/architecture/smart-contracts/process.md
index 3ce2386f..5da21858 100644
--- a/docs/architecture/smart-contracts/process.md
+++ b/src/architecture/smart-contracts/process.md
@@ -1,8 +1,8 @@
# Process Contract
-A process is the building block around which governance is made in Vocdoni. Simmilarly to an Operating System, think of the Processes contract like a Kernel that receives syscall's to spawn a new governance process.
+A process is the building block around which governance is made in Vocdoni. Similarly to an Operating System, think of the Processes contract like a Kernel that receives syscalls to spawn a new governance process.
-Governance processes span across three diferent components: the Ethereum smart contract, IPFS to ditribute [the vote metadata](/architecture/data-schemes/process?id=process-metadata) and the [Vochain](/architecture/services/vochain).
+Governance processes span across three different components: the Ethereum smart contract, IPFS to ditribute [the vote metadata](/architecture/data-schemes/process.html#process-metadata) and the [Vochain](/architecture/services/vochain).
Processes follow a declarative fashion. The expected behavior is declared on the smart contract for integrity and the the Layer 2 blockchain (called [Vochain](/architecture/services/vochain)) reacts according to the current settings.
@@ -23,8 +23,8 @@ The instance of the Voting process contract is resolved from `processes.vocdoni.
// GLOBAL STRUCTS
struct Process {
- uint8 mode; // The selected process mode. See: https://vocdoni.io/docs/#/architecture/smart-contracts/process?id=flags
- uint8 envelopeType; // One of valid envelope types, see: https://vocdoni.io/docs/#/architecture/smart-contracts/process?id=flags
+ uint8 mode; // The selected process mode. See: https://vocdoni.io/docs/#/architecture/smart-contracts/process.html#flags
+ uint8 envelopeType; // One of valid envelope types, see: https://vocdoni.io/docs/#/architecture/smart-contracts/process.html#flags
CensusOrigin censusOrigin; // How the census proofs are computed (Off-chain vs EVM Merkle Tree)
address entity; // The address of the Entity (or contract) holding the process
@@ -67,7 +67,7 @@ struct Process {
uint256 evmBlockHeight; // EVM block number to use as a snapshot for the on-chain census
- bytes32 paramsSignature; // entity.sign({...}) // fields that the oracle uses to authentify process creation
+ bytes32 paramsSignature; // entity.sign({...}) // fields that the oracle uses to authenticate process creation
}
```
@@ -128,9 +128,9 @@ For more details, you can see the [implementation here](https://github.com/vocdo
When a process is created, the entity needs to define what options apply to it. The combination of them produces:
- The process `mode`
- - It determines the external behaviour of the process, when it starts, what can be updated, etc.
+ - It determines the external behavior of the process, when it starts, what can be updated, etc.
- The `envelopeType`
- - Determines the internal behaviour of the votes sent by participants.
+ - Determines the internal behavior of the votes sent by participants.
- The `censusOrigin`
- Determines the way to compute and validate the voter's census proofs
@@ -282,6 +282,4 @@ However:
- Updates on legacy processes need to be sent directly to the original contract instance
- Use `getCreationInstance(processId)` to retrieve the appropriate address
-### Coming next
-See the [Genesis Contract](/architecture/smart-contracts/genesis.md) section.
diff --git a/docs/architecture/smart-contracts/results.md b/src/architecture/smart-contracts/results.md
similarity index 90%
rename from docs/architecture/smart-contracts/results.md
rename to src/architecture/smart-contracts/results.md
index 1b24ea60..959e5d80 100644
--- a/docs/architecture/smart-contracts/results.md
+++ b/src/architecture/smart-contracts/results.md
@@ -22,6 +22,4 @@ mapping(bytes32 => ProcessResults) internal results; // Mapping of all processes
- `setResults` Used by Oracles to register the tally of a process. It will also try to update the `status` of the process on the Processes contract defined in `processesAddress`.
- `setProcessesAddress` Allows the creator to define which Processes contract should be notified about results being available.
-### Coming next
-See the [Storage Proofs contracts](/architecture/smart-contracts/storage-proofs) section.
diff --git a/docs/architecture/smart-contracts/storage-proofs.md b/src/architecture/smart-contracts/storage-proofs.md
similarity index 94%
rename from docs/architecture/smart-contracts/storage-proofs.md
rename to src/architecture/smart-contracts/storage-proofs.md
index 55d24d03..7e1590a6 100644
--- a/docs/architecture/smart-contracts/storage-proofs.md
+++ b/src/architecture/smart-contracts/storage-proofs.md
@@ -32,6 +32,4 @@ uint32 public tokenCount = 0;
- `getBalanceMappingPosition` Retrieves the offset where the balance mapping is located. Used to generate the storage proofs from the client side.
-### Coming next
-See the [Gateway](/architecture/services/gateway) section.
diff --git a/docs/architecture/user-stories.md b/src/architecture/user-stories.md
similarity index 81%
rename from docs/architecture/user-stories.md
rename to src/architecture/user-stories.md
index 030a4fde..6ee8f9f1 100644
--- a/docs/architecture/user-stories.md
+++ b/src/architecture/user-stories.md
@@ -23,7 +23,7 @@ To see how a decentralized election works, let's see the sequence of actions tha
- For every Entity's action on the metadata, it fetches their visibility status
-
+
@@ -48,8 +48,8 @@ To see how a decentralized election works, let's see the sequence of actions tha
- Pin the Merkle Tree on IPFS or similar
- Push the eligible public keys to the [Census Service](/architecture/services/census-service)
- Pin the [Process Metadata](/architecture/data-schemes/process) on IPFS
- - Send a transaction to the process smart contract, including [Content URI](/architecture/protocol/data-origins?id=content-uri)'s pointing to the [Process Metadata](/architecture/data-schemes/process) and the [Census Merkle Tree](/architecture/census-overview), along with the rest of parameters
- - Update the list of voting processes on the [ENS Resolver](/architecture/smart-contracts/entity-resolver?id=entity-resolver) contract for the entity
+ - Send a transaction to the process smart contract, including [Content URI](/architecture/protocol/data-origins.html#content-uri)'s pointing to the [Process Metadata](/architecture/data-schemes/process) and the [Census Merkle Tree](/architecture/census-overview), along with the rest of parameters
+ - Update the list of voting processes on the [ENS Resolver](/architecture/smart-contracts/entity-resolver.html#entity-resolver) contract for the entity
- The **app user** fetches the active processes of an **Entity**
- Read the description and review the options to vote
- The **app user** checks that the identity is part of the process' census
@@ -57,31 +57,31 @@ To see how a decentralized election works, let's see the sequence of actions tha
- The app requests a proof to the **[Census Service](/architecture/services/census-service)**
- The **[Census service](/architecture/services/census-service)** replies with the census Merkle proof if the public key belongs to it
- The app computes the user's nullifier for the vote
- - The app generates the [Vote Package](/architecture/smart-contracts/process?id=vote-package-zk-snarks) with the election choices
+ - The app generates the [Vote Package](/architecture/smart-contracts/process.html#vote-package-zk-snarks) with the election choices
- On encrypted processes:
- The app fetches the encryption public keys to the **Gateway**
- - The app encrypts the [Vote Package](/architecture/smart-contracts/process?id=vote-package-zk-snarks) with the public keys of the voting process
+ - The app encrypts the [Vote Package](/architecture/smart-contracts/process.html#vote-package-zk-snarks) with the public keys of the voting process
- On anonymous processes:
- The app fetches the proving and verification keys and then generates the **Zero-Knowledge Proof**
- The ZK Proof proves that:
- The voter knows a private key, whose public key belongs to the census
- The provided nullifier matches the current process ID and the user's private key
- - The app generates the [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope-zk-snarks)
- - The app selects a **Gateway** among the available ones and submits the [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope-zk-snarks)
- - The **Gateway** submits the [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope-zk-snarks) to the mempool of the Vochain
-- A **Vochain miner** processes an incoming [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope)
+ - The app generates the [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope-zk-snarks)
+ - The app selects a **Gateway** among the available ones and submits the [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope-zk-snarks)
+ - The **Gateway** submits the [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope-zk-snarks) to the mempool of the Vochain
+- A **Vochain miner** processes an incoming [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope)
- The **Vochain miner** checks that the current block is within the process start/end blocks
- The **Vochain miner** checks that the given nullifier has not been used before
- If the process is anonymous:
- - The **Vochain miner** checks that the **ZK Proof** of the [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope) is valid
+ - The **Vochain miner** checks that the **ZK Proof** of the [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope) is valid
- If the process is not anonymous
- - The **Vochain miner** checks that the **Merkle Proof** of the [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope) matches the vote signature and the Merkle root
- - The **Vochain miner** adds the [Vote Envelope](/architecture/data-schemes/process?id=vote-envelope) to the next block
+ - The **Vochain miner** checks that the **Merkle Proof** of the [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope) matches the vote signature and the Merkle root
+ - The **Vochain miner** adds the [Vote Envelope](/architecture/data-schemes/process.html#vote-envelope) to the next block
### After voting
-- The **app User** checks that his/her vots is registered
+- The **app User** checks that their vote is registered
- The app asks a **Gateway** for the envelope status of his/her nullifier
- The **organizer** ends the process
- The **organizer** sends a transaction to the process contract and sets the state of the process as ended
@@ -97,10 +97,10 @@ To see how a decentralized election works, let's see the sequence of actions tha
- An **observer** computes the results
- The **observer** fetches the [Process Metadata](/architecture/data-schemes/process) from the process contract and IPFS
- On encrypted votes, the **observer** requests the encryption private keys to the **Gateway**
- - The **observer** fetches all the [Vote Envelopes](/architecture/data-schemes/process?id=vote-envelope) registered for the process
- - The **observer** checks their ZK Proofs or Merkle Proofs, the [Vote Package](/architecture/smart-contracts/process?id=vote-package-zk-snarks) contents and the restrictions imposed by the process flags
- - On encrypted votes, the **observer** decrypts the [Vote Package](/architecture/smart-contracts/process?id=vote-package-zk-snarks)
- - The **observer** counts the number of appearences of every single vote value
+ - The **observer** fetches all the [Vote Envelopes](/architecture/data-schemes/process.html#vote-envelope) registered for the process
+ - The **observer** checks their ZK Proofs or Merkle Proofs, the [Vote Package](/architecture/smart-contracts/process.html#vote-package-zk-snarks) contents and the restrictions imposed by the process flags
+ - On encrypted votes, the **observer** decrypts the [Vote Package](/architecture/smart-contracts/process.html#vote-package-zk-snarks)
+ - The **observer** counts the number of appearances of every single vote value
- Any vote value beyond the ones defined in the [Process Metadata](/architecture/data-schemes/process) is discarded
- An **observer** publishes the vote results
@@ -117,6 +117,4 @@ To see how a decentralized election works, let's see the sequence of actions tha
- After a period of time, nobody else submits result transactions with higher vote counts
- Results become final
-### Coming next
-See the [Entity Resolver Contract](/architecture/smart-contracts/entity-resolver) section.
diff --git a/docs/deployment/custom-vochain.md b/src/deployment/custom-vochain.md
similarity index 98%
rename from docs/deployment/custom-vochain.md
rename to src/deployment/custom-vochain.md
index 85d2785c..96d6de71 100644
--- a/docs/deployment/custom-vochain.md
+++ b/src/deployment/custom-vochain.md
@@ -1,6 +1,6 @@
# Custom Vochain Deployment
-In this document we will guide through the steps of deploying a full Vochain (Vocdoni's blockchain) stack using a custom arquitecture. It is meant to give the reader a general idea on how Vocdoni components work, and it is not meant to be production ready chain.
+In this document we will guide through the steps of deploying a full Vochain (Vocdoni's blockchain) stack using a custom architecture. It is meant to give the reader a general idea on how Vocdoni components work, and it is not meant to be production ready chain.
The Vocdoni's mainnet chain genesis is 'hardcoded' into the project's code itself, but it is also possible to generate any other tendermint based chain at will for testing, forking or any other purposes.
diff --git a/docs/deployment/gateway.md b/src/deployment/gateway.md
similarity index 100%
rename from docs/deployment/gateway.md
rename to src/deployment/gateway.md
diff --git a/docs/deployment/miner.md b/src/deployment/miner.md
similarity index 95%
rename from docs/deployment/miner.md
rename to src/deployment/miner.md
index 834851cd..8418749e 100644
--- a/docs/deployment/miner.md
+++ b/src/deployment/miner.md
@@ -2,7 +2,7 @@
This section shows how to deploy a node with the miner role running on Vocdoni network, to propose and include blocks in the Vochain.
-To get more information about the miner role, read the [docs](https://docs.vocdoni.io/#/architecture/services/vochain?id=miner).
+To get more information about the miner role, read the [docs](https://docs.vocdoni.io/#/architecture/services/vochain.html#miner).
## Requirements
@@ -80,7 +80,7 @@ After this step, we are ready to deploy the miner node with:
docker-compose -f docker-compose.watchtower.yml -f docker-compose.yml up -d
```
-After this step, the miner node will start to syncronize and propose blocks.
+After this step, the miner node will start to synchronize and propose blocks.
## Obtain miner's public key
diff --git a/docs/deployment/oracle.md b/src/deployment/oracle.md
similarity index 97%
rename from docs/deployment/oracle.md
rename to src/deployment/oracle.md
index 09465b96..d741a85d 100644
--- a/docs/deployment/oracle.md
+++ b/src/deployment/oracle.md
@@ -88,7 +88,7 @@ After this step, we are ready to deploy the oracle node with:
docker-compose -f docker-compose.watchtower.yml -f docker-compose.web3.yml -f docker-compose.yml up -d
```
-After this step, the oracle node will start and the Ethereum node will start to syncronize. It can take many hours to complete the process.
+After this step, the oracle node will start and the Ethereum node will start to synchronize. It can take many hours to complete the process.
## Obtain oracle's public key
diff --git a/src/index.md b/src/index.md
new file mode 100755
index 00000000..adc31a11
--- /dev/null
+++ b/src/index.md
@@ -0,0 +1,20 @@
+---
+home: true
+heroImage: /Logotype.svg
+heroText:
+tagline: A decentralized self sovereign governance platform
+actionText: Get started →
+actionLink: /architecture/general
+lang: en-US
+meta:
+ - name: keywords
+ content: voting, open source, governance, vocdoni, aragon, digital
+features:
+- title: L2 voting Blockchain
+ details: Purpose specific voting blockchain built on top of Tendermint
+- title: End to end verifiable
+ details: Network participants can check the integrity of the whole election
+- title: Censorship resistant
+ details: Designed to be resilient to network outages and vote manupulation
+footer: Made by Vocdoni with ❤️
+---
diff --git a/docs/integration/overview.md b/src/integration/overview.md
similarity index 100%
rename from docs/integration/overview.md
rename to src/integration/overview.md
diff --git a/docs/integration/registry-token-api.md b/src/integration/registry-token-api.md
similarity index 99%
rename from docs/integration/registry-token-api.md
rename to src/integration/registry-token-api.md
index 75eb091e..9e5f3679 100644
--- a/docs/integration/registry-token-api.md
+++ b/src/integration/registry-token-api.md
@@ -35,7 +35,7 @@ secret = "hello"
### Methods
-##### Token revokation
+##### Token revocation
```json
// Request
diff --git a/docs/integration/voting-as-a-service.md b/src/integration/voting-as-a-service.md
similarity index 98%
rename from docs/integration/voting-as-a-service.md
rename to src/integration/voting-as-a-service.md
index e7644676..6fa294e5 100644
--- a/docs/integration/voting-as-a-service.md
+++ b/src/integration/voting-as-a-service.md
@@ -1,6 +1,6 @@
# Voting as a Service
-The following section is an excerp of the article published on the [Vocdoni Blog](https://blog.vocdoni.io/), called [Introducing Voting as a Service](https://blog.vocdoni.io/introducing-voting-as-a-service/).
+The following section is an excerpt of the article published on the [Vocdoni Blog](https://blog.vocdoni.io/), called [Introducing Voting as a Service](https://blog.vocdoni.io/introducing-voting-as-a-service/).
---
@@ -31,7 +31,7 @@ Using their private key and a [decentralized Gateway](https://docs.vocdoni.io/#/
Votes are relayed to the custom voting blockchain, validated and included in the next block.
-As the process goes on, anyone with network access can listen for vote transactions, verify them by themselves or even use the [block explorer](https://explorer.vocdoni.net) to do it manually.
+As the process goes on, anyone with network access can listen for vote transactions, verify them by themselves or even use the [block explorer](https://explorer.vote) to do it manually.
### After the process
When the vote is over, the oracle will trigger a process end transaction. At this point, the process will stop accepting valid votes and Gateways will be able to compute the scrutiny of the process. Even your own gateways can.
diff --git a/docs/manager/manager-api.md b/src/manager/manager-api.md
similarity index 98%
rename from docs/manager/manager-api.md
rename to src/manager/manager-api.md
index 6bc891a1..c5846465 100644
--- a/docs/manager/manager-api.md
+++ b/src/manager/manager-api.md
@@ -4,7 +4,7 @@ The Manager API allows organizations to perform all the necessary management ac
- Managing `Members` and their information. Related to `Member` management, some `Token` calls are also featured
- Creating and managing `Tags` for these members
- Creating and managing `Targets` that combine member attributes and tags in order to provide the ability to segment the members
-- Creating and managing `Censuses` based that eacho of them is related with one concrete `Target`
+- Creating and managing `Censuses` based that each of them is related with one concrete `Target`
Available by default under `/manager`
@@ -258,7 +258,7 @@ Retrieve a list of members with the given constraints.
### updateMember
-**Note**: All attributes execpet`tags` if are included in the request but are empty they are ingored. If `tags == []` this value is stored in the database.
+**Note**: All attributes execpet`tags` if are included in the request but are empty they are ignored. If `tags == []` this value is stored in the database.
- Request
@@ -349,7 +349,7 @@ Imports the given array of members with their info into the database.
```
### sendValidationLink
-Uses the `SMTP` module to send an email to the selected member, containing the necesary info to register his public key. See also `validateToken`
+Uses the `SMTP` module to send an email to the selected member, containing the necessary info to register his public key. See also `validateToken`
- Request
```json
@@ -913,6 +913,4 @@ Remove Tag from Members
}
```
-### Coming next
-See the [Registry API](/manager/registry-api) section.
diff --git a/docs/manager/overview.md b/src/manager/overview.md
similarity index 94%
rename from docs/manager/overview.md
rename to src/manager/overview.md
index bf206d0d..8e6a80a5 100644
--- a/docs/manager/overview.md
+++ b/src/manager/overview.md
@@ -21,6 +21,4 @@ The manager is made of three components:
- Push Notification service
- [Push Notifications API](/manager/push-notifications-api.md)
-### Coming next
-See the [Manager API](/manager/manager-api.md) section.
diff --git a/docs/manager/push-notifications-api.md b/src/manager/push-notifications-api.md
similarity index 93%
rename from docs/manager/push-notifications-api.md
rename to src/manager/push-notifications-api.md
index 7754ee0f..7bde747b 100644
--- a/docs/manager/push-notifications-api.md
+++ b/src/manager/push-notifications-api.md
@@ -2,7 +2,7 @@
The push notifications service allows organizations to send pop up messages to their users devices. Organizations can send notifications at any time and their users do not have to be in the app or using their devices to receive them.
-Currenty the push notifications system used is the Google Firebase Cloud Messassing but any other provider can be easily integrated.
+Currently the push notifications system used is the Google Firebase Cloud Messassing but any other provider can be easily integrated.
Each user can be subscribed to any organization she wants and be notified for one or more events.
@@ -10,14 +10,8 @@ Event subscription is managed with a topic approach, currently supporting the fo
- `_default_post-new`
- `_default_process-new`
-## Index
-1. Ethereum
-2. IPFS
-3. Notifications service
-4. API
-
-### 1. Ethereum
+## Ethereum
Given that the Vocdoni platform uses different smart contracts deployed into an EVM compatible chain as the source of truth, it is a requirement to have access to an Ethereum JSON-RPC compatible endpoint in order to interact with these contracts.
Interacting with this contracts means to read, write and listen for events.
@@ -30,20 +24,20 @@ Some examples:
Currently supported contract events: `NewProcess(bytes32 processId, uint16 namespace)`
-### 2. IPFS
+## IPFS
Another fundamental component of the notifications service is the IPFS node. Data is not stored in Ethereum but in IPFS, and given so, have access to an IPFS node is required in order to retrieve and store data in this distributed file system.
This data can be:
- Voting process metadata (type, mode, questions ...)
- Organization metadata (name, email, ID ...)
-- Prefered organization bootnodes and gateways to connect with
+- Preferred organization bootnodes and gateways to connect with
The actual URI of this data is stored on Ethereum and changes every time any of the data is changed. This is an IPFS property which is a content-addressed system.
Currently supported file changes: News feed modifications on organizations metadata
-### 3. Notifications service
+## Notifications service
The notifications service, in short, has two main different missions:
@@ -65,7 +59,7 @@ Is composed by the following components:
-#### How it works
+### How it works
- **Private database**
@@ -80,7 +74,7 @@ Is composed by the following components:
- Once the `Process` contract address is fetched a component called `ethEvents` starts to listen for logs on the contract.
- Each time a new process is created (the case currently supported) an Ethereum smart contract event is triggered and the `ethEvents` component
handles it.
- - The event will be processed and a notification anouncing the creation of a process will be created and sended to Firebase.
+ - The event will be processed and a notification announcing the creation of a process will be created and sended to Firebase.
- The users subscribed to the corresponding topic will receive the notification
@@ -103,9 +97,9 @@ Is composed by the following components:
This process runs forever and is repeated every scheduled time.
-### 4. API
+## API
-The notifications API is used to generate user tokens that can be useful for certain circunstances.
+The notifications API is used to generate user tokens that can be useful for certain circumstances.
Available by default under `/notifications`
@@ -200,6 +194,4 @@ go run cmd/dvotenotif/dvotenotif.go
-->
-### Coming next
-See the [Integration overview](/integration/overview) section.
diff --git a/docs/manager/registry-api.md b/src/manager/registry-api.md
similarity index 95%
rename from docs/manager/registry-api.md
rename to src/manager/registry-api.md
index b138dc94..58a0e23f 100644
--- a/docs/manager/registry-api.md
+++ b/src/manager/registry-api.md
@@ -113,6 +113,4 @@ The API methods below follow the [JSON API](/architecture/protocol/json-api) spe
}
```
-### Coming next
-See the [Push Notifications API](/manager/push-notifications-api) section.
diff --git a/todo.md b/todo.md
new file mode 100644
index 00000000..a2ec22f3
--- /dev/null
+++ b/todo.md
@@ -0,0 +1,4 @@
+# TODO:
+
+- Add Certificate Authority voting
+- Add zkSNARKs anonymous voting
-
-
-
-
-
-
-
@@ -106,7 +106,7 @@ Unlike ZK Snarks, **LRS do not rely on a trusted setup**.
**Academic papers**
- https://eprint.iacr.org/2018/379.pdf
-- https://dl.acm.org/citation.cfm?id=2103015
+- https://dl.acm.org/citation.cfm.html#2103015
**Libraries**
- Go implementation: https://github.com/noot/ring-go (linkable branch)
@@ -117,7 +117,7 @@ Unlike ZK Snarks, **LRS do not rely on a trusted setup**.
#### 1. Registration to an organization
-First, the Voters need to send their public keys to the Census organization service (each organization can choose which method to use for veryfing and identity). This is done just once so the same public key can be used for multiple elections.
+First, the Voters need to send their public keys to the Census organization service (each organization can choose which method to use for verifying an identity). This is done just once so the same public key can be used for multiple elections.
```mermaid
graph TD;
@@ -135,17 +135,17 @@ The usage of LRS requires the census to be published, so Voters can create their
+ If Census > 1000, census must be split on several groups of keys
+ the organizer will publish a number (N) which will be used by the voters to know to which group of keys are they assigned by using the following formula:
`GroupNumber = VoterPubKey % N`
- + before publishing N the census must pre-compute all the keys to check that if accomplish the minimum size grup of keys. So in case N generates a group with too few, that number must be discarted and try a new one
+ + before publishing N the census must pre-compute all the keys to check that if accomplish the minimum size group of keys. So in case N generates a group with too few, that number must be discarted and try a new one
#### 3. Derivate election keys
-In addition to `N`, the Organizer will publish a uniq ID that will identify the election (`processID`). This ID will be used by both parties (Voter and Organizer) to derivate the temporary election pulic keys using the following mechanism:
+In addition to `N`, the Organizer will publish a uniq ID that will identify the election (`processID`). This ID will be used by both parties (Voter and Organizer) to derivate the temporary election public keys using the following mechanism:
-+ On ECDSA the PubKey derivates from the PrivKey as follows:
++ On ECDSA the PubKey deviates from the PrivKey as follows:
`PubKeyVoter = PrivKeyVoter * G`
+ The Organizer derivate the new temporary PublicKey for each voter this way:
`PubKeyElectionVoter = PubKeyVoter + G*Hash(ElectionID)`
-+ Each voter derivates its new Private Key this way:
++ Each voter deviates their new Private Key this way:
`PrivKeyElectionVoter = PrivKeyVoter + Hash(ElectionID)`
@@ -165,7 +165,7 @@ C-.->Pub3["PubKey V3 + electionID"]
R[Linkable Ring Signature]
V1-.->Priv1["Privkey V1 + electionID"]
-Priv1-- >|create election signatre| R
+Priv1-- >|create election signature| R
subgraph
Pub1-.-R
@@ -393,11 +393,9 @@ true
Time and size scales linearly.
* 100 ring size signature needs 0.8s to be signed and have a size of 19kBytes
-* 1000 ring size signaure needs 7s to be signed and have a size of 193kBytes
-* 5000 ring size signaure needs 38s to be signed and have a size of 964kBytes
+* 1000 ring size signature needs 7s to be signed and have a size of 193kBytes
+* 5000 ring size signature needs 38s to be signed and have a size of 964kBytes
-->
-### Coming next
-See the [Data origins](/architecture/protocol/data-origins) section.
diff --git a/docs/architecture/protocol/json-api.md b/src/architecture/protocol/json-api.md
similarity index 94%
rename from docs/architecture/protocol/json-api.md
rename to src/architecture/protocol/json-api.md
index 76b0937e..e7f8982f 100644
--- a/docs/architecture/protocol/json-api.md
+++ b/src/architecture/protocol/json-api.md
@@ -107,7 +107,7 @@ Then:
`payload.signature` = `ECDSA.SIGN` ( `keccak256` ( `stringify` ( `payload.request` ) ) )
-The verificator will verify the signature, extract the ECDSA public key from the signature, convert it to Ethereum like address and finally compare it with the list of allowed addresses.
+The verifier will verify the signature, extract the ECDSA public key from the signature, convert it to Ethereum like address and finally compare it with the list of allowed addresses.
**Important**: To avoid signature mismatches, the stringified data of the `request` has to be computed always the JSON fields **sorted alphabetically**.
@@ -152,6 +152,4 @@ Where:
-### Coming next
-See the [Franchise proof](/architecture/protocol/franchise-proof) section.
diff --git a/docs/architecture/sequence-diagrams.md b/src/architecture/sequence-diagrams.md
similarity index 59%
rename from docs/architecture/sequence-diagrams.md
rename to src/architecture/sequence-diagrams.md
index 8ea75d36..4a725b66 100644
--- a/docs/architecture/sequence-diagrams.md
+++ b/src/architecture/sequence-diagrams.md
@@ -1,26 +1,26 @@
# Sequence diagrams
-Traditional systems like API's present simple scenarios, in which a centralized service define how data should be encoded. However, decentralized ecosystems like a distributed vote system need much stronger work on defining every interaction between any two peers on the network.
-
-- [Prior to voting](#prior-to-voting)
- - [Initial Gateway discovery](#initial-gateway-discovery)
- - [Set Entity metadata](#set-entity-metadata)
-- [Voting](#voting)
- - [Voting process creation](#voting-process-creation)
- - [Voting process retrieval](#voting-process-retrieval)
- - [Check census inclusion](#check-census-inclusion)
- - [Casting a vote](#casting-a-vote)
-- [After voting](#after-voting)
- - [Checking a Vote Envelope](#checking-a-vote-envelope)
- - [Closing a Voting Process](#closing-a-voting-process)
- - [Vote Scrutiny](#vote-scrutiny)
+Traditional systems like APIs present simple scenarios, in which a centralized service define how data should be encoded. However, decentralized ecosystems like a distributed vote system need much stronger work on defining every interaction between any two peers on the network.
+
+- [Sequence diagrams](#sequence-diagrams)
+ - [Prior to voting](#prior-to-voting)
+ - [Initial Gateway discovery](#initial-gateway-discovery)
+ - [Set Entity metadata](#set-entity-metadata)
+ - [Adding users to a census](#adding-users-to-a-census)
+ - [Voting](#voting)
+ - [Voting process creation](#voting-process-creation)
+ - [Voting process retrieval](#voting-process-retrieval)
+ - [Check census inclusion](#check-census-inclusion)
+ - [Casting a vote](#casting-a-vote)
+ - [After voting](#after-voting)
+ - [Checking a Vote Envelope](#checking-a-vote-envelope)
+ - [Closing a Voting Process](#closing-a-voting-process)
+ - [Vote Scrutiny](#vote-scrutiny)
---
## Prior to voting
----
-
### Initial Gateway discovery
The app wants to get initial connectivity with the available gateways.
@@ -32,16 +32,17 @@ The app wants to get initial connectivity with the available gateways.
- From one of the boot nodes, we get a list of Gateways provided by Vocdoni
```mermaid
+%%{init: {'theme':'forest'}}%%
sequenceDiagram
participant Client
participant DV as DVote
- participant ER as Entity Resolver contract
+ participant ER as Entity Resolver
+ 
+
+