This third course of the Blockchain specialization prepares you to design and develop end-to-end decentralized applications (Dapps) – which provide anyone with access to the blockchain’s features and services. You will use Truffle IDE, smart contracts, a simple web client and a MetaMask client. You will learn about the architecture of a Dapp: the front-end client interface, backed by the blockchain and smart contracts. The course covers the basic design of a Dapp, Truffle development process and commands (init, develop, test and migrate), test-driven development of Dapp, Dapp application models and emerging standards that are essential for predictable Dapp behavior. Main concepts are delivered through videos, demos and hands-on exercises.
Design Improvements: Solidity Features (Part 1)
Loading...
From the course by University at Buffalo
Decentralized Applications (Dapps)
17 оценки
From the lesson
Design Improvements
In this module, we will discuss a few of the many best practices exclusive to smart contracts and Dapps that will improve your basic Dapp design.
Meet the Instructors
Bina RamamurthyTeaching Professor
Computer Science and Engineering Department
[MUSIC]
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 involvement.
In the last module,
we discussed the complete DApp built on a smart contract base solution.
This module is about making a DApp better, more efficient, and
practical, with respect to the block chain.
There are implements that help in the design
of practical decentralized applications around smart contracts.
We will discuss a few of the many implements 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,
see to get today's US prime interest rate.
Is that a provision to get outside information,
that will still keep the block change consistent?
US daily interest rates are the same all over for
a given date, as long as you normalize the date to aprit time.
Recall the aprit 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 go to address Ds 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 in pushing events to subscribing applications.
Explain the use of smart contract named, using Orcalize.
[MUSIC]
Software development, as you know, is incremental and
iterative, with every iteration improving, or 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.
On completion of this lesson,
you will be able to design data of the smart contracts, with proper memory and
storage attributes, apply interface-implementation and
multiple inheritance of a smart contract, manage diligently, ownership and
lifetime of a smart contract Now, let's
discuss just three practices that you can adopt immediately into your development.
Minimize the footprint on the immutable ledger in the blockchain.
Manage ownership and lifespan of a smart contract.
Organize related smart contract using interfaces and
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 to 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 or of the state variables.
We would like only a sliver of data that is needed as state for providence,
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 cost.
One of the ways you can accomplish this, is by currently using memory and
storage keywords.
Memory and storage are indeed keyword 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 erased between function cords.
Memory is a bitery, it's cheaper to use an actinium.
Since everything cost 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 purses between function cause,
storage is a key value store of 32 bites each, for the key and the value.
All stored data is considered as state, and
use in the computation of state hash of the head.
Using a memory location cost few guest points, one to three.
Whereas storage cost in the order of thousands of points.
20,000 points to set up, 5,000 points to change a value, and so on.
You 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 at 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 will consider only the composite data strucked and arrays.
In a solidity smart contract, strucked and arrays are by default assigned storage,
instead of memory even when they are local to functions.
When a structure arrays uses 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 a permanent storage of the smart contract.
And we all know that a smart contract, once deployed, is immutable and permanent.
Receive 600 bytes of storage on EPM.
This space efficiency implement, 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 implement we'll discuss.
How to kill or delete a smart contract.
Have you wondered, what if a deployed smart contract is outdated?
Consider this scenario, in the US, 2016 income tax laws are invalid.
So are the smart contracts we might have deployed for this.
Thus, the smart contracts are now useless.
What happens to the money,
tax, that any of the smart contracts would have collected?
Can we change the ownership of these smart contracts, to a trustee account,
as we deploy smart contracts, for representing the new tax laws?
These are questions to be carefully addressed, not just for
the Internal Revenue Service, but for any business or organization,
that may deploy a blockchain, and a DApp smart contract solution.
Recall that, a smart contract is identified by an address.
This is an important concept.
It may represent a token, an organization, a person, human or
otherwise, under related, logic rules, and operations.
A smart contract has an owner, by default, it is the creator of the smart contract.
It has a value or ether balance.
Its ownership may change, or with may have to be deleted.
Given all this complex attribute, how do you manage a smart contract?
To delete or kill a smart contract,
Solidity provides a function called, self-destruct.
Understand this call is irreversible, as for the default blockchain protocol.
Once killed, the smart contract cannot be revived or accessed.
It is like hurling an expired spaceship into the abyss of space.
And now the good programming practice, is to make sure only the owner, or
the owners of the smart contract, or
an authorized person has permission to self destruct a contract.
Assume a time duration is also specified for the contract.
Modify as our used enforced the destructor's address, and
the time duration for this mod contract.
Here is the code.
What happens when a kill function is executed?
The smart contract code is removed from the state of the blockchain,
if the condition specified by the modifier are satisfied.
In our case, the conditions are that, the function is called by the designated
address, and the time specified has elapsed.
The remaining ethers stored in the address of this smart contract,
is transferred to the address specified in the parameter of this self destruct call.
The smart contract itself, is inaccessible by its current address.
The next concept is equally important for smart contract design.
Recall that smart contract may represent an asset or a business.
During the lifetime of an asset, ownership may change,
it may change due to a sale of an asset, donation of an asset, or by bequeathment.
These are just a few.
There are many more scenarios for ownership transfer.
This function can implement a transfer of ownership.
But make sure, you qualify the transfer with a modifier or
modifiers, so appropriate rules enforced.
For a managing ownership and lifetime,
we are moving into managing relationships among smart contracts.
So far, we've been creating single smart contract.
It is possible, a complex application could be composed of many smart contracts.
One instantiating the other, are inheriting others.
It is also possible that the symbols are name space for an organization,
is defined in a common smart contract that needs to be applied.
Import command can be used to include files in a smart contract.
At the the time of completion,
associations are made between the imported files, and the current smart contract.
And the bicode is generated, based on this association.
This leads us to the programming practice three.
Composability specialization and generalization, or
important tennents from object orientation,
that can help in designing smart contact solutions, for complex problems.
This also promotes reusability of code, and standards across organization and
participants, as you would see in a later module.
We'll explore inheritance next, and its importance, and
small contract based applications.
For example, federal laws refer to here as fed laws, can be illegal framework,
that can variable represent in into face small contract.
Letting the state at the field offices, implement them as they see fit.
In this case, state laws and field laws are also smart contracts, and
they are associated using the input statements.
This is inheritance at work.
As a subtopic of relationship among smart contract,
it is possible to create libraries, and
import existing libraries into your Solidity smart contract code.
Libraries are special smart contract with no ether balance,
no payable functions, and no state to be stowed in the block chain.
A fine example is a safemat.soul by Zeppelin,
that can be included in your smart contract for any math computation.
Inputsafemat.soul.
Many libraries are act to be created.
You can be sure many domain specific libraries will emerge.
Here is an opportunity, you too,
can be a creator of a useful library for your application domain.
Summarizing.
We explored three important concepts in this lesson.
Memory versus storage attribute for data in a smart contract,
managing lifetime and ownership of smart contracts, and inheritance.
Lifetime and ownership, is something unique to smart contract.
And some DApp developers may tend to downplay the importance of this.
You should not.
You will explore many applications of the inheritance concept,
in the next lessons, and also in the next module.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
