解析会话密钥：Web3版“免密支付”

钱包授权一直是与 DApp 交互的必要流程，但我们在 DeFi、GameFi 中交互的过程中往往会需要在短时间内多次授权，这非常影响用户体验。 Odaily星球日报最近关注的“会话密钥”（Session Keys）技术， 则允许用户对 DApp 仅授权一次就可以在后台默认签署后续交易并支付 gas，实现类似 Web2 免密支付的功能，从而极大地优化用户体验。

会话密钥是如何工作的？

简单来讲， 会话密钥允许用户在与应用交互之前签署一个 token 以提前批准特定的交易，用户可以自定义频率、gas 最高价、每日限额等参数，当用户签署该 token 再与该应用交互的时候，符合之前参数条件的交易就会在后台被自动执行并支付 gas。

但目前会话密钥并不支持所有的钱包，仅仅支持智能合约钱包，它是基于账户抽象的智能合约钱包的子技术。在进一步介绍会话密钥之前需要先介绍一下 以太坊 上的地址、智能合约账户以及账户抽象的发展情况。

关于地址、智能合约账户、账户抽象

目前以太坊上有两种地址：第一种地址就是通常的钱包地址，也称为外部拥有账户（EOA），具有发送与接收代币、支付 gas、执行交易的功能；一种是智能合约地址，各种部署在以太坊上的 dapp 就是以智能合约的方式运行着。

但是这样的地址设计存在很多问题，许多以太坊开发者认为 EOA  地址的设计阻碍了钱包在多签、隐私保护、gas 优化等方面的发展，并且不利于交易的可编程。因此， V神 、Ansgar Dietrichs、Matt Garnett,、Will Villanueva、Sam Wilson 等人提出并完成了以太坊改进提案 EIP-2938 ，并提出了“用户抽象”的概念。

关于账户抽象，简单来讲就是让智能合约地址可以支付 gas 和执行交易，使之具备钱包地址的所有功能。 基于账户抽象的智能合约地址就是智能合约账户，也由此衍生出了智能合约钱包概念（就好比个人的 Metamask 账户和 Metamask 这个钱包软件）。

而会话密钥是基于账户抽象的智能合约钱包的子技术。

前面已经提到，支持会话密钥的钱包支持用户自定义免密支付的参数，但是这些参数的可选项完全取决于钱包开发商。且会话密钥并不支持所有 DApp ，所支持的 DApp 取决于你所使用的智能合约钱包是否允许调用该 Dapp 的合约，这个过程是中心化的。

总结一下， 会话密钥就是 Web3 的免密支付，允许用户对 DApp 仅授权一次就可以在后台默认签署后续交易并支付 gas 。那么现在有哪些用例呢？

用例

StarkNet 上的链游孵化器 MatchBoxDAO 在《 How to Make On-Chain Gaming Competitive: ‘Session Keys’ [Part 1 ]》中提出了会话密钥的一些用例，它们包括：

• 用户友好的且不间断的游戏；

• 设置多个 DeFi 仓位的能力；

• 填写包含许多输入项的表单时进行确认；

• 非托管和自我指导的 IRA；

• 重新管理钱包/库存中的资产……

从工作原理来看，由于会话密钥可以允许用户提前批准一些交易，从而减少用户批准次数，因此所有有高频授权、交互的应用场景都会用得到它。我们可以据此推理，会话密钥可以解决 Web3 社交媒体这类需要高频链上交互影响用户体验的问题。

以 Lenster 为例，基于社交协议 Lens Protocol 开发的链上社交媒体 Lenster 上的所有交互都需要授权并支付 Matic ，每次评论和转发都需要钱包授权，非常影响用户体验。

如果 Lenster 实现了会话密钥，这将让用户省去繁琐的多次授权，有更加顺滑的产品体验，极大缩小与 Twitter 这些 Web2 应用巨大的产品差距，我们也许可以期待在未来的某天可以用上一些产品体验媲美 Web2 产品，但架构却是 Web3 的去中心社交媒体。

参考链接

1. Argent X 关于会话密钥的推文

2. 《How to Make On-Chain Gaming Competitive: ‘Session Keys’ [Part 1]》 —— MatchBoxDAO

3. 《 From Sign-In with Ethereum to Session Keys 》—— Wayne Chang

4. 《 An overview of Account Abstraction in Ethereum blockchai n》—— Yash Kamal Chaturvedi

5. EIP-86：Abstraction of transaction origin and signature

6. EIP-2938：Account Abstraction

7. EIP-4337：Account Abstraction via Entry Point Contract specification