以太坊:简述DeFi应用架构设计之道_WEB

原文作者：Keegan小钢前言

DeFi应用跟传统应用的差异性还是比较大的，商业模式不同，产品模型也不同，就连落地实现的技术栈也有很大不同。一般，传统应用也称为Web2应用，而DeFi应用则可被归入Web3之列。我们不说商业模式和产品模型，就只说说技术栈。DeFi应用目前所涉及到的技术栈主要包括：Solidity、Subgraph、PriceOracle、Hardhat、Ethers等等。这些技术栈，大多就连阿里、腾讯、字节等互联网大厂里一些高达P9级别的大佬可能听都没听过。传统应用架构中所热门的微服务架构、大数据架构、云原生架构等，在DeFi应用中也基本毫无用武之地。这些技术栈只是DeFi应用的硬门槛，如果不熟悉这些技术栈，就难以设计出优雅的DeFi应用。而且，除了这些硬门槛，还存在一些软门槛，主要是一些思维上的东西，如果没在区块链行业中沉淀至少一两年的话是掌握不了的。因此，就算是传统应用的架构大佬们，也无法平滑无缝地将技能切换到DeFi行业。而且DeFi也只是这两年才开始爆发起来的，也因此，这个行业中架构师级别的人才非常紧缺。我从2017年中旬就开始研究区块链，在这个行业深耕了几年时间，做过了几款DeFi应用，才终于有了一些根基。基于我的经验总结，来聊聊我理解的DeFi应用的架构设计之道。整体架构

数据：上海升级后一周以太坊单周存款量接近54万枚ETH，创历史第二高记录:金色财经报道，据21Shares分析师Tom Wan披露数据显示，上海升级后一周，以太坊单周存款量达到了53.99万枚ETH，创下迄今为止第二大单周存款记录。流入量最大的单周存款记录发生在2020年11月23日那一周，当时存入了55.658万枚ETH。在提供以太坊质押服务的头部CEX中，币安质押ETH数量最多，达到10.7万枚，其他CEX数据为：Huobi：4.52万枚ETH、Kraken：2.3万枚ETH、Coinbase：1.19万枚ETH。[2023/4/24 14:23:01]

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

下面我来一一介绍下几个模块：Blockchain：底层的区块链网络，一个DeFi应用一般都会部署到多个不同的区块链网络SmartContracts：智能合约，是DeFi应用的核心业务实现，也是灵魂所在PriceOracle：价格预言机，用来提供价格信息的，一般可分为链下预言机和链上预言机KeeperServices：智能合约的任务触发器和执行器，因为智能合约本身没有自动触发执行任务的能力，所以需要外部的任务触发器协助Subgraph：子图，也被称为索引器，主要将链上数据重新组装成方便前端查询的数据GraphNode：Subgraph所运行的环境，会同步链上区块数据给Subgraph处理Wallet：钱包应用，最主流的就是MetaMaskWebUI：前端展示的UI页面，一般用Vue、React等前端框架SDK：封装了对Subgraph的查询、智能合约的调用、钱包的连接等，方便前端UI的调用相信有不少人会产生一个疑惑：为什么一个DeFi应用系统会有这么多不同的组成？首先，智能合约本身缺乏自动执行的机制。Web2应用因为有定时器，所以很多任务都可以用定时器自动执行。但智能合约却没有定时器，因此有些任务就没法自动执行，就需要外部程序来触发执行这些任务。这样的外部程序就被称为Keeper，比如执行Compound的清算任务的liquidator就是一种Keeper。大部分Keeper都是链下中心化的程序。而近一年来，也陆续出现了一些去中心化的Keeper网络，我所知的就有keep3r.network、ChainlinkKeepers、KeeperDAO。其次，也同样是因为智能合约本身的限制，无法像Web2应用一样主动向外部程序发起网络请求获取数据。否则，如果智能合约可以向Coinbase、Binance等中心化交易所发送网络请求获取价格数据的话，那不同节点因为请求的时间不同，获取到的价格也不同，就无法达成一致了。但智能合约又的确需要获取价格信息，所以就有了PriceOracle。PriceOracle主要可分为链下预言机和链上预言机两大类。链下预言机以Chainlink为代表，其基本原理是将多个交易所的数据源进行多层面的聚合后再将最终的价格数据更新到链上智能合约，DeFi应用就可以直接读取链上智能合约的价格信息。链上预言机则以Uniswap的TWAP为主流，其原理我在之前的文章《剖析DeFi交易产品之Uniswap：V2下篇》已经聊过，就不再重复了。另外，智能合约存储的数据和传统Web2的数据库完全不同，没法像MySQL、MongoDB这些数据库一样对数据进行索引查询，也没法做到对数据进行分组、排序或组合。而这种需求也属于刚需，为了满足这种需求，就出现了TheGraph，区块链数据索引协议。Subgraph就是该协议的核心组成，GraphNode则是其运行环境。最后，WebUI和SDK本来是可以合在一起的，但因为很多前端开发人员并不熟悉Web3，因此就将Web3相关的操作抽离出来组装成了SDK。如此分离之后，WebUI就只需要专注于前端的展示层，而SDK则承接了前端的数据层。具体到每个不同的DeFi应用，实际的架构可能稍微有些许差异，比如Uniswap就不需要KeeperServices，也不需要PriceOracle。但大部分稍微复杂些的DeFi应用基本都需要这些组成，也因此，这种架构也已经成为大部分DeFi应用的通用架构。智能合约设计

