Considerations

Issues Developers Must Consider:#

Developers need to think about the stakeholder protection services provided by third parties and design decentralized protection methods. If this is not achievable, developers must inform stakeholders that this technology lacks the kind of protection they are accustomed to. Developers may even decide to abandon application development due to high user risks.

Issues Users Must Consider:#

Users must understand the risks that lack of protection poses to themselves and the parties they represent (clients receiving consultations, patients being cared for, citizens whose rights need protection). This risk must be openly acknowledged, and effective informed consent must be obtained from the service recipients. They should also seek non-blockchain solutions that can fill the gaps.

Lack of Privacy

The two most popular blockchains, Bitcoin and Ethereum, are public and known for their transparency and accessibility, allowing anyone to access, add to, and audit the entire blockchain. However, if transparency poses a serious threat to user privacy, private blockchains may be necessary. For example, Nebula Genomics uses private blockchain technology to allow patients to have "complete control" over their genomic data.

Blockchains may contain information that should only be visible to certain users, which may require a hybrid approach that combines private and public blockchains. For instance, electronic health records contain highly sensitive data that must remain private, as well as information that should be shared with institutions like the Centers for Disease Control and Prevention and health insurance providers. Comprehensive blockchains like Hashed Health, Equideum Health, and BurstIQ can share biometric information while giving patients greater control over their data.

Issues Developers Must Consider:

Developers must carefully consider their ethical obligations to balance transparency and privacy, then decide whether the application at hand is best suited for a public blockchain, private blockchain, or hybrid model. One important factor to consider is the potential identification of blockchain members and the ethical consequences that may arise. Other important decisions include determining who can access what data under what conditions and the time frame for access.

Issues Users Must Consider:

Users need to understand the impact of transparency on their business and service recipients. They must be aware of and address the risks of wallet holders potentially being identified (including cases where wallet holders inadvertently disclose their identities).

For example, a customer of a financial services company may want to make an anonymous donation to a charity or political party without disclosing the amount or their political leanings. The financial services company may recommend using blockchain for the transaction, as it would anonymize the customer's identity. However, the company also has an obligation to inform the customer that this anonymous transaction record is public and to discuss the best methods to avoid identity disclosure.

Zero State Issues#

The accuracy of the data contained in the first block, known as the "genesis block," is often questioned, leading to zero state issues. If due diligence on the data is not properly executed, errors or malicious falsifications can occur. For example, in a blockchain used to track goods in a supply chain, the first block may incorrectly show that a truck is loaded with copper from a specific mine, when in fact the copper comes from another source. Personnel associated with the truck's cargo may have been deceived or bribed, and the person who created the genesis block may be unaware.

If we replace the goods here with blood diamonds (unrefined diamond mines used to fund arms for civil war conflicts), the ethical issues become apparent. If the government establishes a blockchain as a database for land registry records, and the person entering information into the first block mistakenly writes down the landowner's name, it could lead to severe injustices, akin to the land being stolen. Organizations like Zcash, which create privacy-protecting cryptocurrencies, naturally strive to ensure the genesis block is accurate.

Issues Developers Must Consider:

Developers must carefully verify all information that the genesis block is to contain, making every effort to ensure this information is accurately entered. They must also alert users to the zero state issue and disclose the fact that the blockchain may contain erroneous information, allowing users to assess potential risks and conduct due diligence.

Issues Users Must Consider:

Blockchain users should examine how the genesis block was created and where the data originated. They should pay special attention to whether the information recorded on the blockchain has ever been the target of fraud, bribery, or theft. They should consider whether the organization that created the genesis block is trustworthy and whether the block has undergone reliable third-party review.

Users also need to understand that even if the data in the genesis block and subsequent blocks is accurate and legitimate, problems can still arise. For instance, if the truck is loaded with legitimately sourced diamonds, and the routes of multiple trips are accurately recorded on the blockchain, clever thieves may still switch the real diamonds for fake ones during transit. Users must inform service recipients about the zero state issue, disclose the due diligence conducted on the genesis block, and find protective measures to prevent fraud (if any exist).

Blockchain Governance

There are many terms used to describe blockchain technology: decentralized, permissionless, self-governing—these terms may lead users to make assumptions about governance, such as thinking it is a paradise for libertarians and anarchists, or that all members have equal say in how the blockchain operates. However, blockchain governance is very complex and involves significant ethical, reputational, legal, and financial implications. Who holds power on the blockchain, how power is obtained, what oversight exists or does not exist, and how decisions are made are all determined by the blockchain's creators. The following two examples illustrate this point—one notorious, the other ongoing.

The first Decentralized Autonomous Organization (DAO) operated on the Ethereum network. It was a hedge fund initially called "The DAO." Members had different voting rights depending on how much they invested in the fund (in Ether). In 2016, The DAO was hacked, and approximately $60 million worth of Ether was stolen. Members had vastly different ideas about how to respond, and there was even disagreement on whether the hacker's actions constituted theft. One faction believed that the funds obtained illegally through a software vulnerability should be reclaimed and returned to the rightful owners. Another faction believed that The DAO should not consider rewriting fraudulent transactions, but simply fix the vulnerability and allow the blockchain to continue operating. The latter insisted that "rules are law" and "blockchains are immutable," arguing that the hacker's actions complied with the rules and were therefore not ethically unacceptable. Ultimately, the former faction prevailed, and Ethereum implemented a "hard fork" to transfer the funds to a recovery address, allowing users to recover their investments, effectively rewriting the blockchain's record.
The second example involves the governance controversy surrounding Juno. Juno is another decentralized autonomous organization. In February 2021, Juno conducted an "airdrop" on its network, sending free tokens to community members to boost participation. A cryptocurrency wallet holder exploited this system, obtaining a large number of tokens worth over $117 million at the time. In March 2022, the community proposed to remove most of this "whale" user's tokens, reducing their holdings to a normal range for airdrop eligibility. A month later, the proposal passed with a 72% vote, leaving the user with only 50,000 tokens, while the rest were nullified. Now, this user, who claims to be investing with other people's money, threatens to sue Juno.

These incidents illustrate that careful consideration must be given to building governance structures for blockchains and the applications running on them, with due diligence conducted.

Issues Developers Must Consider:

Developers must determine appropriate governance methods, particularly noting that governance structures may leave opportunities for hackers and wrongdoers. This is not a mechanical issue. Developers' values must be clearly expressed and reflected in the blockchain. For example, how Ethereum developers weighed the decision of whether to modify the blockchain or simply fix the vulnerability in the DAO incident reflects the difference in perspectives between the two sides. The divergence between those who voted in favor of confiscating the whale user's tokens and those who opposed it in the Juno incident is similar. To avoid such ethical issues, developers should establish governance guiding principles from the outset.

If the distribution and acquisition of power and money within the system are not carefully considered, conflicts may arise. In the DAO incident, the hacker exploited a software vulnerability, causing chaos within the community: can flawed rules be considered law? In the Juno incident, part of the turmoil stemmed from the lack of thorough consideration regarding the initial distribution of tokens. Developers must understand that those with voting rights have vastly different beliefs, values, ideals, and desires. Sound governance is one of the most important tools for managing these differences, and if developers' values are reflected in the regulatory infrastructure, policies, and processes governing the blockchain, significant ethical and financial risks should be avoidable.

