Ethereum consists of five main parts:

Ethereum consists of five main parts:#

"Ethereum 101" Basics

"Ethereum 201" In-depth exploration of 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 share it as a link with friends who are recently interested 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 a blockchain is, how blocks are added to the chain, how Ethereum operates like a global computer, and how smart contracts function.

Blockchain - A blockchain refers to a public ledger of all transactions processed and maintained by a series of independent computers within a specific network. Unlike centralized management of transaction databases (like how Amazon or Facebook control their 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 a record of all transactions.

These protocols allow computers to agree on all (transaction) actions occurring in 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 computers 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 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 the blockchain agree on the facts occurring in the network, this is called "reaching consensus." Individual computers reach consensus based on the blockchain's rules, and every 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 computers have no objections to each new transaction being added to the chain, it is equivalent to agreeing to the entire historical record of the blockchain, as they must participate in every step of it.

Consensus is a crucial concept that underpins the entire blockchain world. How to verify transactions occurring above without trusting any participant in a trustless network is a very challenging human problem, and blockchain is the optimal solution to this problem. 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, transactions verified as legitimate 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 has its drawbacks, mainly:

Ultimately, the most powerful (and expensive) computers can solve problems faster, leading to the rich getting 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) in exchange for the chance to enter a random selection process. The randomly selected computer needs to verify the next batch of incoming transactions. When the randomly selected computer correctly processes the transactions (within the limits of the proof of stake mechanism), it can earn rewards.

If a participant randomly selected by the network violates the rules of the proof of stake mechanism, then the assets staked by that participant 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 computation 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, helping to validate blocks and package them onto the chain. These nodes also provide validity proofs 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 if one client has a bug or problem.

Currently, there are execution clients and consensus clients, but this is beyond the scope of the 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 specific point in time. Once something new occurs (like processing a new transaction block), the state will update and 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 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 receives the funds.

When such a transaction is packaged onto the Ethereum blockchain, various nodes need to 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 simply a way for all users to reach consensus on the historical transactions occurring in the network, while the blockchain state is the real-time updated account balances after 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, which are then enforced through lawyers and the judicial system.

In a smart contract, two or more users also create a set of rules, but instead of being enforced through the judicial system, they are written in code as a smart contract 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 to enforce them.

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 agreeing on a simple rule: if Bitcoin exceeds $100,000 on January 1, 2032, the smart contract will release those funds to User A; otherwise, it 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 global 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 that can write smart contract code and deploy it directly onto the chain.

Ethereum Foundation researcher John Stark wrote an article about smart contracts, and 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 staked by participants 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 Ethereum Virtual Machine refers to a "virtual" computer composed 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, such as transferring Ether from one wallet to another, represented by the box at the top of the diagram, which is "Information Calling 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 serve as currency or assets that provide voting rights to holders in specific decision-making processes (governance tokens), or they can represent something entirely different. 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 in my pocket can be exchanged for the $1 in your pocket, and both $1 bills 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.

Although NFTs gained popularity primarily due to 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 one of the earliest use cases for NFTs, which have resonated widely with the public. This type of token has sparked interest in the crypto space, but I believe the rise of NFT projects like Bored Apes and NBA Top Shot has led the general public to underestimate the other utility that comes from 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 games into NFTs, allowing users to transfer or trade them.

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

However, if I take the $1 from the glass jar to 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.

More complex transactions may require paying more gas to complete. For example, sending Ether from one wallet to another might only require running a few lines of code on the virtual machine, so it requires 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% on all transactions using the Visa network.

In contrast, Ethereum's "transaction fees" are not fixed; they depend on the supply and demand situation 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, the price of gas is expressed in wei, which is the smallest increment of ETH. 1 wei equals 0.000000000000000001 ETH (10^18 wei, which takes 5 commas to represent 1 ETH), and 1 gwei equals 1,000,000,000 wei, so it is more convenient to compare gas prices using gwei to ETH.

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