Coinbase将于以太坊Shapella升级后受理质押ETH提币请求，美国用户或需要缴税:3月16日消息，Coinbase在博客文章中表示，在Shanghai-Capella（Shapella）升级到以太坊网络后的24小时后，Coinbase将开始受理取消质押请求。Coinbase指出，“取消质押的过程由以太坊协议控制，而我们只是一个通道，因此不清楚取消质押所需等候的准确时间。”

美国客户通过需要为升级前和升级后获得的任何奖励缴纳税款。对于持有质押的ETH(ETH2) 或cbETH的美国Coinbase客户，Coinbase将发布任何必需的1099-MISC，包括与这些资产相关的应税活动，这与一般税务指南一致。

此前消息，质押平台Lido表示，预计将等待5月中旬在完成链上代码审计后启动质押的ETH取款，以确保用户安全。[2023/3/16 13:07:13]

整个DeFi应用系统中，最核心也最复杂的当属智能合约，且智能合约还是需要开源的，其安全性也至关重要，所以，智能合约的设计也自然是非常关键的一环。虽然，具体的设计因具体产品而异，但依然有一些通用的设计原则，有助于我们设计出相对优雅的智能合约产品。所谓的相对优雅，在我看来，最主要的就是满足几个特性：安全性、功能性、扩展性。因为智能合约需要全部开源，所以安全性肯定是排在第一位的，避免遗留各种安全漏洞，尤其要防止闪电贷攻击、重入攻击、权限漏洞等。正式上线主网之前，应该充分进行内部的安全审计和外部审计机构的安全审计，以及充分地测试，包括内部测试和对外的开放测试，甚至公开挂出悬赏，让更多专业人士一起来寻找隐藏的漏洞。满足功能性是一个基本需求，比如，一个借贷产品，能存取借还就是必须满足的基本需求；一个衍生品DEX，能放大杠杠交易也是必须满足的基本需求。但要满足到何种程度，就可能受其它约束条件限制了。比如，衍生品DEX为了防止闪电贷攻击，可能会禁止同个账户在同个区块内既开仓又平仓。扩展性也是非常重要的一个特性，毕竟，一个应用系统并不是只发布一个版本就足够了，总需要持续迭代添加新功能。比如，衍生品DEX，第一版可能只实现市价交易功能，第二版需要增加限价交易功能，第三版再增加止盈止损功能。这几个特性也不是全正相关的，比如，进一步提高安全性，就可能会减低功能性和扩展性，因此，要追求的并不是三种特性全都越高越好，而是要根据情况有所取舍，达到一种平衡状态即可。而要达成目标，所需要遵循的设计原则和背后本质的设计思想，其实还是架构师们所熟知的那些，比如，单一职责原则、开闭原则、依赖倒置原则、接口隔离原则等，以及关注点分离、低耦合高内聚、适度设计等架构思想。Uniswap就是一个很好的典范，就以v2为例，所有智能合约根据模块化拆分为了几个小项目：v2-core、v2-periphery、solidity-lib、liquidity-staker。不同模块之间只依赖于接口，而且只是上层模块依赖于下层模块的接口，下层则不依赖上层，这也符合分层架构思想。而且，整个协议，基本是全自动化的，交易对可以自由创建，手续费率是硬编码的，也几乎没有任何需要运营配置管理的参数，所以，治理成本也非常低。综上所述，Uniswap就变得简单化了，简单就是美，因为简单，测试容易，不容易出BUG，扩展性也好，这就是优雅的设计。做架构设计，最核心的就是要将复杂问题简单化，这应用到开源的智能合约中，显得更加重要。设计实践

以太坊官网：合并不会降低gas费用，质押提款将在上海升级后启用:8月17日消息，以太坊基金会推出的以太坊官网ethereum.org在以太坊升级指南中阐明关于合并的误解，内容包括：1.“运行一个节点需要32枚ETH”的说法是错误的，任何人都可以自由地同步自己的以太坊的自验证副本(即运行一个节点)，不需要使用ETH，无论合并前后。2.合并是共识机制的改变，不是网络容量的扩大，也不会降低gas费用。3.“合并后交易会明显加快”的说法是错误的，尽管存在一些细微的变化，但L1的交易速度将基本保持不变。4.合并后并不会立刻启用质押提款，之后的上海升级将启用质押提款。5.上海升级后，费用奖励将记入验证者控制的主网账户并立即可用。6.启用提款后，出于安全原因，验证者/质押者退出的速率会受到限制。7.更多最新的估计预测，合并后质押APR接近50%，而不是200%。 8.合并升级旨在以零停机的状态过渡到权益证明。[2022/8/17 12:31:25]

