聊聊DeFi应用架构设计之道

简介: 笔记

前言


DeFi 应用跟传统应用的差异性还是比较大的,商业模式不同,产品模型也不同,就连落地实现的技术栈也有很大不同。一般,传统应用也称为 Web2 应用,而 DeFi 应用则可被归入 Web3 之列。

我们不说商业模式和产品模型,就只说说技术栈。DeFi 应用目前所涉及到的技术栈主要包括:Solidity、Subgraph、Price Oracle、Hardhat、Ethers 等等。这些技术栈,大多就连阿里、腾讯、字节等互联网大厂里一些高达 P9 级别的大佬可能听都没听过。传统应用架构中所热门的微服务架构、大数据架构、云原生架构等,在 DeFi 应用中也基本毫无用武之地。

这些技术栈只是 DeFi 应用的硬门槛,如果不熟悉这些技术栈,就难以设计出优雅的 DeFi 应用。而且,除了这些硬门槛,还存在一些软门槛,主要是一些思维上的东西,如果没在区块链行业中沉淀至少一两年的话是掌握不了的。因此,就算是传统应用的架构大佬们,也无法平滑无缝地将技能切换到 DeFi 行业。而且 DeFi 也只是这两年才开始爆发起来的,也因此,这个行业中架构师级别的人才非常紧缺。

我从 2017 年中旬就开始研究区块链,在这个行业深耕了几年时间,做过了几款 DeFi 应用,才终于有了一些根基。基于我的经验总结,来聊聊我理解的 DeFi 应用的架构设计之道。


整体架构


先来看看一个 DeFi 应用系统的整体架构一般是怎样的:

50.png

下面我来一一介绍下几个模块:

  • Blockchain:底层的区块链网络,一个 DeFi 应用一般都会部署到多个不同的区块链网络
  • Smart Contracts:智能合约,是 DeFi 应用的核心业务实现,也是灵魂所在
  • Price Oracle:价格预言机,用来提供价格信息的,一般可分为链下预言机和链上预言机
  • Keeper Services:智能合约的任务触发器和执行器,因为智能合约本身没有自动触发执行任务的能力,所以需要外部的任务触发器协助
  • Subgraph:子图,也被称为索引器,主要将链上数据重新组装成方便前端查询的数据
  • Graph Node:Subgraph 所运行的环境,会同步链上区块数据给 Subgraph 处理
  • Wallet:钱包应用,最主流的就是 MetaMask
  • WebUI:前端展示的 UI 页面,一般用 Vue、React 等前端框架
  • SDK:封装了对 Subgraph 的查询、智能合约的调用、钱包的连接等,方便前端 UI 的调用

相信有不少人会产生一个疑惑:为什么一个 DeFi 应用系统会有这么多不同的组成?

首先,智能合约本身缺乏自动执行的机制。Web2 应用因为有定时器,所以很多任务都可以用定时器自动执行。但智能合约却没有定时器,因此有些任务就没法自动执行,就需要外部程序来触发执行这些任务。这样的外部程序就被称为 Keeper,比如执行 Compound的清算任务的 liquidator 就是一种 Keeper。

大部分 Keeper 都是链下中心化的程序。而近一年来,也陆续出现了一些去中心化的 Keeper 网络,我所知的就有 keep3r.network、Chainlink Keepers、KeeperDAO

其次,也同样是因为智能合约本身的限制,无法像 Web2 应用一样主动向外部程序发起网络请求获取数据。否则,如果智能合约可以向 Coinbase、Binance 等中心化交易所发送网络请求获取价格数据的话,那不同节点因为请求的时间不同,获取到的价格也不同,就无法达成一致了。但智能合约又的确需要获取价格信息,所以就有了 Price Oracle

Price Oracle 主要可分为链下预言机链上预言机两大类。

链下预言机以 Chainlink 为代表,其基本原理是将多个交易所(包括中心化和去中心化的交易所)的数据源进行多层面的聚合后再将最终的价格数据更新到链上智能合约,DeFi 应用就可以直接读取链上智能合约的价格信息。

