Dapp开发简介

CoheeY

已于 2024-12-10 15:30:03 修改

阅读量1.1k

点赞数 14

分类专栏： Way to Web3 文章标签：区块链 web3

于 2024-12-02 02:17:30 首次发布

本文链接：https://blog.csdn.net/weixin_57158039/article/details/144175686

版权

Way to Web3 专栏收录该内容

6 篇文章

订阅专栏

1.Dapp的特点

Dapp最大的特点就是它的后端主要是是基于由区块链网络（如以太坊网络）而非中心化服务器运行的，这也就导致dapp天然具备了如下的优点和缺点。

优点：

1.基于分布式节点而保证Dapp具备零停机风险

白话来说就是，太多节点服务器了，死一个也不会导致你的应用完蛋

2.智能合约的绝对执行解决了信任危机

一切会以智能合约上所写的内容触发交易，且合约代码公开可见不可篡改，降低了信任成本

3.用户隐私的保护

比如，许多Dapp只要用metamask钱包中公钥私钥来进行互动就能完成所有操作，你连注册邮箱都可以跳过，这种匿名性可以保护客户的敏感数据和交易记录不被泄露；同时交易记录在一个去中心化的节点网络上，而不是集中式权威机构，这降低了数据泄露和个人信息被滥用的风险。

4.抗审查和人人可参与性

基本上世界上所有人都可以参与到Dapp的服务中去，不会像过去的一些app一样会由于中心化服务器的限制而导致只有部分地区能访问，也没有所谓的封号这一说，基本是人人都能享有此dapp的服务。

---------------------------------------------------------------------------------------------------------------------------------

缺点：

1.难以维护和更新

如果只是单纯用一个合约来做后端将非常难以维系，这是因为合约本身难以篡改，一旦需要更新则会是一个很麻烦的事情

2.犯罪分子的天堂

由于其匿名和抗审查性的特点，这样会导致犯罪分子使用此类服务进行洗钱等犯罪活动变得十分轻松（所以现在meta mask里面买币都需要提交身份验证）

3.费用问题

以太坊网络进行交易是需要gas费用的，而如果网络拥堵将造成gas费的上涨，这也就导致交易费用的不可控。

2.一个简单Dapp的基本结构

一个Dapp一般都离不开以下三个部分：

1.智能合约

2.前端

3.数据存储

简单概括，部署在以太坊的合约作为后端完成基本服务的实现，以React/Vue的前端通过在内容中打包好的UI和Web3.js/Ether.js/viem这样的接口给到客户端来调用合约中的函数和数据完成交互，而如MetaMask这样的钱包则在前端的调用下负责完成签名和发送交易给智能合约完成最终的交易。

但是区块链本身有个很大的缺点就是对于大数据的存储是一个非常昂贵的事情，这也就导致一些如图片，视频等数据的上链将消耗大量的gas费用。而目前主流的解决方法就是通过和IPFS协议的关联，如通过存储对应的文件的哈希值来进行数据的去中心化存储。

3.Dapp应用的具体架构

具体而言，一个以EVM网络为基础的Dapp的交互流程可以如下图所示

Signer: signer就是如小狐狸钱包这样的web3钱包，它作为存储你公钥和私钥对的一个工具来进行对页面的授权交易，即一旦需要对EVM网络上进行数据的修改，前端中的etherjs调用signer。

具体而言，当用户需要进行交易或操作时，Signer 在本地使用私钥对交易数据进行签名。而签名后的交易数据会被发送到以太坊网络，以太坊网络中的节点使用用户的公钥来验证签名的有效性。
Provider:Provider是以太坊网络中的节点提供商，provider存在的原因是因为我们的交易（或者是合约部署）需要发给以太坊网络中的某一个节点来进行验证，它在这个区块中所有交易打包验证完后广播给其他节点进行验证，当所有验证通过后，就会进行将包含我们交易的这个区块同步到所有网络中去。

