[Active] AEyeWitness: A Proof-of-Concept for Immutable Image Storage on a Blockchain

This is the mandatory structure for a grand application template. Please copy it and make it yours.
Please note that this template ist mandatory for the grant application in order to be reviewed by the AF bord.

Application Status

Status: Approved on the 12.10.2022, submitted on the 27.09.2022
Last updated: 27.09.2022
Submited by Pavel Laskov, [email protected]
**Team: crypto.aLIEns, @laskov, @nikitina, @IKolopatin **
Approved Budget (in h):
Used Budget (in h):
Planned Delivery: 7-8 months from the start of the project

Specify the funding category

Research and Education

Application Title

Project Title



Please include a link of your introduction and your team to the Forum.

Value Application

What will become better and why? Why is your work beneficial for the aeternity ecosystem? (Please describe the impact of your project. How will your work impact the larger aeternity ecosystem? How does a successful contribution of your project look like?)

The main idea of the project is to develop a proof-of-concept application for storing images and their metadata on a hyperchain. Since all such data is immutable, such an application can guarantee that an certain image is taken at certain time and place. For the proof-of-concept, we will assume that no manipulation can take place between the camera and the application; resistance against such manipulation is subject of further research.

The project will address primarily the functionality and the scalability of the image storage application. If the feasibility of such application is confirmed, the project can demonstrate a novel use case for the aeternity hyperchain with a broad a diverse community, e.g., law enforcement organizations, journalists and other stakeholders for whom immutability of images and their metadata plays a crucial role.

Definition of Terms

What exactly are we talking about? Please describe your project.

The PoC will comprise two main components to be implemented as progressive web applications. Using the first app, a user can take a picture on a suitable device and upload this picture, as well as all relevant metadata (e.g., GPS coordinate, orientation, etc.), onto a hyperchain. Using the second application, any user can retrieve the picture from the hyperchain and verify its authenticity and immutability. In addition to the core functionality, a management backend responsible for user account management, image storage management (e.g., separation of various “pools” of images, image deletion, etc.) and other related tasks would need to be developed at some point in future.

Status Quo

What is now?

The proposed PoC would be the first implementation of a secure image storage on a blockchain. Alternative approaches for image certification involve trusted third parties (e.g., for secure timestamping) and incur substantial costs. For example, the CertiPhoto app charges 50c/image and has processed approximately 1.400 images/day since 2016.

Required Work

Steps to get to the goal…
Please list milestones and deliverables of your project.

The project will comprise the following steps:

  1. Study of the hyperchain API and setup of the development environment (1-1.5 months). The general architecture of the proposed applications will be designed and the respective infrastructure (nodes, wallets) set up.

  2. Development of the image storage app (2-2.5 months). The image storage app will connect the standard camera and sensor API for mobile devices with the hyperchain API to immediately transfer obtained images into the hyperchain.

  3. Development of the image retrieval app (1 month). The image retrieval app will enable users to retrieve specified images and to verify their integrity.

  4. Development of a simple management backend (1 month). The management backend will enable users to gain access to the image storage and retrieval functionality and perform simple operations on their content, e.g., image deletion.

  5. Verification of results (1 month). A user study with a group of students using the developed applications will be carried out. Concurrently, a stress-test of the scalability of the developed applications will be performed using bot-like artificial accounts.

  6. Analysis of results and project wrap-up (1 month).


Your time estimate in hours for the Project. Please do not put here Prices!
Please list the estimated timeline by milestones and releases of your project.

The above mentioned project plan will be implemented by a team of two students working on the project approximately 30-35% of their time.

Known Limitations

Will everything work as expected to solve the original problem?

The proposed PoC does not yet guarantee the security of the full path for an image to travel from the camera into the blockchain. In particular it does not address the security requirements for endpoint devices on which pictures are to be taken. These considerations should be addressed after the utility for image storage is demonstrated. Obviously, the proposed application also does not guarantee the authenticity of images taken by endpoint devices, e.g., it cannot ensure the authenticity of a document the picture of which is taken.


What happens after this project is completed?

Do you plan to populate your project? (For example creating a micro-web-page, social media updates, blog-posts, video-materials.)

The exact form of the dissemination of the project results depends on the outcome and is yet to be decided. If the feasibility of the proposed application is verified and the security of the full data path can be guaranteed, appropriate mechanisms for rolling out the developed applications and building the respective community (or communities) will be considered.


