Check out a free preview of the full A Tour of Web 3: Ethereum & Smart Contracts with Solidity course

The "Q&A" Lesson is part of the full, A Tour of Web 3: Ethereum & Smart Contracts with Solidity course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen answers questions about mutability in the blockchain, deploying new contracts, alternatives to the diamond pattern, and the public nature of code on the block chain.


Transcript from the "Q&A" Lesson

>> All right, we did the full thing, do we have any questions?
>> Generally thinking about mutability on the chain like is this storage space? Is it kind of like? I mean can you really mutate things in place like when you push new functions and make a new cut.

Or is it really kind of appending in sort of a read only way and just updating an address of where the new location of the new cut. So everything that was there before is there forever.
>> Correct, you have it correct, all the code will exist wherever you say it should exist.

But, it's the storage that's the important part. The storage will remain with your first diamond contract. As long as you keep that, it doesn't matter how many versions of AU you deploy, what really matters is you are always referencing the latest one and you are always using the same memory.

So yes, there is many versions that did exist, you're just replacing the address or the pointer to which one you're actually using, as the code to call into.
>> The storage on the diamond is mutable.
>> It's always mutable. Storage is always mutable. Contracts, their code is there is some unique ways you can do things that aren't immutable.

But I just wouldn't probably get into that territory it looks really hard, I'm not sure what would be the reason for it unless if there's a way to be able to save some money with how complex contracts are. But to me, the diamond one is the most approachable way to do things.

You can really just replace what you need to when you need to, it takes care of all the internals and it just works. I was reading about it last night with inline assemblies that, you can do some trickeration with like getting into code and making some mutations to it, I don't quite understand exactly how it works.

I'd have to read more on it, I may be completely wrong and how I was even interpreting it, but it was complex to say the least. Let's see, and I'm gonna read it, I think Ryan G has a question. So in our example we replace A with a new contract.

Does that mean there are two A contracts that are deployed, and we're simply only using the second one? Yes, we're updating the pointer as we keep deploying new and new contracts, so that's what's happening. We just don't update the storage and that's the magical part of diamonds. And I also forgot to repeat your question.

Could you say your question one more time?
>> It's similar to what was just asked it's, yeah. Is this all immutable as you push new cuts to your diamond, is it writing to new address space?
>> Yes, it was effectively a very similar question, is it immutable? If we push new cuts to our diamond what are we exactly doing.

Yes, we're not creating new diamond contract, we're mutating its storage. But, the old contracts the new contract each one will be replicated and put into memory and will be there forever. We're just simply pointing to the latest one. The question is currently are there any other alternatives out there that would compete with the diamond contract paradigm.

I've seen some other ones, they just didn't seem as appealing, this one seems the most feature complete. And even reading through just a little bit, I was kinda largely drawn away to the point right away and remember their names. It was just like yeah, I've seen some other ways people do it.

This is just the most concrete one I've seen yet. And obviously it wasn't even that hard they even give you I mean, I was able to create and deploy a diamond fairly quick. Why of coding? What happens if we use another diamonds address our diamonds a public permanent contract on the network?

Everything's always public permanent. So even if I use the keyword private, for a variable meaning only my contract can access this, technically with storage. Other contracts or other front ends can actually read out your storage and see the value if it's say, a simple data type. They may not be able to read out the information with mappings if they don't know the keys, but nonetheless there is no such thing as private, if you will, when it comes to blockchain.

All code is public, I can get your code if we need to.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now