Issues Users Must Consider:

Users must consider whether the values of the blockchain creators align with those of their organization and their clients. They must determine how much volatility, risk, and loss of control they and their clients can tolerate. They must clearly express their standards for good and responsible governance and only use blockchains that meet those standards. Users may be using a decentralized network without a single authority, but they are certainly dealing with some political entity.

Establishing an Ethical Risk Framework for Blockchain

All ethical risks of technology are as numerous as their uses. For example, AI-controlled autonomous vehicles may pose life-threatening risks to pedestrians. Social media applications carry the risk of spreading misinformation. Ethical and reputational risks accompany almost all data-driven technologies, and blockchain is no exception. When applying blockchain, senior leaders must establish a framework to mitigate risks. Various scenarios should be carefully considered: What major ethical issues must our organization strive to avoid? How should edge cases be handled? Ethical issues should be anticipated, and consideration should be given to: What governance structure do we have? What regulatory oversight is needed? Does blockchain technology undermine our organizational values and ethical standards, and if so, how can we mitigate that damage? What protective measures should be in place to safeguard our stakeholders and brand? Fortunately, many of these questions have already been addressed in adjacent AI ethical risk literature, and I have also written a guide on implementing AI ethical projects. All blockchain projects can start with such materials.

Account Abstraction (AA) has been discussed since 2015, with several different versions of EIPs proposed (EIP-101, EIP-86, EIP-859, EIP-2938, EIP-4337). Recently, the development of account abstraction seems to have become a hot topic of discussion in the community, with solutions for account abstraction being gradually introduced at the application level. So what exactly is account abstraction? What do people want to solve through AA? This article discusses Ethereum account types, EIPs for account abstraction, and potential use cases for account abstraction.

The term "smart contract" was first proposed by American computer scientist Nick Szabo in 1994, meaning obligations of the parties to a contract recorded in the form of computer code, enforced by the code under agreed conditions. However, Szabo only proposed the concept without explaining how to implement it. In 1996, Ian Grigg proposed the "Ricardian contract," which could be read by humans and parsed by programs, giving smart contracts legal attributes and becoming the main route for subsequent exploration of smart contracts. The effective implementation of smart contracts requires the following characteristics.

Consistency: Smart contracts need to be consistent with the contract text and not conflict with existing laws. Observability: The content of the contract and its execution process should be observable and transparent, allowing all parties to the contract to observe, record, and verify the contract status through a user interface. Once established, the contract cannot be altered.
Verifiability: The results produced by smart contracts should be verifiable, with a certain degree of fault tolerance. Code execution must comply with the contract, and repeated executions should yield the same results, meeting the conditions to serve as judicial evidence. Privacy: The operation of smart contracts should ensure that the identity information of the parties and the content of the contract are controlled within the "minimum necessary" scope of knowledge, meeting the needs for confidentiality of business information and personal privacy protection.
Self-enforcement: This characteristic is both the core connotation of smart contracts and the main value they provide, meaning that once the conditions specified in the contract are met, the smart contract should have the ability to fulfill obligations without relying on legal enforcement, being unaffected and non-repudiable.
Meeting all of the above conditions is relatively difficult, which is why practical applications of smart contracts have been very limited in the more than a decade since the concept was proposed. Later, "Ethereum" utilized the characteristics of blockchain to achieve the operation of smart contracts through decentralization and immutability. Smart contracts have also been "bound" to blockchain to some extent, leading people to believe that only blockchain and DeFi can realize the value of smart contracts. To date, Ethereum's smart contracts have only been applied in a few areas such as crypto assets, NFTs, gambling, and gaming, without significantly promoting the real economy. Moreover, due to the lack of a scalable application ecosystem and the speculative nature of virtual currencies, applications are also limited. In fact, the concept of smart contracts emerged long before blockchain, and the conditions for their operation are not solely met by blockchain.
Since the advent of Bitcoin, the private sector has launched various so-called cryptocurrencies. According to incomplete statistics, there are currently over 10,000 influential cryptocurrencies, with a total market value exceeding $1.3 trillion. Cryptocurrencies like Bitcoin claim to be "decentralized" and "completely anonymous" through blockchain and cryptographic technology, but limitations such as lack of value support, extreme price volatility, low transaction efficiency, and huge energy consumption make it difficult for them to perform monetary functions in everyday economic activities. At the same time, cryptocurrencies are often used for speculation, posing potential risks to financial security and social stability, and becoming payment tools for illegal economic activities such as money laundering.
To address the issue of significant price volatility in cryptocurrencies, some commercial institutions have launched so-called "stablecoins," attempting to maintain stable value by anchoring to sovereign currencies or related assets. Some commercial institutions plan to launch global stablecoins, which will impact the international monetary system, payment and clearing systems, monetary policy, and cross-border capital flow management.

Recommended reading of the following articles for a better understanding of account abstraction:

✦ "Motivations, History, and Analysis of Account Abstraction" by Sandglass:

https://mp.weixin.qq.com/s/ZGzw3VE-8KEQE5xu7Jw_8A

✦ "Introduction | Overview of Ethereum Account Abstraction" by EthFans:

https://mp.weixin.qq.com/s/3VvjB2GXcH95j2Hr3zcsVg

✦ "Introduction | Account Abstraction (EIP-2938): Why & What It Does" by EthFans:

https://mp.weixin.qq.com/s/CKtk6xKcXFVjyPKDxHBnhw

✦ "On Account Abstraction (2022)" by Sandglass:

https://mirror.xyz/0xbeC73ba0817403cd11C11bE891D671EA30443562/95LlE7sLCL4UTvL7rU3ZAXnBvlDbh7X-rm0QWkc43Us

✦ "EIP-4337" by Plancker DAO:

https://www.notion.so/EIP-4337-0baad80755eb498c81d4651ccb527eb2

Additionally, the first "His Name is Little V" event co-hosted by the Planck community and ECN community shared insights on the EIP-4337 contract wallet.

In computer programming, abstraction and data abstraction refer to the process of hiding all data except for the data related to the "object," aiming to reduce complexity and improve efficiency. It represents objects by omitting unnecessary details. Abstraction is one of the three main principles of object-oriented programming and is related to encapsulation and data hiding. This article will provide an overview of the following aspects:

➤ Ethereum Account Abstraction

External Accounts/User Accounts

Contracts

➤ Proposed EIPs for Account Abstraction

EIP-86: Abstraction of Transaction Origin and Signatures

EIP-2938: Account Abstraction

EIP-4337: Account Abstraction Implemented via Entry Point Contract

➤ Use Cases

Wallets

Sponsored Transactions

Sponsored Transactions are encompassed in EIP-2711 (status: withdrawn), which proposed a mechanism that allows people to transact without owning any ETH by enabling others to pay gas fees.