而如果我们自己从零开始去创建一个以太坊网络节点来再发送交易给它进行验证需要非常大的成本（买服务器/数据同步的时间等成本），所以我们会选择将交易的签名直接发送给Provider已创建好的一个服务器节点。

JsonRPC:JSON - RPC（JavaScript Object Notation - Remote Procedure Call）是一种远程过程调用协议，它是前端与以太坊节点（Provider）之间进行通信的重要方式。
(上图少了个指向provider的箭头)

///比如我们创建一个对应的provider实例（hardhat中直接在config中配置对应的url即可）
const provider = new ethers.providers.JsonRpcProvider('服务器节点的url');

//发送一个查找合约余额的请求：
await provider.getBalance("合约address");

//那么前端会通过http请求发送给node类似如下的Json
{
  "jsonrpc": "2.0",
  "method": "eth_getBalance",
  "params": ["合约地址", "latest"],
  "id": 1
}

//之后node也会返回我们一个JsonRPC数据
{
  "jsonrpc": "2.0",
  "result": "合约具体余额",
  "id": 1
}

ABI:在前端发送完操作给节点信息后，节点又如何通信调用具体的合约的函数呢？于是ABI就起了作用；ABI是一个描述合约接口的二进制格式规范，用于在不同的编程语言和开发环境中准确地调用合约函数。

ABI会在合约最初编译时就产生，在编译过程中，编译器会对合约的结构和函数等进行分析，并根据合约中定义的函数签名、参数类型、返回值类型等信息生成相应的 ABI。

ABI本身不会存在区块链上服务器，只有字节码会被存在服务器里，ABI更像是一个指导手册，让不同的编程语言都能通过这个手册来和合约进行互动。
IPFS/Swarm: IPFS和SWARM就如之前所说的一样，是为了存储大型数据而生的分布式存储节点，IPFS是让每个数据生成一个哈希值，再用这个哈希来配对文件进行指向和访问，替代了过去的http协议的url指向的方法。

具体而言，过去http协议对应一个url对应服务器的IP地址，而再对应IP地址下服务器存储的数据和文件。
而ipfs直接省去了对应服务器的步骤，将数据生成的唯一哈希值来对应数据本身，同时通过分布式多节点的方式存储这些数据，用户直接通过哈希值来访问这个数据，这样既保证了去中心化，也保证了原哈希下对应的内容无法被篡改。

IPFS本身也是分布式节点构成的系统，也就使其本身也具备去中心化性；同时为了保证前端不受中心化服务器所影响，多数Dapp也会选择IPFS来存储自身的前端应用。
TheGraph:The Graph是一个链下的去中心化的索引协议，用于查询以太坊和 IPFS 网络数据，旨在让开发者更方便地从区块链中获取数据。

The Graph是一个提供了一个非常强大的数据获取机制，在the graph出现之前，我们获取链上数据只能在合约部署前就写好的函数和事件，通过在我们自己的服务器数据库中通过日志轮询/WebSocket订阅的方式来进行数据的储存和检索。但是这种数据建设的机制本身就是中心化且有单点停机风险的，这种风险就导致数据的伪造和数据的丢失。

而The Graph通过让数据需求方提供需要索引数据的合约，并让众多分布式节点进行数据的索引和同步，这些节点将表数据存储在IPFS上，当有任何数据需求时只需要对这些节点进行请求即可。这种模式保持了分布去中心化应用的纯洁性，并提供了一种更高效省力的数据解决方案。
Layer2网络：直接在以太坊公链上一笔一笔交易会是一个可能会是一个非常不经济的事情，这就由此诞生了Layer2网络，基于以太坊公链的Polygon是一直以来的明星Lay2网络来降低交易成本和提升交易的速度。
具体而言，Lay2网络通过Rollup算法（乐观和零知识Rollup）将一系列交易打包来执行，最后再把交易数据上链验证，这样打包公摊下来，gas费用大大减少，同时也提高了交易的速度。