链上预言机则以 Uniswap 的 TWAP(时间加权平均价格) 为主流,其原理我在之前的文章《剖析DeFi交易产品之Uniswap:V2下篇》已经聊过,就不再重复了。

另外,智能合约存储的数据和传统 Web2 的数据库完全不同,没法像 MySQL、MongoDB 这些数据库一样对数据进行索引查询,也没法做到对数据进行分组、排序或组合。而这种需求也属于刚需,为了满足这种需求,就出现了 The Graph,区块链数据索引协议。Subgraph 就是该协议的核心组成,Graph Node 则是其运行环境。

最后,WebUI 和 SDK 本来是可以合在一起的,但因为很多前端开发人员并不熟悉 Web3,因此就将 Web3 相关的操作抽离出来组装成了 SDK。如此分离之后,WebUI 就只需要专注于前端的展示层,而 SDK 则承接了前端的数据层。

具体到每个不同的 DeFi 应用,实际的架构可能稍微有些许差异,比如 Uniswap 就不需要 Keeper Services,也不需要 Price Oracle。但大部分稍微复杂些的 DeFi 应用基本都需要这些组成,也因此,这种架构也已经成为大部分 DeFi 应用的通用架构。


智能合约设计


整个 DeFi 应用系统中,最核心也最复杂的当属智能合约,且智能合约还是需要开源的,其安全性也至关重要,所以,智能合约的设计也自然是非常关键的一环。

虽然,具体的设计因具体产品而异,但依然有一些通用的设计原则,有助于我们设计出相对优雅的智能合约产品。所谓的相对优雅,在我看来,最主要的就是满足几个特性:安全性、功能性、扩展性

因为智能合约需要全部开源,所以安全性肯定是排在第一位的,避免遗留各种安全漏洞,尤其要防止闪电贷攻击、重入攻击、权限漏洞等。正式上线主网之前,应该充分进行内部的安全审计和外部审计机构的安全审计,以及充分地测试,包括内部测试和对外的开放测试,甚至公开挂出悬赏,让更多专业人士一起来寻找隐藏的漏洞。

满足功能性是一个基本需求,比如,一个借贷产品,能存取借还就是必须满足的基本需求;一个衍生品 DEX,能放大杠杠交易也是必须满足的基本需求。但要满足到何种程度,就可能受其它约束条件限制了。比如,衍生品 DEX 为了防止闪电贷攻击,可能会禁止同个账户在同个区块内既开仓又平仓。

扩展性也是非常重要的一个特性,毕竟,一个应用系统并不是只发布一个版本就足够了,总需要持续迭代添加新功能。比如,衍生品 DEX,第一版可能只实现市价交易功能,第二版需要增加限价交易功能,第三版再增加止盈止损功能。

这几个特性也不是全正相关的,比如,进一步提高安全性,就可能会减低功能性和扩展性,因此,要追求的并不是三种特性全都越高越好,而是要根据情况有所取舍,达到一种平衡状态即可。

而要达成目标,所需要遵循的设计原则和背后本质的设计思想,其实还是架构师们所熟知的那些,比如,单一职责原则、开闭原则、依赖倒置原则、接口隔离原则等,以及关注点分离、低耦合高内聚、适度设计等架构思想。

Uniswap 就是一个很好的典范,就以 v2 为例,所有智能合约根据模块化拆分为了几个小项目:v2-corev2-peripherysolidity-libliquidity-staker不同模块之间只依赖于接口,而且只是上层模块依赖于下层模块的接口,下层则不依赖上层,这也符合分层架构思想。而且,整个协议,基本是全自动化的,交易对可以自由创建,手续费率是硬编码的,也几乎没有任何需要运营配置管理的参数,所以,治理成本也非常低。综上所述,Uniswap 就变得简单化了,简单就是美,因为简单,测试容易,不容易出 BUG,扩展性也好,这就是优雅的设计。

做架构设计,最核心的就是要将复杂问题简单化,这应用到开源的智能合约中,显得更加重要。


