前沿 | 区块链热点项目技术复盘-05期
【摘要】技术角度复盘:Nostr协议技术、BNB Chain被反对部署Uniswap V3跨链桥、Uniswap 上线 Permit 2 代币授权标准、Flare Network的FIP.01提案、SushiSwap 将推出去中心化永续期货交易所、Sui测试网Wave2 上线
本期我们将会回顾:
Ⅰ. Nostr协议技术架构深度拆解
Ⅱ.A16z反对在BNB Chain上通过Wormhole部署Uniswap V3跨链桥,并支持LayerZero
III.Uniswap 宣布上线 Permit 2 代币授权标准
Ⅳ.Flare Network的FIP.01提案于1.28以93.8%的票数通过
Ⅳ.SushiSwap 将在 Sei Network 上推出去中心化永续期货交易所
Ⅵ. Sui测试网Wave2 上线,将通过两款游戏进行压力测试
Ⅰ. Nostr协议技术架构深度拆解
2月1日,开发者 William Casarin 在社交媒体上发文表示,其开发的 Nostr 协议第三方客户端 Damus 今日已正式上架 App Store。
Nostr简介
Nostr是一个基于加密密钥对的去中心化网络开放协议,可用于创建一个防篡改、抗审查、可扩展的全球社交网络。
其核心价值在于:
- 协议架构简单轻巧 — — 整体架构围绕 Client客户端 和 Relay中继 展开。
- 可扩展性强 — — 架构仅定义了通信主体,相关业务可基于此扩展。
架构梳理
如上图所示,Nostr架构分为3个部分:
- Storage存储:负责社交数据的底层存储和检索。
- Relay中继:负责接收客户端订阅和事件请求、保存客户端发布的历史事件、通知客户端更新的事件。
- Client客户端:负责创建和保管用户身份、发布事件到网络、请求事件或者更新订阅。
需要重点关注的是Client和Relay的关系,示意图如下:
二者关系描述如下:
- 同一个Client能够同时连接不同的Relay,从多个Relay中获取数据。
- Relay之间不通信。
- Client如果需要获取另一个Client发布的数据,二者必须连接到同一个Relay。
下面以Alice发文,Bob关注Alice并接受文章推送为例,分析Nostr的运行流程。流程示意图如下:
1、Alice和Bob首次启动首次Damus客户端时,需要点击【Generate a new key】生成代表身份的ECDSA公私钥对。
2、Alice和Bob的Damus客户端启动后会查询有效的Relay,将其添加到Relay池中,并与之建立连接。
3、因为Alice和Bob连接到同一个Relay,Bob可以看到Alice发送的历史消息,并选择订阅Alice信息。
4、Alice通过Damus客户端发送新动态到Relay,新动态需要使用Alice私钥签名,签名算法为Schnorr签名。
5、Relay收到Alice的新动态后,对数据进行底层存储,并向订阅Alice的Bob推送这条新动态。
6、Bob的Damus客户端对这条新动态进行验签,确认其由Alice发出,向Bob展示将该条动态。
实现分析
Storage存储
Storage的作用是给Relay提供数据存储和检索服务,Relay接收到的每个Nostr事件,都会将事件传递给Storage进行存储。Storage接口定义如下:
Storage并不关注底层具体实现是关系型数据库,key-value数据库还是其他文件系统,只要能提供上述接口功能即可。官方目前给出的Relay实现有:
- nostr-rs-relay:rust实现的Relay,使用SQLite保存数据 — — 关系型数据库Storage并不关注底层具体实现是关系型数据库,key-value数据库还是其他文件系统,只要能提供上述接口功能即可。官方目前给出的Relay实现有:
- Relayer Basic:基于Postgres的Relay — — 关系型数据库
- strfry:由LMDB支持的C++实现的Relay — — KV数据库
大部分Relay都是自带Storage存储,使用关系型数据库居多。
客户端和中继通信
客户端 → 中继
客户端发送给中继的消息分为以下3种类型:
- [“EVENT”, <event JSON as defined above>],用于发布事件。
- [“REQ”, <subscription_id>, <filters JSON>…],用于请求事件和订阅更新。
- [“CLOSE”, <subscription_id>],用于取消订阅。
这里的subscription_id是一个随机字符串,用于指代一次订阅。
filters是一个JSON对象,包含与订阅相关的配置信息,属性如下:
中继在收到客户端的REQ消息后,会查询Storage模块,并返回与过滤器匹配的事件。随后中继会存储过滤器,并在之后收到与之匹配的事件时通知该客户端,直到客户端的websocket连接关闭。
如果REQ消息的subscription_id已存在于中继中,则会覆盖之前的订阅配置。
中继 → 客户端
中继可以发送以下2种类型的消息给客户端:
- [“EVENT”, <subscription_id>, <event JSON as defined above>],用于发送客户端请求的事件。
- [“NOTICE”, <message>],用于向客户端发送人类可读的错误消息或其他通知内容。
中继通过websocket连接写入数据的机制,通知客户端或者发送客户端请求的事件。
II.A16z反对在BNB Chain上通过Wormhole部署Uniswap V3跨链桥,并支持LayerZero
2月3日,OxPlasma Labs发出了Uniswap V3在BNB Chain部署提案,该提案内容为在BNB Chain上使用Wormhole bridge部署Uniswap V3,提案投票截止日期为2月10日。但A16z投资机构使用了1500w个UNI投了反对票,该风险投资机构和Jump Crypto一样在投票中扮演了重要角色,两家公司在提案投票中相互竞争,但目前Jump Crypto尚未投反对票或者赞成票。A16z是希望使用LayerZero作为桥接工具,而Jump则是投资了Wormhole。
Wormhole 相关人员表示,如果 a16z 违背社区投票结果并试图阻止其生效,Wormhole 方会感到震惊,虽然目前来看 a16z 应该不会如此。
投票地址:https://www.tally.xyz/gov/uniswap/proposal/31
可以在投票网站上看出占据绝对大头比例的投票额为A16z的反对票,LayerZero如何吸引A16z对其如此看好。
LayerZero 是一种全链互操作性协议。该协议开发商,Layzero Labs于2022年3月宣布完成1.35亿美元的A+融资,该轮融资由FTX Ventures、红杉资本、a16z共同领投。
LayerZero简介
LayerZeor是一个底层跨链通信协议,解决了区块链中信息孤岛的问题,打通了各个区块链之间的互操作性,能够实现链之间的数据和资产、信息全面流通。
值得注意的是:LayerZero与普通跨链桥之间的不同,前者与后者都能完成跨链资产的转移。但前者并不仅仅于此,LayerZero给自己的定义在一开始便是“Protocol”而不是“Bridge”,希望自己能够成为比 Layer 1 公链更加底层的基础设施级协议。相比与其他协议和跨链桥产品,LayerZero更加通用,设计更简单,能够完成任意形式的跨链消息传输、任意链平台之间的接入。
LayerZero如何实现全链互操作
为描述验证来自一条不同链交易的有效性问题,LayerZero定义了Valid delivery的概念。Valid delivery可以理解为一个基本的跨链通信原语,通过以下性质保证该原语:
1)网络中发送的每一条消息m都与发送端链上的一笔交易t关联。
2)消息m被成功发送给接受者,当且仅当与消息m关联的交易t是有效的且在发送端链被提交和确认。
LayerZero基本组件:
1)Endpoints,LayerZero面向用户的接口,也是跨链协议的核心。
在LayerZero网络中,每条链都有一个Endpoint,由一系列得到智能合约实现。目的是允许用户使用LayerZero协议,并保证链间消息的Valid Delivery。
Endpoint从功能上被分为4个模块:
- Communicator,用户端与协议端交互的接口,打包跨链请求到LayerZero网络。
- Validator,负责验证区块头和交易。
- Network,区块头的传递。
- Libraries,允许新的链添加到LayeyZero中而不需要修改其他模块,解耦特定链和LayerZero之间的关系,使链端更加容易接入LayerZero网络。
上述四个模块架构跟TCP/IP网络协议栈相似,消息在发送端自上而下完成传递,在接收端自下而上完成验证
2)Oracle,一个第三方服务提供链间区块头读取和中转的服务。理论上,Oracle可以使用任何的第三方的服务,而在实际中一般使用Chainlink服务
3)Relayer,链下服务,和Oracle的功能相似但不负责区块头的获取,而是获取指定交易的证明
为确保Valid Delivery,LayerZero网络中Oracle和Relayer的服务必须相互独立,以避免二者串通。
跨链流程:
1)链A用户执行跨链消息相关的交易T,记为T=t。并向Communicator发送跨链请求,请求中包含以下参数:
- t,当前执行的跨链交易的标识符
- dst,链B上智能合约的全局标识符
- payload,跨链消息中可以传输的任何数据
- relayer_args,描述当前跨链消息需要使用哪一个Relayer,和Relayer所需要的参数
2)Communicator根据用户跨链请求,构造一个包含dst和payload的包,记为Packet(dst, payload)。再将Packet、t、relayer_args发送给Validator
3)Validator发送t和dst到Network,通知Network需要将链A的当前区块头发送到链B。
4)Validator同时发送Packet(dst, payload)、t、relayer_args给Relayer,通知Relayer需要将交易t的证明提取并发送到链B上。
5)Network发送t、dst到Oracle,通知Oracle提取交易t的区块头并中转给链B。
6)Oracle从链A读取区块头,记为blk_hdr。
7)Relayer从链A读取交易t的证明,记为proot(t),并在链下存储。
8)Oracle确认区块头blk_hdr被链A确认后,发送blk_hdr到链B的Network。确认的具体步骤将取决于各自链上对区块的处理。
9)链B的Network发送步骤7)中的区块哈希,记为blk_hdr_hash给Validator。
10)链B的Validator通过blk_hdr_hash向Relayer请求跨链消息包。
11)Relayer在收到blk_hdr_hash后,发送一批与当前区块头相匹配的Packet、t、proof(t)回Validator。同一条链上同时可能会有很多用户在使用同一个EndPoints,同一个区块内可能包含了多个Packet等。
12)链B的Validator使用最近收到的交易证明proof(t)和Network存储的区块头blk_hdr对交易t进行验证(交易t是否在链A被提交和确认)。若区块头和交易不匹配,Packet将会被丢弃;若匹配,Packet将会被发送给Communicator。
13)链B的Communicator发送Packet到用户
注:Endpoint合约各部分通知链外都以触发事件的方式完成
如何实现trustless valid delivery
Trustlessness:在跨链场景中,去信任的含义是不需要引入中间第三方机构参与完成跨链的流程,这是一个较为苛刻的条件。而LayerZero将问题转化为一个更宽松的条件,仅仅需要Oracle和Relayer之间独立,相互独立而不是信任一个第三方机构,也可以使得LayerZero协议变得更高效和轻量级。
Valid delivery:LayerZero协议的步骤12)中,验证过程是成功的当且仅当交易区块头blk_hdr和proof(t)相互匹配,有两种情况会发生匹配:
- Oracle提供的区块头和Relayer提供的交易证明二者都有效且被确认。
- Oracle提供的区块头和Relayer提供的交易证明都无效,没被确认但依然匹配。
第二种情况当且仅当Oracle和Relayer二者相互串通时才可能发生,否则几乎不可能在不知道交易的情况下产生一个假的区块头。由此,LayerZero的二者独立的假设就能得到满足。最终,一条跨链消息m能够被成功发送到接收端链,Valid delivery就能够得到满足。
Endpoint的轻量级
由于在Layer 1链上运行智能合约的代价不容小觑,为了额让EndPoint更加实际可用,轻量级的EndPoints客户端是必要的。在LayerZero的设计中,将区块头的存储和跨链交易证明的存储委托到链下实体:Oracle和Relayer。即使在以太坊这种Layer 1链中也能实现高性价比。
III.Uniswap 宣布上线 Permit 2 代币授权标准
1月20日,Uniswap 宣布上线 Permit2,Token 授权每 30 天过期一次,并且可以通过无 Gas 签名重新授权。用户在使用 Permit2 重新授权后,之后 Uniswap 升级服务器后也不需要花费 Gas 再次授权 Token。
Permit2简介
Permit2是Uniswap发布的一种新代币授权标准,可以在不同的智能合约中安全地共享和管理代币授权。
现有方案
目前广泛使用的传统代币授权方式由EIP-20定义。以Uniswap用户交互为例,流程示意如下:
1、Alice使用Uniswap应用,需要提前调用ERC20合约的approve()方法,将一定额度的代币授权给Uniswap合约。
2、Alice有换币需求时,调用Uniswap合约的swap()方法,该方法会调用ERC20的transferFrom()方法进行代币划转。最终完成Uniswap换币流程。
这种授权模式具有以下短板:
1、用户每使用一个新的Dapp(如Uniswap等),都需要发送一笔新的授权交易,将一定数量的ERC20授权给新Dapp合约。这带来了混乱的用户体验,大大浪费了gas,使用成本高。
2、为了方便起见,Dapp通常要求用户授权最大限额,使得应用可以无限期地访问钱包的代币余额。虽然Uniswap从未遭受过漏洞攻击,但无限期的代币授权仍为黑客攻击提供了可能。
EIP-2612针对EIP-20的代币授权进行了优化,增加基于签名的授权模式。用户无需提前授权,只需要在与Dapp交互时,在发送的交易中附加一条许可授权的签名字段即可。
虽然EIP-2612更加方便和安全,但在该标准推出之前的ERC20代币并不支持该功能,而且并非所有新代币都采用该功能,适用性不强。
Permit2方案
Permit2结合了EIP-2612的优点,提出了一种适用于所有ERC20,基于签名的代币授权标准。该标准具有以下优点:
1、支持任何ERC20代币合约。
2、解决Dapp无限授权问题。每次给Dapp的授权可以设置有效期,消除用户对资产安全的担忧。
3、基于签名的授权。用户与Dapp的交互无需提前调用单独授权交易,减少用户使用成本。
技术说明
如上图所示,仍旧以Uniswap用户交互为例进行Permit2流程说明。
1、Alice准备进入Defi世界,需要提前调用ERC20合约的approve()方法,将一定额度的代币授权给Permit2合约。注意,无论用户后续使用多少个Dapp,这一步只需要执行一次。
2、Alice有换币需求时,先使用web3钱包生成Permit2的授权请求签名,这一步是单纯的链外操作。
3、Alice调用Uniswap合约的permitAndSwap()方法,方法入参包含链外签名 以及 本次授权的有效期。该方法会进一步调用Permit2合约的permitTransferFrom()方法,将本次授权的额度和有效期记录在Permit2合约中,并继续调用ERC20的transferFrom()方法进行代币划转。最终完成Uniswap换币流程。
上述流程的重点在于Permit2合约中会维护一个用户授权额度账本,记录了用户的每次授权行为,包括授权额度和有效期。从而解决了用户给Dapp的无限授权问题,更安全。
此外,Dapp合约不再直接和ERC20交互,而是统一和Permit2合约打交道。通过在Permit2合约中支持链外签名授权,使得针对所有ERC20合约,都能使用链外签名授权模式,降低用户gas费。
Ⅳ.Flare Network的FIP.01提案于1.28以93.8%的票数通过
Flare Network于1.10上线,并将占总代币量15%,共计42.79亿枚 Flare Token (FLR) 发放给了符合条件的数百万用户。这是加密货币历史上规模最大的一次空投。
对于后续85%代币的分配规则,Flare Foundation 于1.18提出了 FIP.01 提案,目的为扩大 FLR 分布并降低通货膨胀。
1.28该提案以93.8%的票数通过。FLare Foundation表示,此次投票中不存在投票占比超过3.5%的个体,并且即使排除Flare团队成员的119M票,赞成票依旧有93.03%。
Flare Network简介
Flare是基于EVM的layer1区块链。其上建立的 (1 State Connector 和 (2 Flare Time Series Oracle 两个本地互操作协议,使其能够链上直接以去中心化的方式访问跨链数据和链外时序数据。
- Flare Time Serials Oracle (FTSO 时间序列预言机): 通过一组去中心化的预言机来定时更新链外时序数据
- State Connector (状态连接器) : 对跨链数据进行去中心化的共识
接下来主要分析其 FTSO 的流程。也就也是探究Flare是如何设计构建其预言机的。
FTSO分析
FTSO的任务是定期将链外时序数据 (目前主要是价格数据) 更新到链上。本质上也就是一种 data feed 服务。
其中涉及两方角色
- FTSO Provider 也叫做 Data Provider ,需要自行寻找数据源去构建价格数据。 比如: 从多家交易所获取 XPR/FLR 汇率并取平均数作为自己的汇报价格
- Delegator WFLR代币持有者可以通过将代币质押给Data Provider来参与FTSO并获利
上面流程中涉及的具体细节如下
Ⅳ.SushiSwap 将在 Sei Network 上推出去中心化永续期货交易所
SushiSwap 首席执行官 Jared Gray 在迈阿密的一次会议上表示,去中心化交易所 SushiSwap 将在 Sei Network 网络上推出去中心化永续期货交易所。Jared Gray 表示,本周早些时候已经签署了一份合约,SushiSwap 正在与 Sei Network 合作,研究需要为 Sushi 分配哪些开发人员资源。自Sei推出以来,就被DEX领域寄予厚望,我们接下会来大致分析一下Sei的设计理念,以及其如何在现有的Cosmos基础上实施性能优化。
Sei Network简介
Sei 建立在 Cosmos 上,是第一个特定行业的 L1 区块链,专门用于交易,以「给交易所带来不公平的优势」。这种「不公平的优势」是指Dex等Defi项目在其上运行会拥有比其他应用更大的优势。
它是第一个以订单为重点的 L1 区块链,旨在比其他类型的区块链更快、更可靠。主要建立在 5 个关键支柱之上。
- 双涡轮增压共识(提高吞吐量和延迟)。
- 基于市场的并行化
- 突破 Tendermint(到最终结果的时间约为 600ms)
- 本地订单匹配引擎
- 前沿保护
Sei 的目标是成为「去中心化的纳斯达克」,允许智能合约访问共享流动性。下图是Sei和其他公链的性能对比
我们接下来主要会分析其双涡轮增压共识是如何基于Tendermint共识做出优化的。
Twin-Turbo Consensus 双涡轮增压共识
Sei把自己的共识机制叫做 Twin-Turbo Consensus (双涡轮增压共识) ,其本质上是在 Tendermint 的基础上针对 Defi 需求做出的优化版本。其主要涉及到的优化有以下两个方面:
- optimistic block processing 乐观区块处理
- intelligent block propagation 智能区块传播
基于上面两个优化,Sei可以将吞吐量提高约83%左右。
乐观区块处理
智能区块传播
Ⅵ. Sui测试网Wave2 上线,将通过两款游戏进行压力测试
据Sui官推公布,1月26日Sui测试网Wave2 上线,该网络将运行数周。Wave 2 的测试将由验证者节点、全节点、委托人、app开发者、终端用户参与。在Sui这个全球去中心化、多样的测试网,将协作测试Sui的代币经济学,包括:
- Epoch管理,将在Epoch更迭边界上执行质押和取消质押、质押权益分配等操作。
- Gas机制,通过“tallying rule”监控验证者在“参考gas费”下的性能表现。
- 存储基金,每一个被分配了存储空间的Sui交易将针对每个字节进行收费,该收费将存存储基金会。验证者通过质押权益和SUI的存储基金赚取奖励,确保能够对验证者提供的存储获得补偿。
- 权益委托和权益证明机制,任何Sui社区成员都可以参与网络的权益证明的管理,并收到权益奖励
Wave 2中针对上述的测试项将通过Frenemies和Validator Game两款游戏进行压力测试。
Sui是一个高性能的L1,它直接继承了Diem的Move编程语言来编写智能合约,其核心卖点是高吞吐量+低延迟。
为支撑Sui网络的高吞吐量和低延迟,Sui使用Narwhal交易池协议和改进的Dag异步共识对网络进行加速,前者通过在交易池中实现可靠广播来分担共识过程对交易主体内容传输的负担,后者提高共识的活性。
Narwhal简介
Narwhal解决的问题:交易可靠传输的问题,缓解共识压力。
Narwahl的主要思想:完美的交易池应该完成对交易的可靠传输,也是一个高性能区块链系统的主要赋能者。交易的可靠传输也应该从共识协议中分离开来,共识协议只需要完成排序任务,该排序任务中待排序的主体可以是占用空间较小的一个交易引用。这种分离的综合系统能够让共识的吞吐量对系统吞吐量影响降到最小。
参考:https://dl.acm.org/doi/10.1145/3492321.3519594
交易池设计
交易主要生命周期:
交易 — — -> 缓冲区 — — -> 进入交易池 — — -> 打包成交易池区块 — — -> Narwhal协议传播 — — -> 生成交易池区块Cert — — -> 发送到共识层
详细设计流程:
交易池实现
可靠广播实现:
经典的可靠广播范式double-echo,需要完成两次阶段广播过程(echo阶段、vote阶段,可参考PBFT的prepare、commit阶段就是一次double echo阶段),复杂度为O(n²)保证Totality性质,这对于大规模扩展来说是一个瓶颈。
在实现中,Narwhal交易池实现广播的阶段,Narwhal并未采用可靠广播算法double-echo。协议中通过两种机制来进行优化:
1)一次的广播-响应投票生成区块的Cert,用来证明区块已经被2f+1个验证者节点收到。但是仅仅一轮只能保证验证者在局部视角看到系统中存在2f+1节点收到了该区块(并不能证明有2f+1个验证者知道了系统中已经有2f+1个节点收到了区块),可能会导致某个诚实的验证者收到了区块却并未收到Cert。Narwhal协议使用Dag的结构,每个区块必须引用上一个轮次的2f+1个Cert来实现相同的double echo效果,收到区块的验证者就能通过当前区块的Cert看到系统中被Cert引用的区块被安全确认了。
2)拉取策略,轮次r的区块完成可靠广播,需要保证轮次r-1的2f+1个区块存在对应的Cert。因此,验证者一旦收到轮次r的一个区块的Cert,但轮次r-1缺少区块所引用的2f+1个Cert以及区块。验证者对每个区块只需要O(1)个请求,当请求得到响应后所有其他的区块请求都能被丢弃。
验证者节点扩展:
Narwhal交易池特点
- 验证者节点上具备高吞吐量的数据可用引擎,该可用性通过密码学证明来保证
- DAG架构能够快速检索每个区块的交易信息
- 验证者的可扩展架构,网络、磁盘I/O分离到各个验证者的worker中
- 共识完全分离架构,共识层可灵活进行替换
Tusk & Bullshar
Tusk协议是Narwahl论文中的补充共识协议,来源于Dag-Rider,而Bullshark则是Dag-rider的改进版本。共识协议实现的是异步共识,在网络异步时通过random coin产生随机数进而达成共识,保证在异步网络中的活性。可与Narwhal交易池协议单独分离开使用。
从理论上来说,系统的吞吐量主要受限于共识的理论复杂度。从工程实现上说,共识的目的是排序,排序的过程并不关心内容是什么,目的是对特定的“顺序”达成共识。Narwhal通过分离交易的可靠传输过程到交易池中,缓解常规做法中共识协议传输全量的交易内容的压力,使得共识协议每次只需要传输少量交易的引用。分离的设计,好处在于第一无论是异步共识还是半同步共识在运行过程中都不需要关心交易的同步、传输问题;第二,Tusk和Bullshark作为异步共识的作用主要体现在活性上,异步共识没有视图切换的过程,共识中DAG的策略,每个节点都在贡献“区块”(指共识的区块)。不存在由于主节点异常导致的失去活性的局面。因此,从性能的角度来说,异步共识协议的补充对于Sui来说并不是主要优化。
版权须知:引用信息版权属于原媒体及作者。如未经鉴叔J Club同意,其他媒体、网站或个人不得转载本站文章,鉴叔J Club保留追究上述行为法律责任的权利。