You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/pages/lessons/fundamentals/eth-intro-part-2.mdx
+4-8Lines changed: 4 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ have at least a fuzzy idea of how to answer these questions:
21
21
- What makes Ethereum decentralized?
22
22
- What is ether and why is it a necessary component of the network?
23
23
24
-
In this post, we’ll build on these concepts and explore some of the implications
24
+
In this lesson, we’ll build on these concepts and explore some of the implications
25
25
for developers, so return to Part 1 if you skipped it or need a refresher.
26
26
27
27
## What’s next?
@@ -34,7 +34,7 @@ We’re going to take a deeper look at how you can interact with the Ethereum ne
34
34
35
35
## Web2 vs. Web3
36
36
37
-
It’s hard not to collect accounts in today’s web. You have one for each social media app, news site, delivery service, retailer, and airline — to name a few. Each of these accounts lives on the company's servers, which makes you subject to their terms and conditions, privacy policy, and security practices. Your account can be frozen, deleted, censored, or altered at the discretion of the host company.
37
+
It’s hard not to collect accounts in today’s web. You have one for each social media app, news site, delivery service, retailer, and transit provider — to name a few. Each of these accounts lives on the company's servers, which makes you subject to their terms and conditions, privacy policy, and security practices. Your account can be frozen, deleted, censored, or altered at the discretion of the host company.
38
38
39
39
Web3 represents a paradigm shift for account management: you and you alone own your Ethereum accounts. When you create an account, it’s done outside of the scope of any company and can travel with you to multiple apps. In fact, creating an Ethereum account doesn’t require interaction with the Ethereum blockchain at all. Let’s create one now to prove it.
40
40
@@ -90,10 +90,6 @@ That's all there is to it! There's no registration process and no round-trip to
90
90
91
91
In the code above, you'll find two components of an account: a public address and a private key. Put simply, a **private key** is the password for an account. A **public address** is a shareable account number derived from the private key. As seen in the code sample, both are typically represented as hexadecimal numbers.
92
92
93
-
<Calloutemoji="💡"size="md"variant="info">
94
-
**Note**: Conveniently, Ethereum users and app developers don't have to understand exactly how the the account generation process works, but if you're interested in a very deep dive, see my previous posts: Ethereum 201: Mnemonics and Ethereum 201: HD Wallets.
95
-
</Callout>
96
-
97
93
## Using an account
98
94
99
95
This is an important takeaway: **the only way to affect a change on the blockchain is via a transaction** and every transaction must be signed by an account. Accounts can initiate transactions which transfer ether, deploy smart contracts, or interact with contracts to do things like mint new tokens. Let's briefly explore each.
@@ -175,7 +171,7 @@ Finally, a "raw" transaction is just the transaction data and signature represen
175
171
176
172
### Deploying smart contracts
177
173
178
-
A full introduction to smart contracts will be covered in a separate blog post, but this is a good opportunity for a sneak peak; interacting with smart contracts looks very similar to a standard transaction.
174
+
A full introduction to smart contracts will be covered in the next lesson, but this is a good opportunity for a sneak peak; interacting with smart contracts looks very similar to a standard transaction.
179
175
180
176
Briefly, **smart contracts** are programs that live on the Ethereum blockchain, available for anyone to use. When you're ready to deploy a smart contract, you compile the code down to bytecode and include it in a transaction as a `data` value:
181
177
@@ -244,7 +240,7 @@ So, we can create Ethereum accounts with surprising ease: offline and separate f
244
240
245
241
### Permanent passwords
246
242
247
-
A harsh reality of this world is that there are no password recovery services for basic account types. If you lose your private key and recovery phrase, you can kiss that account goodbye. Such is the double-edged sword of true ownership. App developers have an ethical obligation to onboard and educate Ethereum newcomers on this reality. (Note: social recovery wallets may improve this user experience and "account abstraction" is one related research effort – topics for another blog post.)
243
+
A harsh reality of this world is that there are no password recovery services for basic account types. If you lose your private key and recovery phrase, you can kiss that account goodbye. Such is the double-edged sword of true ownership. App developers have an ethical obligation to onboard and educate Ethereum newcomers on this reality. (Note: social recovery wallets may improve this user experience and "account abstraction" is one related research effort – topics for another lesson.)
Copy file name to clipboardExpand all lines: src/pages/lessons/fundamentals/eth-intro-part-3.mdx
+12-13Lines changed: 12 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,7 @@ Let's start with a simple definition: a **smart contract** is code (i.e., a comp
24
24
It may be helpful to think of contracts and individual accounts as the two types of actors within this system. With their programmed instructions, contracts can interact with the blockchain in much the same way as individual accounts: by sending and receiving ether or by interacting with other contracts. Contracts can go a step further by managing some internal state – a concept we'll explore shortly.
25
25
26
26
<Calloutemoji="💡"size="md"variant="info">
27
-
Note: Over the years, individual accounts have been described in a variety of ways. **Externally owned account** (EOA) is the original term as defined in the [Ethereum Whitepaper](https://ethereum.org/en/whitepaper/). You are likely to see that acronym again.
27
+
Note: Over the years, individual accounts have been described in a variety of ways. **Externally owned account** (EOA) is the original term as defined in the Ethereum Whitepaper. You are likely to see that acronym again.
28
28
</Callout>
29
29
30
30
A contract can be as complex or as simple as you need it to be. You can leave the contract open for the world to use, restrict its usage to only your account, or require a certain balance or the ownership of a particular asset to interact with it. Either way, if your contract is deployed to Ethereum Mainnet, that code is public!
@@ -33,25 +33,25 @@ A contract can be as complex or as simple as you need it to be. You can leave th
33
33
34
34
In this paradigm, that's a requirement. Users (or other contracts) may utilize your contract to move real value around. They need to be able to trust that your contract does what you say it does, and in order to do that, they need to be able to read it for themselves.
35
35
36
-
In reality, most users aren't reading the source code of each smart contract they interact with, but most wisely won't touch a contract if that source code isn't verified (e.g., on [sourcify](https://sourcify.dev/) or [Etherscan](https://etherscan.io/)) and vetted (e.g., audited) by industry veterans.
36
+
In reality, most users aren't reading the source code of each smart contract they interact with, but most wisely won't touch a contract if that source code isn't verified (e.g., on sourcify or Etherscan) and vetted (e.g., audited) by industry veterans.
37
37
38
38
Consider the alternative: if contracts are black boxes, there's nothing to stop a bad actor from publishing a contract that appears innocuous, but actually grants themselves the ability to move your assets. Today, bad actors can deploy such a contract and try to lure users in via social engineering, but often wallet interfaces will warn users when code is unverified and to proceed with caution.
39
39
40
40
## What about my business model?
41
41
42
42
Are you wondering how to preserve your competitive edge if all your smart contract code is open source? Public blockchains do force you to get creative here.
43
43
44
-
It's not necessarily a more restrictive landscape though. Because each contract is open source, you have the ability to build a platform that others can build on top of, or you can build on top of what others have already done. [Safe](https://safe.global/), for example, is an open source [multisig](https://ethereum.org/en/developers/docs/smart-contracts/) wallet with a rich ecosystem of auxiliary financial tools being built around it. Anyone can build a product that's compatible with a Safe, without any sort of permission from the Safe team.
44
+
It's not necessarily a more restrictive landscape though. Because each contract is open source, you have the ability to build a platform that others can build on top of, or you can build on top of what others have already done. Safe, for example, is an open source multisig wallet with a rich ecosystem of auxiliary financial tools being built around it. Anyone can build a product that's compatible with a Safe, without any sort of permission from the Safe team.
45
45
46
-
Open source licenses also vary widely. Another prominent player in the industry, Uniswap, introduced a product with a unique time-delayed [license](https://blog.uniswap.org/uniswap-v3?ref=snakecharmers.ethereum.org#license). Their code was instantly available as open source software, but restricted in its commercial reuse for two years. Creative licensing will surely continue to be explored in this domain.
46
+
Open source licenses also vary widely. Another prominent player in the industry, Uniswap, introduced a product with a unique time-delayed license. Their code was instantly available as open source software, but restricted in its commercial reuse for two years. Creative licensing will surely continue to be explored in this domain.
47
47
48
48
## What does a contract look like?
49
49
50
-
Ethereum smart contracts can be written in a handful of programming languages, each specially created for the purpose. Each have tradeoffs, but any will do the trick; in the end, the code just needs to compile down to bytecode that the [EVM](https://ethereum.org/en/developers/docs/evm/) (Ethereum Virtual Machine) can read. Popular language options include [Solidity](https://soliditylang.org/), [Vyper](https://docs.vyperlang.org/en/stable/), and a newcomer, [Fe](https://fe-lang.org/).
50
+
Ethereum smart contracts can be written in a handful of programming languages, each specially created for the purpose. Each have tradeoffs, but any will do the trick; in the end, the code just needs to compile down to bytecode that the EVM (Ethereum Virtual Machine) can read. Popular language options include Solidity, Vyper, and Fe.
51
51
52
52
Each language is worth a look, but below is a "Hello, World"-style example written in Solidity, the most established of the languages. This example contract is titled `Billboard`, stores a single message, and contains one function to update that message. As written, anyone has the unrestricted ability to update that message.
53
53
54
-
You can imagine that a website might display whatever message is stored and provide an input to type in a new message, replacing the current one. The combination of a smart contract and its user interface is what's referred to as a decentralized application, or "[dapp](https://ethereum.org/en/dapps/)" for short.
54
+
You can imagine that a website might display whatever message is stored and provide an input to type in a new message, replacing the current one. The combination of a smart contract and its user interface is what's referred to as a decentralized application, or "dapp" for short.
55
55
56
56
```solidity
57
57
// SPDX-License-Identifier: MIT
@@ -96,7 +96,7 @@ tx = {
96
96
w3.eth.send_transaction(tx)
97
97
```
98
98
99
-
Tools like [web3.py](https://web3py.readthedocs.io/en/stable/) offer slightly more human-friendly ways to go about this. One of the other outputs of a compilation is the contract's **ABI**, and some additional metadata.
99
+
Tools like web3.py offer slightly more human-friendly ways to go about this. One of the other outputs of a compilation is the contract's **ABI**, and some additional metadata.
100
100
101
101
<Calloutemoji="💡"size="md"variant="info">
102
102
**Note**: ABI stands for **Application Binary Interface**. An ABI is a machine-readable data blob that conveys how a contract can be interacted with – which functions are available and expected data types. It's some JSON that you pass into an Ethereum library (e.g., web3.py, ethers.js, etc.), so that it can provide you with a human-friendly interface. Does the name make sense now? An ABI communicates the interface for your application's bytecode.
@@ -140,15 +140,15 @@ Over the years, standards for various digital assets have proposed, debated, and
140
140
**Note**: To save you the Google search, _fungible_ means interchangeable or indistinguishable. In other words, if you own 100 fungible tokens, it doesn't make any difference which 100 tokens they are. NFTs, on the other hand, may each have unique qualities, so the particular token you own is significant.
141
141
</Callout>
142
142
143
-
To demystify those standards: the different token types are simply smart contract patterns that anyone can make use of. The [ERC-20 standard](https://eips.ethereum.org/EIPS/eip-20) specifies which functions your fungible token contract must include, but at its core, the contract simply maintains list of public addresses and how many tokens each one owns, represented by an integer.
143
+
To demystify those standards: the different token types are simply smart contract patterns that anyone can make use of. The ERC-20 standard specifies which functions your fungible token contract must include, but at its core, the contract simply maintains list of public addresses and how many tokens each one owns, represented by an integer.
144
144
145
-
The [ERC-721 standard](https://eips.ethereum.org/EIPS/eip-721) overlaps with ERC-20, but importantly introduces a unique token ID and some metadata for each token.
145
+
The ERC-721 standard overlaps with ERC-20, but importantly introduces a unique token ID and some metadata for each token.
146
146
147
147
These two standards are brought up to illustrate their compounding effect. As more of these building blocks are standardized, the easier it gets to quickly stack them in creative ways and innovate at the fringes.
148
148
149
149
## Contracts within contracts
150
150
151
-
Continuing the comparison to object-oriented classes, _inheritance_ is another concept you will commonly find in contracts. Well-trusted organizations like [OpenZeppelin](https://www.openzeppelin.com/contracts) implement token standard contracts, for example, so that contract developers can simply import and inherit that functionality.
151
+
Continuing the comparison to object-oriented classes, _inheritance_ is another concept you will commonly find in contracts. Well-trusted organizations like OpenZeppelin implement token standard contracts, for example, so that contract developers can simply import and inherit that functionality.
152
152
153
153
Within Solidity, inheritance is declared using the `is` keyword:
154
154
@@ -166,13 +166,12 @@ Beyond inheritance, contracts have the ability to interact with other deployed c
166
166
167
167
## A note on upgradeability
168
168
169
-
While the blockchain is said to be immutable, there are patterns of writing smart contracts that can support upgradeability. These patterns introduce trade-offs which may or may not make sense for your use case.
170
-
171
-
This is not exactly beginner-friendly content, but you can [read more](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies) about OpenZeppelin's preferred approach if you are so inclined.
169
+
While the blockchain is said to be immutable, there are patterns of writing smart contracts that can support upgradeability. These patterns introduce trade-offs which may or may not make sense for your use case. The specifics are beyond the scope of this introductory lesson.
172
170
173
171
## Starting off on your own
174
172
175
173
A couple tips and resources to take your next steps:
174
+
- Continue on your journey within D_D Academy. The Tiered NFT track and ERC-20 lesson are great next steps.
176
175
- The user interface can be a bit intimidating, but [Remix](https://remix.ethereum.org/) is great for being able to open a web browser and have a Solidity developer environment immediately ready for use.
177
176
-[Solidity by Example](https://solidity-by-example.org/) is a great reference manual to keep nearby while writing contracts. Succinct code samples are organized by topic.
178
177
- OpenZeppelin's [Contracts Wizard](https://docs.openzeppelin.com/contracts/5.x/wizard) is a terrific starting point for token contracts, in particular. You can select a few preferences and have the bones of a contract generated for you. There's even a convenient button to open that contract within a Remix environment.
0 commit comments