Feeling Anxious in the Bear Market? What Should We Really Be Researching?

After the FTX collapse, I've clearly sensed increased anxiety within the crypto community. Some have chosen to quit and exit for safety, while others remain - whether to continue airdrop farming, accompany the industry's growth, or await the next bull market. Regardless of the reason, most people experience varying degrees of anxiety with market volatility, with few maintaining genuine peace of mind.

I've emphasized many times in previous posts that in this complex crypto world filled with black swan events, the best way to reduce anxiety and distress is to keep yourself busy with genuine learning and research. However, many people still don't know what specifically to research or how to go about it.

Today, I'll share a research approach that can help you focus more deeply: studying EIP protocols.

If we compare Ethereum to a massive ship, EIP can be understood as the steering wheel of this vessel, essentially controlling the development direction of the entire Ethereum ecosystem. Therefore, studying EIP helps us observe industry development dynamics more deeply, understand what industry pain points are being addressed, track progress, and provides significant value for researching specific projects in depth.

Although studying EIP has certain barriers to entry, it's genuinely helpful. You should give it a try.

## What is EIP? How does it relate to ERC?

Before diving into research, let's clarify the concept of EIP and its relationship with ERC, which we hear about frequently.

EIP stands for Ethereum Improvement Proposals, which are improvement suggestions proposed by the Ethereum developer community for the ecosystem's development. These suggestions contain specific standards and protocols involving Ethereum's core protocol, client APIs, smart contract standards, and more.

EIPs can be broadly categorized into three types based on their domains: Standards Track EIP, Meta EIP, and Informational EIP.

Let me briefly mention Standards Track EIP, as ERC is actually a subcategory within this classification. The other three subcategories are Core, Networking, and Interface.

ERC stands for Ethereum Request for Comment, primarily used to record application-level development standards and conventions on Ethereum. Examples include typical token standards (ERC20, ERC721) and wallet formats (EIP75, EIP85).

So essentially, EIP is a broader concept than ERC - in other words, ERC is a subset of EIP.

## EIP Content Structure

What does a standard EIP typically contain?

It generally includes: Preamble, Abstract, Motivation, Specification, Rationale, Backwards Compatibility, Test Cases, Reference Implementation, Security Considerations, and Copyright. Some sections are optional and don't appear in every EIP, such as backwards compatibility, test cases, and reference implementation.

We'll revisit this in our practical analysis section.

## EIP Process

You might wonder: how exactly are EIPs created?

Generally, an EIP goes through these stages from conception to formal recognition or abandonment: Idea, Draft, Review, Last Call, Final, Stagnant, Withdrawn, and Living.

The official website provides a clear diagram showing EIP process states.

Typically, a smooth EIP process involves having an idea, drafting according to EIP standards, passing initial review by the EIP editorial team to become a formal Draft proposal. This process can be lengthy as the editorial team provides professional suggestions requiring targeted optimization and modifications.

Once reaching Draft status, the EIP proposal is officially merged into the official EIP repository, making it publicly accessible. This is followed by extensive public discussion and optimization phases, progressing through Review, Last Call, and Final stages. Final represents the ultimate state where an EIP can be formally adopted - for example, ERC-type proposals officially become ERC standard protocols.

Furthermore, in subsequent Ethereum upgrades, these new standards are implemented into the latest network, allowing project teams to explore new application scenarios based on these standards.

This mechanism continuously drives Ethereum ecosystem development and progress, addressing bottlenecks encountered during business development.

Copyright Waiver: All EIPs belong to the public domain under intellectual property law. The copyright waiver must specify relevant licensing documents using the statement "Copyright and related rights waived via [CC0](/LICENSE)."

## EIP Case Analysis

The previous discussion of EIP fundamentals was somewhat abstract. Let me use a practical example for more intuitive understanding.

I recently noticed that among the 260+ active proposals from the 2022 community, EIP-5585 has generated significant discussion, currently ranking 13th overall and 5th among NFT annual proposals, with growing momentum. Let's use EIP-5585 as an example to share how we can follow EIP developments and participate in protocol analysis and discussion.

