5

I have reviewed some techniques around Upgradeable smart contracts from starting point(Elena Dimitrova's Eternal Storage) to zeppelinOS's Unstructured Storage pattern. As I understood from posts that I have read, there is no secure&best pattern. Instead, the technique can vary dependent to your dApp design and business model. As far, most of the community thinks that zeppelinOS's approach is state of art.

I have a pain point on determining the strategy and ask for help to clarify my mind. In assumed scenario, I am required to hold identities of citizens for government on public ethereum chain. I have deployed a contract with following structure:

Contract CitizenController{
    ...    
    struct Person{
        bytes name;
        uint birthDate;
        bool gender;
    }

    mapping (address => Person) people;
    ...
}

And the government suddenly made a new regulation that forbids holding gender publicly available data. And also they made storing irisInfo mandatory on publicly available data. Therefore, I am required to modify my struct to :

struct Person{
    bytes name;
    uint birthDate;
    bytes irisInfo;
}

I would not require gender any more and must store irisInfo in smart contract. In my comprehension, it can be achieved using Eternal Storage as the data is stored as KeyValue Pairs. Still, I can not say that it is not possible using Proxy Contracts.

In summary, is it possible to modify struct(add/delete field) in upgradeable proxy contracts ? If that is the case, could you provide a sample code like above ? If not, do you think that it would be possible soon ?

PS: I am open to reading suggestions about upgradeable smart contracts or rabbit holes of solidity

1 Answer 1

2

tl;dr the upgradeable part is the library which only contains logic, not storage. Only editing

You can't do that since the interface in which you define your struct is linked to the storage contract on creation. This logic is designed to be able to make modifications in the library to existing functions, generally.

Nontheless deleting the struct wouldn't do anything. You can just leave it blank for new entries. What you're asking is deleting information in the storage contract, which is possible by editing a function (with it's old name) in the library to set it to null, redeploy the library and link it. But even then the history of setting the value in the first place would still be available.

It's not a good idea to store personal data on chain, especially not unencrypted. If it's encrypted you could still burn the keys for example.

Therefore we say blockchains are CRAB and not CRUD. Create, Read, Append, Burn.

This is possible however:

  • Add logic to the library and redeploy it
  • Update the address in the proxy (in my architecture that's done by setting the new address in the contract registry)
  • write a second interface for it and a second storage contract
  • Bind the second interface to the original proxy and link it to the second storage contract
  • Deploy the second storage contract

I added some stuff to their approach.

It adds a little bit of overhead due to adding a registry but gives more transparancy and a better overview, especially if you are developing on private chains.

https://github.com/kyriediculous/did-poc

2
  • First, I am not developing on private chains. Your repository seems like having a good architecture and design patterns. I will review your code to have a deep comprehension, but I did not understand whether your contracts answer my question above or not . Can you point it out as a comment ? Commented Jul 24, 2018 at 19:13
  • I edited my answer, I hope it suffices. Commented Jul 24, 2018 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.