• 一开始用户是必须创建Unipass账户吗？像Google这样的第三方账户能不能直接一键登陆？

  如果这里的一开始指的是游戏进入的时候，并不是的，UniPass 只是钱包账户而非游戏账户；当然有一种情况是游戏希望用 UniPass 做为统一账户，这个也是可以支持的。

  Google OAuth 的支持在近期就会上线，其他第三方 OAuth 我们也争取在下一个大版本加入

• 合约钱包相比EOA钱包（或者说游戏内置的钱包，比如StepN这种游戏自带钱包）最大的优势是什么？

  只说一点的话，就是提高用户转化率和资产安全。

  1. 把助记词去掉对 Web2 用户来说，不仅仅是操作流程大大简化，还杜绝了因为密钥（助记词）管理不当造成的不可逆损失；即便用户环境遭到严重入侵导致暂时性丢失资产，用户还有机会在发觉后通过社交恢复等手段拿回账户的控制权，相比之下 EOA 钱包的泄露是不可逆的。

  2. Gas 的隐藏对用户来说更是减轻了早期进行出入金的负担，避免了用户在深入游戏之前流失，尤其是当游戏资产在多链都存在的时候，用户无需每个链都专门去购买相应的 gas。

     其他还有角色和权限控制能力，账户逻辑升级能力，链下授权链上成交等灵活和强大的适应性，而这一切都不需要用户更换他在链上的地址。

• Unipass合约钱包如果要跟需要验证 eip-712 签名信息的合约交互，钱包的签名、认证是如何完成的？和传统的EOA钱包相比区别在哪里？

  UniPass Wallet SDK 提供 signTypedData 接口，支持 EIP-712 格式的签名和验证。当外部合约需要在链上进行 EIP-712 签名验证时，可根据 EIP-1271 协议调用 UniPass Wallet 合约进行验签。应用合约需要加入对 EIP-1271 的支持。

  合约钱包与 EOA 钱包的区别

  • EOA 链上验签，是直接在应用合约内实现 k1 验签。
  • 合约钱包链上验签，是应用合约直接调用合约钱包的验签接口进行验签，此接口遵循 EIP-1271 协议。

• 合约钱包相对传统的EOA钱包，应该多了一个deploy，这个额外的时间和费用是如何处理的？

  deploy 是后置的，用户在第一次从合约钱包里向外转账的时候才需要真正 deploy 合约，目前的 gas 消耗约 80k，这部分成本可以由用户自己出（已经有资产了），也可以由场景方补贴（已经是一个有特定资产的用户了），后一种情况对于获得我们的「用户共享计划」权益的合作方来说也是标记自己用户的方法。

• 群里有说gas费在用户端隐藏，这个不太明白，能说一下具体原理和实现方式吗？

  一句话来说原理是 Meta Transaction（元交易）机制。

  合约钱包方案里用户的账户是一个智能合约，它的鉴权机制是内置的，也就是操作和签名是作为合约调用的参数传入内部，再由内部逻辑进行验签。那么可以看出，用户签署的内容（操作和签名）并非完整的 Layer 1 交易，而是它的一部分，这个 Layer 1 交易可以由任何人帮忙提交并支付需要的 gas。用户签署的东西就被称作元交易。

  换句话说，一笔智能合约钱包的调用操作至少包含两方的签名，一个是用户对自己想做的操作给出的签名，这个在 data 字段里，传入合约去校验；另一个是帮忙提交 Layer 1 交易的 relayer 的签名，它就是一笔正常交易需要的那部分。

  至于 relayer 为什么愿意帮忙付，最简单的是用户授权他们从自己账户里扣走稍多一点的其他资产作为 gas，比如 alice 要在 polygon 给 bob 转账 100 usdt，她可以选择接受 0.1 usdt 的额外支出来让 relayer 帮她支付交易提交所需的 matic（比如仅需价值0.05美金的 matic），relayer 有利可图就会自动帮忙转发，这一切都是原子交易，童叟无欺。

• 文档图中有个relayers/proxy，这个具体的作用和权限是什么？目前是Unipass提供的服务器吗？

  作用和权限就是上面提到的代付提交交易所需的 gas，我们提供默认的服务，合作方想自己跑 relayer 我们也非常欢迎，会给完整的代码（后面也会开源）和技术支持。

• EMail OTP是在哪里被验证的？是Unipass服务器上还是在链上合约里？

  OTP 只能是服务器验证的，链上合约验证的都必须是用户主动外发的邮件。

• 关于MasterKey，是client slice和server slice组合后生成的吧？是保存在Unipass服务器上吗？如何保证安全？

  Master key 是由 Client slice 和 Server slice 进行交互式签名后生成的，Master key 本身不存在私钥，只有一个计算出的公钥。这也是 MPC（更确切一点的话是 tss） 方案比 SSS 方案更优的地方，即密钥碎片永远不需要在某处碰面来还原一个主私钥。

  • Client slice 会在 client 端使用用户设置的密码（密码会进行 pbkdf2 处理）进行加密，并生成一个 keystore 文件。当前 keystore 将会保存在 UniPass 云端存储中，后续用户可以将 keystore 存储至 Google Drive、iCloud 等第三方存储或者下载至本地。我们也在研究配合第三方 OAuth 使用 AWS 的服务将密码更换为 HSM 解密密钥的可能性。
  • Server slice 是每个账户独立生成的，并使用 AWS 的 HSM（Hardware Security Modules）进行加密保存，由 UniPass 对用户进行 2FA 后才可以调用。

• Unipass钱包恢复使用Guardian EMail，这个希望能介绍一下大概的原理和流程，为何需要48小时的lock？ 是否有人工干预？如果非本人使用Guardian EMail进行恢复, 如何进行阻止？

  首先邮件恢复不需要人工干预（下个问题的答案里有详细说明），但是可以通过我们的服务让用户恢复流程更方便。

  其次关于 48h 时间锁等设定，我们内部有一个 Role Based Access Control 系统，规定了不同角色 + 权重的 credentials 发起社交恢复的话对应的条件。

  最后当用户进行账户恢复时，会通过邮件 / 短信 / UniPass 应用等多种渠道通知用户。若用户发现是恶意账户恢复时，可以通过登录 UniPass Wallet，立即中断账户恢复流程。

• Unipass钱包是必须依附于Unipass服务器吗？能导出到传统钱包吗？或者说如果Unipass不再提供服务，用户还能正常管理钱包吗？

  不依附服务器。首先因为是智能合约钱包，用户的地址不对应私钥，也就没办法「导出密钥」到比如 MetaMask，但是用户可以把合约的控制权转移给某个 MetaMask 地址，这就类似 gnosis safe 只用 1-1 单签的使用方法。

邮件社交恢复也可以完全脱离 UniPass 进行，我们后续会开放一个开源前端页面，用户通过邮箱等信息可以检索到自己的地址，在页面上填写比如上述的某个 MetaMask 地址作为新的 Master key，一键生成一封邮件内容，然后用邮箱将此邮件发送给另一个自己能收到的邮箱，下载 eml 文件，回到这个前端上传 eml 并用 MetaMask 钱包提交交易，即可完成社交恢复，全程不依赖 UniPass 任何服务。

如果 UniPass 不再提供服务，受影响的是主要 MPC 相关的操作，用户可以通过社交恢复按照上面的方式把 MPC 生成的 Master key 替换成某个自己掌握的 EOA 地址甚至另一个合约地址。