The importance of having access to customer feedback is clear to everyone. This way, people are protected from improper actions, or, vice versa, can share positive experiences about a particular service they enjoyed. However, such reviews are often controlled directly by service providers, which raises questions both about the reliability of information such feedback contains and about its relevance (a provider’s tracking center may disable the option to leave negative feedback). That’s where an independent feedback system comes into play, offering reviews from real users. This, in turn, would mean that the reviews are genuine, and, therefore, objective and credible.
So far, it seems, there’s hardly been a one-stop solution to this problem. We have to collect feedback from several aggregators, leaving the question of trust at the mercy of service providers. Here is where a decentralized service with an elaborate system of reputation, ratings and reviews could save the day. A system with the option to check the reputation of its participants, a system that can be trusted.
This is basically the underlying concept behind the project designated as Open Place Reviews, a decentralized system based on the blockchain technology, used for storing feedback. This project is at an early stage right now and requires a lot of effort and community involvement to make this world a better place.
I’d like to share my own vision of an architecture for this project, and specifically for the part related to a blockchain-based public database (OpenDB).
Blockchain Using: basic properties
First of all, we have to admit that choosing a blockchain technology is not a trivial task. We have to take into account many factors. And even after that, the expediency of using blockchain in projects can be confirmed only on the basis of experience gained from actual, real-life usage. Here, I will focus on the description of benefits that this approach will provide as well as on the limitations it inherently has for a feedback system.
A blockchain is a list of records, or blocks, that are linked to each other. Each block contains a combination of several operations (name “transaction” is also commonly used) of a certain type. In an OpenDB, a operation is, essentially, any action undertaken in respect of feedback (like adding, modifying, or deleting it). It is worth noting here that in the blockchain itself you cannot physically change or delete anything. Instead, if that be the case, a new operation is created that is interpreted as a modification or deletion of information from a particular review/piece of feedback.
To make sure that users who leave feedback are acting in good faith, to maintain ratings, combat fake reviews and avoid boosting, each review should have an author. And that’s where a digital signature system steps in. Each review must have a valid digital signature. This way, we can achieve:
- Authentication (to verify the authorship of a review);
- Cryptographic security (impossible to forge; only the owner of the private key can sign their review);
- Integrity (to check whether there is distortion of information);
- Non-repudiation (to make sure that a review’s author cannot successfully dispute their authorship or the validity of the associated review).
One of the key advantages of blockchain-based platforms is the protection of stored data against modification and substitution, as well as the ability to carry out a quick audit of such integrity. Despite the stated security properties, all data in the blockchain is open and publicly accessible. These properties are inherent in blockchain “by design”.
The above is achieved in a simple way: each new data block has an identifier that depends on the data contained in that block. Any change will invalidate this identifier which is effectively a hash function that has all the required properties:
- For any given input value, it must always generate one and the same hash function value;
- Each hash value in the output range should be generated with approximately the same probability;
- The output value of the hash function has a fixed size;
- Hash function is fast when computing hash from data, but going the opposite way (i.e extracting the original data behind that hash) is an algorithmically undecidable problem;
- Even the smallest change to the input will result in a completely different output value.
All blocks are linked to form a chain where the identifier of each block (the hash function of that block) is linked to the next block in the chain. It is by using this simple architecture that we achieve the stated security properties. And since data is in open access, any user can recalculate the identifier (hash) and compare it with the value that is stored in the blockchain to determine whether it’s reliable and integral.
The other side of the coin is that with blockchain it is impossible to cancel (delete) an obviously erroneous (wrong) operation. To do that, you need to create a new operation and with certain actions undertaken on the way (depending on how blockchain is implemented). This allows you to keep a complete history with all stages and editing steps, but it also creates excessive data that grow with each new operation like a ball of snow rolling downhill. And since the size of a blockchain file is NOT unlimited, it is necessary to pre-calculate and take into account the rate at which it will grow.
There are two important features that a feedback system should have: it should be distributed and it should be decentralized. There are various approaches to implementing the stated features in blockchain-based systems, each with its own advantages and disadvantages. Blockchain is a distributed system without a central administrator. To agree on a new block to be added to a network, its [network] participants use a special consensus algorithm to come to a common decision as to what the new state of the network should be, i.e. agree on the next block to be added to the chain.
The “Bitcoin” cryptocurrency is a good real-life example of a distributed and decentralized system. It is achieved by means of an original consensus algorithm which has a beautifully simple architecture but requires network participants to utilize significant computing capacities. As a result, the generation/creation of each new block comes at a price (to add every operation, a fee is to be paid to that block’s creator). Such an approach is not applicable to OpenDB.
Among the available and described approaches towards building systems based on blockchain, we believe that an acceptable solution would be a decentralized yet not an undistributed structure that possesses the following features:
- Only authorized network users can create new blocks (Blockchain Servers);
- Blockchain data is open (in public domain), that is, can be read by all users (OpenDB users);
- Only authorized network users (Application Servers) can add new operations;
- Adding operations is free of charge.
Such a structure requires more complex algorithms of consensus, resolution of contradictions and other methods of interaction between the elements of the blockchain network (including the exchange of blocks and operations).
Like any feedback and review system, OpenDB requires a user authorization method to be used. The difficult part is to implement it on the basis of blockchain. After studying the specified requirements and source codes of the already implemented part of the authorization subsystem, one could come up with an architecture that has the following properties:
Ease of Use
Users are offered a choice of login / signup options:
- Registration using a nickname/username and a password;
- Use of existing Google, Facebook, OSM accounts (using the OAuth technology);
- Registration using a public/private pair key generated by the user.
- A new pair of keys is generated for each new session;
- Use of Scrypt as a key derivation function for stretching a password into a longer key, frustrating brute-force attacks and making them more difficult to execute;
- The master private key is not stored on the server;
- Use of secure cryptographic primitives.
Use of Cryptographic Primitives
The security of the system is based on time-tested, standard crypto primitives.
Hash values are calculated using the SHA-256 hash function.
For signatures, the elliptic curve digital signature algorithm
(ECDSA) is used with the following recommended curve parameter: secp256k1.
Note: For convenience and speed of calculation, only the hash value of a operation and block is signed.
For key derivation, Scrypt password-based key derivation function is used with the parameters recommended by default.
It should be kept in mind, however, that the main source of security incidents is in the way these “reliable” algorithms are implemented.
For example, in August 2013 the java.security package was reported to contain a critical bug in the implementation of a random number generator, which compromised a digital signature used.
Challenges and Recommendations
An Application Server can calculate the master private key. It also stores session private keys. Hence, the server is a potential source for confidential data to leak through. It is required that the user–Application Server connection channel be protected. The channel connecting the Application Server and the Blockchain Server is used to transmit publicly available data that is easily validated. Therefore, there is no need to protect this channel.
The basic rule of a blockchain-based system is: no one believes anyone. Therefore, the Blockchain Server does not trust Application Servers and other Blockchain Servers. So we need to verify all operations from Application Servers and all blocks from other Blockchain Servers. Validation is based on some basic rules (check hashes and signatures) but also additional validation rules were added to the blockchain before (like sys:validate operations).
Problem with wait timings. Need some approach for implementation of queues with operations that have been validated but not yet included in a block. For example, after a user signup operation, before that operation is included in the block, the user cannot undertake any action. Possible solutions: use of operations cache for the AppServer; using already validated operations from the queue to validate follow-up operations for the Blockchain Server). May be use sequences for related operations.
Protection against the reuse of operations. For example, an attacker can intercept a generated operation and try to send it to the Blockchain Server again. Need some additional validation rules to prevent that from happening.
The algorithm of consensus and the ways of data exchange in the network (operations and blocks) are not trivial and require considerable effort to design and implement correctly.
Since many application details are not fully defined, a certain configuration file could be used instead of the Genesis Block (for example, with timeouts for creating a block, limits on the size of operations and blocks), because it will be impossible to make changes to the blockchain afterwards.