Using Ethereum as a Decentralized Archive

Ethereum is a powerful computer which uses the blockchain for processing and storing information in a decentralized way. Applications, known as smart contracts, are executed on the blockchain and the cost of interacting with these applications is baked into the price.

Ethereum may not be the only decentralized computer but it is the most well known. While it is mainly used for creating and managing digital currencies known as tokens now, decentralized applications or dApps can be developed for all kinds of purposes from voting and ballots to shared property ownership to trading. Whatever requires an immutability and openness can easily be managed by Ethereum.

What if academic information published by a university or public institution could be stored forever, without change, on the Ethereum blockchain? Below we explore the beginnings of a smart contract which could be used to replace existing, centralized mechanisms in a public and immutable way.

The Item Smart Contract

Let’s imagine we want to store a digital asset along with its metadata. We’re going to make some assumptions here:

1. The asset will be stored on some kind of 3rd party system, perhaps a decentralized system such as IPFS or Storj.io. The stored asset will be identified by a hash,

2. We need to store some additional metadata against the file (or file hash), which will further describe the asset being stored. The metadata will be a simple list of name/value pairs and a metadata field can have a name with multiple values,

3. Each archived item will be stored as a single transaction on the blockchain (we could instead have an archive which stores multiple items but this could be explored at a later time).

In its simplest form, the contract might look like:

pragma solidity ^0.4.21;

contract Item {
    Field[] fields;
    string fileHash;
    
    struct Field {
        string name;
        string value;
    }
    
    mapping (uint => Field) metadata;
    
    function Item(string _fileHash) public {
        fileHash = _fileHash;
    }
    
    function addField(string _name, string _value) public {
        Field memory field = Field(_name, _value);
        fields.push(field);
        metadata[fields.length -1] = field;
    }
    
    function getFieldCount() public view returns (uint)
    {
        return fields.length;
    }

    function getFieldName(uint8 _id) public view returns (string) {
        return fields[_id].name;
    }
    
    function getFieldValue(uint8 _id) public view returns (string) {
        return fields[_id].value;
    }
    
    function findFieldValueByName(string _name) public view returns (string) {
        string memory value;
        
        for (uint i = 0; i < fields.length; i++) {
            if (keccak256(fields[i].name) == keccak256(_name)) {
                value = fields[i].value;
            }
        }
        
        return value;
    }
    
    function getFileHash() public view returns (string) {
        return fileHash;
    }
}

So what is this contract trying to do? Firstly we have a contract called Item which encompasses a single archived item being stored on the Ethereum blockchain.

contract Item {
}

We initialize the contract with a single file hash:

function Item(string fileHash) public

As outlined earlier, this could be an IPFS hash for example (which would keep within the spirit of a completely decentralized archive).

Our metadata is stored as a hash map of field structs, with each struct holding a name/value pair.

struct Field {
    string name;
    string value;
}

mapping (uint => Field) metadata;

The method addField will allow us to push metadata into the Item, allowing us to describe the asset in more details.

The methods getFieldCount, getFieldName, getFieldName and getFieldValue allow us to directly interact with each field name/value pair, allowing any interaction with the smart contract to loop over the metadata and retrieve all name/value pairs.

The method findFieldValueByName allows us to retrieve a field value by it’s name (there is one caveat with the current implementation; see if you can spot it).

Lastly, we have a way of retrieving the fileHash using getFileHash.

Taking It Further

This is a very simple example of archiving an asset and associated metadata to the Ethereum blockchain but it starts a nice discussion around utilizing blockchain technology as an archival mechanism.

There are obviously a number of improvements which can be made to the above smart contract, some might include:

– Assigning an owner to the contract and only allowing the owner to add metadata,

– Facilitating a change of ownership, and possibly integrating a financial incentive for transferring ownership to a new party,

– Controlling usage of the metadata and asset and perhaps even collecting a small fee for usage by 3rd parties.

Additionally, other blockchain technologies could be integrated to assist with identification and ownership. For example, using a blockchain-based identity to verify the author, or using a licensing ledger such as Po.et to manage copyright of the asset.

This small example gives an insight into the power of not just Ethereum but also smart contract-based blockchain technologies in general. Blockchains such as Ethereum will fundamentally shift the way we think about archiving, as we move from tranditional, centralized systems to decentralized and democratized information ecosystems.

This code is available on Github. The code currently compiles and works. It was developed on Remix a powerful, browser-based IDE.