设计实践


下面以我目前负责的 DeFi 应用为例,聊聊我的一些实践总结。

先简单介绍下背景,小部分朋友知道我最近加入了新团队,在负责一个 DeFi 产品,确切地说,是一个衍生品 DEX。交易模式主要采用 AMM 模式,但不是 Uniswap 那样提供双币流动性的 AMM,而是提供单币流动性的 AMM,我们称为 Elastic AMM。具体业务就不展开了,以后再另外细聊,这次我主要还是讲讲架构设计方面的考量。

整个应用系统的整体架构和上面所说的大致相同,所以我不打算再赘述整体架构,而主要想聊聊智能合约方面的设计。

智能合约层面,其实还分为了主协议外围协议。而我主要想聊的是主协议的设计,下图就是主协议的架构:

51.png

绿色的只表示参与到系统中的几种角色,其它颜色的则都是智能合约里的子模块了。

首先,我采用了分层架构思想,将系统进行了层次划分,上层依赖于下层,但下层却不能依赖上层。其次,模块之间只依赖于接口,而不依赖于具体实现。这样,模块之间才能实现低耦合。

作为 Trader 和 LP 的用户,都统一跟 Router 交互,Router 在其中就相当于起到了路由网关的作用。而且,因为底层对它没有依赖,所以就很容易升级替换。

每个交易对分别有一个 Amm 合约和一个 Margin 合约,且 AmmMargin 是相互绑定的。因此,自然而然地,就想到了用工厂模式来创建不同的交易对。原本的设计中,其实只有一个工厂合约,但在具体实现中,最终发现工厂合约超过了**智能合约最大字节数,**于是就将工厂合约拆分成了三个。

Amm 的职责是负责底层的兑换交易,而 Margin 的职责则是管理用户的仓位。LiquidityERC20 是流动性代币合约,由 Amm 继承。Vault 管理着主协议中的实际资产,由 Margin 继承。该模块是整个协议的核心,只实现底层基本的功能,比如加减保证金、开平仓、添加和移除流动性等。扩展性的功能则可由上层模块实现,比如由 Router 实现 ETH 和 WETH 的兑换支持,再比如后续再添加上层合约支持限价单、止盈止损等。

Config 合约则管理了所有可配置的参数,PriceOracle 即封装了一些读取价格的接口。

一旦理解了这个架构,就会发现其实很简单也很清晰。当然,做架构设计难的地方就在于,并非总能想到这么简单的方案。


总结


DeFi 应用系统的整体复杂度其实还远远比不上 Web2 应用系统的,但因为技术栈几乎完全不同,而且产品思维上也有较大差异,而且 DeFi 应用还都是开源的,这些都变成了这个行业的门槛。所以,缺乏经验的人现在进入其实并不太容易上手了,就算是 Web2 的高端人才,进了 Web3 依然需要些时日进行学习和沉淀。

这次我主要分享了下目前 DeFi 应用的整体架构,以及智能合约层面的架构设计的一些经验总结。虽然和 Web2 相比,技术栈不同,还需要具备区块链思维,但本质上的架构思想其实还是通用的。

后续我再以目前负责的项目为例,深入聊聊一些细节上的设计。


