0.Web2App架构
当我们开发一个现代化toC应用程序的时候,无论是WebApp还是MobileApp还是DesktopApp,他们的基本架构都可以用以下三端来概括:
从左到右分别是:前端:也叫客户端.应用的前端是用户在浏览器内看到的页面,或者移动设备里使用的App.前端掌控了视图和展示.后端:也叫服务器端.应用的后端存在的意义主要就是为前端提供接口和数据,通常应用的主要业务逻辑会在后端中.数据库:数据库顾名思义,专门存储数据的.后端会读取或者修改数据库的内容.为什么软件都需要这三端?为什么前端不直接连数据库呢?中间为什么还要有一个后端?这其实有很多方面的原因:a)工程化
开发者角度:现代化应用的前端没有精力同时处理复杂的数据模型以及视图的状态管理.工程化的角度而言,让每个工程师都全知全能地维护一套臃肿的系统是不好的.除此之外很多的逻辑是不需要前端参与展示的,比如电商平台的库存等.架构角度:每个端都有自己的一套规则和语言去描述数据.前端用人类能理解的思路来构建页面,后端用面向对象的语言来操作数据,数据库使用关系代数语言来访问物理存储.没有办法规定一套万金油的规则来统一三端.同时由于语言各司其职,所以性能侧重点也不同.b)通信
协议角度:观察图中,可以看到连接三端的两个连接方式是不一样的.通常toC的应用程序前端和后端沟通使用HTTP协议,而后端和数据库则有不同的协议,如MySQL就和MongoDB有着不同的协议.我们可以通过一层很薄的后端(GraphQL+Hasura)或者规定新的协议(OData)来达到类似前端直连数据库的效果,也有CouchDB这样为这样的通信而生的协议,但依然没有解决其他的缺点.数据映射角度:前端处理UI,后端处理对象,数据库处理数据.前端与后端的连接使用了UI与对象的映射,后端与数据库的连接需要使用对象关系进行映射.c)安全性
数据角度:因为在目前,我们所使用的应用越来越多是基于Web的应用,所以如果让前端直连数据库,那么在浏览器这个不安全且开放的环境下,很难防住数据泄露和黑客攻击.数据库理论上可以通过各种鉴权等手段控制数据可见度,但是后端存在的另一个巨大意义就是确保在可信的环境中,以设计好的方式运行,并排除已知的安全性问题.d)Web2应用架构给DApp的启示
从以上三个角度,我们分析了为什么Web2应用是三端架构,而这也带给了我们对区块链DApp的一些思考:工程化:对应了区块链中的模块化思想.各个组件各司其职,存储则可以用存储链,用户数据则用传统的公链存储.开发者无需太高的开发心智负担.通信:对应了区块链网络不同的共识机制.这些不同的机制也让区块链的互通变成难题,但也有诸如Cosmos和Polkadot的互通协议,尝试去链接整个网络.但从Web2应用的角度来说,这并不意味着是最佳的解决方案.数据映射则可以对应面向账户或者UTXO的设计模式,两者在性能,隐私,和开发复杂度上各有优劣.安全性:对应了区块链的去中心化与Verify,NotTrust思想.安全性在区块链领域中更为重要,因此需要可验证,甚至完全透明公开的方式来对数据的处理和数据的可见度进行调整,从而实现透明和Permissionless的DeFi,公开且具有所有权的NFT,以及DApp最重要的可组合性.Web3DApp架构
大多数的Web3DApp都遵循了如下的架构：简单应用(纯链上数据且交互并不复杂),例如:Uniswap以及纯链上存储的NFT项目.前端与Web2App没有区别.无后端(链上智能合约作为后端).区块链作为数据库.大多数的Web3DApp都遵循了如下的架构:a)Web3DApp细化组件
更细化地来说,完整的Web3DApp的工作流程涉及到更多的组件:前端:浏览器,钱包,页面.前后端通信:节点Provider,索引协议.概念上的后端:区块链网络上的智能合约.后端数据库通信:节点Provider,存储网络网关.数据库:智能合约状态和去中心化存储网络.
b)Web3DApp如何做到无后端?
区块链网络上的图灵完备的智能合约的存在,让区块链能成为最好的Serverless平台,或者说是可以被视作Trustware的WorldComputer.应用的数据和后端逻辑都可以在智能合约中实现.
和Serverless函数相比,智能合约更加优秀,也造就了比Web2应用更加优秀的架构和模式:付费方式:Serverless函数通常是开发者支付费用,而智能合约大部分交互费用都是由用户来支付,且用户也会心甘情愿地为链上空间而付费.执行环境:Serverless函数有非常灵活的执行环境,而智能合约的执行环境虽然选择很少,但非常轻量级.部署环境:Serverless函数部署在中心化云服务平台,而智能合约部署在去中心化和无需许可的去中心化网络上.除此之外,网络的运营成本也是从中心化平台转嫁到了矿工,经济系统会更加具有自主性.但是,对于一个真正完整的应用来说,只通过智能合约作为后端,是无法实现完整的功能的,因此会需要有Keeper网络或预言机等其他组件.2.Web3Crypto-nativeDApp架构Web3DApp指的是通过智能合约作为后端实现的,简单的去中心化应用.要完成一个复杂应用,可能或多或少会引入中心化的服务,真正要实现一个Crypto-native且trustless的DApp,则需要在架构上加入新的变化.Web2的复杂应用其实也远远不止是我们之前所概括的三端了,需要非常多模块化,中间层以及水平拓展的架构拆分.
a)前端?开源+Self-hosted前端
Web3前端的触发逻辑其实和Web2本身就不太一样.Web3的操作都是用户进行通过和确认的,且以链上地址为核心,而不是Web2中,客户端直接发送到服务器和数据库触发数据更新.
对于Web3前端的发展,我认为有两个大的趋势:框架的选择:前端的两大框架React与Vue中,React占了Web3的主导地位,主要就是因为生态与各种组件的积累,比如web3-react与Center.dev.但是我个人感觉React项目的主导权始终还是在Meta手里的,开源协议的更改也多次引起争议,所以如果有机会使用Vue框架搭配一些依赖尽量少的第三方库来进行前端开发的话,还是比React更加好的.前端的Hosting:前端是DApp被黑(恶意劫持或脚本注入)以及被censor(Uniswap和Flashbots的源码中都有OFAC的黑名单)的重灾区.YearnFinance很早就鼓励用户自己托管DApp的前端;在Arweave这样的永久存储网络上托管前端也能保证每个版本的前端都不会被删除,永久可访问;Trustless.fi也提出了前端Marketplace的概念,让用户在多个社区托管的前端中选择,这也能保证中立性和“前端多样性”;Etherscan等其他区块链浏览器其实也算是中立的前端,用户可以通过它来直接进行交互,或者也有专门的应用给合约生成前端,如okcontract;最近Tornado被censor,也有很多社区(比如codeisspeech和theshake)在自发托管它的前端.
这两个点的发展会让DApp的前端有censorshipresistence,大大地提升DApp整体的安全性和去中心化程度.
b)后端?ZKP+智能合约
App架构的演进过程会是这样的:Web2应用:前端?后端?数据库Web3简单应用:前端?智能合约Web3复杂应用:前端?ZKP?智能合约
智能合约虽然让整个应用变得去中心化,但用一个公开网络上的智能合约去处理应用的逻辑是一把双刃剑.数据与代码公开了,保证了透明可查与可组合性,但也把隐私和安全风险完全暴露,同时链上空间与计算的成本非常高.ZKP会成为Web3时代的RSA,消除应用的通信安全性短板,和去中心化短板,真正实现trusted且trustless的DApp.ZKP的加入作为一个前后端之间的中间层与通信方式,又一次非常好地发挥了它的两大优点:隐私:Web2应用中,隐私一直算是默认选项,但区块链网络的性质让DApp一直拥有着形同虚设的“隐私”,ZKP作为中间层,可以将敏感数据在链下处理,从而解决这一个问题.扩容:链上空间有限,因此很多Web2应用中的复杂算法无法实现,ZKP能在保证计算可信的情况下,将算法在链下执行,链上验证.有无数项目正在朝着这两个方向努力,这里就不列举了.主要需要攻克两个难点:计算可行性:ZKP的计算种类是受限制的,并非所有的计算可以通过ZKP来解决.优化:当操作的复杂度提高时,计算时间和空间会显著提高,这就需要非常多的软硬件优化.同时很多情况下只能在吞吐量上进行显著提升,整体Proving的overhead很难削减.c)数据库?去中心化节点服务
我们之前讲述了DApp如何用区块链来作为后端与数据库.要让DApp连接上区块链网络,就需要节点服务.目前来说,DApp常用的都是中心化的NaaS,比如Alchemy与Infura,未来在我的构想里有三个更好的方向:去中心化NaaS,协议化Infura,但是这个其实没有特别大的必要和可行性,NaaS去中心化的目的主要是为了抗审查而已,不用其他的需求.多中心NaaS,使用多个中心化NaaS作为备选(类似Chainlink+Uniswap的预言机组合).这是一个更加可行且靠谱的方案,能保证抗审查和uptime.自托管NaaS.终极方案,不仅可以保证“数据库”连接的可信与各种数据的隐私和抗审查,也可以增加网络的去中心化程度.搭配上自托管前端,整个DApp就会无比去中心化.
d)Crypto-nativeDApp实例
最近刚被制裁的Tornado.cash(尤其是老板本)是一个非常Crypto-native的DApp,它满足了我们很多的定义:前端使用了NuxtJS的Vue框架,而不是常用的React框架.完全使用前端代码中的ZK电路和智能合约实现,没有任何服务器端代码.代码完全开源,托管在IPFS中.旧版本无私钥或多签控制.我相信未来会有更多应用以Tornado.cash的范式来进行架构的打造,这是目前我心目中最完美的去中心化的Web3应用架构.3.Web3Infra
上述只是简化版的架构,以下是较为具体的一个实际DeFi应用的架构:
其中包含了除了节点服务以外的几个补充的基础设施:Indexer:左侧的TheGraph.链上数据没有办法方便地查询,所以需要indexer对合约相关数据进行组装.Oracle:右下角的Chainlink.链上需要拿到合约或者网络以外的价格等数据,因此需要链上(UniswapTWAP)或者链下预言机(Chainlink)喂价.Keeper:右下角的Keep3rNetwork.智能合约本身没有自动触发执行任务能力,因此需要外部触发器进行协助.这几个基础设施在一个DApp的搭建中至关重要,我们会在未来的文章中详细介绍Oracle与Indexer的问题与革新机会.
为什么只有这几个基础设施被纳入考量中,而诸如NFT创作工具,No-Code合约生成工具,和合约前端生成器没有被考虑到呢?因为我个人认为,一个好的Web3基础设施需要有不断的价值捕获的能力,持续和使用它的应用一起增长,而不是一次付费就结束了,这也是Web2SaaS和Web3Protocol中得出的经验.熊市是一个非常好的搭建和提升基础设施的机会.我相信这些革新的FatInfra会撑起下一轮DApp的创新,并且作为BaseLayer捕获到巨大的价值.在未来的文章中,我们会详细讨论这些基础设施的最佳潜在优化方案.关于ForesightVentures
ForesightVentures押注加密货币未来几十年的创新历程，旗下管理多支基金：VC基金、二级主动管理基金、多策略FOF、特殊目的S基金「ForesightSecondaryFundl」,总资产管理规模超过4亿美元。ForesightVentures坚持“Unique,Independent,Aggressive,Long-term”的理念，通过强大的生态力量为项目提供广泛的支持。其团队来自包括红杉中国，中金公司，谷歌，比特大陆等顶级金融和技术公司的资深人士。Website:https://www.foresightventures.com/Twitter:https://twitter.com/ForesightVenMedium:https://medium.com/@foresightventures-zhSubstack:https://foresightventures.substack.comDiscord:https://discord.com/invite/jYtyfxfBLinktree:https://linktr.ee/foresightventuresRelatedLinks
0:https://learnblockchain.cn/article/4338https://www.zhihu.com/question/4570870980a:https://www.zhihu.com/question/457087098/answer/1864992254https://www.zhihu.com/question/457087098/answer/18636658070b:https://www.zhihu.com/question/457087098/answer/19111731540c:https://www.zhihu.com/question/457087098/answer/1864258142https://www.zhihu.com/question/457087098/answer/19108525801:https://medium.com/iearn/self-hosting-web3-services-299306b706ee1a:https://twitter.com/suhailkakar/status/15558942075705139201b:https://www.informit.com/articles/article.aspx?p=30068282:https://mp.weixin.qq.com/s/1h6yqCWyzYLM8WPGlGdtVA2a:https://twitter.com/ChainLinkGod/status/1562125152506195969https://github.com/Uniswap/web3-reacthttps://center.devhttps://www.codemag.com/article/1701041/Legal-Notes-What’s-the-Deal-with-ReactJS’s-Licensing-Schemehttps://twitter.com/paulmillr/status/1558578060940791809https://github.com/Nemusonaneko/projects-with-restrictions/https://medium.com/iearn/self-hosting-web3-services-299306b706eehttps://twitter.com/samecwilliams/status/1561127191106158592http://Trustless.fihttps://twitter.com/forgivenever/status/1556820240993882112https://okcontract.com/whitelisthttps://twitter.com/lickitungxbt/status/1558477975292715016https://twitter.com/DotTheShake/status/1557703404574707717https://twitter.com/mallowsxyz/status/15606554676131430402b:https://twitter.com/LeopoldSayous/status/15159823666359664662c:https://ethereum.org/en/developers/docs/nodes-and-clients/nodes-as-a-service/2d:https://mp.weixin.qq.com/s/USa7y6IZRjYXa8mWK4t2Lghttps://ipfs.io/ipfs/QmTFnDJbfZLbopwjowmwNE9LFvK599sxhktAArQUvH7Tex3:https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-applicationhttps://mp.weixin.qq.com/s/ifaVkhdgmh41zxDKVE68Kwhttps://www.usv.com/writing/2018/10/the-myth-of-the-infrastructure-phase/https://www.usv.com/writing/2016/08/fat-protocols/
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。