Some use cases include:

Allowing application developers to pay fees on behalf of users.
Allowing users to pay fees with ERC-20 tokens, with the contract acting as an intermediary to collect ERC-20 tokens and pay network fees in ETH.

Operation

This proposal can support these use cases through a paymaster mechanism.

For use case 1: The Paymaster will verify that the sponsor's signature is included in the paymasterData, indicating readiness to pay for the UserOperation. If the signature is valid, the Paymaster will accept the instruction and deduct the UserOperation fee from the sponsor's share.

For use case 2: The Paymaster will check whether the sender's wallet has enough ERC-20 balance to pay for the UserOperation. If sufficient, the Paymaster will accept the instruction and pay the ETH fee before requesting the ERC-20 tokens in postOp.

Mixing

Let's discuss the example of the Tornado Cash mixing mechanism to understand how we can use AA in DeFi protocols.

Privacy Issues in Traditional Tornado Cash Contracts

When users make withdrawals, Tornado Cash provides them with privacy protection. They can prove that the funds come from a unique deposit, but no one except the user knows where that deposit originated.

Users typically do not hold ETH in their withdrawal addresses; if users use their deposit addresses to pay gas, it creates an on-chain link between the deposit address and the withdrawal address.

This issue can be resolved by third-party relayers, who verify that the ZK-Snark and nullifier remain valid, publish transactions using their ETH to pay gas, and collect users' refunds from the Tornado Cash contract.

Solution Provided by Account Abstraction: Users can submit an AA transaction targeting the TC contract, after which ZK-SNARK verification and nullifier checks are executed, and PAYGAS is called directly and quickly. This allows withdrawers to pay gas directly with tokens sent to their withdrawal address without needing a relayer or creating an on-chain link to their deposit address.

DeFi Protocols

Let's explore the case of the DeFi protocol Uniswap to understand how we can use AA in DeFi protocols.

A new version of Uniswap can be created that allows direct transactions targeting the Uniswap contract.

Currently, users can deposit tokens into Uniswap in advance; Uniswap can store users' balances and public keys to verify transactions spending those balances.

The goal of AA is to improve the gas efficiency of DeFi protocols by prohibiting transactions that do not meet higher standards from being packed onto the chain (e.g., the existence of matching orders).

In the traditional model: Normal traders would store their tokens outside of the Uniswap contract.

In the new model: Arbitrage traders would store their tokens on Uniswap, and in the event of changes in external markets, they could also transfer transactions to execute arbitrage. Ultimately, if another arbitrage trader executes this transaction first, these unprofitable transactions will not be packed onto the chain. This allows arbitrage traders to avoid paying gas and reduces the number of garbage transactions packed onto the chain. This will increase the scalability and market efficiency of the blockchain, as arbitrage traders are better able to correct price discrepancies in cross-chain transactions.

Arbitrage traders refer to traders who exploit price differences between two or more markets by buying low and selling high simultaneously.

Original link: https://etherworld.co/2021/10/06/an-overview-of-account-abstraction-in-ethereum-blockchain/

Six, The Future of Ethereum's PoS Protocol

Casper PoS is a security-deposit based economic consensus protocol. In the protocol, nodes, as "bonded validators," must first deposit collateral (this step is called bonding) to participate in block production and consensus formation. The Casper consensus protocol constrains the behavior of validators through direct control of these deposits. Specifically, if a validator does anything that Casper considers "illegal," their deposit will be forfeited, and their rights to produce blocks and participate in consensus will be revoked. The introduction of deposits addresses the "nothing at stake" problem, which is the low cost of wrongdoing in classic PoS protocols. Now there is a cost, and it is objectively proven that validators who do wrong will pay this cost.

In the future, Ethereum will use the Casper PoS protocol, which does not use computational power for proof but uses digital assets to prove its existence. That is, there is no need to spend money to buy mining machines; instead, one can buy ETH with physical assets to become a validator.

Plain text

Seven, Challenges of Ethereum Programming

Coding is not that difficult, especially if one has a background in other software programming. However, if programmers want to become core developers of Ethereum to study technical issues such as security and scalability, it can be relatively challenging, as this is a very new technology, and only a small portion of people understand these challenges, but it is not impossible. If anyone here wants to join the Ethereum research group, we are also hiring, and of course, we welcome volunteers. In addition, we are quite open to everyone working on other Ethereum projects. In summary, our Ethereum community has many different aspects; some people come in because they are interested in the technology, while others want to do other software development based on it, and some are currently researching on the platform to understand what can be developed on it. Even though blockchain technology has been around for 9 years, I still feel it is very young, developing rapidly, and there are many different ways to get involved.

Plain text

Eight, Recommended Learning Methods by Vitalik

For those interested in becoming Ethereum programmers, I recommend starting to follow these two websites:

http://ethereum.org (This website has tutorials and guides on how to write smart contracts, how to upload them, and how to write apps);

http://github.com (This website has a lot of technical information about how Ethereum models work and more).

The first thing: What is Ethereum?

Ethereum is a platform based on smart contracts, built on decentralized internet applications, capable of programming payments in any Bitcoin/Ether. This means the platform can compare the prices of Bitcoin and Ether trading platforms in different countries around the world through regional blockchains. Once a price difference is found, it buys Bitcoin and Ether from the lower-priced platform and sells it on the higher-priced platform to profit from the price difference. This is a new profession that has gradually emerged in the industry, commonly referred to as "brick-moving" arbitrage.

Using large high-end cloud computing, short-selling or going long on global currency trading platforms (buy low, sell high), completing transactions within 0.28 milliseconds, with unlimited floating trading points for value-added, ensuring every investor's dividends increase. Our members only need to entrust their Bitcoin and Ether to the platform for trading, with no need for any operation. The Ethereum platform guarantees each member a monthly return of up to 15%--25%. As long as digital currencies exist and prices fluctuate, the profit margin will always exist, and there will always be profits to be made, with returns of up to 15%--25%. Everyone knows that this year is the inaugural year for the development of digital currencies, so the platform's ability to generate revenue and stability is self-evident.

The second thing: Company Introduction?

Company Introduction

The company was established in preparation in 2015, and the project was globally launched in 2016. As of now, it has been successfully promoted in over 45 countries, and our platform has 18 language versions globally. Our customer service team has reached hundreds, and our trading team has thousands. In a short period, we have successfully showcased our best side; our team consists of young, vibrant professionals who are always eager to achieve goals. Now, we are gradually mastering compound interest, and through quality asset management services, we have achieved great success.

Our platform trades using your investment and compound interest. The average monthly income is 30%?50%, with half of (15-25%) allocated to investors. The cryptocurrency market allows people to gain more profits, but our strategy primarily focuses on the security of funds.

Here, you are investing in the future of the internet blockchain! We are committed to the global popularization of the Ethereum platform, promoting its quality capabilities and prospects, as well as implementing asset management plans and obtaining economic benefits through cryptocurrency exchange trading activities.

The third thing: Who is the founder?

Ethereum Founder: Vitalik Buterin

