Software development, as you know,
is incremental and iterative with every iteration improving over the previous.
Did you know that security was afterthought and was retrofit into HTTP protocol?
From HTTP to HTTPS.
See the beginnings of this improvement in RFC 2660 and RFC 2818.
Ethereum improvement proposal framework, EIP,
that manages ongoing improvements to
ethereum protocol is a good example of iterative process improvement.
Recall that EIP is similar to the request for
comments RFC of the Internet Engineering Task Force, IETF.
Minimize the footprint on the immutable ledger in the blockchain.
Manage ownership and lifespan of a smart contract.
Organize related smart contract using interfaces in
inheritance for reuse and proper type classification.
For minimizing the footprint on the blockchain,
let's consider storage versus memory attributes of data.
By default, all the state changes did variables define in the smart contract,
are saved as state on the blockchain.
Recall from, course one,
that the state hash of the ethereum block header,
is computed using Merkle tree or Patricia Merkle tree of the state variables.
We would like only a sliver of data that is needed as state for provenance,
governance, and immutability to be saved on the blockchain.
So, our goal is to minimize the state or
the footprint of the Smart Contract and lower the gas costs.
One of the ways you can accomplish this,
is by correctly using memory and storage keywords.
Memory and storage are indeed keywords in
the solidity language and they mean the same as in your regular computing system.
Memory is transient memory in RAM and storage refers
to persistent store in the permanent storage device like your hard drive.
Memory is temporary and is a race between function calls.
Memory is a byte array.
It's cheaper to use an Ethereum.
Since everything cause gas points,
we have to be aware of this.
Every contract is assigned a storage space and this storage is permanent.
The values in it persists between function calls.
Storage is a key value store of 32 bytes each for the key and the value.
All storage data is considered a state and used in
the computation of state hash route of the header.
Using a memory location,
cause few guess points,
1-3, whereas storage costs in the order of thousands of points.
Twenty thousand points to set up,
5,000 points to change a value and so on.
You may may wonder why we are so concerned about this memory versus storage difference.
Understand, that a smart contract is
global and a copy of it is present in every full node.
The state footprint hash is present in every block.
We don't want unnecessary details on the immutable ledger.
There are many ways we could manage the memory versus storage trade-off.
Here we'll consider only the composite data struct and arrays.
In a solidity smart contract,
struct and array are by default assigned storage instead of memory,
even when they are local to functions.
While a struct or array is used as a parameter or a local variable in a function,
declare them as memory variables.
If the memory attribute were not there,
temporary variable investors would have
been a storage variable wasting state variable space.
Since we declared investors to be memory type,
its space of 30 by 20 bytes is on
the temporary memory is some permanent storage of the smart contract.
And we all know that a smart contract once deployed is immutable and permanent.
We saved 600 bytes of storage on EVM.
This space efficiency improvement,
is not just for one node but for every full node on the blockchain.
In the development of a smart contract in solidity language,
consider using memory variables for any transient data.
Use storage variable only for something that needs to be persisted on the blockchain.
Now, let's move into the second improvement we'll discuss;
how to kill or delete a smart contract.