Do you own an Ether Rock on either the broken contract or the official contract? Is your rock one of the millions of NFTs created in 2021, or is it a special one from 2017? Answering this question is not as straightforward as it may appear. Behind the question is a puzzle, and, after months of careful thought, I think I’ve solved it.
Official Contract
Let’s focus on the official contract first, since it is the simpler one. It was deployed on December 26, 2017, and its code limits the number of rocks to 100. The rocks were not all generated in 2017, however.
It turns out that only rocks 0-17 were assigned owners that year. When ownership is changed to something other than the zero address (the default), an SSTORE operation is performed in the EVM. This is a gas-intensive operation that introduces a new branch into the account storage tree that all Ethereum nodes must maintain.
Rock 18 is an interesting edge case. It was not assigned an owner in 2017, but it was assigned a price. Since assigning a price also requires an SSTORE operation, it makes the most sense to group rock 20 together with the earlier ones.
For rocks 19-99, however, not a single SSTORE operation was performed in 2017. It is problematic to label those rocks “old” with no qualifications.
Despite the fact that rocks 19-99 had no associated SSTORE operations, they did consume some storage, in the following sense. The number 99 had to be written in the code in order to bound the number of rocks. In hex, 99 translates to 63. Below is a portion of the Ether Rocks bytecode, with the aforementioned 63 highlighted.
Storing the number n requires a number of bits that is logarithmic in n. As n grows, the logarithm of n also grows, but at a much slower rate. In computer science, this is formalized using big O notation. We say that the size of the representation of n is O(log n).
So, in terms of associated storage use, we can at least say that rocks 19-99 belong to the O(log n) category. For rocks 0-18, the amount of storage grows linearly with the number of rocks. Thus, they belong to the O(n) category.
Broken Contract
Now, we can move on to the broken contract, which was deployed the day before the official one. Due to a small typo, rocks in the broken contract are always listed for sale, and even rocks beyond number 99 can be purchased.
In the broken contract, rocks 0-11 were assigned owners in 2017. Rock 12 was not assigned an owner in 2017, but it was assigned a price. (I failed to acknowledge this in a previous article.) Those belong to the O(n) category. And since the number 99 was written in the code (despite the bug), rocks 13-99 belong to the O(log n) category.
What about rocks 100 and above? They were not referenced at all in 2017. Thus, only a constant amount of storage was used for them, and they can be said to belong to the O(1) category.
Conclusion
I’ve presented a clean and sensible way to categorize items that were generated from an old contract over a period of time. This approach can be used to categorize items in several Ethereum projects, including Etheria, PixelMap, and MoonCats.
Of course, this categorization is just one factor that goes into the valuation of Ethereum relics, and different people will assign it different weights. Some may think it should have no weight at all.
My intuition tells me that storage use will matter in the long run. By determining exactly what information was stored on the Ethereum blockchain during the 2015-17 time period, we can ascertain the “historical weight” of digital items.