Backend

Storing Images

Instead of storing images on-chain, we decided to hash the image data, break images up into 20x20 pixel sections and store references to this information in a simple Mysql database instance.

We were hoping to use the md5 hashing for image verification, however, we were forced to crop, flatten alpha channels, and add meta data to the md5 — so our md5 is now simply an internal UUID. Fortunately, this is still verifiable by hitting our image CDN endpoint and comparing it to the data in the contract, since the contract data is only mutable via the original owner.

Building the map

The IPO map builder has two main goals :

Reduce the number of times image files are loaded from disk to reduce load on the NFS servers. Be capable of handling multiple uploads of the same image (image collisions) with different hover text and links.

Currently, one processing daemon generates a new map approximately once every 2 minutes, this reduces load on the CDN, processing servers, and client storage while still providing users with visible results in a reasonable amount of time.

The full map begins as a blank 2000 by 2000 pixel Bitmap and PNG stored on an NFS server within the datacenter to be served by the CDN. The map file is stored with the map ID (the block number at time of generation) within its filename so they can be fetched without having to browse the entire directory. Bitmap prevents any image loss based on future compression and PNG reduces load on the CDN and end user devices.

Meta data such as hover text and link text are stored in a JSON file with the same ID as the map image so the frontend can infer the filename without having direct access to the storage. This meta data includes a mapping between section number and its meta data to assist the frontend in building the overlay grid and drawing hover tool tips without having to query the blockchain. This reduces network load on users with high latency or low bandwidth connections. Before a purchase, chain data is used as the authoritative source via web3 rather than the metadata file in order to reduce the chances of a double spend attempt due to latency in the building of the meta data file.

Building the IPO Map