，以以太坊（Ethereum）为主流，也包括Solana、Aptos等其他非EVM链。本身是软件，需要运行在一系列节点上，这些节点组成P2P网络或者半中心化网络。节点不仅负责接收新的输入并生成新的区块，还需要存储运行时产生的所有数据，并负责同步、对外提供查询等RPC服务。
钱包：帮助用户管理自己在上资产的软件，加密存储用户的私钥。当用户需要和交互时，就需要用到私钥签名；
智能合约：运行在上的一段托管程序，主要用来和外部账户交互；
UI：这里特指前端页面，因为直接通过RPC调用合约个别用户，普通用户仍需要一个前端页面，并通过JavaScript脚本配合钱包签名与合约交互。
因为上所有数据全透明，要查询任意区块的数据，可以通过EtherScan这个网站查。其他公链，无论是与Ethereum兼容的BSC、Polygon，还是不兼容的Solana、Aptos等，也提供类似XxxScan这样的查询网站。这些Scan能提供基本的读写合约的能力，有助于kaifa阶段的测试。
本身以及钱包、EtherScan等属于基础设施，如何基础设施不在本文讨论范围之内。本文定如何kaifaDApp。
一个完整的DApp需要kaifa以下部分：
智能合约：将逻辑写入合约，并部署在链上；
UI：为用户提供一个交互式UI，配合钱包完成特定功能。
此外，对后端kaifa有经验的同学应该知道，通常来说，App数据会存储在数据库中，前端与后端交互，离不开后端对数据的查询和修改。在DApp中，同样需要一个查询的“后端”，但这个后端通常不是数据库。
有的同学会认为，既然节点本身提供了查询链上全部数据的PRC接口，那么，前端直接查询节点是否可行？答案是不行。因为节点提供的数据，是用户产生的原始日志。
举个例子，假设有个NFT合约，允许用户创建NFT，那么，一段时间内，节点产生的日志如下：
用户A创建了NFT-1；
用户B创建了NFT-2；
用户B把NFT-2转移给了用户X；
用户C创建了NFT-3；
...
这些未经聚合处理的数据没法生成一个不断更新的数据库表：
OwnerNFTID
用户A1
用户X2
用户C3
所以，一个DApp除了前端外，还需要一个后端服务，它主要功能是不断聚合链上产生的数据，并根据DApp的业务需求设计表结构以方便查询。
一个直观的想法是用Java或者Go语言等编写一个后端服务，再配上一个数据库，就可以为前端提供RESTAPI来实现查询。只不过自己维护后端服务比较麻烦，还需要租用云端服务器、数据库等资源，费时费力。
我们推荐另一种后端服务：TheGraph。它本身也可看作是一个基础设置。TheGraph可以让我们部署一个Graph查询服务，如何定义表结构以及如何更新则由我们提供一个预编译的WASM。整个配置、WASM代码以及查询服务都托管在TheGraph中，无需自己搭建服务器，非常方便。