Author: Yongxin Xu

Editor: Matt McKinney

Last time, I introduced a blockchain application framework -- Forge Framework by ArcBlock, which provides the easiest way for developers to create custom blockchain and build blockchain applications.(Click here to check my last post :D)

For this post, I am going to share my DApp idea and the experience of how to conceive a DApp using a set of four questions we should consider before building a DApp. In addition, I will discuss the progress of my DApp, such as how to define a transaction protocol.

Recently, a DApp idea for vending machines came to my mind. It is about making a trustworthy ledger for vending machines. Why does a vending machine need a trustworthy ledger? As we all know, the vending machine is a form of selling merchandise and making money and since it is all about making money, it is necessary to have a ledger to track money. So, why does the ledger have to be “trustworthy”? Running a vending machine business usually requires participation from multiple parties. In my model, there are not only operators of vending machines, but also manufacturers of vending machines, suppliers of merchandise, and proprietors who provide their premises to install the physical vending machines. What’s more, every party has a corresponding profit share periodically.

Therefore, it is critical to do the accounting in a way that everyone trusts.

Another key question is why not use a traditional database? In simple terms, it is because it is relatively easy to tamper with the data stored in the database. But using blockchain is different. In essence, blockchain is a distributed, immutable, and transparent accounting system that provides a low-cost way of trust --machine trust. Because of this trust mechanism, blockchain technology can guarantee the authenticity of the ledgers and ensure every party can get its own profits fairly. Hence, blockchain is a great use case for the ledger aspects of vending machines.

The discussion above is actually answering one of the four questions we should consider before building a blockchain app. That is, why blockchain? Although blockchain as a concept is getting more and more popular, we cannot blindly follow the trend. This is because we have already had a lot of mature and sophisticated technology to solve certain problems in life. Therefore, we need to understand why blockchain can be a critical component of our app. As I mentioned above, my vending machine project requires the immutability of blockchain to solve the trust problem, and this problem can only be solved easily and at a low cost by blockchain.

The second question is which parts of my app need blockchain, and which parts should use traditional technologies. In other words, which parts do we want to be on-chain and which to be off-chain? Because what blockchain can do is relatively restricted, we should use blockchain for the most critical part, while achieving other things using more traditional methods. For my vending machine DApp, since I require the blockchain to ensure the ledger is immutable, I only need to store relevant data on the chain. As for how each bill is generated and how it is presented to the relevant parties, these are completed outside of the blockchain.

The third question is do I need to create a custom chain for my project? Or, do I want to develop my DApp on an existing chain, or do I need to use the relatively new concept of cross-chain? The answer to this question depends on our design and planning of the project. Because my DApp is a brand new project, I plan to build it with my own chain.

Last but not least, do I need to create a wallet? In Forge Framework, the concept of a wallet is the same as an account; it can be the initiator, or the recipient, of all activities on the chain. By the way, all activities in the Forge Framework are called “transactions”. A transaction is the smallest unit of activity on the chain. In my vending machine project, I want each vending machine can send bill information on the chain, and then each relevant party's ledger has a record of this information. As a result, I need to create a wallet account for each vending machine and each related party.

After thinking about these questions, we may start to model our DApps. Let me tell you what my vending machine DApp model looks like: my DApp is composed of three parts:

• the creation of bills,
• the recording of bills,
• and the presentation of bills.

The creation of bills refers to simulating a traditional vending machine system to generate data for a bill. The bill is recorded on the chain by the vending machine’s wallet sending the related data to the chain. Finally, the bill and the final ledger of each party are presented in the traditional web platform with the data loaded from the chain. Basically, the first and the third part are mainly off-chain, while the second part - the recording of the bill, will be on-chain, which is the one we are least familiar with, and is what I was working on this week.

As we mentioned earlier, every activity in the chain is called a transaction. Creating a wallet is a transaction; a transfer is another type of transaction. So, how do we define a transaction? A transaction is defined by something called a transaction protocol. In Forge Framework, many common transactions such as create a wallet, transfer, and exchange, are already defined for the convenience of developers. In addition, Forge Framework simplifies the process of making and deploying a custom transaction protocol by providing a template for developers to follow.

In order to meet the needs of my DApp, I built a new transaction protocol, called “aggregate transaction”. This transaction satisfies my billing requirements: First, when the vending machine initiates the “aggregate transaction”, the transaction will send information of the merchandise to the chain, such as its name, its price, and the time of purchase, as well as the information of the related parties, like the operator, the manufacturer, the supplier, and the proprietor. After the “aggregate transaction” is successfully sent on the chain, not only will that information be recorded on the chain, but also the profit amount from this merchandise will be updated simultaneously in each of the related parties' wallet accounts. This is my definition of “aggregate transaction”.

After the definition of the new transaction is confirmed, the next step is programming! Next week, I will show how to program a transaction protocol by using Forge Framework and how to build a simulator test my work.