First, where can we view the latest protocols?

There are two main approaches. One is observing recent changes through EIP's GitHub repository.

The Watch and History features help you directly see the latest dynamics in the protocol repository.

Another approach is viewing through status categories on the EIP official website.

For example, under the Draft category, you can quickly see which protocol proposals are currently in Draft status.

From this table, we can see important information like protocol authors (Veega Labs, etc.), forum addresses for protocol discussion, current status (Draft), and protocol type.

For instance, EIP-5585 belongs to the ERC category, meaning if this protocol ultimately passes community review and reaches Final status, it will become the ERC-5585 standard protocol, allowing all project teams and ecosystem builders to expand their application scenarios using this protocol.

The Discussion-To field is where specific protocol discussions take place - a crucial address containing all detailed discussions, problem explorations, and improvement suggestions for this protocol.

You can post any questions or suggestions here as replies. Protocol authors and other users also engage in discussions here. Researching and participating in these discussions generates many meaningful ideas and broadens our perspective, helping us understand which directions the industry should develop.

So I strongly encourage everyone to take action immediately.

Now let's return to the EIP-5585 protocol itself, examining what problems it solves and what design considerations it incorporates.

From its Abstract and Motivation sections, we can see it aims to solve the core problem of separating NFT (ERC-721) ownership from commercial usage rights, allowing NFT holders to independently manage these rights and maximize NFT commercial value.

Clearly, this is an application-layer protocol that can be understood as an on-chain authorization management protocol for NFT IP rights. For example, it can manage rental rights, reproduction rights, distribution rights, exhibition rights, and other benefits.

Based on my current understanding, this protocol might have the following potential applications:

1) NFT project teams can more safely, conveniently, and cost-effectively connect to more scenarios and users through the protocol, increasing brand influence and commercial revenue;

2) Introducing new user roles through the protocol, applying NFTs to gaming, commercial licensing, metaverse, and other fields to increase holder revenue;

3) Helping commercial brands more conveniently discover and establish commercial partnerships with IPs;

4) Helping game developers more conveniently integrate and apply NFTs.

After analyzing the protocol's value, let's examine the interface definitions section.

The protocol provides 11 interface definitions, with authorizeUser being the most core interface.

The main difference between these two interfaces is that one can authorize all NFT rights to a specified user, while the other authorizes specified rights (string[] rights) to users. A key parameter here is rights.

The rights parameter's surface meaning is clear - it refers to the rights that NFT holders authorize to users. However, the parameter type is a string array, meaning without other constraints, this parameter can be freely defined content, creating a new problem. Due to the lack of standard rights definitions, we don't know what values to pass when using this parameter.

From the protocol designers' perspective, they likely intended for NFT project teams to customize a set of rights based on the NFT's available rights, allowing users to choose only from the project's rights.

Some community members have suggested the protocol should provide a getRightsOfferings function to query available rights parameter values - an excellent suggestion that would make rights usage clearer.

Even so, rights application remains the biggest challenge. After all, globally, legal regulations vary by country and region, with different definitions of copyright and commercial usage rights. There's currently no completely unified copyright law, making standardization difficult and hindering widespread application.

The author mentioned in comments that a16z has defined an on-chain licensing protocol for NFT copyright issues, but whether this adequately covers and applies to all application scenarios requires further verification.

Ultimately, whether this protocol can truly be implemented and widely applied to real scenarios depends crucially on promoting industry development toward effective NFT rights standards and specifications. This is likely the author's initial intention in proposing this protocol.

Honestly, it's a long and challenging road. I genuinely hope more experts from legal, commercial, technical, and related fields can participate in building the entire industry ecosystem. I look forward to seeing more protocols like 5585 being defined to stimulate discussion and promote faster, healthier industry development. This is also my motivation for writing this article - let's build the future of blockchain together.