It should be pronounced as gwey, but I have heard some people pronounce it as 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 verifying blockchain transactions need to be economically incentivized. Without these incentives, it would be challenging to persuade them to operate computers and maintain the blockchain, and if there are not enough computers running on-chain, it will lead to excessive centralization of the blockchain, 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 develop a wide range of cool things 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 several generations ago, 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 public chains.

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 the application they are building; 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 set of processes to outline how community members can propose improvements to the Ethereum protocol. These processes include 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 relying on a globally distributed community for oversight and improvement.

Proposals can relate to the core rules that the blockchain follows (like when to reach consensus) or propose a standardized version of core components of Ethereum, such as non-fungible tokens or wallets (described further below). When users build an application using Ethereum's composability based on certain standardized protocols, it is evident that the code will run 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."

This type of EIP is worth mentioning here because it serves as a template for the contract standards of 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 rather than 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 parts of ERC-20 and ERC-721, 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 (like 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 portion of a valuable, non-fungible token.

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

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

Fractionalized NFTs are not just about money. NFTs represent unique digital assets, so fractionalized NFTs also imply concepts of ownership, identity, and community.

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

Once developers deploy smart contracts on the blockchain, even if some smart contracts are no longer 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 test on a testnet to ensure the code will run as expected.

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's test coins have no actual 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 fetched 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 vulnerable points on the blockchain).

Readers can envision establishing a consensus mechanism for the oracle system (composed of multiple oracles), where, despite the presence of vulnerabilities (because off-chain data can always be manipulated in some way), 9 out of 16 oracles must 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 verified and packaged onto the chain, this pending transaction is sent to a waiting area called the mempool.

Before processing transactions, the computers in the network verify the validity of the transactions. 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 section below on wallets and identity verification for more). While the computers in the network verify 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 beginner readers, it is acceptable to think of the mempool as a 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 below regarding scalability).

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

Sidebar - How do users and applications interact with Ethereum?

Users typically 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 directly interact 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 use AWS to access server space. 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 very 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 is not only to give users the right to self-custody; it is also the user's 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 wallet security.

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 idea 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 will use multiple crypto wallets for different purposes.

Here, it is also necessary to understand other definitions 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 record, etc.). This address corresponds to a household (or in this case, an account of yours).

You might share your address with friends who want to send you letters or gifts, but it’s not a problem if someone sees your home address in the local government's property records. Similarly, it’s fine if someone sees your public key.

Private Key - On the other hand, the private key is the password to the wallet, so you must 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 certainly be uneasy.

To reiterate—anyone who obtains the private key can access the corresponding wallet; 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 methods used for encryption and identity verification, known as public-key cryptography.

Remember that the public key is publicly accessible. When a user initiates a transaction to a friend's wallet (using the 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 a public chain), the assets cannot be "unlocked" without the specific private key (the wallet holding the assets corresponding to the private key).

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 as securely as the private key because losing the mnemonic phrase or storing it in a discoverable place means exposing everything in the wallet.

Users must take appropriate measures to save the mnemonic phrase, ensuring its security and confidentiality.

Developers of wallet applications cannot access the mnemonic phrase, so if readers lose their keys and mnemonic phrase, then 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 (so if users use a custodial wallet, they do not have to manage their own 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 a Google email address and password.

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

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

Even Coinbase's CEO Brian Armstrong has mentioned the importance of non-custodial wallets, as custodial wallet providers face the risk of government regulation. For users who prefer to manage their assets and transactions in a fully 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) provide users with software to access their wallets, but primarily, 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 MetaMask's permission), and manage their assets through Rainbow.

There are also non-custodial hardware wallets, where the private key is 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 grant users autonomy (directly holding assets) and serve as the sole identity for accessing the Ethereum world.

Ethereum applications allow users to "Sign in with Ethereum," meaning "log in using their non-custodial wallet." Thus, non-custodial wallets represent users' identities, expanding the design space in the crypto world regarding 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 a trust network based on 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 wallet security?

I do not intend to use charts in this section, as it is unrealistic to put all necessary information about wallet security into a single chart. In the crypto world, wallet security is crucial, and it is 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 secure wallet usage.

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 tweet themselves on Twitter:

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

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

