Civic Participation Tool — upgrade to OpenStad

This article will explain the advantages of our upgrade to the existing Openstad participation tool currently in use throughout the Netherlands, currently called the Civic Participation Tool. Please see the previous article for an introduction, demo, and source code.

Openstad is a tool that is run by several neighborhoods in Amsterdam, The Hague, and other cities in the Netherlands. It allows citizens to propose changes to the infrastructure (e.g. “Create a new flower bed next to the boulevard”), and for those proposals to be voted on by the citizens. The proposals with the highest votes are then executed by the local government. Openstad currently uses a Nodejs server / Mongodb database architecture.

A simplification, as there is also an image server, but for now this illustrates the main difference between Openstad and Civic: that the data layer has been replaced by an EOSIO blockchain.

Contents

1. High-security Data Layer
2. Data Privacy
3. The Open Neighborhood Model: Fixing Data Fragmentation
4. Socially Accountable Data
5. Transparent Human Government
6. Identity
7. Scalability
8. Conclusion and Wins

High-security Data Layer

Using a blockchain instead of a server/database system provides significant upgrades to the security of the system.

Security, both physical and digital, is an integral part of a goverments service and it’s reputation. Improving security of systems/citizens retains trust and can reduces costs.

The following properties present a major upgrade to the security of Openstad.

1. There is no central administration node in the system. All operators of the blockchain run independently and in real-time cryptographically audit all data from the other nodes. If any of the other nodes running the blockchain with its applications and data is compromised the other nodes will know this instantly and be able to prove this cryptographically. This allows for a much more robust, redundant, available data layer with extremely high data integrity and security compared to a server/database system.
2. The history of operations executed in applications is cryptographically audited by all nodes in the system. This “immutable” transaction history forms a very high-quality piece of data that can never be altered without detection after it is written, allowing operators and citizens to trust the history of events more. This data quality does not exist within Openstad currently.
3. Civic uses asymmetric cryptography for authentication. A secret private key is generated by the citizen and only the corresponding public key is stored on the blockchain. The application can verify the citizen has the secret key, by checking a cryptographic proof (digital signature) against the stored public key. This means that the application is able to verify that the citizen knows/owns their secret, without having to store this secret. Without needing to store a citizen’s secrets (i.e. their password) in the database means that a data breach does not compromise the citizen’s authentication, also leading to fewer attempts to compromise this data.
4. Authentication keys (public keys as explained above) are stored and secured on the blockchain. Authentication authorization (e.g. who works for the government and is allowed to perform a proposal review/feasibility study) is also secured by the distributed blockchain. This provides additional security guarantees that authorization cannot be accidentally compromised compared to Openstad.
5. The application logic (e.g. who and how can proposals be created) and the application data (e.g. what data is stored for each proposal) are very tightly coupled together. The cryptography of the system guarantees that the data corresponds to the logic. This is different from a server/database architecture where logic and data are not coupled together logically. This provides high-level security for applications deployed in the blockchain, and will be discussed in the section “The Open Neighbourhood Model”.

Data Privacy

Due to the immutable nature of a blockchain transaction history, special care has been taken to ensure data privacy requirements are met.

The current system implements two techniques to achieve full GDPR compliance.

First, personal information such as a citizen’s name is stored in a regular database, and never on the blockchain. This can be seen in the architecture diagram above. At the request of a citizen, their personal information can be completely removed. The history of that citizen’s actions on the blockchain is not removed, but are then completely anonymized.

Accidents happen, and sometimes a citizen or public servants may add unwanted personal or other information to the application (e.g. a photo with a person in it is added to a proposal). If this happens, the data can immediately be removed out of the current state of the blockchain which means it will stop being processed. However, the transaction history will still contain that data. This is why we have built the data privacy layer that runs on top of the blockchain. This can be used to programmatically remove the visibility of parts of the blockchain history to the public that has inappropriate or personal information that has been requested to be removed.

The Open Neighborhood Model: Fixing Data Fragmentation

Openstad has a very flexible architecture allowing multiple sites to use the same backend system. This allows multiple neighborhoods to run different user interfaces within the one deployed system. This is system #1 as depicted in the above graphic.

