Solidity Bootcamp

The last discussion on Solidity between @salief and I were around finding a new topic for this weeks research.

So far I suggested reading:

  • Fat Protocols

And along reading the curation protocol I had a question: Why do we use uint40 data instead of uint256 in some places. Led me to this article:

  • All about conversion

If you would like to see how the last topic was executed you can check out our githubs here:

Topic: Interfaces


Big fan of Fat Protocol

also Val did u get ur answer about why uint40 there rather than uint256? I believe its because of struct packing and optimizing the Listing struct so it requires fewer storage slots

my optimization game is so weak, could use a lil deep dive in common practices for how storage/memory works and best ways to optimize for contract read/writes (for gas)

1 Like

Confused on if it costs more or less gas, some places I’m seeing that it’s the same complexity

Currently trying to better my understanding of contract storage.

1 Like

Like how it is for the curation protocol?

all the stuff u see in CuratorStorageV1.sol is stored in storage

Passively digesting the engineering calls and these are my learnings:

Registry = “phone book” for contract addresses so we never lose contact with the addresses once they get reassigned to new deployments or updates. This can happen by referencing an “index” to a contract instead of the 0x address.

ThemeRegistry - a program

When thinking of a registry think about how your ENS name is initially set to an address on the blockchain, that entire naming system is “a registry of names” mapped → to addresses (or phone numbers if you want to keep the scenario going)

If I were to go in and update that owner address on my ENS name today, everywhere I am defined on the internet as “valcoholics.eth” doesn’t get broken because it’s communicating to the registry of my address not my bare 0x000 address.

Creating a Registry Contract in Solidity - Verite Documentation › verite › developers › tutorials

@valcoholics yep this is great – and I think it might be most helpful to describe registries at large (as you’ve done) and then hone into how the themeRegistry is being implemented.

In my mind, this looks like:

Generic Registries

yourdataType registryKey → yourDataType registryValue

– some type of index (iterating over value that could represent a number, contract address, wallet address, etc) mapped to → data structure OR pointer to a data structure

(We chose “pointer to a data structure” in this new ThemeRegistry strategy outlined below, we are actually deploying pure bytecode data to it’s own address and storing that address)

Theme Registry

 uint256 themeIndex  → address dataContract

and if you know your themeIndex, you can find and decode the dataContract into the end of the line themeURI which right now is just storing string ipfs links…
(ex: “ipfs://bafybeid33egfd2osmkyq6xtwl37epcc7tarsbnlc3kun3fsr7tfq7gv3qq/1”)
but can be turned into base64 encoded JSON stuff!

Look at us kind of knowing what we are doing lol

1 Like

replace “string” with “yourDataType” in the general section and yes

Ok I think I understand this, but can you do a quick run through of this process?

@valcoholics just realized in the generic version index is marked as an uint256. that should also be a “yourdataType” esque value. cuz u can use addresse or uints or wtv therse

1 Like