Inspiration

Often we get around unique thoughts and research work that we write down somewhere and don't straight away want to reveal to the world but want some form of patent so we can later prove to the world or in court that We thought it at approximately this time and day. So later, if there's conflict, it can be resolved. We don't just get ideas once or once; We get many at different stages of life.

Is any file in our computers truly timestamped? If so, can it be proven in court? Probably not, So we wanted to create something that saves the fingerprint of one's thoughts or research work in time and solely theirs, i.e. non-transferable—what better way to implement than a blockchain-backed by the only truly decentralized time chain?

What it does

It gives the user the power to save any file's existence proof on-chain, which works as proof of ownership in time. Not only this but because of the Merkle tree data structure, users can upload many files with just one proof on-chain, reducing the irrelevant each file hash individual existence.

Illustration

We call it "commit" when the user saves a file or multiple files. This project also connects all the commits in one Merkle tree, that gives one single hash for all the files. Each commit has a name that users can scroll through when they connect their wallet. Users can select the commit and upload the relevant file/s, and They can easily prove the existence of the file time-stamped by the blockchain to anyone in the world!!.

User Behind the scenes
First Commit Saving new file/files proof. Calculating SHA256 of files -> If multiple files calculate Merkle root -> save hash/root on-chain using stacks.js.
Other Commits Adding new file proof while maintaining older commit history. Calculating SHA256 of files -> Getting previous Merkle root + new files hash -> save new Merkle root.
Verify Select commit using the name and upload relevant files. Get the Merkle root of the selected commit and the previous, if it exists. Calculate Merkle root using old + files hashes and compare with on-chain.

Note: Sybill Attack is not possible as we are using SHA256 i.e. size of sample space is 2^256 which is approximately the total number of atoms in the observable universe. So Guessing or saving common files is useless and the probability of collision is practically zero until the files are copied.

How we built it

Assumption: Commits only make sense when files are added after the time when the contract is deployed. Else, a central body will be required to resolve disputes in older file ownership.

We deployed the contract on the Stacks blockchain such that it manages all the commits and makes it easy to integrate with the front end. Used React & Redux along with Stacks.js and API to get all the essential things done. Also, calculating hashes using the native web crypto API. All the relevant links are shared.

Challenges we ran into

  • Learning a completely new language i.e. clarity and understanding, of how to use it for our project.
  • Reading so many docs from so many places, to understand that we are doing it right.
  • Getting the right thing from the front end and integrating the whole project.
  • Lastly, each team member works remotely.

Accomplishments that we're proud of

Just uploading each file hash would have been enough, but that would be a waste of storage on the blockchain as well as it will reveal the contents publically as blockchain storage is public. We used the Merkle tree data structure to cut it down to just one hash for each commit. Not only that, we made a commit chain, just like blockchain in which the last Merkle-root/block contains proof of all the files of one user. Integrating everything was difficult for us as we all are still undergrads.

What we learned

  • How to work with a no-loops environment i.e. clarity of language.
  • Working concepts of stacks blockchain, like proof of transfer, stacking, etc, and its link with Bitcoin.
  • What blockchains can be used for and what to store on-chain and off-chain.
  • Time management during hackathons and that integration take time.

Make it simple, make it work!

What's next for Filechain

  • Addition of a decentralized database to remove the name and other irrelevant metadata.
  • Addition of multi-sig as work/research might be done by two people.
  • AAddition of Merkle path proof, so one proves the file's existence in just a few kilo-bytes, anywhere and to anyone in the world.
  • Addition of a folder-like system i.e. each account can have multiple commit accounts.
  • Addition of time-locked proofs for whatsoever reason.
  • Improving UI and some UX changes like making an all-commits page not just in verify, sorting commits on the basis of the number of files, etc.

Note: Please use a Chromium-based browser, as a few things might glitch in Firefox.

Share this project:

Updates