By speaking with Openstad at Odyssey we learned that, despite this functionality being available, neighborhoods around the Netherlands were instead opting to deploy their own instance of Openstad instead of joining the existing deployment. This has now created a fragmented system as seen in system #2 in the above graphics.

As discussed in the security section above, each application on the blockchain gets a cryptographically enforced guarantee that their data corresponds to their logic. Due to this characteristic, this will allow all neighborhoods in the Netherlands to deploy on one blockchain system without compromising trust barriers between their data. Each neighborhood can control its logic (optionally, they can deviate slightly from that provided by Openstad) and all neighborhoods are built on top of the much more secure data layer as explained above. This provides greater security as a whole and centralizes data in one system providing better analytics for and between neighborhoods about their democratic processes. This also means that citizens moving between neighborhoods do not need to create new accounts each time.

This reasoning can also be applied beyond the ecosystem of neighborhoods using Openstad, alowing a secure, cooporative and interoperable ecosystem of goverment applications.

Using this model, other applications can be securely trusted to build on the same data layer. We explored this idea with several teams, including Ontola at the event, who could put their democratic feedback tool for government meetings onto our data layer while ensuring that the Openstad neighborhood planning tool security was not compromised at all. Thinking this far ahead, the advantages of our data layer when scaled and used by multiple parties in an ecosystem become even more beneficial for the government and citizens.

Socially Accountable Data

The data layer uses a customized eosio blockchain. This uses a specially designed governance smart contract (program on the blockchain) that creates a special rule that applies to the entire blockchain:

At the data layer, all objects, entities, and actions are cryptographically linked to humans. We call this the socially accountable data layer.

This means that actions done by the government are linked to their corresponding public servant/citizen behind that action. Also, the ownership structure of the government, data layer operator, and application developer accounts are also linked to humans. This concept also applies to all actions done by citizens. This creates a system where humans are accountable to each other for what they do, creating better synergy and accountability for actions even if done on behalf of an organization.

This allows the government to sustainably scale the cooperation with other organizations in their ecosystem faster, as they can trust humans that are more accountable.

Due to the data privacy logic layer explained above, the decision about what social information is made publicly available to other citizens can be customized as needed.

Transparent Human Government

The proposal history section shows citizens the entire history of each proposal, from creation, feasibility study, approval, voting, and execution.

It shows the work done by the government to help citizens understand the proposal, and then the execution of it after. Using the social accountability layer, it shows which humans at the government conducted this work, bringing a human touch back to abstract government processes.

This transparency allows the citizen to feel more included in what is going on in their neighborhood, and feel that their government is working for them.

Identity

During the event, we almost completed the integration of a Self-Sovereign Identity (SSI) solution with team OdySSI.

This uses identity provider IRMA, which provides government-issued credentials about citizens. The user is required to sign in using the IRMA mobile app, which provides these credentials to our system. This provides the name of the citizen, as well as their postcode which can be used to ensure that they are part of the neighborhood they are trying to join. This can replace existing outdated and costly infrastructure currently used to onboard citizens into neighborhoods.

Additionally, citizens do not have to fill out (yet another) form with their name and other details when they sign in to Openstad and may not need to use a password.

We will be excited to explore how this could significantly help Openstad onboard citizens into their system more securely and with a better user experience.

Scalability

We conducted an analysis of the limits of the currently implemented Civic Participation Tool. This looked at the current infrastructure resources used by the system and compared them to the resource limits available for a production level eosio blockchain. We did not conduct automated limit or concurrency tests so these should only be used as a rough guide.

A medium-scale production system can handle (M = million):

• 900 neighborhoods with 90,000 proposals, 2.5M votes, and 2.5M citizens
• 975 concurrent citizens that all make an action within 1 second

We found this system to easily accommodate the planned operations that Openstad expects in the future.

Conclusion and Wins

We found that our upgrade can meet the data privacy and scalability requirements needed by Openstad and provide a variety of wins compared to the current system as summarised below:

We are currently defining the next stage of work with the city of The Hague and are extremely excited about the future of this system.