How to deconstruct global new and old projects using technological logic?

Author: Wyz Research

Background

When we see a blockchain project, whether it's a newly emerged public chain, a compliant project's consortium chain, or many blockchain projects that claim to be public chains but are actually privately managed, or when we see a dApp, whether it's DeFi, GameFi, wallets, NFT trading platforms, or some hybrid applications.

You will see many flashy descriptions or beautiful designs, which can easily create a positive impression on users and even lead to a certain deviation from the perceived authenticity.

However, to identify a "technically sound" quality project, one must look beyond the surface to understand its essence. It is essential to have a clear understanding of how it is constructed, how it is built, and who is in control. Projects in the industry often use appearances to project a blueprint that supports secondary prices and market capitalization. Without the ability to discern the technology, the likelihood of falling into a bubble increases.

To find the answer to this question, we need to utilize standard technical thinking to dissect blockchain and dApps, just as understanding pathology is necessary to identify the source of a disease. One must possess the ability to dissect projects thoroughly. This article will provide the basic logic for dissecting chains and dApps (non-commercial logic), upon which other factors can be layered to assist in judgment.

Definition

First, we need to understand the relationship between computing resources, blockchain, and applications.

We often hear descriptions such as blockchain is decentralized, Ethereum is a world computer, and applications built on Ethereum are called dApps. These descriptions represent that: blockchain is the underlying layer, and applications are the upper layer.

From a technical logic perspective, applications require computing and storage when being built, and blockchain can provide an environment for applications, which has computing and storage capabilities.

When we map the micro-level technical layered logic to the entire internet, we can deduce from this perspective:

The underlying layer of the internet is the internet infrastructure, which provides a layer of computing resources, while the upper layer consists of various applications that we commonly encounter, similar to internet platforms.

Since the large-scale development of cloud services, cloud services have become mainstream and can almost replace the entire internet infrastructure.

Thus, this represents that the structure of the internet can be understood as: cloud + applications.

By synthesizing and comparing the above two structural deductions, we can conclude:

Blockchain networks possess capabilities similar to cloud services, providing an environment for application deployment.

Inclusion Relationship

Building a blockchain network requires underlying computing resources. Currently, blockchain networks in the industry do not entirely consist of self-built resources; most will use the cloud, which means cloud services are also the foundational infrastructure layer for blockchain networks. Therefore, blockchain networks become a new component rooted in the internet.

In summary, we can define as follows:

• Blockchain network = new "cloud service (distributed)"

• Applications on the blockchain dApp = new applications under the new "cloud environment"

Based on the fact that blockchain is still rooted in internet infrastructure, we will again list some key supporting evidence, including:

• Computing resources (even physical machines) must connect to the internet communication network

• Many blockchain networks deploy nodes in virtual machines on cloud servers

• After deploying nodes, cloud resources need to be managed

• Node software still needs to be deployed on hardware or cloud service operating systems

• It is necessary to rely on cloud services to develop web or mobile sites for the frontend

• Accessing the chain still uses remote calling methods developed on the internet

All these factors make blockchain and blockchain networks an inevitable small part of today's internet, rather than a replacement, because this is not a revolution like hardware upgrades, but a new technological model that forms a new part with distributed characteristics alongside the internet, which will attract new applications and business forms to take root and grow on this technological structure.

Detailed Dissection and Comparison

Based on the above foundational theory, we will further deconstruct blockchain and dApps.

First, we will categorize blockchains:

• Public Chain

• Consortium Chain

• Open Consortium Chain

• Non-Currency Public Chain

Then we will further classify these types of chains into:

• Permissioned Chain

• Permissionless Chain

This means that if a chain has permission requirements, there must be a process to obtain permission, and in the corresponding permission application process, the applicant's information will certainly be provided. The permission process represents KYC (know your customer), and under certain specific official requirements (such as financial institutions, legal real-name identities), there may be more complex designs.

The permission process will definitely be designed into the product, so in terms of product model design, permissioned chains and permissionless chains will also be divided into two forms of usage:

• First: Obtain permission, then perform related technical operations.

• Second: No permission required, directly perform technical operations through corresponding open tools.

These are the two forms of joining all blockchains currently. Let's specifically experience these two forms using two common actions: developing a dApp and building nodes to connect to the network.

When Our Goal is to Develop a dApp

Developing a dApp ultimately aims to provide users with a service, so the basic development steps of application software remain unchanged: the frontend allows user interaction, while the backend controls data. However, the dApp on the blockchain effectively turns the backend into the chain. The application development team builds a frontend, and whenever it needs to call the "backend," it directly accesses the corresponding contracts and on-chain data deployed on the chain through remote calling ports.