A Russian kid who vowed to disrupt the real economic system with blockchain, his newly created blockchain platform has attracted the attention of tech giants like IBM and Samsung, as well as investment banks like Barclays and Credit Suisse.

Born: 1994

Current Position: Founder and Chief Scientist of the blockchain platform "Ethereum"

Education: University of Waterloo, Canada

Awards: Bronze Medal in the Olympiad in Informatics, Thiel Fellowship, 2014 World Technology Award

Blockchain Definition: Blockchain is a decentralized ledger composed of cryptographic algorithms and economic models.

The cryptocurrency he developed is rivaling Bitcoin, and he defeated Facebook founder Mark Zuckerberg to win the 2014 IT Software World Technology Award. This award recognizes Buterin's outstanding achievements in designing and developing the Bitcoin 2.0 platform Ethereum.

Vitalik Buterin's Legendary Story

Born in 1994 in Russia, he began researching Bitcoin at 17 and founded "Bitcoin Magazine."

At 18, he won a Bronze Medal in the Olympiad in Informatics.

At 19, he dropped out of the University of Waterloo in Canada; that November, he published the first version of the "Ethereum White Paper" and began recruiting developers.

At 20, he received the Thiel Fellowship and established the non-profit Ethereum Foundation, publicly presenting the Ethereum project at the Bitcoin conference in Miami. That July, he launched the crowdfunding for the Ethereum project, raising 31,000 Bitcoins (approximately $18.4 million at the time).

At 21, the initial version of Ethereum, Frontier, was released, and Ether began trading publicly on exchanges worldwide.

At 22, he was named one of Fortune magazine's 40 Under 40 in 2016.

Vitalik Buterin, the 22-year-old hacker, disrupts the real economic system.

This September, Fortune magazine's bold headline also became a hot topic of debate among blockchain experts worldwide.

The protagonist of the discussion is the 22-year-old Vitalik Buterin.

He is the founder of the hot blockchain platform Ethereum. At an age when most people have just stepped out of campus, he harbors ambitions to change the world: to disrupt the real economic system with blockchain.

Today, there are over 700 cryptocurrencies based on blockchain technology worldwide, and since Ethereum's launch in late July 2015, it has swept the virtual currency market. As of October 31, 2016, the total market value of Ether (the cryptocurrency that maintains the operation of the Ethereum platform) reached approximately $944 million.

Although it is still far from Bitcoin's $11.18 billion, its rapid rise has led various sectors to view it as Bitcoin's number one competitor.

Vitalik Buterin has attracted over $100 million in investment.

—— Ethereum and related applications and their fundraising amounts

Ethereum public blockchain platform------raised a total of $18.4 million

DigixDAO ------established a gold-backed financial platform on Ethereum, raised $5.5 million

Augur ----- a decentralized market prediction platform based on Ethereum smart contracts, raised $5.32 million

The DAO ----- a venture organization based on the Ethereum platform that invests in shared economy projects using blockchain technology, raised $132 million

The fourth thing: How is the project developing?

Looking back at major events in the Ethereum platform:

On January 1, 2016, the Ethereum project developed abroad, launching in over 40 countries globally, with the platform available in 8 languages.

On August 1, 2016, Ethereum entered China.

On October 22, 2016, a meeting was held in the Philippines.

On October 23, 2016, the first club in China was established.

On November 4, 2016, a meeting was held in Vietnam.

On November 7, 2016, a meeting was held in Russia.

On November 13, 2016, a charity event was held in the Philippines.

On November 18, 2016, the Russian club opened.

On November 24, 2016, the second meeting in Vietnam was held.

On November 28, 2016, a meeting was held in Malaysia.

On December 4, 2016, a charity event was held in the Philippines.

On December 7, 2016, the Russian club opened in Yekaterinburg.

On December 17, 2016, a major conference was held in Moscow.

On December 17, 2016, a football match was held in Pakistan.

On December 18, 2016, a 招商会议 was held in Shenzhen.

On January 8, 2017, the second meeting and club in Malaysia was held.

On January 8, 2017, the second club in China opened in Ningbo.

On January 15, 2017, a 招商会 was held in Yunnan, China.

On January 20, 2017, a group photo was taken of the winter promotion award winners.

On April 10, 2017, Ethereum rapidly developed, with the global membership exceeding 230,000.

On May 21, 2017, global membership exceeded 300,000, and Ether's price surpassed 1,000 yuan. Ethereum became the first digital currency to reach 1,000 yuan after Bitcoin. The history of cryptocurrency has been rewritten!

On May 21, 2017, Ethereum trade's global membership exceeded 427,000, doubling every day! The price of Ethereum soared to 3,000 yuan, and the Enterprise Ethereum Alliance (EEA) added 86 new member institutions! These include Deloitte, DTCC, Infosys, Mitsubishi UFJ Financial Group, Canadian National Bank, State Street Bank, Toyota, Samsung SDS, San Francisco Stock Exchange, Wall Street Emerging Technology Center, Wall Street Blockchain Alliance, Jiangsu Huaxin Blockchain Research Institute, etc. The complete member list can be accessed at: https://entethalliance.org/enterprise-ethereum-alliance-release-05-19-2017.pdf

The Ethereum team developed Ethereum Trade, with Vitalik Buterin as one of the shareholders. The development of Ethereum has laid a sustainable foundation for Ethereum Trade, and the Ethereum Trade team promotes Ethereum worldwide. Under the promotion of Ethereum Trade, ETC and ETH have skyrocketed several times in just a few months.

Like-minded people tend to gather together; a certain group of people must share common values, goals, hobbies, etc.; this is consensus. In simple terms, it is the power of the masses! When consensus reaches a certain level of breadth and height, it forms a brand; the brand's recognition and influence are also reflections of consensus. The future belongs to unicorns and is also an era of brand competition.

The entire blockchain circle has also been caught up in the bubble. The most interesting phenomenon I have observed is that those teams that truly possess technology are not in a hurry at all, possibly related to their smooth financing, while those whose resumes are packaged to be incredibly impressive but whose concepts are pieced together or even logically inconsistent are the ones who are in a rush.

From the level of code submissions, Ethereum is undoubtedly the most active blockchain in development. Whether it is the number of submissions on GitHub, the number of stars and forks in repositories, or the number of developers, it far exceeds Bitcoin, Ripple, Bitcoin Cash, EOS, and Litecoin, as well as all other cryptocurrencies.

Ethereum is an open-source blockchain underlying system, somewhat akin to the blockchain version of Android, providing APIs and interfaces for everyone to quickly develop various decentralized applications (Dapps) on it. Although currently, blockchain still cannot match traditional internet in speed and efficiency, according to statistics from Chain Tower Research, as of September 30, 2018, the Ethereum platform has recorded 940 DApps, of which game DApps account for 352, making up 37.5%, prediction DApps account for 20%, trading market types account for 5%, and others account for 37.5%.

In simple terms, the Ethereum development community can be roughly divided into three levels of developers, from the outside in, from upper-level application projects to the underlying architecture.

