ERC930 - Eternal Storage Standard

[AugustoL]

EIP: 930
Title: ERC930 Eternal Storage
Author: Augusto Lemble <me@augustolemble.com>
Type: Contract Standard
Category: ERC
Status: Draft
Created: 2018-03-15

Simple Summary

This contract provides the necessary logic to store any type of data in a smart contract using it as a storage.

Abstract

The ES (Eternal Storage) contract is owned by an address that have write permissions. The storage is public, which means everyone has read permissions.
It store the data on mappings, using one mapping per type of variable.
The use of this contract allows the developer to migrate the storage easily to another contract if needed.

// Using contract storage
string myName = "Vitalik"; 

// Using Eternal Storage
s.getString(keccak256("myName")) = "Vitalik";

Motivation

There is some implementations of Eternal Storage contracts already done and being used but there is not some consensus over it. Storage is one of the most important parts of smart contracts development and using this contract will allow developers to use a standardized version of ES and therefore have safer contracts and also use this standard with another that define only certain logic and behavior over a contract, for example: An ERC20 token can use the contract or eternal storage it wont affect the standard since the only thing that changes is the write/read operations used inside the functions.

Specification

EternalStorage

Note The nomenclature used for the functions and variables was tried to be as short as possible, since we don't want to have to use +30 more characters per line to assign an uint.

• s == storage
• h == hash
• v == value

Storage

The storage of the contract is kept in a internal variable, it is also an struct with a set of mappings, one per each variable type.

  struct Storage {
    mapping(bytes32 => bool) _bool;
    mapping(bytes32 => int) _int;
    mapping(bytes32 => uint) _uint;
    mapping(bytes32 => string) _string;
    mapping(bytes32 => address) _address;
    mapping(bytes32 => bytes) _bytes;
  }

  Storage internal s;

Methods

owner

Returns the owner address of the ES.

function owner() constant returns (address owner)

SET methods

Execute a write operation over the storage, it can only be called by the ES
owner. It will write the value v over the boolean value identified with the
hash h.

The function SHOULD revert if the msg.sender is not the owner.

  function setBoolean(bytes32 h, bool v) public onlyOwner {
    s._bool[h] = v;
  }
  function setInt(bytes32 h, int v) public onlyOwner {
    s._int[h] = v;
  }
  function setUint(bytes32 h, uint256 v) public onlyOwner {
    s._uint[h] = v;
  }
  function setAddress(bytes32 h, address v) public onlyOwner {
    s._address[h] = v;
  }
  function setString(bytes32 h, string v) public onlyOwner {
    s._string[h] = v;
  }
  function setBytes(bytes32 h, bytes v) public onlyOwner {
    s._bytes[h] = v;
  }

GET methods

Execute a read operation over the storage. It receives the hash identifier h of the variable stored and it returns the value of it.

function getBoolean(bytes32 h) public view returns (bool){
  return s._bool[h];
}
function getInt(bytes32 h) public view returns (int){
  return s._int[h];
}
function getUint(bytes32 h) public view returns (uint256){
  return s._uint[h];
}
function getAddress(bytes32 h) public view returns (address){
  return s._address[h];
}
function getString(bytes32 h) public view returns (string){
  return s._string[h];
}
function getBytes(bytes32 h) public view returns (bytes){
  return s._bytes[h];
}

Events

OwnershipTransfered

Triggered when the ownership of the contract change.

event OwnershipTransfered(address indexed previousOwner, address indexed newOwner);

Implementations

• Basic Token example using Eternal Storage

Revisions

• 2018/03/15: Initial Draft

Copyright

Copyright and related rights waived via CC0

[VoR0220]

It's an interesting way of solving a problem many are trying to solve.

[AugustoL]

I have to add a section about gas costs, hopefully I will be able to add it soon, anyone that wants to collaborate on this send me an email to me@augustolemble.com :)

[AugustoL]

@VoR0220 yes right? I think it is going to be used a lot whit the use of proxys for upgradeability and it will be great to have consensus over the use of it :)

[VoR0220]

Well here's what would be the way to better define that would be through a template or a generic type which I believe is already in the works, but fleshing that out would enable this in a very simplistic way. All you would need to do is take an index of templateKey and resolve it to field of templateStore which would be interpreted at runtime. This will definitely be going in the "dangerous" category as it requires low level assembly but that's what I'm thinking from a compiler definition. @chriseth @axic what do you think?

[Arachnid]

Is it necessary for this to be an EIP? It seems like it could just be a software library.

[AugustoL]

@Arachnid It is not an EIP, it is a Ethereum Request for Comments . We would use this in our smart contracts and I think more projects will use it too. So this is just to kickstart the discussion about a contract standard that we can use.
Since the ERCs are posted here thats why I submitted it here 🤓

[Arachnid]

ERCs are a subset of EIPs. Either way, my question stands - since you're looking at one particular implementation, rather than an interface multiple contracts will implement, what's the need for an EIP/ERC?

[AugustoL]

@Arachnid Im not looking for a particular implementation, Im looking to discuss how the interface of a smart contract with only storage purposes will be, we have ERCs with standards for tokens and proxies but there is none for a storage contract.
II think it is needed because some smart contracts will need it and is better if we all use the same standard for it.

[fulldecent]

This smells like an antipatern

[AugustoL]

@fulldecent why?

[fulldecent]

We already have bytes4 function selectors to query any arbitrary type.

Also the set of types is arbitrarily small. The built in types are much richer and composible.

If dynamic naming is required at runtime then applications will want to explain why by using a name.

I can't think of any application where storing random numbers, identifying them by name, and those names having no context, being useful.

[AugustoL]

@fulldecent thx for the reply, you are right about dynamic naming and that the set of types are very limited. I imagine this being used in contracts with a simple storage like ERC20-721-827 tokens where you would be able to reuse the same storage in another contracts.
I can't think of any application where storing random numbers, identifying them by name, and those names having no context, being useful. I wouldnt describe it that way, but it is useful if you need to export the storage to another contract and have control over it. How would you do it?

[trigun0x2]

@AugustoL I've put some thought into this topic before and I've never been sure about what layer to authenticate the user.

My thought was to have an array of whitelisted contracts that are able to interact with the ES then do the authentication (onlyOwner, onlyCOO) in the smart contract using the ES.

Would love to get your input on this topic.

[shrugs]

re: owner; If you need more comprehensive access control, you could compose this function with an RBAC-backed proxy that lets you have multiple different access layers and logics.

This sort of approach is basically necessary for contract upgradability. You can see various approaches attempted in https://github.com/zeppelinos/labs as well as some articles about the different approaches for eternal and unstructured storages (with a comprehensive overview of the various pros/cons and implementations coming from Elena in the near future).

I have no opinion on whether or not it fits within the ERC/EIP scope, but I very much support a standard interface for these getters and setters.