I am the author of the original post from Trail of Bits. Nick: thank you for acknowledging that you agree with most of the issues pointed out in our review of your proposal.
Regarding the new reference implementations, I think the complexity has got even worse than what we initially reviewed and blogged about. There are now three reference implementations, which makes everything even more confusing for users, and further review of the proposal more difficult.
The "low complexity" version is far from having a low complexity. For example, see the following code and then compare it to the upgrade function in OpenZeppelin's library. This level of complexity is not necessary to update a key-value pair in a mapping.
The direction that the proposal is taking now highlights its primary fundamental issues:
It is excessively complex
It assumes that users will use it correctly, and no guidance on risks is provided
The proposal and implementations would be suitable for a custom solution but do not meet the maturity required for a standard.
I think it would be beneficial to re-start the proposal, create a simple API, use existing common vocabulary, and avoid the pitfalls shown in our blogpost.
Hi Josselin,
I don't agree with the points of your article that are outdated or inaccurate which I address in my article. I think your article is unnecessarily negative. I think you can help with some of the informational/procedure parts you mention in your article and that would be great.
EIP-2535 Diamond Standard is a good and useful standard that applications can use.
OpenZeppelin's upgrade function can't be compared to the Diamond Standard's because they do different things. The Diamond Standard provides more functionality than OpenZeppelin's proxy. With the Diamond Standard you can have functions from multiple implementations/facets, which is a core part of what the Diamond Standard is about.
The diamondCut function that is linked to provides an important safety feature: You have to be explicit about what functions you are adding or replacing or removing. The function then checks and enforces that you don't make a mistake about that. This safety feature is a good thing and protects users.
The diamondCut code that is linked to is easy to read and is straightforward.
The functions and facets are looped over.
The logic is separated into three parts: Add, Replace, Remove
Some safety checks are done (require statements) and then the appropriate logic is execute to add or replace or remove.
Having three different implementations does not affect the complexity of the code, since each implementation is separate.
I think that if the most complicated thing about the Diamond Standard is that people have to choose which implementation to use, that's pretty good.
There are three different implementations to meet the needs and wants of different people. It is not hard to sort out which implementation to use, and in many cases I don't think it matters much which one is used because they do the same things. These are implementations of the standard, not the standard itself. People are free to write their own implementations or use other implementations if they want to.
People that want a simple implementation should use the diamond-1 implementation: github.com/mudgen/diamond-1
People that want a more gas-efficient implementation should use the diamond-2 implementation: github.com/mudgen/diamond-1
People willing to pay a little more gas and want the simplest loupe functions should use the diamond-3 implementation: github.com/mudgen/diamond-3
Hello Readers,
I am the author of the original post from Trail of Bits. Nick: thank you for acknowledging that you agree with most of the issues pointed out in our review of your proposal.
Regarding the new reference implementations, I think the complexity has got even worse than what we initially reviewed and blogged about. There are now three reference implementations, which makes everything even more confusing for users, and further review of the proposal more difficult.
The "low complexity" version is far from having a low complexity. For example, see the following code and then compare it to the upgrade function in OpenZeppelin's library. This level of complexity is not necessary to update a key-value pair in a mapping.
The direction that the proposal is taking now highlights its primary fundamental issues:
The proposal and implementations would be suitable for a custom solution but do not meet the maturity required for a standard.
I think it would be beneficial to re-start the proposal, create a simple API, use existing common vocabulary, and avoid the pitfalls shown in our blogpost.
-Josselin
Hi Josselin,
I don't agree with the points of your article that are outdated or inaccurate which I address in my article. I think your article is unnecessarily negative. I think you can help with some of the informational/procedure parts you mention in your article and that would be great.
EIP-2535 Diamond Standard is a good and useful standard that applications can use.
OpenZeppelin's upgrade function can't be compared to the Diamond Standard's because they do different things. The Diamond Standard provides more functionality than OpenZeppelin's proxy. With the Diamond Standard you can have functions from multiple implementations/facets, which is a core part of what the Diamond Standard is about.
The
diamondCutfunction that is linked to provides an important safety feature: You have to be explicit about what functions you are adding or replacing or removing. The function then checks and enforces that you don't make a mistake about that. This safety feature is a good thing and protects users.The
diamondCutcode that is linked to is easy to read and is straightforward.Having three different implementations does not affect the complexity of the code, since each implementation is separate.
I think that if the most complicated thing about the Diamond Standard is that people have to choose which implementation to use, that's pretty good.
There are three different implementations to meet the needs and wants of different people. It is not hard to sort out which implementation to use, and in many cases I don't think it matters much which one is used because they do the same things. These are implementations of the standard, not the standard itself. People are free to write their own implementations or use other implementations if they want to.
People that want a simple implementation should use the diamond-1 implementation:
github.com/mudgen/diamond-1
People that want a more gas-efficient implementation should use the diamond-2 implementation: github.com/mudgen/diamond-1
People willing to pay a little more gas and want the simplest loupe functions should use the diamond-3 implementation: github.com/mudgen/diamond-3
More info about this here: github.com/mudgen/diamond
Also people can contact me if they have questions.