The outer layer consists of various upper-level application project developers built on the Ethereum underlying architecture. These developers may not directly participate in the technical advancement of the underlying architecture but still contribute to the prosperity of the entire community ecosystem. From the once-popular CryptoKitties to the "funding pool" game Fomo 3D, both are DApps built on Ethereum.

The second layer consists of peripheral developers from outside the foundation who are also invested in the underlying architecture. Since Ethereum is a completely open-source ecosystem, developers worldwide can participate in underlying development work in various forms as long as they are interested. Ethereum's off-chain scaling solution, Raiden Network, is one example.

The core is the "Ethereum Foundation," led by founder Vitalik Buterin, headquartered in Singapore, currently having a research team of about 30 people, dispersed around the world, dedicated to researching and developing the core underlying architecture. Many of them are developers from the post-90s generation, just like Vitalik.

To address the problem that cryptocurrencies must rely on proof-of-work mechanisms (PoW), which leads to massive energy consumption, the Ethereum community has actively researched how to transition to proof-of-stake mechanisms (PoS) in recent years. Sharding technology is the key technology for Ethereum's transition from PoW to PoS.

One major difficulty of the PoS mechanism is how to generate good random numbers to ensure that attackers cannot effectively try many random numbers simultaneously to achieve their attack goals. This part must rely on cryptography led by Justin Drake's verifiable delay functions (VDF) and specialized ASIC (application-specific integrated circuit) hardware research.

In the past, the ASIC mining machines discussed in the cryptocurrency circle were mainly aimed at PoW calculations, with the goal of quickly calculating PoW to seize the advantage of block generation. Now, the ASICs discussed in Ethereum are specifically for calculating VDF. Justin Drake's goal is to design an ASIC that makes it difficult for attackers to easily surpass through performance or strong computing power to crack its random numbers. In other words, the likelihood of the entire network being compromised can be reduced to a level that does not require much concern.

Another key direction for Ethereum is Casper, with Danny Ryan as the main developer. Casper is the key to Ethereum's transition from proof-of-work (PoW) to proof-of-stake (PoS) mechanisms, expected to address the inherent drawbacks of PoS mechanisms, such as collusion among nodes, and smoothly replace the PoW mechanism.

Currently, Ethereum has over 14,000 nodes globally, distributed around the world. Most nodes are in the United States and Europe, with U.S. nodes accounting for 43%. Asia, particularly China, has the most nodes, accounting for 13% of global nodes.

In fact, China's Ethereum community has been developing for a long time, with many early Ethereum core developers coming from China. However, in the recent surge of blockchain entrepreneurship, many early members of Ethereum in mainland China have shifted to various other projects, while the core Ethereum development community in Taiwan and Hong Kong continues to thrive.

In Taiwan, the Taipei Ethereum community, established for over two years, includes Vitalik himself and many blockchain industry leaders like Litecoin founder Charlie Lee, who have personally participated. Additionally, the global developer team of the Ethereum Foundation currently has about 30 people, of which 4 or 5 are from Taiwan.

The development work of Ethereum can be simply divided into four processes: researching theories, writing specifications, implementing prototypes, and developing clients. In reality, the production of software programs is certainly not that simple; the actual operation is more complex, but the sequence still follows research, specification writing, and then development and implementation.

The Ethereum Foundation not only welcomes peripheral developers to contribute voluntarily but also offers rewards to encourage more programmers to tackle more challenging problems. Since early 2018, a total of $11 million in rewards has been issued for 52 projects.

Among these, projects addressing Ethereum's scalability and security have received the most funding and support. In terms of amounts, 61.3% of the rewards were allocated to scalability projects, and 16.8% to security projects. In terms of project numbers, 29.1% were scalability projects, and 18.8% were security projects.

The application process for development rewards consists of several steps. The first step is to submit a project application. Applicants must clearly demonstrate their commitment to the Ethereum ecosystem, development capabilities, development focus, and progress planning. They must also present their differentiation from other projects. Of course, the project must support open-source.

Gavin Wood provided a very clear definition in the Ethereum Yellow Paper. Although some content is dirty and perplexing, the overall structure is still clear. After reading the Yellow Paper, you will understand that Ethereum not only has many revolutionary innovations but also has a self-reinforcing technical barrier. If you also read Vitalik's Purple Paper, you will realize that he had already deeply considered future scalability issues long before you.

I will briefly introduce Ethereum's technical highlights, and you can judge for yourself whether those projects claiming to disrupt Ethereum can achieve that.

Unmatched Ease of Use

The interface design of Ethereum is not elegant but very simple, and the protocol is also very easy to understand. Although there are many technical flaws, these are not the primary concerns for developers implementing DAPPs. If you want to create a better chain, you must first implement: a user-friendly VM, a language that supports development, parameter serialization and deserialization scripts, storage data structure models, leveldb storage interfaces, and line protocols, etc.

Due to the head effect, there will be a large number of toolchains based on Ethereum in the future, making disruption on public chains more difficult. The cost of switching main chains is very high.

Powerful EVM

Much lighter than existing general-purpose VMs on the market, simple and easy to use. It does not have a lot of external dependencies. It also has the ability to temporarily store data and choose between stack or memory, with no limits on the size of stack and memory.

I can predict that many advanced language toolchains will be introduced on top of the EVM, extending the boundaries of applications with capabilities like types and abstractions, but for the role of the EVM, it is already sufficient.

From UTXO to Accounts Implementation

Let me first mention a separate example. Baidu, due to its particularly strong search capability, used a keyword indexing model for its forums instead of a traditional forum model. This means that when you enter a forum, the series of posts you see is a search result rather than a section. Sometimes when problems arise, the first post disappears while the second and third posts remain, leading to the saying "the first post feeds the bear."

UTXO was once seen as a masterpiece of Bitcoin, contrary to our habitual thinking, as it constructs the user's account balance system by finding all transactions that can be signed by the user. At the same time, due to the existence of the UTXO queue, Bitcoin easily implements a technique to prevent double spending through packaging and comparing long and short chains.

Ethereum uses an account system, simplifying the implementation difficulty and saving space with the concept of state. This trade-off is actually difficult to judge because each transaction requires an additional nonce to prevent replay attacks, and there are also some flaws in scalability and privacy protection.

But regardless, this system has run hard for a long time, until today. In my view, it has made the implementation of light clients very simple, which is very meaningful for developers.

Trie Design, Friendly to Light Clients

Each block header in Ethereum has three pointers representing three core trees: state, transactions, and receipts.

The transaction tree is relatively simple, and receipts are an RLP-encoded data structure. In addition to simplifying indexing, the use of logbloom also makes it very convenient for light clients.

The design of block headers is closely related to light clients. Most nodes do not need to fully synchronize but require convenient access to data.

The main data structure within blocks is MPT, where sparse areas use KV nodes. In the trees of state and accounts, the depth of diverge nodes is 64, using sha3(k) as the key, making it very difficult to perform DoS attacks.

Currently, the entire state access query can become faster, and full synchronization of full nodes can also become fast, but this is beyond the scope of our discussion today.

