Stacks-wallet-web: 公开方法来签署任意消息

感谢您发布此信息！ 我认为这样的功能至关重要。

感谢您发布此信息！ 我认为这样的功能至关重要。

我同意，我认为团队中的许多人也会同意👍我会在我们讨论这个问题时努力更新这个问题。

@MarvinJanssen 是否指出您希望在短期内构建的用例以帮助权衡优先级？

@markmhx说的是短期的，我需要它的原因只有一个。

我正在创建一个服务器端组件来跟踪用户应用程序存储桶 URL（用于区域文件）。 为了保护此 API，用户应使用 Connect 签署他/她的存储桶 URL。 然后服务器通过 BNS 合约解析用户上报的 BNS 名称，并使用对应的委托人来验证签名。 我基本上需要验证一个特定的消息实际上来自一个在 BNS 上拥有名字的委托人。 如果您有其他解决方案，请告诉我。 我的备用计划是引入简单的 Clarity 合同并让用户通过合同调用提交证明，但这使它成为一种变通方法的变通方法...

我在 Eth 上看到了另外 2 个主要用例：

• 证明您拥有一个地址，该网站将显示只有您可以看到的有关您的地址的分析（这很好）
• 投票（与 uniswap 不同，例如需要支付 gas 费，synthetix 每次投票只需要一个签名，不需要任何费用，这听起来像是治理投票的权利）

@psq是的，从长远来看，我们需要它用于 DeFi 和 DeX，以及进行需要用户签名的服务器端匹配的平台。 （就像以太坊上的 0x 协议和 Wyvern。）

感谢您提供额外的上下文🙏我分配给 Jasper，以便他可以设计。

我看到这是在冰箱里@markmhx这是否意味着它将在以后的冲刺中考虑？ @MarvinJanssen正在等待更新🙂

我已将此问题移回看板积压工作。

请注意，我们不再针对 2 周的 sprint 工作，而是针对从上到下的积压中反映的优先级的增量交付。

我完全同意评估签名类型数据结构的系统，但这是一项更大的工程任务，我认为我们不应该首先承担。 结构化数据的主要好处是无需费用的链上交易，其逻辑与该签名中的数据相关联。 但是，有两点：

• 赞助交易使得任何合约调用都可以免费。 这里唯一的缺点是你不能做批量签名
• ETH 规范与如何在 EVM 中对这种数据格式进行 RLP 编码和使用非常相关。 我们必须做很多工作来确定它如何与 Clarity 一起工作，然后我们可以从中制定规范，然后我们可以将其添加到钱包中

字符串是目前 Stacks 最明显的用例。 它将允许一个非常常见的用例，即向可以证明他们拥有 STX 地址的用户提供链下访问。 例如，如果您拥有 NFT，则提供特定功能的 Web 应用程序。

更具体地说明用例：

• 登录网络应用程序并证明您拥有 STX 地址
  
  
  
  • auth 目前还没有在技术上解决，因为它使用与 pre-2.0 不同的密钥进行签名，但我们可以/应该改变它
  
  
• 为链下分享一条特定消息，证明您拥有 STX 地址
  
  
  
  • 签署一个字符串，这个问题的“简单”版本
  
  
• 免费代币审批
  
  
  
  • 后置条件解决
  
  
• 免费的 DAO 投票
  
  
  
  • 通过赞助交易解决
  
  
• 批量免费的 DAO 投票，或其他复杂的批量链上免费的东西
  
  
  
  • 需要 ERC712 等效
  
  

昨天在与@MarvinJanssen和@GinaAbrams的对话中确定，.BTC 应用程序不会迫切需要任意消息签名，除非两件事情依次发生：

1. 在接下来的几周内，我们无法将 Atlas 修复部署到主网。
2. 他无法使用自定义 Clarity 智能合约以及使用 Stacks Wallet 扩展进行交易签名和广播来实现他需要的 zonefile 报告机制作为解决方法。

任意消息签名路由基本上是上述路由的回退，按列出的顺序更可取。 它将涉及将带有区域文件数据的签名消息发送到中心化服务器，这将节省最终用户签署交易的成本，但也会导致中心化方的不良参与。

@agraebe @diwakergupta我将在下周与 splat 联系，了解 Atlas 部署计划的进展情况，以便我们可以在此处向@MarvinJanssen提供有关时间安排以及它如何影响他的选择的更新。

他很高兴等待一两个星期，看看我们是否可以在主网上获得修复并为他节省任何一种解决方法的工作。

这是非常宝贵的东西，使用来自身份的签名将证明名称和很多东西的所有权，尤其是在链下操作方面，100%