Please confirm that your research and development will be published free of any proprietary license (open-source, open-access). Please provide a link to the GitHub repository of your open source project.

The PoC applications as well as the code for reproduction of experimental results will be available as open source.


Please confirm that your research and development code will be maintained with bug fixing and new updates free of charge for at least one year after publishing it.

The PoC applications will be maintained for one year after their publishment.


Dear @laskov, thank you very much for the AEyeWitness application. Nice to see a useful use case for hyperchains.


This seems like a useful idea… just the PoC will be difficult, I think.

The most challenging part it seems will be proving an image was taken at a particular GPS location. Unless the imaging hardware itself has some built-in means to prove this… it seems like this is prone to GPS spoofing - not sure that is the correct name for that, but it seems like it is self-explanatory.

If that issue is real and there is no existing hardware solution. It seems that, for this project, a hardware solution will also be required.

What are your thoughts on that?

1 Like

Hi ,I have some questions, if store img in hychain; Will the hc node be very large; as the number of pictures increases

Dear @_dog and @charles,

Thanks for your questions about our idea. We are aware that data may be manipulated on its way from hardware to the app. At the moment it is not clear how this can happen and how to prevent such manipulation. In the worst case, one would need to have tamper-resistant hardware to prevent this. As I mentioned in our proposal, this issue will be investigated in more detail later, once the base functionality of the app is tested assuming honest users.

Regarding the node size, we have not yet looked into this issue. I agree that it is infeasible to keep all data at every node. Presumably, the data should be split across a large number of hyperchains that would need to be somehow linked together.


Perhaps, game theory the users with some kinda of consensus mechanism and things like financial costs for acting badly. If publishers of images have an incentive to earn for posting images, they should be willing to lock in some coin as collateral for acting properly. When/how it is released needs to be thought out though.

It wasn’t my point. But about storing images on nodes… perhaps, publishers could upload to some set of central or public sources… and what you actually store is the hash of the image on the node or blockchain… and not the images themselves. Something like that… Maybe?

Well, storing images somewhere else and keeping their hashes in a blockchain was actually the first idea we had. I don’t think this would work. Suppose an attacker compromises the storage and deletes an image he or she does not like. The hash will be intact but it won’t be useful anymore. Not only do we have to protect the integrity of the graphical evidence but its intactness as well. Hence distributed storage is IMHO essential for the “witness” functionality.


Dear @laskov, thanks for your application on hyperchains. The AEyeWitness Application is approved by AF.


@laskov what is the planned incentive to store the images or is that even relevant in this scenario as nodes are “forced” to keep all images? we were shortly discussing that recently and wondering about how storage and filesharing could be incentivized in a meaningful way. probably not every participant would want to store all files.

how does the proposal relate to / differentiate from solutions like IPFS & Filecoin? or is it “only” about preventing data manipulation?

I need to admit that I didn’t closely follow the BitTorrent/Tron and IPFS/Filecoin projects. but I’d be interested in if this worked out and maybe we could come up with an even better solution to that problem.

1 Like

Our idea is similar to the Filecoin but there are some important differences:

  1. The storage infrastructure should be homogeneous. It should not comprise independent storage providers all negotiating different deals with storage requestors. Instead, a storage node should be an entity providing some backbone storage for a fixed fee. Whether the nodes should be owned by a single “operator” or by independent providers remains to be clarified. But they should all play by the same rules which should lead to a simpler protocol.

  2. From the security standpoint, the threat model should be primarily focused on data integrity. It should be prevented that some data stored in the network is manipulated or deleted. In Filecoin, AFAIK, the storage contract can be broken by the provider at the expense of forfeiting its fee. For our use case, data stored in the network should be immutable. It should be kept for a prescribed time interval and it can only be removed upon a legitimate request of its creator / owner.

  3. Another issue is timestamping. The time at which the data is stored should be recorded and verified in the network, in contrast to trusted time service used in conventional applications. Ideally, other metadata, e.g., GPS location, should be verified but I do not see at the moment how this can be achieved. Perhaps some ideas could be borrowed from logistics use cases whose goal is to verifiably determine the location of goods at arbitrary time points. In this way, the location of a client taking pictures should be verifiable at any time.

1 Like

Hi all,

Time went by and our idea gradually took its current shape. We are happy to announce its final design and implementation. You can find our code at:

and the high-level explanation of our design and use-case in the following document.

AEyeWitness_HLD.pdf (735.8 KB)

Looking forward to your feedback!

The CryptoaLIEns.