Future Opportunities

Because the Purple Paper has brought new directions, I will no longer introduce compression algorithms or uncle block implementations. The Purple Paper introduces the PoS mechanism, more friendly light client synchronization implementations, scoring and measurement implementations, sharding, and cross-shard communication. Ethereum is not only growing but also has a lot of practical business to constantly validate its design and obtain feedback. Just this point, other general public chains cannot simply criticize Ethereum's scalability and think they can solve it.

Imagine you are at a party with 23 people; what is the probability that two people share the same birthday?

The correct answer is about 50.7%, which may differ from your intuition.

This is the famous birthday paradox; we can easily be blinded by what is easily visible and fall into a trap of our own logical correctness that is actually flawed.

To prove the authenticity of this probability, I wrote two programs. The second one is a loop formula that directly calculates 365/365 * 364/365 * 363/365 * ... * 343/365, and the result matches the correct answer. The second one exhaustively checks 100,000 groups of 23 birthdays, and the repeated results were 49.8%, close to the correct answer.

Not satisfied, I ran it for a while longer, and as the number of people increased, the probability of a birthday match approached 1. In other words, the probability of two people sharing the same birthday in a standard domestic primary or secondary school class is very high.

For potential cognitive biases, my consistent approach is to analyze theoretically first, then validate through practical data.

There are also some things that not only have intuitive biases but also cannot be validated at the moment. For example, my first interaction about Bitcoin on Weibo occurred when Bitcoin was at $20, and my article criticizing Ethereum's memory hard was published when ETH was $0.8. At that time, not only did intuition tell you that this numerical game was likely to go to zero, but no one could foresee or deduce the uncontrollable situation that followed.

Ruffchain faced controversy from day one. Even this track itself is filled with various extreme interpretations. We do not have time to explain, nor is it necessary to explain. If I were a critic, I could find various information interpretations every day and make some irresponsible predictions. However, my vision for Ruffchain is not complicated; my energy and limited capabilities only allow me to do the following:

Create a user-friendly public chain that separates transactions and contracts, rather than implementing transactions through contracts like ETH or packaging contracts through a transaction like BCH.
Form a one-stop solution based on the business data of some suitable industry clients. This way, anyone can use blockchain services at an absolutely low cost in the future.

I have often criticized Ethereum's technology, but its low-cost, low-threshold contracts have maintained their leading position in smart contracts to this day.

This development has taken nearly two years, with countless iterations, projections, and optimizations for potential block size growth, and repeated adjustments to the P2P network protocol (which will require another major upgrade in the future). The workload has been much larger than I expected. In this process, I found that the entire industry is much earlier than I anticipated. Many foundational technologies have not been well established. We still do not have a high-performance distributed database for random read and write, nor do we have sufficiently usable P2P networks to support various blockchain businesses in the future. Aside from the technical iterations and upgrades of a few major main chains in the market, there are no decent engineering solutions, and many technological innovations in numerous white papers are completely unusable under the current infrastructure.

But this is also an opportunity; once these technologies mature, the visible application scenarios will become richer. Just like artificial intelligence was most popular in the 1950s, but it wasn't until later that hardware acceleration capabilities like GPU arrays, and then FPGA to ASIC, that we had the ability to truly apply artificial intelligence to everyday scenarios.

Regarding industry access, fortunately, our target clients have provided us with a lot of support, willingly becoming our test subjects, providing rich testing business data, and encouraging us to improve our technology. This indicates that blockchain is not a pseudo-demand; these clients need to solve the trust relationships of multi-party operational data and acknowledge that this is a part of their business flow with extremely high costs.

However, this part also presents some other challenges: we need to put some potential clients' applications on-chain and provide technical support services. This part, like companies such as BAT, requires proactive filing, and the requirements and content for filing are very numerous. For example, content regulation; since blockchain data is immutable, once content that does not comply with the laws and regulations of the application location is generated and packaged, how to roll back and clean it up is more energy-consuming than technical development and is also work that the team did not anticipate.

After the mainnet goes live, it will enter a regulatory trial operation phase, during which the block data will be completely cleared after the trial operation, and any unfiltered block information that violates local laws and regulations will be marked by nodes and forcibly rolled back.

A new P2P network protocol, better storage, and retrieval optimizations, with stronger performance to support some business scenarios with higher network requirements.
We need the support of community power to improve a rich open technology ecosystem, hoping to have a richer application library, middleware library, business modules, and various optimization and security modules in the coming year. For this, the Ruffchain Foundation will provide generous rewards.
More business cooperation; applications will bring more technical feedback, and the foundation of business landing is the main direction for the future technological evolution of the mainnet. Compliance remains a challenge; once asset data is on-chain, the workload for security and privacy is indispensable. If financial data is involved, the workload will increase by an order of magnitude.
The cold start of the mainnet and subsequent development depend on the support of community users. We were born at the end of a bull market and the beginning of a bear market. In a bull market, it is all "faith," while in a bear market, it is all "scams." The operational pressure has always been significant. In the future, I will continue to focus more on evangelism and business development, and activities such as recent AMAs and node plans will be launched successively.

To complete this without an EVM and a large state tree, in order to maintain BCH's centralization while supporting contracts, the omni protocol can only utilize the op-return field in the existing data structure. Although USDT has been implemented on the BTC mainnet, it is still far from being a contract.

First, Op-return is still included in the transaction, meaning that executing a contract requires a real transaction to carry it. Since each transaction needs to be signed, changing the field would invalidate the signature, so normal BCH transactions cannot load external information into the op-return field. This leads to a large number of new BCH transactions as carriers, which may be meaningless, putting significant pressure on the network, and in addition to paying the official fuel WHC, BCH must also be paid.

Secondly, without the existence of an EVM, the pressure of interpreting plain text ledgers is significant, and mistakes also need to be interpreted. Any input in an op-return field is considered valid by default, meaning that once a large number of tokens are supported, the situation becomes very concerning.

According to the development plan of Wormhole, its first step is to port omni over, the second phase is to create a decentralized protocol similar to 0x, and the third phase is to support non-fungible token needs like ERC721. The fourth phase is to introduce off-chain settlement mechanisms like plasma.

However, in my view, the design of this path is quite strange. Following my previous analysis, it should be like this: the main chain can support using a field to expand a ledger, and it is best not to create a large number of transactions, so Wormhole should have a layer 2 system to explain and execute a certain amount of contracts from the first day it plans to support dapps, ultimately creating a transaction on BCH to package and submit. The measurement unit of WHC should be gas, and this gas can be calculated based on an assessment of network resources to determine the reasonable amount of contract execution (the quantity tends to stabilize) contained in each block.

The correct order should be: 1. Port omni. 2. Implement decentralized settlement between BCH and tokens within a single transaction. (There is a pit here; since ETH is not an ERC20 standard token, protocols like 0x still require an ETH token to assist, and BCH is the same.) 3. Establish an independent extension layer responsible for packaging WHC contracts and submitting them centrally. 4. Wait for new technologies to catch up.

