I'm ramping up on learning Solidity, and have some ideas. At the moment I am curious if files/images can be put on the blockchain. I'm thinking an alternative would be some hybrid approach where some stuff is on the blockchain, and some stuff is in a more traditional file storage and uses address references to grab it. One issue I foresee is gas price of file uploads.
Is it possible to store images on the Ethereum blockchain?
It's absolutely possible!
Should you do it? Almost certainly not!
One issue I foresee is gas price of file uploads.
- The cost of data storage is 640k gas per kilobyte of data.
- The current gas price is approximately 15 Gwei (or 0.000000015 ETH).
- At today's price, 1 ETH is approximately $200.
That works out at just under $2 per kilobyte.
It's not for me to tell you if this is too expensive for your application, but you should also consider that the price of both Gas and Ether vary dramatically over time, and you should expect to experience periods when this number will be significantly higher.
Note: I tried to store that +10,000 long base64 string of a 100kb image, but it did't accept. but when i tried 1kb image, it worked.
yes. This is the solidity code to do it:-
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;
contract ImgStorage {
uint i=0;
mapping(uint => string[]) public base64_images;
function push(string memory base64_img) public {
base64_images[i].push(base64_img);
i++;
}
function returnImage(uint n) public view returns(string[] memory){
return base64_images[n];
}
}
You can convert image to base64 and vise versa online. Here is NodeJS code to convert image to base64 string:
const imageToBase64 = require('image-to-base64');
const fs=require('fs')
imageToBase64("img/1kb.png")
.then(data => {fs.writeFile('1kb_png.md',data, (err)=>{console.log(err)})})
.catch(err =>console.log(err))
I totally agree with @Peter Hall that storing the image on ethereum is too costly.
So, what you can do instead of this?
- You can store the image on IPFS. IPFS gives you a fixed length of a hash. Now, you can store this hash on Ethereum and it cost less than another way.
Technically, yes, you could store very small images. But you shouldn't.
Preferred Alternative
Store the image in a distributed file store (for example, Swarm or IPFS), and store a hash of the image on-chain, if it's really important for the image to provably untampered. If that's not important, then maybe don't put anything on chain.
What technical limit is there?
Primarily, the block's gas limit. Currently, Ethereum mainnet has an 8Mgas block limit. Every new 32bytes of storage uses 20k gas. So you can't store data that sums to more than 12.8kb, because it doesn't fit in the block.
Why shouldn't I use it for small files?
The blockchain wasn't designed for that usage (which is why other projects like Swarm and IPFS exist). It bloats and slows everything down, without providing you any benefit over other file storage systems. By analogy, you typically don't store files in a SQL database, either.
You can store images on Ethereum blockchain, but it is too expensive because of "blockspace premium" of high quality blockchain.
Other, more affordable decentralised storage solutions include
- Chia
- Filecoin (where Filecoin VM smart contracts can manipulate files)
- Arweave
- Storj
Storing images on-chain is an emphatic NO!
Storing images in a database is also not a good practice, I'm assuming you just mean file storage solutions like S3 / firebase. Storing images on a central server is okay but it depends what you want to achieve, there are decentralized storage solutions like IPFS and Swarm that you could look into.
Ethereum is too heavy as well as expensive to store large blobs like images, video, and so on. Hence, some external storage is necessary to store bigger objects. This is where the Interplanetary File System (IPFS) comes into the picture. The Ethereum Dapp can hold a small amount of data, whereas for saving anything more or bigger such as images, words, PDF files, and so on, we use IPFS.
IPFS is an open-source protocol and network designed to create a peer-to-peer method of storing and sharing data. It is similar to Bit Torrent.
If you want to upload a PDF, Word, or image file to IPFS.
1- You put the PDF, Word, or image file in your working directory.
2- You inform IPFS to add this file, which generates a hash of the file. Note an IPFS hash always starts with “Qm....”
3- Your file is available on the IPFS network.
Now you uploaded the file and want to share the file with Bob. you send the hash of the file to Bob, Bob uses the hash and calls IPFS for the file. The file is now downloaded at Bob’s end. The issue here is that anyone who can get access to the hash will also be able to get access to the file.
Sharing Data on IPFS by Asymmetric Cryptography
Let' say you uploaded a file to IPFS and you want to share it only with Bob.
Bob will send you a public key. you will encrypt the file with Bob's public key and then upload it to IPFS network.
You send the hash of the file to Bob. Bob uses this hash and gets the file.
Bob decrypts the file using his private key of the public key that was used to encrypt the file.
In Asymmetric Cryptography, public keys are generated by the private key and if you lock something with a public key, the only key that will unlock that thing is the private key that the given public key is generated from.
The better way of dealing with files on the blockchain is to use some sort of file storage services like AWS-S3, IPFS, Swarm, etc.
You can upload the files to one of the above file storage servers and generate the hash key(Which is used to access the file), and keep this key in the blockchain.
The advantages of using this method are -
- Low-cost solution
- Easy and fast access to files using file storage searching algorithms
- Lightweight
- Flexibility to move from blockchain to DB or vice-a-versa
- If the file storage system has good security from tampering, then be assured as these files will not be accessed without the right hash key
- Easy to perform migration of file storage from one service to another
© 2022 - 2024 — McMap. All rights reserved.