dBase: Story behind creation
Inspiration
Since our teenage years, the blockchain world has been a realm of endless fascination and potential for us. Only recently did it dawn on us — blockchain is more than a ledger for transactions; it's a canvas for innovation. Yet despite our eagerness to dive into Web3 development, we lacked a guiding light, a project that stoked the fires of motivation. That changed when we faced a roadblock on a side project. We needed sensor data that was out of our reach, though we knew it existed somewhere in the digital ether. Our desire to simply pay for access to this data collided with our discovery of the Chainlink hackathon. The pieces of the puzzle laid themselves out — this was our chance to create something that addressed a real need
Eureka Moment
As we delved deeper, we hit a wall. Though we could store data on the blockchain, the cost was exorbitant. Chainlink functions offered a solution, but they felt too centralized for our taste — contrary to the decentralized spirit we were chasing. Our research on existing blockchain databases left us unfulfilled. This quest for a truly decentralized database — one that was permissionless yet private, secure yet accessible — became the cornerstone of dBase.
Building dBase
The journey of building dBase was a blend of excitement and challenge. It felt like assembling a jigsaw puzzle without the picture on the box — thrilling yet daunting. Piece by piece, we wove together smart contract logic, data hashing mechanisms, and node synchronization protocols. We harnessed Chainlink's verifiable randomness function (VRF) to evenly distribute data entry load across nodes, ensuring no single point of failure. Our smart contract architecture evolved to automate subscriptions using Chainlink Automation, enabling cross-chain data exchange via Chainlink CCIP, and maintaining a fair pricing model.
Challenges Along the Way
Crafting a decentralized database is no small feat. Establishing a permissionless system that protected data creators’ exclusive rights to edit or delete their data required a delicate balance. We had to build an infrastructure that functioned seamlessly both on and off-chain, a dance between security and cost-efficiency. Working against the clock of the hackathon, juggling with the limitations of smart contract development, and keeping the user experience intuitive was a Herculean task. Yet through each obstacle, we uncovered new solutions and fortified the foundation of dBase.
Lessons Learned
The creation of dBase has been a profound learning experience. It brought to light the intricate relationship between decentralization and user autonomy. It challenged our technical skills, pushing us to innovate beyond the conventional scope of smart contracts. Most importantly, it solidified my belief in the blockchain's potential to revolutionize how we manage and lease our digital assets.
Conclusion
dBase isn't just a tool; it's a statement. It's a bridge between the untapped potential of blockchain technologies and practical use cases in industries desperate for data integrity and security. With dBase, we're paving the way for a future where data isn't just stored — it's an asset that can be traded, rented, and wielded without sacrificing decentralization. We've faced down the challenges and emerged emboldened, ready to redefine data sovereignty on the blockchain.
How dBase Operates: A Deep Dive into Functionality
Adding Data
Users have a playground or smart contract through which they add data. Each time data is added, payment is required for the addition. Payment is made through a Web3 wallet in dBase token.
Each piece of data entered into the SQL database is represented as a BLOCK. A block contains:
- Block number
- ID (randomly generated)
- Date and time of creation
- Name (generated using the sha256 algorithm with a seed)
- Address of the person entering the data (Public wallet address)
- Entry type (enum)
- JSON data (key: value)
After entering each piece of data, it is first transmitted to a smart contract, which creates a hash for truth verification. Following that, with the assistance of the Chainlink function, it is sent to one of the nodes. Our node is randomly selected using the Chainlink VRF. Once the data is inputted into one node, an event is emitted to synchronize all other nodes.
Reading Data
Users can read data through the playground or smart contract. Data can be searched by the block name, meaning a query can be only made using the name of the block (for now). The name is generated using a seed (sha256), as well as the values of the "key" stored within the JSON.
Reading data is based on a subscription model. During the reading of a block, it is checked whether the block has been updated or modified. Verification is done in the same way as creating an update.
Modifying Data and Deletion
The data within blocks is fixed and cannot be modified. Modifications and deletions are done by creating a new block and linking it through "invisible" fields to the previous or future block. Invisible fields are not entered in the database but are obtained through the hashing method.
Example:
(original block)
- Block Name: blaz+151120230439+sensors+0 => 22b1e09dba606…db71f334bc52b98ed01fc1
(modification)
- Block name: blaz+151120230439+sensors+1 => 0bebd721db0713b1…d1c2c41b2bcc8c04f99db
Names can be generated only if we have the "Secret Phrase," which in this case is "blaz." This way, no permissions are needed because only the person who knows the secret phrase can submit a modification that will be accepted.
Modification includes a set of data, as well as the entry or creation of a block (with updated data).
Deletion is done by leaving the JSON field empty, and for the entry type, DELETE is specified.
Block Naming Convention
The block name is created using the following method:
[secret] + [search_term] + [nonce]
- Secret: a secret phrase used to "encrypt" the block, akin to a cipher.
- Search Term: an expression used for querying data, ranging from simple to complex.
- Example search term:
sensor1_101220231026(timestamp)or similar.
- Example search term:
- Nonce: the sequential number of the block. It is increased by 1 for any modification.
Example block name: myHackathon + outdoor_sensors_1 + 0
As mentioned, data is stored in the form of key-value pairs. Each key has its own name generated similarly to the block name creation process.
Example of creating a key:
[secret] + [search_term] + [key_name] + [nonce]
- Secret: a secret phrase used to "encrypt" the block.
- Search Term: an expression used for querying data.
- Nonce: the sequential number of the block.
- Key Name: a normal name for the key without encryption. For instance, if the heat sensor value is stored here, the key name would be "temperature."
Example key: myHackathon + outdoor_sensors_1 + temperature + 0
Example of a block:
{
"ID": 1,
"Date_time": "2023-11-13 19:49:00.000Z",
"Name": "bb446e66e33350f3e56f7c7a159490e9124c4c2a839fa37a7d32a7cac4ab0115",
"field": {
"14fa84a3f185f6b3acc43528176e77b9686113308982a4798d1a058f48bdd256": "21",
"c9aab3c775bef2e8f686ba29fb612f9ae56b52b9edd02ae9f940761da47c8db2": "85"
},
"id": "1bd3sluo04j9m9q",
"vsrta_unosa": "PUT"
}
As observed, even though anyone can inspect the block data and read all values, the data is meaningless. Due to the hash encryption, there's no practical way for someone to decode this. Only a person who knows how to generate the original name can decipher this. In this case, the number 21 represents temperature, and 85 represents air humidity.
myHackathon + outdoor_sensors_1 + temperature + 0 ---SHA256---> 14fa84a3f185f6b3acc43528176e77b9686113308982a4798d1a058f48bdd256
myHackathon + outdoor_sensors_1 + humidity + 0 ---SHA256---> c9aab3c775bef2e8f686ba29fb612f9ae56b52b9edd02ae9f940761da47c8db2
Backups and DDoS Protection
Backups
There is no need for backups due to the distributed nature of the network. In case of data loss, we can copy the data from any member of the network. The data is easy to verify thanks to the underlying blockchain. Therefore, only one person needs to have all the data to confidently assert that the data has not been altered.
DDoS Protection
By design, the database is resilient to DDoS attacks because there is no single individual whose disruption could impede the normal functioning of the database. The decentralized structure ensures that there is no central point of vulnerability that could be targeted to disrupt the database's operations.
Creating Our Token
To address the funding challenges of our network and streamline the payment process, all operations related to the database are conducted using the dBase token. This token adheres to the ERC-20 standard and serves multiple purposes within our network.
Token application
Compensating Nodes:
The dBase token is utilized to compensate our network nodes for their services. Node operators are rewarded with these tokens for their contribution to the network's functionality.
Payment for Data Transactions:
In addition to compensating node operators, the dBase token functions as a means of payment for both reading and writing data within the network. Users can seamlessly engage in data transactions using this ERC-20 token.
This approach not only resolves the network financing challenge but also simplifies and unifies the payment processes associated with the database, fostering a more efficient and cohesive ecosystem.
Use Cases for dBase
Hospitals - Embracing Decentralized Healthcare
Decentralized healthcare has long been at the forefront of blockchain discussions. A major obstacle to its implementation is the high cost of data storage on the blockchain. dBase offers an affordable and secure storage solution, enabling hospitals to write and generate tamper-proof NFT prescriptions for patients, revolutionizing traditional medical record-keeping.
Decentralized Data Marketplace
A platform where data from various sensors and IoT devices can be bought, which is especially beneficial for collective research projects and investigations. Imagine a system where anyone can sell or rent their data securely, ensuring full protection and anonymity for the individual. Meanwhile, the buyer can have confidence that the data is unaltered and genuine.
Accounting
A company can maintain its accounting books within dBase with the assurance that the data remains unaltered. If any changes occur, there's full transparency. Custom functions can be written to analyze, group, and process financial data, aiding in the integrity and analysis of fiscal records.
Private Companies
The system can be utilized for secure record-keeping. Each business transaction can be recorded as a block in the database, providing a traceable, immutable record of all business activities. This feature is particularly useful in sectors like finance, where precise record maintenance is crucial. The system can also manage inventory and supply chain processes.
Pharmaceutical Companies
These companies can use dBase to track the lifecycle of drugs from production to distribution, ensuring traceability and authenticity. Moreover, it enables real-world evidence studies through secure storage and analysis of diverse data sources, including electronic health records, claim and billing data, and wearable device data.
Planned Features Not Yet Implemented in dBase
dBase Functions: Expanding Database Functionality
We intended to introduce a suite of JavaScript functions that could expand our database's capabilities significantly. These functions would leverage the Chainlink DON network, allowing them to interface fluidly with the dBase database and execute complex operations or computations. Unfortunately, due to time constraints primarily from academic commitments, this feature remains on our roadmap for future development.
Update and Deletion Capabilities
Although the strategy for updating and deleting data has been detailed previously, fully realizing this functionality within dBase proved to be challenging amidst our private obligations, particularly academic ones. Hence, this remains a work-in-progress that we aim to complete post-hackathon.
Data Marketplace Functionality
The vision for a comprehensive data marketplace within dBase — where users could freely trade and manage data — was planned out meticulously. Regrettably, due to the limited time frame of the hackathon, we could not bring this functionality to fruition. We are determined to integrate this feature, ensuring that dBase supports seamless data economies in the near future.
Things that we wanted to implement, but didn't have time for it 😥
Dynamic NFT - We planned to use dynamic nft as a basis for creating a subscription model for our base. The plan was to buy an NFT that lasts for a month and you can enter and read data an unlimited number of times
Chainlink CCIP - to ensure that the correctness of data can be proven on other blockchains, we planned to use chainlink CCIP for data transfer. However, due to time constraints, we were not able to
Log in or sign up for Devpost to join the conversation.