Inspiration:

A drought of trust and truth plagues our civil society and personal lives, and we see its effects every day. Without a universally-trustable means to verify facts, we tend to listen only to the propositions that already agree with our worldview--leaving us without a shared foundation to build upon. We were motivated to solve this challenge of proving the truth in a world where falsities and misinformation are becoming ever-easier to concoct. After some consideration, we settled on tackling the specific issue of ensuring trust in images. With the rapid development and quality of deepfakes, images will likely act as a prime source of disinformation in the years ahead.

How we built it:

We translated our original Node.js backend to Django and built our blockchain in Python, which we then unified with a React frontend to upload files and receive responses from our server.

What it does:

We thought that blockchain was an ideal candidate for implementing a solution to this problem, since it provides a basis for trust in decentralized, peer-to-peer networks. With some deliberation, we landed on the idea of using a blockchain to keep a record of original media content, so that tampering, deepfakes, and edited/photoshopped files can be easily spotted.

Journalists or other users who want to prove that their original photos are unedited/untampered/not-deepfaked can add their images to our service, which we named TrustChain. Information about those images are stored as new blocks in a blockchain. This means that this information cannot easily be tampered with and some level of trust is guaranteed.

Citizens who aren’t sure whether a certain image is trustworthy (e.g. they suspect the image might be edited, deepfaked, etc.) can check that image against our blockchain. Based on what images other users have already put into TrustChain, we’ll return a list of similar images that already exist as blocks within our blockchain, along with their hashes and timestamps. A citizen can then review this log of information, comparing their suspicious image with a history of similar images that we provide. The original unedited image would be recorded on the blockchain first, so if users’ image matches the image in our system that comes first chronologically, the user can be confident that the image is trustworthy.

Let’s look at how exactly we can identify similar images within the blockchain. After a user chooses to put an image into the blockchain, we then store a record of that image and a timestamp as a new block in our blockchain. We also store two hashes of the image in the block.

The first of the two hashes we store can be thought of as a “general” hash. Without going into too much detail of how it is generated, this “general” hash is identical or very similar for images which are similar to one another. It essentially places similar images into similar hash buckets, so we have a concise way of determining whether two images are similar.

The second hash amplifies minute differences between images, so we can quickly tell if there are small differences between the two files. Even if two images differ only by a single pixel their second hashes will be different from each other.

These two types of hashes allow us to compare uploaded images with images already in our blockchain, providing the basis for the comparison functionality described above.

What we learned:

We learned a lot about the feasibility of different hacks in our ideation process, and about the technical promises and limitations of hashing as we were building our blockchain.

We also each chose tasks that allowed us to learn a new tech stack or skill set, and we traded knowledge on our individual areas of proficiency.

Challenges:

Most of the challenges we faced had to do with learning new technologies. Every single team member had to work with frameworks, concepts, and languages that they hadn’t ever used before. It was difficult to take our new knowledge and put it to use, but ultimately that’s what makes hackathons fun in the first place.

Our biggest challenge, though, was the innate need for food and sleep. We wish we didn’t need rest and could add a couple more features to TrustChain, but unfortunately, we’re only human.

Where we take it from here:

In the future, we plan to make TrustChain truly peer-to-peer. This means that TrustChain users around the world would have their own copies of the blockchain that they can independently verify. All this adds an additional layer of trust because users will no longer have to rely on a single, centralized blockchain where all records are stored. There will no longer be a single point of failure.

Share this project:

Updates