When giving advice to the Huobi public chain, the first paragraph is to write its strategic positioning, that is, what the motivation is, why to do this, and then set technical and operational goals.

What is the purpose of supporting contracts on the BCH network? What is BCH's fate? The Bitcoin white paper describes a peer-to-peer payment system, not a super ledger and operating system that supports numerous distributed applications.

The historical mission of Wormhole is not to kill Ethereum or defeat EOS. Alipay is not a speculative system; Alipay is a bank.

In terms of system performance, CDNs play an important role in optimizing network performance. I originally wanted to learn about the principles and technologies related to P2P CDN, but I didn't expect that learning about P2P itself would take a long time, as P2P has many differences from my original understanding.

Although P2P systems have only recently become popular, the technological pioneers of P2P have existed for a long time. Early examples include NNTP and SMTP, as well as the Internet routing system, which are mostly decentralized and rely on participants' resource contributions. However, the nodes in these systems are organized, and the protocols are not self-organizing.

What were those inspiring P2P systems like?

The Past of P2P is Like Smoke. Peer-to-peer (P2P) computing is not a new technology. Traveling back in time to before the "Internet bubble" in 1999, the release of three systems sparked the first P2P craze:

Napster music sharing system

Freenet anonymous data storage

SETI@home volunteer-based scientific computing project.

Napster allowed users to download music directly from each other's computers over the internet. By enabling bandwidth-intensive music downloads to occur directly between users' computers, Napster saved enormous operational costs and could provide free services to millions of users. Although legal issues ultimately determined Napster's fate, the idea of cooperative resource sharing inspired many other applications.

Freenet aims to combine distributed storage with content distribution, anti-censorship, and anonymity. It is still alive but may involve the "dark web," which is not convenient to mention. SETI@home is the largest and most influential distributed computing project globally. SETI (Search for Extraterrestrial Intelligence) is a scientific experiment searching for intelligent life beyond Earth, using radio telescopes to listen for narrowband radio signals from space, as some signals cannot be naturally produced. If such signals are detected, it could prove the existence of extraterrestrial civilizations.

On May 17, 1999, SETI@home officially began operation, attracting a massive number of volunteers worldwide. The SETI@home project is headquartered at the Space Sciences Laboratory at the University of California, Berkeley, and the recorded and analyzed signal data comes from the Arecibo Observatory in Puerto Rico, which once housed the world's largest single-dish radio telescope with a diameter of 350 meters. This record now belongs to China's FAST telescope project. Last year, on March 31, SETI@home officially announced it would enter hibernation, and the volunteer computing resources distributed globally would no longer receive new data packets. The data that needed to be analyzed has all been processed, and researchers will now focus on backend analysis of the results and publish the project's research findings. To some extent, SETI@home may be the most successful P2P project.

More than twenty years have passed, and P2P technology has far exceeded the realm of music sharing, anonymous data storage, and scientific computing, gaining increasingly widespread application in open-source communities and industries, especially with the success of Skype and the brilliance of P2P in the IPFS and Filecoin blockchain fields, P2P technology has once again received significant research attention.

What is P2P? What does P2P systems mean?

P2P networks, or peer-to-peer computer networks, are a distributed application architecture that distributes tasks and workloads among peers, forming a networking or network form of the peer-to-peer computing model at the application layer. — Baidu Encyclopedia

However, in reality, P2P does not have a unified and complete definition.

2.1 Characteristics of P2P Generally, P2P systems are distributed systems with three typical characteristics: decentralization, self-organization, and multiple management domains.

2.1.1 Highly Decentralized Peer nodes implement client/server functionality, and most of the system's state and tasks are dynamically distributed among peer nodes, with almost no dedicated nodes with centralized state. Therefore, most of the computing, bandwidth, and storage required by the operating system are provided by participating nodes.

2.1.2 Self-organization Once a node is introduced into the system (by providing the IP addresses of participating nodes and some necessary key data), maintaining the system requires almost no manual configuration.

2.1.3 Multiple Management Domains Participating nodes are not owned and controlled by a single organization/institution. Generally, each node is owned and operated by an independent individual who voluntarily joins the system.

2.2 Classification of P2P Systems P2P systems can be roughly classified based on the presence or absence of centralized components.

2.2.1 Semi-Centralized P2P Systems In such systems, there is a dedicated controller node used to maintain the collection of nodes and control the system. Semi-centralized P2P systems are relatively simple and can be managed by a single organization through the controller. For example, early versions of BitTorrent had a "tracker" that tracked whether a group of nodes was uploading and downloading the same content and periodically provided a set of nodes that could connect to the nodes; the BOINC volunteer computing platform has a website to maintain membership and assign computing tasks; Skype has a central website to provide login, account management, and payment services.

Semi-centralized P2P systems can also provide organic growth and rich resources. However, they do not necessarily provide scalability and resilience, as the controller forms a potential bottleneck and single point of failure.

2.2.2 Decentralized P2P Systems In decentralized P2P systems, there are no dedicated nodes that affect system operation, and there are no inherent bottlenecks, allowing for good scalability and potential resilience to failures, attacks, and legal challenges.

In some decentralized P2P systems, resource-rich nodes, high availability, and publicly routable IP addresses act as supernodes. These supernodes also have additional responsibilities, such as serving as junction points for nodes behind firewalls, storing states, or maintaining indexes of available content. Supernodes can improve the efficiency of P2P systems but may also increase their vulnerability to node failures.

Advantages and Disadvantages of P2P Due to these technological characteristics, P2P technology has inherent advantages:

3.1 Low Deployment Threshold Since P2P systems rarely or do not require dedicated infrastructure, the upfront investment required to deploy P2P services is often much lower than that of CS systems.

3.2 Organic Growth Since resources are provided by participating nodes, P2P systems can grow almost indefinitely without needing to "upgrade" existing infrastructure, such as replacing servers with more powerful hardware.

3.3 Adaptability to Failures and Attacks P2P systems are highly adaptable to failures because there are very few nodes critical to system operation. To attack or shut down a P2P system, an attacker must simultaneously attack a majority of nodes.

3.4 Richness and Diversity of Resources Popular P2P systems have rich resources that few organizations can bear alone. These resources have different hardware, software architectures, networks, power supplies, geographical locations, and jurisdictions. This diversity reduces the vulnerability to cascading failures, attacks, or even censorship.

Everything has two sides, and P2P is no exception. For example, the decentralization capability of P2P can help citizens avoid censorship; at the same time, it can also be abused to evade law enforcement and engage in criminal activities. P2P systems face many challenges, raising concerns about their manageability, security, and enforceability. Additionally, P2P applications are affecting the traffic provided by internet service providers and may disrupt the current internet economy.

How do P2P systems work? The most important technology in P2P systems is constructing a network overlay layer whose routing capabilities can work well under high node loss. For P2P scenarios, more specific issues include maintaining application state, coordinating application-level nodes, and content distribution.

