## 6 Designing a Distributed Questions and Answers System
### Data Provenance  
In centralized and federated systems, the trustworthiness of the data is provided through a direct connection to trusted servers; e.g., the user of a centralized Q&A system trusts a server not to hide or alter the information of the system. Fully decentralized alternatives can also be considered to obtain trustworthy data.  
We propose the use of asymmetric cryptography identities to ensure the trustworthy provenance of data. Data that are digitally signed by trusted identities are trusted in the system. Following the technological choices of the architecture, the use of IPNS [32] or the Ethereum [57] identity infrastructure can be used.  
Following our Q&A system example, every question, answer, and vote is digitally signed by the authors. Replicating the behavior of Stack Overflow, every user can submit questions and answers to the system. Thus, every signed question or answer is consider valid. A simple version of the system may consider every question, answer, and vote valid, thus having weak consistency requirements. Such a system would not need coordination technologies (Guideline 2) to work. However, systems such as Stack Overflow implement strategies to avoid system abuses; for instance, the system only allows authors with at least 15 reputation points to vote. Five reputation points are earned with each positive vote to a question or answer. Thus, to implement such strategies, our system should only allow the votes of users with at least three positive votes. Since these votes also have to be valid, the vote verification is recursive, until it reaches a trusted base case; e.g., identities that were initially allowed to vote without reputation in the system.  
If negative votes are not considered in the system, answering whether a vote is valid is a non-monotonic problem. Thus, it can be implemented in a distributed system with strong consistency without coordination mechanisms (Guideline 1). However, the recursive nature of the example shows that the size and complexity of the data needed to trust a response may not be trivial.  
The consideration of negative votes to questions and answers that would decrease the reputation of the authors adds complexity to the problem. The question of whether an identity has at least 15 reputation points is no longer monotonic, since observing new negative votes may change the results. Fortunately, adding and subtracting values to a number are commutative operations. Thus, and following the proposal of CRDTs, we could chose availability over consistency and be able to operate in the system while not knowing all the up and down votes, trusting that eventual consistency will be achieved (Guideline 3).  
Furthermore, digital signatures may not be enough to prove authorship in the system. A malicious agent may sign data previously authored by other agents. Deciding the identity of the first author is therefore a non-monotonic problem that cannot be resolved with strong consistency without coordination. This problem is similar to the double-spending problem and could be resolved using the Blockchain if the designer considers that the system requires such strong consistency (Authors could use blockchain to claim authorship by registering a fingerprint of their content in the blockchain before publishing it.) (Guideline 4).  
Non-monotonic searches (see Section 4.2) with strong consistency requirements, such as determining the exact number of votes for a question, may need the use of the Blockchain as a coordination mechanism. For instance, the votes of a Q&A system or the authorship of questions and answers could be registered in a Blockchain to provide consistency to those queries. Our architecture proposes the development of smart contracts using Ethereum [57] to provide such consistency for these systems.