为什么开发DApp需要用到区块链技术

最近，我突发奇想，想做一个和自动贩卖机有关的去中心化应用。简单来说，它是自动贩卖机的信任账本。我们知道，自动贩卖机是用来卖东西的。既然卖东西，就需要账本。那为什么是信任账本呢？ 因为运营一台自动贩卖机，往往需要多方的参与。在我的应用场景里，不但有贩卖机的运营方，还有贩卖机的制造方，商品的供货方，以及场地的租赁方。并且，每一方都会定期有相应的利润分成。

因此，我需要用一个大家都信任的方式来进行记账。

那为什么不用现有的数据库呢？ 因为数据库里的数据容易被篡改。但是区块链就不一样了。因为，区块链从本质上来说，就是一种分布式的、不可篡改、高通明度的记账系统，它能够提供一种低成本的信任方式，就是机器信任。因为这种信任机制，我们能保证我们的账本具有真实性，确保每一方都能公正的获得属于自己的利润。因此，我们需要区块链来给我们提供一个信任账本。

上面的讨论，其实是在回答我们开发 DApp 前需要思考清楚的第一个问题 —— 为什么要用区块链？ 区块链这个概念虽然越来越火，但我们不可以盲目跟风。因为我们目前已经有很多完善、成熟的技术可以非常方便的解决了我们生活中的问题。所以，我们一定要定位清楚，我们的应用为什么要用区块链。而像我之前和大家提到的，我的自动贩卖机项目需要区块链来解决信任问题，并且这个问题只有区块链才能很轻松地解决。

第二个问题是，我的 DApp 哪些部分需要用区块链，哪些部分要用传统的方式？ 也就是说，我们要构思清楚哪些部分我们要放在链上，哪些要放在链下。因为目前区块链的开发成本比较大，因此好钢用在刀刃下，我们要将区块链用于最关键的部分，而其他事情就用传统的方法来做。就我的项目而言，因为我需要区块链来保证自动贩卖机账本的不可篡改性，所以只需要在链上完成记账，也就是记录数据这个步骤。至于账单如何生成、如何呈现给相关方，就通过链下的方式来解决。

第三个问题，我需不需要为我的 DApp 发链？ 还是说，我要在原有的链上开发应用，或者考虑跨链？这个问题取决于我们对项目的设计和规划。因为我这是一个全新的项目，我打算用自己的链来开发。

最后一个问题，我需要创建钱包吗？ 在 Forge 里，钱包的概念就和账户一样，是链上所有行为的发起方，或者是接收方。另外我多说一句，我们 Forge 里所有行为都称为「transacTIon」［2］，英文直译是「交易」，意译的话，可理解为事务。它是链上最小的活动单位。在我的贩卖机项目里，我希望通过贩卖机的账户在链上发送账单信息，同时相关方的账本里会有这笔账单的记录。因此，我需要为每一台贩卖机，和每一位相关方创建钱包账户。

思考完以上四个问题，我们就可以开始为自己的 DApp 建模了。我来和大家介绍下我的模型。我的自动贩卖机 DApp 共由以下三个部分组成：

•账单的生成，

•账单的记录，

•以及，账单的呈现。

账单的生成是指模拟现有的贩卖机系统，随机生成账单信息。而账单的记录是通过贩卖机的钱包账户将这些数据发送到链上。最后，账单的呈现是通过调取链上的数据，在链下整合后通过 pc 端平台来展示。因此，我第一部分和第三部分主要依赖链下的技术，而第二部分--账单的记录，就是链上的了。这部分通常我们最不熟悉的区域，也是我上周主要在做的部分。

前面我们提到，链上的一切行为都叫作交易。创建钱包算一个交易，转账也算一个交易。那我们是如何定义一个交易的呢？交易定义是通过 transacTIon protocol［3］，交易协议，或者说是智能合约，来完成的。Forge 开发框架为开发者提供了很多常见的交易协议，例如钱包的创建、转账、交换资产等等。同时 Forge 开发框架简化了编写、部署交易协议的过程，通过提供模版化流程让开发者可以轻松定义新的交易协议。

为了满足我 DApp 的需求，我做了一个新的交易协议，叫「合并交易」。这个交易满足了我记账的要求：首先，当贩卖机发起这个「合并交易」时，该交易会为链上发送商品的信息，例如：商品的名称、价格、消费时间，以及商家的信息，例如：运营方、制造方、供货方，和场地方。而且，「合并交易」发送成功后，不但这些信息会永远地记录在链上，同时，相关方的钱包账户里会更新相应的利润金额。这个就是我对「合并交易」的定义了。

确认好了交易协议的定义，接下来就是写码的工作了！下周，我会向大家展示通过 Forge 开发框架制定交易协议的编码过程，以及如何用 Python 来完成我剩下的链下部分。