Compare OpenZeppelin SDK with ERC930/ERC1504

We want to upgrade business rules contracts but keep the same data. We separated data and business rules in different contracts. We created a solution to store data based on ERC930/ERC1504. It seems nice but we want to compare it with your approach.
Have you consider this approach any time during your discussions in OZ?
@ylv-io, would you mind to talk with us? @nventuro? Anyone else?

1 Like

Hi @Suzana_Maranhao

OpenZeppelin SDK uses the “unstructured storage” proxy pattern.
A big advantage of this approach is that little modification is required to make contracts upgradeable.

The following articles contain more background, including some of the alternatives considered:

Dear Andrew,

Thank you for your reply and all your help.
I agree with you that OpenZeppelin approach require few modifications. On the other hand, there are some limitations related on what you can do when upgrading data.
I loved your solution to upgrade business logic, but I still evaluating a different option related to upgrade data.
I coded an example to you. Hope you can have time to consider it. The files are save on:

  • Storage.sol -> a generic storage class
  • LegalEntityMapping -> a mapping between my original data structure and the real way it is stored using the generic storage.
    Original variable: mapping(address => LegalEntityInfo) public legalEntitiesInfo;
  • BNDESRegistry -> a contract to check business rules (I think it will be very useful to use openzeppelin upgrade in this class)
  • BNDESFactory -> a contract to create others and to help to upgrade the mappings (if necessary)

What do you think? If you like it, maybe you could consider to incorporate this solution in OpenZeppelin :slight_smile:

1 Like

Hi @Suzana_Maranhao

Thanks for sharing the code.

I am still fairly new to upgradeable contracts, so I am interested to understand what can be done with this mechanism that can’t be done with the “unstructured storage” proxy pattern (OpenZeppelin SDK).

Hello @Suzana_Maranhao! I took a look at your code- it’s very nice! I’ve played around with similar ideas, in particular for a passion hackthon project of my own.
(Have a look:

I am a big fan of making all the pieces of the contract modular, so that we can rebuild the parts as necessary. I noticed though that your contracts themselves do not look like they are designed to be upgradable? Also I would be curious to know more about what you are thinking for “upgrading data”. Do you mean updating the data, or adding new interfaces to the data?


1 Like

Hello @abcoathup and @Dennison_Bertram ,

I think both patterns are complementary. I think OpenZeppelin has a very good pattern to update rules, but there are some limitation to data (As I read here:
This code is design to store data in a way that allow changes in the data or in its schema as time goes on. Using Storage.sol, I can store data “without schema” (key-value). The semantic/schema is defined in the Mappping classes (in my example, LegalEntityMapping). The mapping class allow easier use of the data in the BNDESRegistry class. BNDESRegistry does not know the complexity of store data as key-value.
I can transform BNDESRegistry in an openzeppelin upgradeable contract and have the best of the different worlds.

  • Upgradeable contracts using OpenZeppelin approach.
  • Data and Business rules segragated (as stated by software engineer best practices in general).
  • Data and even its schema upgradeable without limitations
    I do not think the class Storage needs to be upgradeable because it is generic.
    Using BNDESFactory I can upgrade the mapping class (I created a function to show that).
    Using OpenZeppelin approach I can upgrade BNDESRegistry.
    @Dennison_Bertram -> yes, BNDESRegistry is not upgradeable yet. I still need to incorporate Open Zeppelin approach here.
    @Dennison_Bertram -> By “upgrading data”, I mean updating the data itself but also its schema.
    @Dennison_Bertram -> I saw you also created a code segreating storage and the acess to the data in a different context. Nice.

I would love to discuss that with your team in a call if possible.
Thank you!

1 Like