4.1 Maintenance of Overlay Network P2P systems maintain an overlay network, which can be considered a directed graph G = (N,E), where N is the set of computers and E is a set of overlay links. A pair of nodes connected by a link in E knows each other's IP addresses and communicates directly over the internet.

In semi-centralized P2P systems, new nodes join the overlay network by connecting to a controller located at a known domain name or IP address. Therefore, the overlay initially has a star topology, with the controller at the center. Dynamic overlay links can form between participants introduced by the controller.

In decentralized P2P systems, new nodes need to obtain the network address (e.g., IP address and port number) of a node already participating in the system through an external channel. For example, such addresses of bootstrap nodes can be obtained from a website, and new nodes contact bootstrap nodes to join the overlay network.

4.1.1 Unstructured Overlay Networks In unstructured P2P systems, links between different nodes are unconstrained, so the overlay graph has no specific structure. In a typical unstructured P2P system, a newly joined node forms its initial links by repeatedly executing a random traversal starting from a bootstrap node and requesting a link to the traversal's terminating node. By executing more random traversals, nodes gain additional links.

Typically, the minimum node degree is chosen to maintain connectivity in the overlay graph, while the maximum node degree is maintained to bind and manage the overhead associated with maintaining overlay links.

4.1.2 Structured Overlay Networks In structured overlay networks, each node has a unique identifier in a digital space, which evenly distributes them in that space. The overlay network graph has a specific structure: the identifiers of nodes determine their positions in that topology and limit their sets of overlay links.

Keys are also used when allocating nodes. The key space is divided among nodes, and each key is accurately mapped to one of the current overlay nodes through a simple function. For example, a key can be mapped to the node whose identifier is closest to the key in the counterclockwise direction. In this technique, the key space is considered circular.

The structuring of the overlay network is aimed at improving the efficiency of key-based routing. Key-based forwarding schemes implement KBR (n0, k), which generates a path, i.e., a series of overlay nodes, given a starting node n0 and a key k, leading to the node represented by the key k. Generally, they achieve a balance between the number of routing states required at each node and the number of forwarding nodes needed to pass messages. Typical implementations require a logarithmic relationship between the amount of state per node and the number of forwarding hops.

Thus, in semi-centralized P2P systems, the controller facilitates the formation of the overlay layer. In other P2P systems, the maintenance of the overlay network is entirely decentralized. Compared to unstructured overlay networks, structured overlay networks require more resources to maintain a specific graph structure. In return, structured overlays can efficiently execute key-based forwarding methods.

The choice between unstructured and structured overlays depends on the usefulness of key-based forwarding methods for the application and the frequency of updates among overlay members. Key-based forwarding methods can reliably and effectively locate uniquely identified data items and maintain a generating tree among member nodes. However, maintaining a structured overlay in a high-loss environment incurs related costs, and if the application does not require the functionalities provided by key-based forwarding methods, those costs should be avoided.

Of course, some P2P systems use both structured and unstructured overlays simultaneously, for example, using structured overlays for controllers while content distribution can use unstructured overlays.

4.2 Distributed Network State Most P2P systems maintain some application-specific distributed network state. Generally, the network state is considered a collection of objects with unique keys. The maintenance of distributed network state involves the storage and locating mechanisms for these objects.

4.2.1 Network State in Semi-Centralized Systems In semi-centralized P2P systems, state objects are typically stored on the nodes that insert the objects and any nodes that subsequently download the objects. The controller node maintains information about which objects exist in the system, their keys, names, and other attributes, as well as the current nodes storing those objects. Queries for a given keyword or a set of keywords matching object names or attributes are directed to the controller, which responds through a set of nodes from which the corresponding state objects can be downloaded.

4.2.2 Network State in Unstructured Systems Similar to semi-centralized systems, content is typically stored on the nodes that introduce it into the system and replicated on other downloaders. To facilitate content discovery, some systems place copies (or pointers) of inserted objects on other nodes, for example, along paths traversed randomly in the overlay.

To locate objects, querying nodes typically send request messages through the overlay network. Queries can specify the desired objects by key, metadata, or keywords. Nodes that receive queries and have matching objects (or pointers to matching objects) respond to the querying node. In this case, node i inserts an object into the system and keeps its unique copy, but also inserts pointers to that object along paths ending at node r. When node s attempts to locate the object, it sends numerous queries, first reaching all nodes one hop away, then those two hops away. In the final step, the query reaches node r, which returns the address of node i.

Typically, the scope of flooding is limited to the probability of finding objects that exist in the system with the number of messages required. An alternative to flooding is for the querying node to send request messages along the overlay layer through random traversals.

4.2.3 State in Structured Overlay Networks In structured overlay networks, distributed state is maintained using Distributed Hash Tables (DHT). DHT has the same put/get interface as traditional hash tables. By using a simple function, the key/value pairs inserted are distributed among the nodes in the structured overlay network.

Given this copy placement strategy, the put and get operations of DHT can be directly implemented using KBR primitives. To insert (place) a key/value pair, we use KBR primitives to determine the responsible node for key k and store the key/value pair at that node, which then propagates it to the set of copies of k. The responsible node can respond to retrieval requests or forward them to a node in the copy set.

When DHT fluctuates, the mapping of keys to nodes changes, and key/value pairs must be moved between nodes. To minimize the required network communication, large data structures are typically not directly inserted into DHT; instead, an indirect pointer is inserted into the value corresponding to the key, pointing to the node that actually stores the value.

Thus, unstructured overlay networks are very effective at locating widely replicated objects, while systems based on KBR can reliably and effectively locate any object that exists in the system, regardless of its sparsity. In other words, unstructured overlay networks excel at finding commonly existing items, while structured overlay networks excel at finding needles in haystacks. Unstructured networks support arbitrary keyword-based queries, while KBR-based systems directly support keyword-based queries.

4.3 Distributed Coordination Typically, a group of nodes in P2P applications must coordinate their operations without centralized control. For example, a set of nodes replicating a specific object must notify each other of updates to that object. Similarly, nodes interested in receiving specific streaming content may wish to find nearby nodes that have available upstream bandwidth among those currently receiving that channel.

Generally, there are two different approaches to solving this problem: self-replicating techniques, where information spreads through the system in a virus-like manner

Tree-based techniques, where a distribution tree is formed for propagating information.

Here, we will focus only on decentralized P2P systems, as in semi-centralized systems, the controller node can complete coordination.

4.3.1 Coordination in Unstructured Overlay Networks In unstructured overlay networks, coordination typically relies on self-replicating techniques. In these protocols, the way information spreads is similar to how infections spread among people: the node generating the information sends it to neighboring nodes in the overlay, and those neighboring nodes send the information to their neighbors, and so on. This propagation method is very simple and effective, but there is a trade-off between the speed of information dissemination and management costs. Additionally, if a given piece of information is only of interest to a subset of nodes, and those nodes are widely dispersed in the overlay network, that information may end up being unnecessarily transmitted to all nodes.

A more efficient way to coordinate actions among a set of nodes is to form a generating tree among the nodes. The generating tree is embedded in the overlay network graph and is completed using distributed algorithms. This tree can then be used