下面以我目前负责的DeFi应用为例，聊聊我的一些实践总结。先简单介绍下背景，小部分朋友知道我最近加入了新团队，在负责一个DeFi产品，确切地说，是一个衍生品DEX。交易模式主要采用AMM模式，但不是Uniswap那样提供双币流动性的AMM，而是提供单币流动性的AMM，我们称为ElasticAMM。具体业务就不展开了，以后再另外细聊，这次我主要还是讲讲架构设计方面的考量。整个应用系统的整体架构和上面所说的大致相同，所以我不打算再赘述整体架构，而主要想聊聊智能合约方面的设计。智能合约层面，其实还分为了主协议和**外围协议。**而我主要想聊的是主协议的设计，下图就是主协议的架构：

Alonzo升级后Cardano智能合约部署数量已超2500个:金色财经报道，据最新数据显示，自从Alonzo完成升级后，Cardano智能合约部署数量已超2500个，本文撰写时为2,554个。[2021/9/18 23:33:55]

绿色的只表示参与到系统中的几种角色，其它颜色的则都是智能合约里的子模块了。首先，我采用了分层架构思想，将系统进行了层次划分，上层依赖于下层，但下层却不能依赖上层。其次，模块之间只依赖于接口，而不依赖于具体实现。这样，模块之间才能实现低耦合。作为Trader和LP的用户，都统一跟Router交互，Router在其中就相当于起到了路由网关的作用。而且，因为底层对它没有依赖，所以就很容易升级替换。每个交易对分别有一个Amm合约和一个Margin合约，且Amm和Margin是相互绑定的。因此，自然而然地，就想到了用工厂模式来创建不同的交易对。原本的设计中，其实只有一个工厂合约，但在具体实现中，最终发现工厂合约超过了**智能合约最大字节数，**于是就将工厂合约拆分成了三个。Amm的职责是负责底层的兑换交易，而Margin的职责则是管理用户的仓位。LiquidityERC20是流动性代币合约，由Amm继承。Vault管理着主协议中的实际资产，由Margin继承。该模块是整个协议的核心，只实现底层基本的功能，比如加减保证金、开平仓、添加和移除流动性等。扩展性的功能则可由上层模块实现，比如由Router实现ETH和WETH的兑换支持，再比如后续再添加上层合约支持限价单、止盈止损等。Config合约则管理了所有可配置的参数，PriceOracle即封装了一些读取价格的接口。一旦理解了这个架构，就会发现其实很简单也很清晰。当然，做架构设计难的地方就在于，并非总能想到这么简单的方案。总结

声音 | Coin Metrics数据工程师：以太坊伊斯坦布尔升级后，智能合约调用Gas供不应求:Coin Metrics数据工程师Antoine Le Calvez在一系列推文中指出了以太坊伊斯坦布尔升级带来的“负面后果”：“虽然技术上是成功的，但最近的以太坊伊斯坦布尔升级并非没有负面影响。一些EVM操作被重新定价，成本更高，这影响了一些智能合约活动。” 在最新的网络升级中，EIP主要集中在降低成本、为智能合约引入新功能等方面。然而，据Calvez透露，自从升级以来，智能合约的Gas消耗量激增。“一个调用被认为是一个契约函数的本地调用，它不会在区块链上广播或发布任何内容。”Calvez分享了一份图表，并说明道：“在全球范围内，智能合约调用Gas的供不应求情况在升级之后变得更加频繁。失败率是原来的四倍多。”此外，Calvez指出，像Gemini这样的大型交易所也受到了同样的影响。以太坊开发者Tim Beiko也证实了Calvez的发现。[2019/12/10]

DeFi应用系统的整体复杂度其实还远远比不上Web2应用系统的，但因为技术栈几乎完全不同，而且产品思维上也有较大差异，而且DeFi应用还都是开源的，这些都变成了这个行业的门槛。所以，缺乏经验的人现在进入其实并不太容易上手了，就算是Web2的高端人才，进了Web3依然需要些时日进行学习和沉淀。这次我主要分享了下目前DeFi应用的整体架构，以及智能合约层面的架构设计的一些经验总结。虽然和Web2相比，技术栈不同，还需要具备区块链思维，但本质上的架构思想其实还是通用的。

标签：DEFETHWEB以太坊DEFIDOeth钱包地址怎么注册Web3 Inu以太坊最新价格行情昭

中币交易所热门资讯