-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ERC930 - Eternal Storage Standard #930
Comments
It's an interesting way of solving a problem many are trying to solve. |
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 :) |
@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 :) |
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 |
Is it necessary for this to be an EIP? It seems like it could just be a software library. |
@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. |
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? |
@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. |
This smells like an antipatern |
@fulldecent why? |
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. |
@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. |
@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 ( Would love to get your input on this topic. |
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. |
I would specifically identify the storage requirements for that contract and handle the use case as it arrived.
ERC-721 is perhaps the most thoroughly reviewed ERC in modern history. A specific goal of 721 was to identify ALL potential uses cases up front. In all of this discussion I have never heard a use case that required off-the-shelf backend storage as ERC-930 is proposing. And to be sure, 721 was reviewed at four different Ethereum conferences and we had a 4-day discussion just for latin etymology and naming. |
@trigun0x2 Ive been thinking about having something like that and also about using RBAC, I think in this case using RBAC is the best option for the same reason @shrugs mentioned, this storage contract is useful for upgradeability purposes and I saw the necessity on having a storage like this while I was working on token proxy and upgradeability. |
@fulldecent I understand what you mean, I was looking for something more standarized to not work over different storage requirements for every smart contract, I think that using an storage like these fulfill more of the storage requirements of smart contracts. There is some cases maybe most of them where you dont even need something like this, but in my case where Im working on a set of different contracts using token proxy upgrade ability this is the best thing I came up with to use as storage for our contracts. |
I must agree with @fulldecent on this. I can't imagine situation where I need generic data storage because Ethereum's smart contract itself is generic data storage, thus when I want to upgrade for example ERC20 contract it usually requires upgrade of logic(adding new implementation to proxy, etc.) but not the change of storage. @AugustoL Can you extend the Motivation section with more detail description of situation(s) where you need such kind of contract proposed in EIP930 and what would be the tradeoffs against proxy pattern? |
Is there any reason you are taking a bytes32 for every get/set function? Why not just have the contract perform the IE function getString(string h) public view returns (string){
return _storage._string[keccak256(h)];
} |
To give some more context on the above, it seems like it would be error prone to force the client to use a keccak256 compliant function to get the correct hash when retrieving or setting storage with 32 bytes. It assumes all clients interacting with the contract are using something like Is there some other oddity I am missing, maybe something to do with the variant type sizes (uint8/16/...256)? In addition, Im also running into some collision issues in this type of implementation (see: https://medium.com/nomic-labs-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) . Basically, if I use this pattern, inside of something like this , and then declare a |
Hi @AugustoL,
Thanks! |
@RealDeanZhao Two different string having the same hash is quite improbable (almost impossible). |
@ondratra So why not use the string as the key directly, it will be much simpler for the code. Are there any other considerations? Is it because solidity cannot concat a string, it will be simpler to use keccak256 to build any hash key. |
@RealDeanZhao I think that it creates an opportunity for optimization. If you write |
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
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.
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.
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.
Methods
owner
Returns the owner address of the ES.
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 thehash
h
.The function SHOULD
revert
if themsg.sender
is not the owner.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.Events
OwnershipTransfered
Triggered when the ownership of the contract change.
Implementations
Revisions
Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: