Understanding development and deployment knowledge allows a newbie to become a BUIDL.
If you can’t deploy contracts, you might not qualify as a BUIDL.
Every airdrop enthusiast enters the chain and applications as a user, but from the chain’s perspective, users have certain levels of limitations. Among these, application developers hold the highest value for the chain.
Application developers create dApps that attract users, who generate gas during use. Developers deploy contracts on the blockchain, actively attracting users to perform operations on the chain, infinitely increasing the blockchain’s value.
Thus, having development capabilities or even just basic development knowledge is a better path to increasing the chances of receiving airdrops or, more accurately, becoming a true builder on the blockchain.
In this article, we will detail the basic development knowledge needed for users who like to experience chain operations. It will not cover building front-end, development environments, or SDK operations. This article aims to bring ordinary users into the theoretical phase of beginner-level development experience. Those interested in practical phases can continue to study more in-depth knowledge.
In our previous article “How to Technically Deconstruct Global New and Old Projects?” we explained the defining attributes of blockchain. Blockchain is not just a ledger; the design of all existing public blockchains today is for the growth of surface applications.
Thus, understanding blockchain development knowledge is consistent with traditional internet application development, with the architecture understanding shifting to the backend becoming the blockchain, and the data state in the database becoming the data state on the blockchain.
For internet application development, one initially needs to purchase cloud services (or earlier, computing devices connected to the network could also serve as servers for deployment). Suppose we buy two servers, one for deploying the front end and one for the backend, and purchase a website. We configure the website with the front-end development part, then develop the backend to manage data. The website’s interactive data enters the backend during use. When front-end users need feedback data for operations, it’s executed after accessing the data state in the database.
With such a complex process, users hardly feel the backend in traditional applications, but on the blockchain, the presence of both front and backend is noticeably apparent.
The backend of a dApp transforms the servers and databases used in the development of internet applications into the blockchain and its overall state on the blockchain. During development, the blockchain backend exposes a remote procedure call (RPC) interface, which all developers and applications use to interact with the blockchain. This explains why, when using MetaMask to experience different dApps, it is necessary to add different networks in the dApp, with the URL representing the entry point for the RPC.
In other network designs, there is a method to further upgrade dApps. If a blockchain relies on a single RPC, heavy interaction could lead to congestion even before transactions are submitted to the chain. Applications that can set up their own RPCs have a significant advantage, although, in the current public blockchain domain, especially with the design of Proof of Stake (PoS), there are not many dApps that operate in this manner. This brings us to understand that interacting with the blockchain for development requires a wallet and an RPC port.
After gaining access, the next step is how to perform operations on the blockchain. Ethereum, known as the “world computer,” can run various types of smart contracts that automatically execute. This process involves deploying contracts to the network to be executed by the Ethereum Virtual Machine (EVM). The term “Virtual Machine” (VM) is crucial in the cloud service industry, and the computing devices in the Ethereum network can be seen as a massive computing and storage area, i.e., a virtual machine, enabling smart contracts to run and execute task commands.
Thus, smart contracts become the key, and for developers, the most critical aspect is the smart contract. The deployment of smart contracts involves three steps: writing the code, compiling it, and then deploying it. After deployment, the contract functions can be directly called.
Ethereum has standardized tools that have been greatly simplified. After understanding the entire process, one can attempt it by carefully reviewing these tools. Remix, Hardhat, and OpenZeppelin represent some of the simplest and most open tools currently available, in addition to which there are tools like Thirdweb that assist in development and simplify some of the processes.
Starting with Testnets of Various Networks
We have recently explored the testnets of public blockchains like Berachain, Taiko, and Shardeum. This exploration provides insight into development knowledge. As a regular user operating MetaMask for network interactions, the first step involves adding a testnet in MetaMask and obtaining testnet tokens, which are limited in quantity and can be claimed from the testnet faucets as outlined in the official documentation of these three projects. The test tokens for these chains are Bera, ETH, and SHM, respectively.
Berachain and Shardeum are L1 blockchains using their native tokens, whereas Taiko is an L2 aimed at expanding Ethereum, hence it uses ETH. Since Ethereum has its public testnets, Taiko also utilizes Ethereum’s testnets for some functionality tests, requiring users to distinguish which chain they are ultimately interacting with.
After obtaining the test tokens from the faucets of the three chains, the next steps involve using development tools to deploy contracts to the blockchain. This involves three steps: finding the contract, modifying it, and completing the contract deployment in the IDE.
Upon review, all three projects support deployment using Remix. Remix is an online editable environment that is very convenient, eliminating the need for more complex tools like SDKs or terminals. However, the simplified process described here only covers a one-time deployment, and modifications to the contract and testing its calls require other tools.
On OpenZeppelin, several common token issuance contracts are modularly displayed. One can directly choose a function from there and then jump directly to Remix for deployment.
Subsequently, I made some settings to this token issuance contract, using the full name of Wyz Research, the abbreviation of Wyz, and selected the pre-issuance function from the options, and specified the control of ownership of the contract. Through these operations, the contract code on the right side added the constructor shown in the first red box, and the pre-issued tokens also had an address pointing to them.
Next, click on “Open in Remix” in the top right corner, and we can start editing in the Remix interface.
Before starting to edit in the Remix interface, please adjust the network and wallet address in MetaMask correctly. After entering the page, we need to modify the two corresponding addresses mentioned above, replacing them with my wallet address. It is shown as follows:
Then click on the “Auto compile” on the left side, that is, to compile automatically. If it does not compile automatically, you need to click the blue button on the left side. When a green check mark appears on the far left, it is ready. Then click the button below the green check mark on the left side to enter the deployment page.
With the wallet modified correctly, click on the account part in the top left corner, this position represents the account paying the gas fee, and the position below represents the deployment address. After selecting, it is shown as follows:
Click “Deploy”, and MetaMask will pop up to pay the gas fee for this operation.
During the contract deployment process, the contract pending will be displayed at the bottom of Remix.
After the contract deployment is successful, the transaction success will be displayed at the bottom.
After completing the deployment, when entering the browser to view the transaction through the button in the wallet, it can be found that we have just completed an action of contract creation, and during the execution of the contract, a certain amount of tokens was sent to one of them.
When clicking on the address for viewing again, it was found that I minted 10 million tokens in the address. However, possibly due to the test network browser, the token name was not displayed, which is an issue that still needs to be verified.
This deployment used Shardeum, and the process is the same if deployed on Berachain or Taiko, only requiring the corresponding network to be adjusted in the wallet. Remix, this type of online IDE, provides a simple entry for network operations.
Engaging in some development operations on the blockchain is the simplest construction attempt for non-application users. It is possible to try issuing some assets using contracts or to fork other dApps’ codes. Every contract of a dApp on the blockchain interacts through a combination, for example, the swap we see on Uniswap is one contract, while providing LP is another contract.
Compared to Dex, contracts for other DeFi, GameFi are more complex. Although the development process is complex and lengthy, understanding their principles can help with more construction on the blockchain and applications.
PS: Next, Wyz Research will also deconstruct DeFi, GameFi, and other dApps to introduce their design thoughts and structure to the readers. Stay tuned.
Understanding development and deployment knowledge allows a newbie to become a BUIDL.
If you can’t deploy contracts, you might not qualify as a BUIDL.
Every airdrop enthusiast enters the chain and applications as a user, but from the chain’s perspective, users have certain levels of limitations. Among these, application developers hold the highest value for the chain.
Application developers create dApps that attract users, who generate gas during use. Developers deploy contracts on the blockchain, actively attracting users to perform operations on the chain, infinitely increasing the blockchain’s value.
Thus, having development capabilities or even just basic development knowledge is a better path to increasing the chances of receiving airdrops or, more accurately, becoming a true builder on the blockchain.
In this article, we will detail the basic development knowledge needed for users who like to experience chain operations. It will not cover building front-end, development environments, or SDK operations. This article aims to bring ordinary users into the theoretical phase of beginner-level development experience. Those interested in practical phases can continue to study more in-depth knowledge.
In our previous article “How to Technically Deconstruct Global New and Old Projects?” we explained the defining attributes of blockchain. Blockchain is not just a ledger; the design of all existing public blockchains today is for the growth of surface applications.
Thus, understanding blockchain development knowledge is consistent with traditional internet application development, with the architecture understanding shifting to the backend becoming the blockchain, and the data state in the database becoming the data state on the blockchain.
For internet application development, one initially needs to purchase cloud services (or earlier, computing devices connected to the network could also serve as servers for deployment). Suppose we buy two servers, one for deploying the front end and one for the backend, and purchase a website. We configure the website with the front-end development part, then develop the backend to manage data. The website’s interactive data enters the backend during use. When front-end users need feedback data for operations, it’s executed after accessing the data state in the database.
With such a complex process, users hardly feel the backend in traditional applications, but on the blockchain, the presence of both front and backend is noticeably apparent.
The backend of a dApp transforms the servers and databases used in the development of internet applications into the blockchain and its overall state on the blockchain. During development, the blockchain backend exposes a remote procedure call (RPC) interface, which all developers and applications use to interact with the blockchain. This explains why, when using MetaMask to experience different dApps, it is necessary to add different networks in the dApp, with the URL representing the entry point for the RPC.
In other network designs, there is a method to further upgrade dApps. If a blockchain relies on a single RPC, heavy interaction could lead to congestion even before transactions are submitted to the chain. Applications that can set up their own RPCs have a significant advantage, although, in the current public blockchain domain, especially with the design of Proof of Stake (PoS), there are not many dApps that operate in this manner. This brings us to understand that interacting with the blockchain for development requires a wallet and an RPC port.
After gaining access, the next step is how to perform operations on the blockchain. Ethereum, known as the “world computer,” can run various types of smart contracts that automatically execute. This process involves deploying contracts to the network to be executed by the Ethereum Virtual Machine (EVM). The term “Virtual Machine” (VM) is crucial in the cloud service industry, and the computing devices in the Ethereum network can be seen as a massive computing and storage area, i.e., a virtual machine, enabling smart contracts to run and execute task commands.
Thus, smart contracts become the key, and for developers, the most critical aspect is the smart contract. The deployment of smart contracts involves three steps: writing the code, compiling it, and then deploying it. After deployment, the contract functions can be directly called.
Ethereum has standardized tools that have been greatly simplified. After understanding the entire process, one can attempt it by carefully reviewing these tools. Remix, Hardhat, and OpenZeppelin represent some of the simplest and most open tools currently available, in addition to which there are tools like Thirdweb that assist in development and simplify some of the processes.
Starting with Testnets of Various Networks
We have recently explored the testnets of public blockchains like Berachain, Taiko, and Shardeum. This exploration provides insight into development knowledge. As a regular user operating MetaMask for network interactions, the first step involves adding a testnet in MetaMask and obtaining testnet tokens, which are limited in quantity and can be claimed from the testnet faucets as outlined in the official documentation of these three projects. The test tokens for these chains are Bera, ETH, and SHM, respectively.
Berachain and Shardeum are L1 blockchains using their native tokens, whereas Taiko is an L2 aimed at expanding Ethereum, hence it uses ETH. Since Ethereum has its public testnets, Taiko also utilizes Ethereum’s testnets for some functionality tests, requiring users to distinguish which chain they are ultimately interacting with.
After obtaining the test tokens from the faucets of the three chains, the next steps involve using development tools to deploy contracts to the blockchain. This involves three steps: finding the contract, modifying it, and completing the contract deployment in the IDE.
Upon review, all three projects support deployment using Remix. Remix is an online editable environment that is very convenient, eliminating the need for more complex tools like SDKs or terminals. However, the simplified process described here only covers a one-time deployment, and modifications to the contract and testing its calls require other tools.
On OpenZeppelin, several common token issuance contracts are modularly displayed. One can directly choose a function from there and then jump directly to Remix for deployment.
Subsequently, I made some settings to this token issuance contract, using the full name of Wyz Research, the abbreviation of Wyz, and selected the pre-issuance function from the options, and specified the control of ownership of the contract. Through these operations, the contract code on the right side added the constructor shown in the first red box, and the pre-issued tokens also had an address pointing to them.
Next, click on “Open in Remix” in the top right corner, and we can start editing in the Remix interface.
Before starting to edit in the Remix interface, please adjust the network and wallet address in MetaMask correctly. After entering the page, we need to modify the two corresponding addresses mentioned above, replacing them with my wallet address. It is shown as follows:
Then click on the “Auto compile” on the left side, that is, to compile automatically. If it does not compile automatically, you need to click the blue button on the left side. When a green check mark appears on the far left, it is ready. Then click the button below the green check mark on the left side to enter the deployment page.
With the wallet modified correctly, click on the account part in the top left corner, this position represents the account paying the gas fee, and the position below represents the deployment address. After selecting, it is shown as follows:
Click “Deploy”, and MetaMask will pop up to pay the gas fee for this operation.
During the contract deployment process, the contract pending will be displayed at the bottom of Remix.
After the contract deployment is successful, the transaction success will be displayed at the bottom.
After completing the deployment, when entering the browser to view the transaction through the button in the wallet, it can be found that we have just completed an action of contract creation, and during the execution of the contract, a certain amount of tokens was sent to one of them.
When clicking on the address for viewing again, it was found that I minted 10 million tokens in the address. However, possibly due to the test network browser, the token name was not displayed, which is an issue that still needs to be verified.
This deployment used Shardeum, and the process is the same if deployed on Berachain or Taiko, only requiring the corresponding network to be adjusted in the wallet. Remix, this type of online IDE, provides a simple entry for network operations.
Engaging in some development operations on the blockchain is the simplest construction attempt for non-application users. It is possible to try issuing some assets using contracts or to fork other dApps’ codes. Every contract of a dApp on the blockchain interacts through a combination, for example, the swap we see on Uniswap is one contract, while providing LP is another contract.
Compared to Dex, contracts for other DeFi, GameFi are more complex. Although the development process is complex and lengthy, understanding their principles can help with more construction on the blockchain and applications.
PS: Next, Wyz Research will also deconstruct DeFi, GameFi, and other dApps to introduce their design thoughts and structure to the readers. Stay tuned.