ERC-67: 带有元数据、值和字节码的 URI 方案

将交易编码到 URI 中的格式

摘要

本提案（灵感来自 BIP 21）定义了一种将交易编码到 URI 中的格式，包括接收者、以太币数量（可能为零）和可选字节码。

动机

想象一下这些场景：

* 像 ShapeShift 这样的交易所或即时转换器想要创建一个单一的以太坊地址用于支付，这些支付将被转换成其内部系统中的信用额度或将比特币输出到一个地址。
* 商店想要向客户展示一个二维码，这个二维码会弹出一个支付，金额正好是 12.34 以太币，其中包含关于所购产品的元数据。
* 博彩网站想要提供一个链接，用户可以在其网站上点击该链接，它将打开一个默认的以太坊钱包并执行一个具有给定参数的特定合约。
* Mist 中的一个 dapp 想要简单地要求用户通过一次调用来签署一个带有特定 ABI 的交易。

在所有这些场景中，提供者都希望在内部设置一个交易，包括接收者、相关的以太币数量（或没有）和可选字节码，所有这些都不需要最终用户做任何繁琐的操作，而最终用户只需选择一个发送者并授权交易。

目前，这种实现的解决方法很笨拙：ShapeShift 创建了大量的临时地址，并使用内部系统来检查哪个地址对应于哪个元数据，对于想要以以太坊支付的商店来说，没有任何标准方法可以将关于价格的特定元数据放在调用中，并且任何实现合约的应用程序都必须使用不同的解决方案，这取决于它们所针对的客户端。

该提案超越了地址，还包括可选字节码和值。当然，这会使链接更长，但它不应该是用户可见的东西。相反，它应该以视觉代码（QR 或其他方式）、链接或一些其他方式来传递信息。

如果在所有钱包中正确实现，这将使直接从钱包执行合约变得更加简单，因为钱包客户端只需要放入通过读取二维码获得的字节码。

规范

如果我们遵循比特币标准，结果将是：

 ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?data=<bytecode>]

可以添加其他数据，但理想情况下，客户端应该从区块链的其他地方获取它们，因此，与其拥有一个要向用户显示的 label 或 message，不如从身份系统或交易本身的元数据中读取这些信息。

示例 1

点击此链接将打开一个交易，该交易将尝试将 5 个独角兽 发送到地址 deadbeef。然后，用户只需根据每个钱包用户界面进行批准。

 ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&data=0xa9059cbb00000000000000000000000000000000000000000000000000000000deadbeef0000000000000000000000000000000000000000000000000000000000000005

没有字节码

或者，字节码可以由客户端生成，并且请求将是纯文本：

 ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?function=nameOfFunction(param)]

示例 2

这与上面的函数相同，将 5 个独角兽从发送者发送到 deadbeef，但现在使用了一个更易读的函数，客户端将其转换为字节码。

 ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&function=transfer(address 0xdeadbeef, uint 5)

理由

待办事项

安全考虑

待办事项

版权

在 CC0 下放弃版权和相关权利。

Citation

Please cite this document as:

Alex Van de Sande (@alexvansande), "ERC-67: 带有元数据、值和字节码的 URI 方案 [DRAFT]," Ethereum Improvement Proposals, no. 67, February 2016. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-67.