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...
Из курса от партнера University at Buffalo
Decentralized Applications (Dapps)
95 оценки
Из урока
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.
Познакомьтесь с преподавателями
Bina RamamurthyTeaching Professor
Computer Science and Engineering Department
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.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