相关文章
|
3月前
|
人工智能 自然语言处理 开发工具
统一多模态 Transformer 架构在跨模态表示学习中的应用与优化
本文介绍统一多模态 Transformer(UMT)在跨模态表示学习中的应用与优化,涵盖模型架构、实现细节与实验效果,探讨其在图文检索、图像生成等任务中的卓越性能。
统一多模态 Transformer 架构在跨模态表示学习中的应用与优化
|
4月前
|
存储 编解码 Serverless
Serverless架构下的OSS应用:函数计算FC自动处理图片/视频转码(演示水印添加+缩略图生成流水线)
本文介绍基于阿里云函数计算(FC)和对象存储(OSS)构建Serverless媒体处理流水线,解决传统方案资源利用率低、运维复杂、成本高等问题。通过事件驱动机制实现图片水印添加、多规格缩略图生成及视频转码优化,支持毫秒级弹性伸缩与精确计费,提升处理效率并降低成本,适用于高并发媒体处理场景。
218 0
|
5月前
|
人工智能 监控 安全
NTP网络子钟的技术架构与行业应用解析
在数字化与智能化时代,时间同步精度至关重要。西安同步电子科技有限公司专注时间频率领域,以“同步天下”品牌提供可靠解决方案。其明星产品SYN6109型NTP网络子钟基于网络时间协议,实现高精度时间同步,广泛应用于考场、医院、智慧场景等领域。公司坚持技术创新,产品通过权威认证,未来将结合5G、物联网等技术推动行业进步,引领精准时间管理新时代。
|
7天前
|
人工智能 Cloud Native 中间件
划重点|云栖大会「AI 原生应用架构论坛」看点梳理
本场论坛将系统性阐述 AI 原生应用架构的新范式、演进趋势与技术突破,并分享来自真实生产环境下的一线实践经验与思考。
|
6月前
|
Web App开发 Linux 数据库
Omnissa Horizon 8 2503 (ESB Release) - 虚拟桌面基础架构 (VDI) 和应用软件
Omnissa Horizon 8 2503 (ESB Release) - 虚拟桌面基础架构 (VDI) 和应用软件
360 8
Omnissa Horizon 8 2503 (ESB Release) - 虚拟桌面基础架构 (VDI) 和应用软件
|
14天前
|
机器学习/深度学习 人工智能 vr&ar
H4H:面向AR/VR应用的NPU-CIM异构系统混合卷积-Transformer架构搜索——论文阅读
H4H是一种面向AR/VR应用的混合卷积-Transformer架构,基于NPU-CIM异构系统,通过神经架构搜索实现高效模型设计。该架构结合卷积神经网络(CNN)的局部特征提取与视觉Transformer(ViT)的全局信息处理能力,提升模型性能与效率。通过两阶段增量训练策略,缓解混合模型训练中的梯度冲突问题,并利用异构计算资源优化推理延迟与能耗。实验表明,H4H在相同准确率下显著降低延迟和功耗,为AR/VR设备上的边缘AI推理提供了高效解决方案。
218 0
|
6月前
|
人工智能 Cloud Native Serverless
从理论到落地:MCP 实战解锁 AI 应用架构新范式
本文旨在从 MCP 的技术原理、降低 MCP Server 构建复杂度、提升 Server 运行稳定性等方面出发,分享我们的一些实践心得。
2489 104
|
4月前
|
消息中间件 存储 Kafka
一文带你从入门到实战全面掌握RocketMQ核心概念、架构部署、实践应用和高级特性
本文详细介绍了分布式消息中间件RocketMQ的核心概念、部署方式及使用方法。RocketMQ由阿里研发并开源,具有高性能、高可靠性和分布式特性,广泛应用于金融、互联网等领域。文章从环境搭建到消息类型的实战(普通消息、延迟消息、顺序消息和事务消息)进行了全面解析,并对比了三种消费者类型(PushConsumer、SimpleConsumer和PullConsumer)的特点与适用场景。最后总结了使用RocketMQ时的关键注意事项,如Topic和Tag的设计、监控告警的重要性以及性能与可靠性的平衡。通过学习本文,读者可掌握RocketMQ的使用精髓并灵活应用于实际项目中。
2333 9
 一文带你从入门到实战全面掌握RocketMQ核心概念、架构部署、实践应用和高级特性
|
3月前
|
人工智能 数据可视化 Java
什么是低代码(Low-Code)?低代码核心架构技术解析与应用展望
低代码开发正成为企业应对业务增长与IT人才短缺的重要解决方案。相比传统开发方式效率提升60%,预计2026年市场规模达580亿美元。它通过可视化界面与少量代码,让非专业开发者也能快速构建应用,推动企业数字化转型。随着AI技术发展,低代码与AIGC结合,正迈向智能化开发新时代。

热门文章

最新文章