Day 29 : Become a self-taught blockchain developer with zero knowledge in 365 days
--
PREVIOUS: DAY 28
START TO CLARITY THE INSUFFICIENCE OF THREE TOPICS
blockchain application
second solution: disassemble the development
the disassemble of the Dapps: logic 1 of disassembling
Dapp can be disassembled into three parts. The backend that runs on the decentralized peer-to-peer network, the smart contract itself, the frontend of the user interface. This kind of classification is pretty clear. Strictly speaking, the smart contract is part of the backend, so it could also be classified into two parts.
the choice of the private and public platform
To be frank, I have no idea which to choose. The first reason is that there is no exact idea yet, so it’s hard to distinguish which one would be better in this situation. And the second reason is I'm just the newbie. I can feel that I have no ablity to make decisions on this part yet.
Even though there are problems I mentioned above, I suppose I would use the public platform, and assume it would be Ethereum. And" Ethereum mainnet for enterprise" would be my target. After all, I have merely little knowledge of the private and federated platforms yet.
Sand table deduction: logic 2 of disassembling
INTRODUCTION TO THE ETHEREUM STACK, JAVASCRIPT API LIBRARIES, BACKEND API LIBRARIES, DEVELOPMENT NETWORKS, TESTING SMART CONTRACTS, SMART CONTRACT LIBRARIES
(1) sand table deduction
I would like to start from the sand table deduction. And the deduction would focus mainly on the software development itself.
Let's have a optimistic hypothesis first. Asssume that I'm fully equipped with the ability as a normal blockchain developer, and prepare to develop an application aiming for the B2B service. And the precedure of the service requires multi-party cooperation.
(2) The importance of GitHub
In order to develop this kind application, I would definitely have to work with other developer, so first we have to rely on tools like version control system like Git to have smooth developement process. And GitHub would be a good choice (I have to master GitHub, and accumulate some experience and projects on it before strating).
(3) 4 layers of blockchain realted part
Then the development can get started. Unlike the logic 1 of disassembling, here, I would like to catogorize the developement into two parts. One is blockchain realted, and the other is non-blockchain related.
For the blockchain related part, I would classify them into layers. And list the corresponding tools that is required. But I have to remind myself to foucus on the underlying purpose and the function of the tool instead of the tool itself. It is actually really easy to be violated. Also, when learning the tools, the framework, the libraries, always ask myself why does this tool exist and what is it for? It is quite contradicted that the tools are created in order to make the developemnt more convenient but we are often lost in the tools. It is recommeded to strat from the simplist tool and then move the more difficult one. Plus, never just duplicate the code without knowing what it is.
There are totally four layers, which is all related to the Ethereum. Layer 1 is Ethereum virtual machine, which is not the thing for me to worry about, I just need to know have to interact with it. Layer 2 and layer 3 is smart contract and ethereum nodes, and I have to write the smart contract and try to connect to the Ethereum nodes in order to make the app truly decentralized. For layer1, layer2, and layer 3, they are all scope of the backend. The last is layer layer 4, ethereum client API. It is mainly for the user side to connect to the Ethereum blockchain.
(4) the tools for these 4 layers
◎slanted is the tools with the highest priorities
In the development process, there are two famous frameworks,which are Embark and Truffle. The are the pre-made stack for the developemnt. But I think they are too "huge", so maybe let's skip them and come back later.
If we focus on the smart contract itself, which is layer 2. We would see two stuff. One is Remix,the environment for developing the smart contract, and the other is Solidity. What's worth mentioning is that there are resouces for the coding of smart contract, such as OpenZeppelin Contracts. I have to be clear that which part of the work it is able to simplify. Plus, web.js is the library allowing the smart contract to be written by Javascript, which is really a good news for me. There might be no need to learn Solidity from scratch and the use of Remix. For the more advanced stage, YUL AND YUL+ is the one enabling the better gas usage for smart contract. At last, after finishing the coding of smart contract, I might need the testing tools to test the contract itself, such as OpenZeppelin Test Environment, Whiteblock Genesis, and hevm.
Then, here comes the layer 3, Ethereum node This part would be mor complicated. For the backkend developer to access to network, there are backend API libraries to do the job. Not only could these libraries simplify the development, they can also provide utility functions so as a developer you can spend less time dealing with the intricacies of Ethereum clients and focus more time on the unique functionality of the application.
If I want to understand the operation of the node in advance, INFURA offers node as a service. Also, geth or parity are the nodes allowing me to connect with, so that I can access many information of the node and do some local test on the Ethereum network. Metamask(similiar to infura) allow me have my own nodes, so that I can use it to test the security of Ethereum, and even interact with my own application.
What's noticeable is that before the application get online, I should first use the development network, a kind of the private network, to test my application and the smart contract, such as Ganache(inlcuded in Truffle). It is the local developement test costing no gas. And before the offical launch to the public mainnet, it is also common to launch it to the public testnet such as Görli first . In my oponion, choosing one of these two would be ok.
For the last layer, layer 4, it is the last step of the blockchain related part. It would need me to get familiar with some Javascript API libraries, so the user of my service is able to connect to the blockchain newwork. Also, Javascript client libraries allow the application to call smart contract functions by reading the Application Binary Interface (ABI) of a compiled contract. This is the key to make to application more powerful.
The above are the diassemble of the 4 layers of the blockchain related part of the blockchain application.
(5) non blockchain related part
As for the non blockchain related part of the application, it is basically the same as the normal application The backend has to focused mainly on the database and application server, and the frontend has to focus on the user experience and the user interface.
#
