At this point, you should know the basic concepts of a smart contract; how to design and code one in solidity language and how to test it using remix environment. In the last module, we discussed the complete D-App built on a smart contract based solution. This module is about making a D-App better, more efficient, and practical with respect to the blockchain. There are improvements that help in the design of practical decentralized applications around smart contracts. We will discuss a few of the many improvements possible. Here are a few. Number one, we need to make sure we don't save unnecessary data on the blockchain. Recall blockchain is not a data repository. Number two, is there a way to log the events happening on the chain? Either forgetting a notification of completion of an operation or if something needs attention. Number three, smart contracts cannot access the outside links, C, to get today's US prime interest rate. Is there a provision to get outside information that will still keep the blockchain consistent? US daily interest rates are the same or lower for a given date as long as you normalize the day to epoch time. Recall that epoch time is the universal time in seconds from January 1st, 1970. Then how do we solve this problem of accessing an external resource from a smart contract? We're going to address these in this module. On completion of this module, you will be able to list additional features of solidity that make a smart contract efficient, practical, and useful. Reuse code and apply hierarchical structuring of a smart contract for specialization and generalization. Illustrate the use of events and pushing events to subscribing applications. Explain the use of smart contract named using oracles. 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.