Private Key: Password to your inbox (never share)

Wallet: Stores your private key

Mnemonic Phrase: Private key recovery system (never share)

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

Security and resilience are conflicting goals: printing your private key on a flyer is very resilient, but your NFT will disappear (the private key is leaked). You can easily solve security issues by destroying your private key, but the consequence is that you will also lose access to your NFTs. Balancing 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, so I can 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 very important for identity in 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 as two extremes of centralized and decentralized.

Unlike traditional companies that have centralized control over the creation and leadership of 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 projects.

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

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, as the automatically executed smart contract code runs many functions of the DAO.

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 are gradually evolving toward decentralization, and many of them are more akin to group chats about bank accounts rather than truly autonomous organizations.

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 to be described in a dedicated section (or even an entire guide!), but my personal view is that participating in DAOs in the crypto space is key to redefining digital-native identity, so it makes sense to discuss DAOs alongside "identity" in this chapter.

Narrow Definition of DAC

The DAC mentioned earlier is a broader concept. However, a strictly defined DAC must first achieve complete decentralization. This is reflected in not relying on centralized servers, not depending on centralized central leadership, and not relying on centralized domain names.

For a narrowly defined 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 be fully open-source. Every participating node has the right to understand every detail of how the system operates and every line of code.

Secondly, the servers that play a centralized role must decentralize their computing and storage functions, deploying computational and storage capabilities across every participating node in the system based on fair and open principles. Each node can participate in the overall system's computing and storage operations, providing services according to its capabilities, and the entire system will provide corresponding feedback based on the size of the node's contribution. 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 Definition of 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 nodes oppose their actions, they can be removed and new leadership can be elected. The rest must abide by these decisions or voluntarily leave the DAC. Theoretically, if a DAC experiences significant conflict and the opinions cannot be reconciled, it can split into two independent DACs.

For a strictly defined DAC, there should not be any significant centralized entities within the entire system, such as domain names, copyrights, or any company assets. In other words, these things cannot belong to a specific person or group of people within the system; if they do, they must be decentralized. If they cannot be decentralized, they must be abandoned.

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

Broad Definition of DAC

From a broader perspective, many traditional centralized organizations or systems also have the opportunity to be transformed into DACs, or certain organizational systems may not be able to achieve complete decentralization for various reasons, but that does not prevent them from becoming a DAC. For example, some websites cannot fully decentralize because domain names themselves are centralized entities; as of now, we cannot decentralize all domain names. However, they can still 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, profit distribution mechanisms, node service (mining) mechanisms, and voting mechanisms. Undoubtedly, the public transparency of all rules and principles within the system must be the bottom line for all DACs, and all details must be clear and quantifiable. Ambiguous 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 name belonging to a specific person within the system. However, this degree of inequality must remain within a controllable range. If a particular 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 the entire system, even if they receive 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 and narrow definitions of DAC mainly make some concessions between democracy and fairness due to objective conditions. However, I believe that the broad DAC is a transitional phase for organizations and systems toward 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 in science fiction are very famous. Similarly, for DACs, which are very similar to robotic mechanisms, Stan Larimer, who defines DACs, has also 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 its shareholders.

Third Law

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

In the specific practice of DACs, these three laws should be seriously incorporated into the system rules of the DAC and allow all shareholders to verify whether these three laws have been strictly established. 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 are ineffective if they do not follow the rules, and hostile coercive control will also be ineffective.

Second Law: Non-Invasion Mechanism

It ensures that any changes to DAC rules (source code) are not executed without the consent of the 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 adopt more means to resist any threats to the survival of the DAC. The first two laws have already reduced the likelihood of introducing bad nodes. An open system or open-source software can greatly prevent the possibility of the entire system collapsing due to the introduction of bad nodes through the above means.

However, a more serious danger is that DACs that must be exposed to all hostile environments, as well as those DAC developers and personnel within the system 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 pose fatal harm to DACs. To exist as a trusted entity, the best way for a DAC is to achieve international autonomy through node services.