What it does
ValGun is a plugin that implements a self-developed protocol used to achieve validation of data being stored in a decentralized database. Specifically, we utilize blockchain-based consensus to achieve validation of both incoming and outgoing data from a peer to a new user, in a decentralized, secure manner. This is best used for volatile, user-generated data that will need to be accessed in the future, but should still be validated at present, upon release.
The tremendous growth of blockchain-based products has created a necessity for powerful, secure data storage solutions. Most decentralized applications are prevented from storing their data on blockchains, such as Ethereum, because of expensive gas costs. As such, this forces them to store their data via centralized solutions. However, when central authorities have access to all data, an immense amount of privacy and security vulnerabilities surface, with a single point of failure leading to loss of massive amounts of data. Decentralized databases address these issues through distribution of data across multiple nodes across the world, allowing access to data even if one node is down in a cost-effective manner. Additionally, decentralized databases offer ease of scalability due to their distributed nature.
While decentralized databases provide a useful solution to many issues that dApp developers face, they provide no way to prevent malicious actors from sending in false data into the database. This especially arises when a new peer joins the network, as there is no way to ensure that the data they receive is verified and true. As such, ValGun ensures that all data entering the decentralized database has been validated through a consensus protocol, and any data requested by a new peer, is also validated. This ensures that all data being stored in a decentralized database holds honesty and integrity.
The use case we present in our demonstration is on ratings of a political candidate. This use case is especially apt for ValGun because it requires validation that a user is real (via public-private keys) and that their single rating entering the database is in defined bounds of 1-5. Here, ValGun ensures that the data being sent in is true and that malicious actors cannot make multiple users that each falsify sending in multiple positive or negative ratings.
In addition to political ratings, ValGun is useful anywhere constantly-changing data must be validated before being stored. Other use cases are numerous. For example, in the case of decentralized social media, to ensure malicious users don’t falsify data through making a post with a large amount of upvotes, ValGun is able to validate the post data being sent into GunDB to ensure that a user is real and is only sending in one upvote, rather than multiple false upvotes. Another use case is for self-reporting COVID-19 statistics in a decentralized manner (decentralization is necessary in order to prevent a centralized party from providing false statistics to the public), the statistics must be further validated, or they could easily be manipulated by malicious actors sending in false data into the decentralized database. Here, ValGun can ensure that self-reporting users are real and that they are unable to send in more than one test result.
How we built it
The ValGun protocol works by verifying incoming data and validating outgoing data. For validation of incoming data, all Nodes (Partial and Full) validate the information using the validate function for each use case. Once the information is validated, it's stored on the database as a key, value pair with the key as the hash of the data and value the data itself. The hash is then sent to the mempool and gets mined on the blockchain. For validation of outgoing data, when a new peer joins the network, they find the hash of the informations on the blockchain. Then they request the information using the key as the hash. The information they get from the other nodes can be verified by hashing the data and confirming its the same as the hash on the blockchain.
Let’s consider a scenario where the network is rating different politicians on a scale from 1-5. Imagine you are a node in that network and wish to give the politician John Doe a rating of 5. On your node, you will gossip a rating message to your peers and they will continue forwarding your message until the whole network is aware of it. The message you send will be signed with your private key to ensure no one can vote on your behalf. In addition, the message will also be stored in a decentralized fashion across the network using GunDB under its hash to allow for future retrieval.
Upon receipt of your message, the peer will validate your message by Checking the signature Ensuring the user is trusted and not double voting Making sure the rating is actually an integer from 1 to 5
If the validation passes, then the peer will add the hash of your message to its mempool and add it to a local hashmap which stores all message hashes that have been validated. The peer will also compute the politician’s new record by requesting it from GunDB and adding your rating to it. This new record will then be stored locally and its hash will be added to your mempool. It is crucial that only the hashes of incoming data are being stored locally - otherwise, you would be storing all incoming data defeating the point of a decentralized database.
Miners that keep track of the mempool constantly try different nonces to solve the proof-of-work on the block they’re working on that builds on the tip of the longest chain. When they successfully mine a block, it will be broadcasted to the rest of the network to be added to every full node’s block tree if validated and stored in GunDB under its hash to enable future retrieval.
To this point, we have established how data can be added to the blockchain. It remains to discuss how we retrieve data from it. Suppose you are a new light client that joins the network. You will request the chain tip from your peers until you are familiar with where the rest of the network is at with their block trees, ensuring that the blocks you receive have valid proof-of-work and lead to genesis. If you then wish to see how the politician John Doe is doing, you will go in reverse through the ledger until you find a record hash with a key of “John Doe.” That hash is then requested from GunDB for its associated data and then checked so that the hash matches with that of the ledger’s. It is important that you look through the ledger of confirmed data as the current chain tip may not be adopted in the future. Note also that it is not necessary for the light client to go through individual ratings as they only care about politician records, increasing efficiency.
Challenges we ran into
The biggest challenge we ran into while building ValGun was the poor, sparse documentation provided by decentralized databases. Only two decentralized distributed graph databases currently exist - GunDB and OrbitDB. A common complaint from developers utilizing either of these is that there is a lack of clarity in their documentation, code-based comments, and variable names. As such, much of our time was spent in interpretation of the documentation in order to properly use existing functions. We kept this issue in mind when writing our own code and documentation, in hopes that developers can easily understand and use our product.
Another major challenge we faced was building our blockchain system from scratch. Because GunDB doesn’t utilize a blockchain, we ran into issues when trying to establish consensus among our nodes. As such, this required building a custom-designed blockchain and a mining system from the ground up, which proved to be a difficult task in the short amount of time of the hackathon.
Accomplishments that we're proud of
A current criticism of decentralized databases is that adversarial nodes can easily disseminate erroneous or false information into the database without verification. We’re proud of solving a problem that lies at the crux of modern database management—finding a way to decentralize database management while ensuring validity of the data. This allows moving data ownership away from single corporations, such as AWS or Google Cloud, who could access or modify data to serve their needs. We’ve built a robust product that works and can help shape the manner in which databases manifest themselves in the decentralized world.
What we learned
Each team member came into the hackathon with little blockchain and decentralized database experience—we’ve learned a lot about how to validate information and work with partial and complete nodes. We’ve also learned how to build on top and modulate existing frameworks—much of our early work rested upon diving deep into the code base for GunDB and modulating their functionality. We also learned a lot about deploying crypto-based projects, creating an app in NextJS that allows an individual to interact with the backend that we built.
What's next for ValGun
Right now, ValGun harnesses GunDB and interfaces on top of it—our goal is to make a stand-alone tool that allows for decentralized database management. In addition to making complex queries possible on GunDB, we hope to establish a clear way to ensure mining incentives exist for our validation blockchain. We’ll be continuing working on ValGun beyond the hackathon and have reached out to advisors in the Bay Area to guide us in terms of further development and commercialization.
Log in or sign up for Devpost to join the conversation.