In this process, permissioned chains and permissionless chains will produce distinctions based on the connection parts.

On a permissioned chain, the first step is to obtain access permission to the blockchain.

Taking the open consortium chain as an example, generally, one needs to register on the official portal. After registration, one enters the portal, obtains a corresponding blockchain address, and then purchases chain gas with fiat currency to recharge gas into the used chain address.

Once completed, one can use the corresponding chain address account with the help of a wallet tool to connect to the network, deploy contracts using the corresponding tools, and develop the calling part with the chain using SDK, linking it to the frontend development. If switching from an open consortium chain to a consortium chain or private chain, the only part that may need to change is how to use the chain account.

This completes the development of a dApp on a permissioned chain.

What about operating on a permissionless chain?

On Ethereum, we would directly use the chain's wallet to generate a new address, then purchase ETH on the platform and transfer ETH to that address. For other public chains, one can choose to purchase other gas tokens.

Next, on Ethereum, one can use Remix or other IDEs to write code first, then compile the code, and subsequently deploy contracts on the chain. IDEs like Remix support corresponding networks, languages, and wallets, making it easy and convenient to access the corresponding network. The dApp also needs to develop a user-end page, and most frontends will access the chain for related operations by invoking wallets.

In this usage process, we can observe that whether it is development tools, chain RPC, wallets, or using IDEs, all will utilize open-source tools and open platforms, requiring almost no authentication and permission. This also represents the greatest characteristic of permissionless chains: public and open.

This is the process of developing a dApp on a permissionless chain.

As we practice, we will also clearly find that, apart from the permission acquisition part, in the later stages of the chain, due to open-source tools and open characteristics, the processes related to developing with the chain will have a certain universality.

When Our Goal is to Join the Blockchain

Developing applications is a common form of joining the blockchain, and this form aims to develop applications. A higher-level approach is to connect to the blockchain and become part of the chain, providing resources for external needs. Similarly, there are significant differences in obtaining permission across different chains.

In permissionless chains, when becoming a node, there are generally distinctions and requirements for different functional nodes, such as hardware computing power, storage space, etc. Different requirements are set to execute different tasks.

When Ethereum was still in its 1.0 phase, participating in mining meant joining as a node, completing the verification and storage of the network's total state using the computing power of hardware in PoW calculations. At that time, GPU capability was required. However, after Ethereum transitioned to 2.0, hardware requirements decreased, but it would choose to execute client and verification client roles, with different clients fulfilling different network needs.

Joining the network as a node represents an enhancement of decision-making capabilities regarding the chain, while generally, developing applications will not choose to build nodes due to cost issues.

On a fully anonymous public chain like Ethereum, as long as hardware requirements are met, there is no need for permission for network identity, and the entire process can still remain anonymous.

Compared to the node joining process on Ethereum, the node joining process on permissioned chains will only add a verification node permission process, but it may be more beneficial for user experience due to self-built nodes. Currently, some permissioned chains implement infrastructure business redistribution in this manner.

Evaluation Factors

In the cryptocurrency industry, most practitioners may confuse blockchain with cryptocurrency, but if we consider cryptocurrency merely as a part of the larger blockchain industry, we can evaluate various blockchain characteristics based on their openness compared to all existing blockchains globally, based on the degree of the following two factors:

The factors are:

• Degree of data openness

• Permission licensing

The two evaluation factors can be further detailed into:

Data openness:

• Data fully public

• Data selectively public

• Data not public

Permission openness:

• Completely open

• Anonymously open business nodes

• Real-name open verification nodes

• Real-name open business nodes

• Only open verification node access to permitted members

• Only open business access to permitted members

After making such detailed distinctions, we find that even in the cryptocurrency industry that advocates complete decentralization, there may exist many chains and applications with restricted permissions. Especially now, to filter airdrop users, most chains and applications exhaust all means to classify on-chain users, almost violating the principle of no permission required.

What level of openness a chain or platform has externally, under the push of market development rules, the more open it is, the greater the scale expectation. From a technical perspective, the more open it is, the higher the universality, and at the underlying rule level, it must be compatible with broader adaptability.

This also directly relates to the principles of a blockchain and dApp in business and external performance. For example, when a chain has no restrictions on the joining of verification nodes, it means that after joining, rules must be implemented to ensure long-term service to the network. This is also why public chains promote mining and token incentives. Ensuring openness must also resolve issues of malfeasance and stability within the rules.

The above is the most basic logic for dissecting and evaluating blockchain and dApps, and it does not involve differences brought by business scenarios for applications and chains. Crypto has bull and bear markets, but blockchain technology does not.