Ethereum consists of five main parts:

Ethereum consists of five main parts:#

"Ethereum 101" Basics

"Ethereum 201" Delving into more complex concepts

(Ethereum 301) Identity verification in the context of cryptocurrency

(Ethereum 401) Decentralized finance section

(Ethereum 501) The future of Ethereum, with a particular focus on the transition to PoS (Proof of Stake) (if this is not relevant to you now, don't worry too much).

In each section, I explain many complex technical terms, compile numerous practical charts, and elucidate the most important conceptual themes in Ethereum in plain language. Additionally, I have included extra materials at the end of the guide for further exploration.

When learning about Ethereum, you can quickly read and check different parts of the guide as needed, or use the guide as a source of inspiration for exploring the future, or as a link to share with friends who have recently shown interest in the cryptocurrency field.

For example, you can press Ctrl+F to search for "Uniswap" to learn more about decentralized exchanges. Alternatively, you can search for "wallet" to learn more about the security of non-custodial wallets.

In a popular blog post by Vitalik Buterin (co-founder of Ethereum), he wrote,

"Sometimes, a slight oversimplification is exactly what we need to understand the world."

By condensing these complex topics into minimalist content, I hope this guide can help everyone understand the world of Ethereum.

Ethereum 101 - Basics

Before understanding Ethereum, we need to grasp its foundational concepts.

In this section, I will explain what blockchain is, how blocks are added to the chain, how Ethereum operates like a world computer, and how smart contracts function.

Blockchain - A blockchain is a public ledger of all transactions processed and maintained by a series of independent computers within a specific network. Unlike a centralized way of managing these transaction databases (like how Amazon or Facebook controls its data), there is no single data owner on the blockchain, making it decentralized. The computers in this network follow specific protocols and mechanisms to maintain records of all transactions.

These protocols allow computers to agree on all (transaction) actions occurring within the network or to reach consensus: Did computer A transfer funds to computer B? Did computer B send those funds to computer C, and when? What happened last week? What happened six months ago?

The computers in the network are independent, so computer D and E (and F and G...) may not know computer A, B, or C. A series of rules in the blockchain means that a single computer does not need to independently verify the accuracy of the data provided by other computers to reach consensus on transactions that occurred in the blockchain's history.

In other words, computers can reach consensus without trusting each other. This trustless consensus mechanism is crucial among the computers in the network.

There are many blockchains, each following its own set of rules to reach consensus. The Ethereum blockchain aims to provide infrastructure services and design space for cool and novel applications in various fields, such as gaming, art, finance, and social media.

Consensus Mechanism - When all computers on a blockchain agree on the facts occurring in the network, this is called "reaching consensus." Individual computers reach consensus based on the rules of the blockchain, and each time a new transaction is packaged onto the chain, all computers must go through the entire consensus process.

Once these computers reach consensus, the transaction block is packaged onto the blockchain, becoming part of the network's historical record.

In essence, if the computers have no objections to each new transaction being added to the chain, it is equivalent to agreeing on the entire historical record of the blockchain, as they must participate in every step of it.

Consensus is a vital concept that underpins the entire blockchain world. How to verify transactions that occur above without trusting any participants in a trustless network is a very challenging human problem, and blockchain is the optimal solution to this issue. Different protocols (or "consensus mechanisms") can facilitate individual computers to reach consensus within the blockchain. Below are two main consensus mechanisms:

Proof of Work (PoW) - In a proof of work mechanism, computers compete to solve complex mathematical problems. The network rewards the first computer to solve the problem with economic incentives, motivating the people behind the computers to continuously update and run nodes (in other words, ensuring the network processes transactions).

You may have heard that this process of competing to solve computation-intensive mathematical problems is called "mining." Essentially, validated legitimate transactions can be safely added to the blockchain. This is also the rule implemented by the Bitcoin blockchain and the current Ethereum blockchain.

The proof of work mechanism also has its drawbacks, mainly:

Ultimately, the most powerful (and expensive) computers can solve problems faster, thus the rich get richer;
Solving high-difficulty mathematical problems on computers consumes a lot of energy, which has become one of the most criticized aspects of the entire blockchain.

Proof of Stake (PoS) - In contrast to expending a lot of computational power to reach consensus (like PoW), the proof of stake mechanism constrains/incentivizes participants using the risk of penalties (and some economic incentives).

In the proof of stake mechanism, participants prepare funds (technically, they "stake" their funds) and gain eligibility to enter a random selection process. The randomly selected computer must verify the next batch of incoming transactions. When the randomly selected computer correctly processes the transaction (within the limits of the proof of stake mechanism), it can receive rewards.

If a participant randomly selected by the network violates the rules of the proof of stake mechanism, then the assets that participant staked will be reduced (or "forfeited").

PoS blockchains do not request all computers in the network to solve those mathematical problems simultaneously; instead, they randomly select computers for transaction verification. Skipping the heavy computational process can alleviate the two main issues that arise with the PoW mechanism. This is also part of the reason why Ethereum plans to implement this consensus mechanism when deploying the next generation of blockchain in 2022.

Nodes - For the Ethereum blockchain to operate, participants in the network need to run specific software to assist them in interacting with the blockchain. I tend to think of each node as an independent computer running Ethereum software.

Similarly, the more nodes (participants in the network), the more decentralized it becomes, but sometimes maintaining all nodes can be a bit cumbersome, so different nodes serve different purposes:

Full Nodes - Full nodes are used to store the complete blockchain data, help validate blocks, and package them onto the chain. These nodes also provide validity proof for past transactions.

Light Nodes - Light nodes are designed to have relatively fewer functions than full nodes. Instead of storing complete blockchain data, light nodes only store a small amount of proof of past transactions. These nodes allow more people to participate in the network because they store less data and are more economical to run.

Archive Nodes - Archive nodes are the library/Wikipedia of the Ethereum world. They store all the data from full nodes and even more. Analysis tools and wallet providers may use archive nodes to pull information from long ago.

Clients - This is the software for Ethereum that allows computers (nodes) to interact with the Ethereum network. Individual nodes can choose the client software they want to use, but using multiple types of clients is crucial for decentralization to avoid issues or bugs in any one client.

Currently, there are execution clients and consensus clients, but this is beyond the scope of this guide.

Nowadays, there are many available clients on-chain, and the Ethereum community is striving to diversify the clients that the largest nodes run.

Importantly, any user who wants to participate in running the Ethereum network can create their own client, meaning users do not have to rely on third-party entities to verify the blockchain.

State - The state of the Ethereum blockchain refers to the account balance situation on the blockchain at any given point in time. Once something new occurs (like processing a new transaction block), the state is updated to accurately reflect the status of the blockchain after packaging the new transaction.

The state of Ethereum retains information about different accounts and their balances. In other words, once the blockchain verifies a new transaction, the state will also update accordingly, reflecting the new account balances using the information from the newly added transaction.

Sidebar - How are blocks packaged onto the blockchain?

A user may want to send some funds to another user using the Ethereum blockchain. Once the initiating user initiates the transaction, it must be packaged onto the transaction chain before the receiving user can receive the funds.

When such a transaction is packaged onto the Ethereum blockchain, various nodes must complete the entire consensus process before the transaction is packaged onto the chain and becomes part of its history.

In the diagram below, it discusses the simple transaction mentioned above, where one user sends funds to another user. This transaction is packaged into a block, waiting for nodes to reach consensus before adding it to the chain.

Source: Understanding Ethereum

In fact, the blockchain is merely a way for all users to reach consensus on the historical transactions occurring in the network, while the state of the blockchain is the account balances that have been updated in real-time with new transactions.

Source: Understanding the Ethereum Yellow Paper

Smart Contracts - To some extent, smart contracts are like electronic versions of traditional contracts used in the physical world. In traditional contracts (like employment contracts or apartment leases), two or more parties establish a set of terms and then enforce those terms through lawyers and the judicial system.

In smart contracts, two or more users also create a set of rules, but instead of enforcing the contract through the judicial system, they are written in code as smart contracts and sent to the blockchain (or deployed on the blockchain). Smart contracts automatically execute based on the pre-written code without the need for lawyers.

The sidebar above describes the process of packaging blocks onto the chain. Smart contracts are the code deployed onto the chain through transactions within the block. Future transactions can "call" or interact with the smart contract.

For a simple example, User A wants to bet User B on the value of Bitcoin in the next two years. User A believes Bitcoin will exceed $100,000 on January 1, 2032, while User B believes it will be below that price.

Then, the two users can establish a smart contract, placing their funds into the contract, and agree on a simple rule: if Bitcoin exceeds $100,000 on January 1, 2032, the smart contract will release those funds to User A; otherwise, the smart contract will send the funds to User B. This transaction process is very simple, direct, and trustless.

Smart contracts allow anyone to deploy code on a world computer in a trustless manner, and they also enable anyone to verify the content of the code in a trustless way (as long as they can read the code!).

Ultimately, the existence of smart contract technology has brought tremendous opportunities for a wave of emerging decentralized applications, which would not be possible without blockchain technology.

The biggest difference between Bitcoin and Ethereum is that Ethereum has spawned a wave of smart contract computing platforms, which can write smart contract code and deploy it directly onto the chain.

Ethereum Foundation researcher John Stark wrote an article about smart contracts; if you want to delve deeper into this concept, I recommend reading it.

Ether (ETH) - Ether is the native currency that supports the Ethereum blockchain. In the proof of work mechanism, (mining) rewards are paid in Ether to the computers that solve mathematical problems. Additionally, the funds that participants stake in the proof of stake mechanism are also in Ether (32 ETH must be staked).

Ether is the name of the cryptocurrency, while Ethereum is the name of the network.

Ethereum Virtual Machine (EVM) - The name Ethereum Virtual Machine refers to a "virtual" computer made up of all the independent small computers participating in the Ethereum network. This large computer does not physically exist in a specific location but operates like a large global computer.

The state of the Ethereum blockchain is active on this computer, and when the next block is packaged onto the chain, it is responsible for executing the rules for state updates. If users in the Ethereum network want to include smart contract code in their transactions, that code will run on the EVM.

Sidebar - How does the Ethereum Virtual Machine work?

Although it may not be necessary for beginners to understand the complexities of how the EVM operates, it is an important component of the Ethereum blockchain and can help readers roughly understand how decentralization scales.

In the diagram below, although the image is somewhat complex, it is well drawn. Let's look at it step by step:

We start with the state of the Ethereum blockchain at a specific point in time. The box on the left is called "World State σ t."

A transaction is packaged onto the chain, for example, transferring Ether from one wallet to another, represented by the box at the top of the diagram, which is "Information Call Transaction."

The Ethereum state before the transaction occurs (again, the left box) plus the input data of the new transaction (the top box) are all run on the EVM. Here, the EVM updates the state of the blockchain.

Once the EVM updates the state, the new state "World State σ t+1" will be stored.

Tokens - Generally, tokens refer to assets on the blockchain. Tokens can represent many different types of assets.

For example, tokens are generally considered assets that can be treated as currency or assets that provide voting rights to holders in specific decision-making processes (governance tokens), or they can represent entirely different things. Tokens are atomic units of value representing different types of assets in the crypto world.

Fungible Tokens - The term "fungible" refers to goods or items that can be exchanged for one another, meaning they are interchangeable. This is not a crypto-native term; regular currency refers to fungible currency.

For example, the $1 bill in my pocket can be exchanged for the $1 bill in your pocket, and both can be used to buy something worth $1; they are equivalent. When interchangeability is applied to crypto concepts, it refers to whether it can be exchanged with other crypto assets in the same set. My Ether can be exchanged for your Ether.

Non-Fungible Tokens (NFTs) - Non-fungible tokens refer to digital assets that are irreplaceable due to their unique existence.

While NFTs have primarily gained attention for digital art and collectibles, they are not limited to these forms; they can be any unique digital asset.

Digital art and collectibles happen to be among the earliest use cases for NFTs and have resonated widely with the public. This type of token has sparked interest in the crypto space for many, but I believe the rise of NFT projects like Bored Apes and NBA Top Shot has led the general public to underestimate the other utilities that come with deploying unique digital assets on a trusted settlement layer like the Ethereum blockchain.

Conceptually, NFTs can also be applied to many use cases beyond digital collectibles. If a product or service requires the ability to verify the ownership and scarcity of a specific digital asset, then NFTs on a public blockchain come into play.

For example, concert venues might use NFTs instead of tickets, or video game designers could turn hard-to-obtain assets in the game into NFTs, allowing users to transfer or trade them.

This concept can also take new forms: some assets can be both fungible and non-fungible, depending on the set they are compared to. For instance, if I hold a 19th-century $1 coin and place it as a collectible in a glass jar. Clearly, this $1 (non-fungible!) is entirely different from a crumpled-up dollar bill stuffed in my pocket.

However, if I take the $1 from the glass jar to spend at Starbucks, they might be willing to accept it. This is because, to some extent, it is interchangeable with other $1 bills, even though from another perspective, they are entirely different.

Source: Graphical Guide to Understanding Uniswap

Ethereum 201 - Further Insights

In this section, I will explain why gas costs are high, how composability works, and how users interact with applications built on Ethereum.

Gas - Every interaction with the Ethereum blockchain incurs a cost (gas), which depends on how much computational power the Ethereum Virtual Machine consumes to run that specific code.

Since each block on the blockchain can only accommodate a fixed number of transactions, the concept of gas helps Ethereum allocate scarce block space resources.

The more complex a transaction, the more gas it may require to complete. For example, sending Ether from one wallet to another might only require a few lines of code to run on the virtual machine, so it needs less gas than a computation-heavy interaction, such as exchanging tokens on a decentralized exchange (see the decentralized finance section below for more).

You can think of gas as similar to the service fees charged by centralized credit card companies.

For example, Visa, which has been created, operated, and maintained since the 1950s, charges a fixed fee of 3% for all transactions using the Visa network.

In contrast, Ethereum's "transaction fees" are not fixed; they depend on the supply and demand conditions of the network at the time of the transaction. Gas fees are used to pay the computers participating in the operation of the Ethereum blockchain (read more below).

Gas is priced in ETH, and users can choose to pay more gas (by tipping the computers) to speed up transaction times and increase the chances of their transaction being packaged into the next block.

Gwei - Technically, gas prices are expressed in wei, which is the smallest increment of ETH. 1 wei equals 0.000000000000000001 ETH (10^18 wei, which takes 5 commas to express 1 ETH), and 1 gwei equals 1,000,000,000 wei, so it is more convenient to compare gas prices in gwei to ETH.

Users have become accustomed to expressing gas prices in gwei. For example, 0.0001 ETH is 1 gwei, which is a low gas fee. Users can use Gas.Watch to monitor real-time gas prices. Gas prices will fluctuate with the demand for transactions packaged into the blockchain.

It should be pronounced as gwey, but I have heard some people say goo-ee. So, I am hesitant to ask others how to pronounce it.

Sidebar - Why is gas needed, and how is it applied?

Computers responsible for validating blockchain transactions need to be economically incentivized. Without these incentives, it would be challenging to persuade them to operate computers and the blockchain, and if there are not enough computers running on-chain, it would lead to the blockchain becoming overly centralized, controlled by just a few users.

As mentioned above, the gas paid to network participants fluctuates based on the demand for transactions packaged into the blockchain.

Source: Understanding Ethereum

Solidity - Solidity is a programming language that users can use to write smart contracts and create decentralized applications on the Ethereum blockchain.

Importantly, Solidity is a Turing-complete programming language, which essentially means "anything you can write in code can be written in Solidity." This indicates that developers can use Solidity to create a wide range of cool applications on Ethereum.

Composability - Since smart contracts are deployed as open-source code on Ethereum, anyone can build on top of these smart contracts (or "fork" the code and modify it), indicating that applications on Ethereum (and other similar blockchains) are composable.

You can think of composability as the API of the blockchain. Although developers could theoretically create applications based on other technological infrastructures in earlier generations, the difference in crypto composability compared to other fields lies in the fact that all underlying protocols are decentralized.

In other words, developers do not have to worry about a centralized entity controlling all the underlying data and suddenly changing the platform's rules or restricting developers' access, as developers building applications based on the Twitter API encountered in 2018.

Sidebar - What are some examples of composability? How is it applied in practice?

Composability refers to developers being able to create new applications using other applications that have already been built and deployed on the public chain.

For example, Compound, as a DeFi application, allows users to earn profits through deposits like a high-yield savings account. Suppose a developer of a project (like the Argent crypto wallet) wants to embed Compound into their application; they can easily integrate Compound without having to rebuild the system. This is composability.

Source: Understanding Ethereum

Ethereum Improvement Proposals (EIPs) - Given that blockchains like Ethereum are inherently public, decentralized, and open-source, the way their developer communities modify protocols is vastly different from how centralized entities make decisions. The development process of modern open-source communities (like the active communities of Linux and Python) is more similar to that of Ethereum.

The Ethereum community has established a process to outline how community members can propose improvements to the Ethereum protocol. This process includes providing public forums for discussion and encouraging community participation in open-source, which is particularly important for the Ethereum blockchain as it is a decentralized blockchain that relies on a globally distributed community for oversight and improvement.

Proposals can relate to the core rules that the blockchain follows (such as when to reach consensus) or propose a standardized version of core building blocks of Ethereum, such as non-fungible tokens or wallets (described below). When users build an application using Ethereum's composability based on certain standardized protocols, it is evident that the code will function as expected.

Ethereum Request for Comments (ERC) - ERC is a category of EIP, specifically, ERC is an EIP that describes "application-level standards and agreements."

These types of EIPs are worth mentioning here because they serve as templates for contract standards for some of the most important and well-known use cases on Ethereum. Developers can use these contract standards when building on Ethereum to save time and effort instead of starting from scratch. Some well-known ERCs include:

ERC-20: This is a token standard for fungible tokens.

ERC-721: This is a token standard for non-fungible tokens.

ERC-1155: This is a token standard that optimizes some ERC-20 and ERC-721 tokens, generally used for fractionalized non-fungible tokens.

Sidebar - Why break down (or make fungible) non-fungible tokens?

Although the concept of fractionalized NFTs sounds paradoxical, there are several different use cases for it.

The best way to interpret it is that some artworks are very expensive (for example, Beeple's NFT sold for $69 million or the Mona Lisa painting), making it difficult for ordinary people to afford. Fractionalizing an expensive NFT gives consumers the opportunity to hold a small part of a valuable, non-fungible token.

It is worth noting that most fractionalized NFT shards are interchangeable, so a shard of the Mona Lisa's face held by one user would not conflict with a shard of its hand or background (i.e., the shards are equivalent).

However, these different parts of the shards are not actually fungible (I would prefer to spend less money on a background shard than on a face shard), and in reality, users would only hold a small interchangeable shard of the entire artwork.

Fractionalizing NFTs is not just about money. NFTs represent unique digital assets, so fractionalizing NFTs also implies concepts of ownership, identity, and community.

Testnets - A testnet is a copy of the blockchain that allows developers to develop freely and test how their code will run on the "mainnet" blockchain.

Once developers deploy smart contracts on the blockchain, even though some smart contracts may no longer be in use, as long as the blockchain remains active, this code is visible.

Due to this permanence and the potential for smart contracts to interact with large amounts of funds, developers want to ensure their code runs as expected by testing it on a testnet.

In the case of Ethereum, there are several testnets (like Rinkeby, Ropsten, and Kovan) available for developers to test their code without risking real assets. Testnets serve as a development practice environment for crypto software developers.

Faucets - Faucets distribute "fake" ETH to developers so they can use these test coins to test smart contracts on the testnet.

Developers need ETH to deploy smart contracts and interact with them, but unlike the ETH on the mainnet, the testnet test coins have no real economic value. Faucets are a convenient way for developers to obtain ETH test coins.

Imagine you are a developer preparing to deploy a smart contract on Ethereum. Suppose the smart contract you have will handle some funds, possibly similar to a decentralized exchange (discussed in the decentralized finance section below).

First, you want to test the smart contract on the testnet to ensure the code runs as expected. You will need some testnet ETH to run the smart contract.

However, keep in mind that the testnet is merely a copy of the Ethereum blockchain, so the ETH on the testnet is essentially "fake," meaning these tokens cannot be exchanged for ETH on the mainnet.

If readers want to test contracts with Ether and observe their actual operation, faucets can conveniently provide users with ETH to use/spend on the testnet.

Oracles - Oracles can be used to connect blockchains with external systems as needed. At times, applications built on Ethereum may wish to interact with external data streams protected by non-Ethereum networks. Some data must be retrieved off-chain, such as today's weather or the score of a basketball game.

Thus, oracles serve as an interface to the "real world."

For crop insurance, oracles can be used to query the weather near orange groves in Florida or to verify scores for decentralized sports betting applications. Oracles have potential trust issues (because the network of computers that make up the blockchain cannot truly verify the weather in Florida), but there are good solutions to address this risk for applications that require oracles.

Oracle providers (like Chainlink) build systems to try to ensure their oracles are not easily attacked (but individual oracles remain a vulnerable point on the blockchain).

Readers can imagine establishing a consensus mechanism for the oracle system (composed of multiple oracles); even though there are vulnerable points (because off-chain data can always be manipulated in some way), it still requires 9 out of 16 oracles to reach consensus on the information of the oracle network. Or a similar mechanism.

Mempool - When a transaction has been submitted by a user but has not yet been validated and packaged onto the chain, this pending transaction is sent to a waiting area called the mempool.

Before processing transactions, the computer nodes in the network will validate the transaction's validity. For example, when an account sends a transaction, it may spend more than the valid funds in the account, or there may be a mismatch between the private key and the public key of the initiating wallet (see the wallet and identity verification section below for more). While the computers in the network validate these potential issues, the pending transactions wait in the mempool.

Technically, each participant in the network has its own mempool, but for the sake of simplicity for entry-level readers, it is acceptable to think of the mempool as the waiting area for all blockchain transactions.

Typically, transactions wait in the mempool for a few seconds to a few minutes, depending on demand (discussed further in the scalability section below).

Pending transactions on Ethereum can be viewed on data providers like Etherscan.

Sidebar - How do users and applications interact with Ethereum?

Users primarily use web applications through browsers like Chrome. These web applications are built using specific libraries (like web3.js or ethers.js) that allow web applications to interact directly with blockchain nodes.

Source: Understanding Ethereum

Applications built by developers interact with Ethereum by running client software on nodes. In the example below, the running client is Geth, which is a command-line interface for interacting with the Ethereum blockchain.

There are also "node-as-a-service" providers like Infura, which allow developers to conveniently interact with nodes controlled by service providers, similar to how developers access server space using AWS. Subsequently, these nodes can interact with smart contracts and individual account balances on Ethereum.

This is quite different from the "backend" vs. "frontend" of other software products today. In the lower left diagram, we can see how a user connects to a traditional web application.

Next to this diagram is an example of the architecture of an Ethereum-based application. The two are remarkably similar! The difference is that Ethereum serves as a backend infrastructure for crypto applications, giving it global, permissionless, and censorship-resistant characteristics.

Source: The Architecture of a Web3.0 Application

Ethereum 301 - Wallets and Identity

By design, blockchains enable users to self-custody their assets, but the role of wallets goes beyond just giving users the right to self-custody; it also represents users' self-presentation in the crypto world.

In this section, I will introduce the relationship between DAOs and identity, as well as how users can ensure the security of their wallets.

Wallets - Storing your assets in a crypto wallet is like keeping cash in a physical wallet. However, these crypto wallets also store information that represents you and your actions, such as the applications you have interacted with and the transactions made with that wallet.

It is important to remember that, by design, blockchain transactions are public and transparent, so when you do something with your wallet on Ethereum, your wallet manages traceable, public data about those transactions.

This traceable data emphasizes the concept of "owning your data" in web3—your assets, transaction history, and data interacting with decentralized applications move with your wallet. Moreover, unlike physical wallets, many crypto users use multiple wallets for different purposes.

Here, other definitions need to be understood to fully explain the concept of wallets:

Public Key - This is a long line of code representing the external address of the wallet. The public key is like your home address; it is unique and not secret (public records, etc.). This address corresponds to a household (or in this case, an account).

You might share your address with friends who want to send you letters or gifts, but even if someone sees your home address in local government property records, it is not a problem. If someone sees your public key, that is also fine.

Private Key - On the other hand, the private key is the password to the wallet, so you should not let anyone know your private key. The private key corresponds to the public key of a specific wallet, so if someone obtains the private key, they can fully access the wallet.

The private key is like the key to your home; you don't mind if someone randomly knows your home address, but if they have the key to your home, you would be understandably anxious.

To reiterate—anyone who obtains the private key can access the corresponding wallet, so do not share your private key with anyone, and do not store it in a place where others can find it.

Sidebar - What is the principle behind public and private keys?

The mechanism behind public and private keys is very important foundational knowledge. Essentially, public and private keys are a method used for encryption and identity verification called asymmetric cryptography.

Remember that the public key is publicly available. When a user initiates a transaction to their friend's wallet (using their friend's public key), it is like locking the transaction, which can only be unlocked when the user's friend actually holds the private key of the receiving wallet. Although the transaction is visible (because it exists on the public chain), without the specific private key (the wallet holding the asset corresponding to the private key), those assets cannot be "unlocked."

Whether you are a developer building projects on Ethereum or just a user, it is crucial to understand the difference between public and private keys. Misusing (or "misplacing") public and private keys can lead to severe financial consequences, and unlike forgetting a password on a centralized website, application developers cannot help users recover keys.

As more users create crypto wallets and transact on the blockchain, this transaction model will become more standardized. At the same time, it is also essential to pay attention to the learning curve and help explain to other users.

Source: How to Generate Public and Private Keys

Mnemonic Phrase - A set of mnemonic words (usually 12 to 24 random words) is the ultimate wallet recovery tool in emergencies. It needs to be protected just like a private key because losing the mnemonic phrase or storing it in a discoverable place means exposing everything about the wallet.

Users must take appropriate measures to securely store the mnemonic phrase to ensure its safety and confidentiality.

Developers of wallet applications cannot access the mnemonic phrase, so if readers lose their keys and mnemonic phrase, their wallet cannot be recovered. If only the private key is lost, the wallet can still be recovered using the mnemonic phrase.

Custodial Wallets - These wallets are managed by custodians (any centralized entity responsible for managing wallet funds), such as a regular Coinbase account, which is custodial. These custodians are responsible for managing the basic assets in the wallet (therefore, if users use a custodial wallet, they do not have to manage their private keys) to provide users with a more centralized and smoother user experience.

This user experience typically does not include crypto-native identity verification mechanisms; for example, a user can log into their Coinbase account using their Google email address and password.

Custodial wallets are a good way to start your crypto journey and a practical method for converting cash assets into cryptocurrencies. On the other hand, since these custodians are held and managed by centralized entities, they also bring some of the issues that decentralization aims to solve, such as data ownership, information flow control, and potential regulatory requirements.

A popular saying in the crypto world about custodial wallets is, "Not your keys, not your coins."

Even Coinbase's CEO Brian Armstrong has mentioned the importance of non-custodial wallets, as custodial wallet providers may face regulatory risks from the government. For users who prefer to manage their assets and transactions in a completely decentralized manner, non-custodial wallets are a better choice.

Non-Custodial Wallets - The managers of these wallets are simply... you! Software providers (like MetaMask, Argent, and Rainbow) offer users software to access their wallets, but importantly, the wallet assets are stored on-chain rather than with the wallet provider.

Therefore, if something happens to the MetaMask wallet that prevents access, users can switch to the Rainbow wallet, import their wallet (without needing permission from MetaMask), and manage their assets through Rainbow.

There are also non-custodial hardware wallets, where the private keys are stored directly in a physical device (usually a small metal object that looks like a USB).

Using non-custodial wallets comes with the burden of managing public keys, private keys, and mnemonic phrases, but these wallets give users autonomy (directly holding assets) and serve as the only identity for accessing the Ethereum world.

Ethereum applications allow users to "Sign in with Ethereum," meaning "log in with your non-custodial wallet." Thus, non-custodial wallets represent users' identities, expanding the design space of the crypto world with new ways of thinking about identity, credentials, and ownership.

Social Recovery Wallets - This is a wallet recovery strategy supported by some non-custodial wallet providers.

These wallets do not require a mnemonic phrase (as some users have lost their mnemonic phrases); users can delegate others in their social network to verify whether the wallet corresponds to the person it should correspond to. Through social recovery wallets, users can back their non-custodial wallets with the trust network of their social circle while still retaining the advantages of self-custody/decentralization/single sign-on.

Argent is an example of a social recovery wallet.

Sidebar - How can users ensure the security of wallet usage?

I do not intend to use charts in this section, as it is unrealistic to put all the necessary information about wallet security into a single chart. In the crypto world, wallet security is crucial and worth spending some time exploring best practices for managing funds.

@Punk6529 published a great Twitter thread covering all the information users need to pay attention to for securely using wallets.

Vitalik has written extensively about the importance of social recovery wallets (click here to read the Chinese version). Here is more information about wallet security from hardware wallet provider Ledger.

Here are some highlights from @Punk6529's long tweet, but I strongly recommend readers to read the entire thread on Twitter:

"Unlike public keys, never disclose your private key to anyone. If someone gets your private key, it's game over."

"Address/Public Key: Your email address (can be shared)

Private Key: The password to your inbox (never share)

Wallet: Stores the private key

Mnemonic Phrase: The recovery system for the private key (never share)

Password (optional): An additional password for creating a new wallet (never lose)

Security and resilience are conflicting goals: printing your private key on a flyer is highly resilient, but your NFTs will disappear (the private key is leaked). You can easily solve security issues by destroying the private key, but the consequence is that you also cannot access your NFTs. Balancing these two goals of security and resilience is an art.

Ethereum Name Service (ENS) - The Ethereum Name Service is an open-source domain name system born for the Ethereum blockchain, somewhat similar to traditional website domain providers.

ENS maps addresses on Ethereum to human-readable names, allowing me to use something like "brunny.eth" as my address instead of this long string of public key: 0xF67cAEbBbE7b630d137d2901637C02899ED3211b.

Readers can try this directly in their crypto wallets (custodial or non-custodial): create a small transaction sending a small amount of ETH, not using my public key, but using "brunny.eth" as the recipient. This service will match "brunny.eth" with the corresponding wallet address.

Overall, as a public good, ENS domains are crucial for identity within the Ethereum ecosystem, and thus they deserve their own version of a domain name system.

Decentralized Autonomous Organizations (DAOs) - DAOs are a crypto-native form of organization. They can be companies, non-profits, social groups, or any other type of organization that self-manages and organizes based on crypto-native rules.

The crypto-native rules here refer to concepts like community ownership, transparency, and decentralization, and it is worth noting that decentralization exists on a spectrum rather than being a binary state.

Unlike traditional companies that have centralized ownership and management in creating and leading organizational structures, DAOs are designed to operate projects and businesses in a decentralized manner without a central entity making decisions, striving for community ownership of the project.

Another vision of many DAOs is to achieve complete decentralization and democratization. That is, various decisions within the DAO are made democratically by the main participants voting.

DAOs can vote not only on changes to application-level products on-chain but also play a role in rewarding and incentivizing participants in the system.

Some DAOs are indeed very close to the level of autonomy, in a sense, with many functions of the DAO being run by automatically executed smart contract code.

An example of this is DAOs in DeFi, where the core value proposition of such DAOs is the decentralized maintenance of smart contracts serving certain purposes in DeFi. Most DAOs gradually evolve toward decentralization, with many being more akin to a group chat about a bank account rather than a truly autonomous organization.

DAOs are, in fact, social byproducts of various things, including permissionless blockchains, non-custodial wallets, identity verification tools (like ENS), and the shared willingness of ecosystem participants.

DAOs deserve a dedicated section for description (or even an entire guide!), but my personal view is that the DAOs you participate in within the crypto space are key to redefining digital-native identity, so it makes sense to discuss DAOs alongside "identity" in this chapter.

Narrow DAC

The DAC mentioned earlier is a broader concept. However, a strictly defined DAC must be fully decentralized. This is reflected in not relying on centralized servers, not depending on centralized central leadership, and not relying on centralized domains.

For a narrow DAC, the entire system and code of conduct must be completely open and transparent. If it appears in the form of software or a network system, it must have fully open-source code. Every participating node has the right to understand every detail and every line of code that runs the system.

Secondly, the servers that play a central role must decentralize their computing and storage functions, deploying computational and storage capabilities across every participating node in the system based on fairness and openness principles. Each node can participate in the overall system's computing and storage operations, providing services based on its capabilities, and the entire system will provide corresponding feedback based on the contribution of each node's capabilities. This feedback is likely to be a reward in the form of system shares. Depending on the system, this behavior of nodes providing services to the system is usually referred to as mining, and the nodes providing mining behavior are called miners.

Narrow DAC

As the developers and leaders of the entire system, their position within the system must be equal to that of other participants (nodes) in the system, without any privileges. Whether project leaders or developers, they are merely performing different roles and must respond to questions within the community. If more than 51% (this ratio is not fixed and can be modified according to the initial terms of the DAC) of the nodes oppose their actions, they can be removed and new leaders elected. The rest must abide by these decisions or voluntarily leave the DAC. Theoretically, if a DAC experiences significant opposition and the two sides cannot reconcile, it can split into two independent DACs.

For a strictly defined DAC, there should not be any significant centralized elements in the entire system, such as domains, copyrights, or any corporate assets. That is, these things cannot belong to a specific person or a few people within the system; if they do, they must be decentralized. If they cannot be decentralized, they must be abandoned.

Some may find the strict definition of DAC somewhat harsh, but if complete decentralization cannot be achieved, the human factors in the entire process cannot be minimized. Similar to Bitcoin and BitShares, both conform to the concept of a narrow DAC.

Broad DAC

From a broader perspective, many traditional centralized organizations or systems also have the opportunity to transform into DACs, or some organizational systems may not be able to achieve complete decentralization for certain reasons, but that does not prevent them from becoming a DAC. For example, some websites, because the domain itself is a centralized entity, as of now, we cannot objectively decentralize all domains, but it is still possible to become a broadly defined DAC while retaining some centralized assets.

However, even as a broadly defined DAC, the most basic principle remains that all rules of conduct within the system must be public, and there must be democracy and fairness among nodes. These rules will include the overall goals of the system, operational mechanisms, benefit distribution mechanisms, node service (mining) mechanisms, and voting mechanisms. Undoubtedly, the public transparency of all rules and principles in the system must be the bottom line for all DACs, and all details must be clear and quantifiable; vague or unquantifiable details are of no help to the system.

Democracy and fairness among nodes are also a bottom line that DACs cannot breach. In a broadly defined DAC, this democracy and fairness are relative. Due to some unchangeable objective reasons, a certain degree of asset and rights inequality can be allowed, such as a server and domain belonging to a specific person within the system, but this degree of inequality must remain within a controllable range. If a certain person (node) or group of people (nodes) participating in the system has more non-transferable rights than others (nodes), this system cannot be called a DAC. This non-transferability means that after a unanimous vote by all, even if they obtain more than 51% of the votes, there are still rights and assets that cannot be removed; this organization cannot be considered a DAC.

Summary

From the definitions above, it can be seen that the broad DAC and narrow DAC mainly make some concessions between democracy and fairness due to objective conditions. However, I believe that the broad DAC is a transitional stage for organizations and systems moving towards a narrow DAC, and we should believe that a strictly defined DAC is the goal we pursue in the future.

DAC Laws

Isaac Asimov's three laws of robotics are very famous in science fiction. Similarly, for DACs, which are very similar to robotic mechanisms, Stan Larimer, who participated in defining DACs, has prepared three laws for us.

First Law

A DAC must adhere to the business rules it publishes.

Second Law

Unless it violates the First Law, a DAC can only change its rules with the consent of the shareholders.

Third Law

Without violating the First and Second Laws, a DAC must protect itself.

In the practical implementation of DACs, these three laws should be seriously incorporated into the system's guidelines, allowing all shareholders to verify whether these three laws have been strictly formulated. Through these three laws, the protection of shareholder rights within the system and how other rules are changed can be monitored, but they themselves can never autonomously change these rules.

First Law: Integrity Mechanism

Multiple DAC nodes mutually review the behavior of each DAC node to ensure that all rules can be enforced. The rogue behavior of a single node can be simply blocked by the collective. Even the system's creators' failure to follow the rules is ineffective, and hostile high-pressure control will also be ineffective.

Second Law: Non-Invasion Mechanism

It ensures that any changes to DAC rules (source code) cannot be executed without the consent of a majority of shareholders; without collective agreement from more than half of the votes, the invasion of a small number of nodes will also not succeed.

Third Law: Self-Protection

It enables the entire system to take more measures to resist any threats to the survival of the DAC. The first two laws have already reduced the possibility of introducing bad nodes. An open system or open-source software can greatly prevent the potential collapse of the entire system due to the introduction of bad nodes.

However, a more serious danger is that DACs that must be exposed to all hostile environments and those developers and personnel within the DAC who are constantly under strict regulation may be subjected to various methods, such as shutting down websites, strengthening regulation through laws, issuing bans, or even more sinister methods of regulation and restraint, which can often cause fatal harm to DACs. If a DAC is to exist as a trusted entity, the best way is to achieve international autonomy through node services.