本文标题如何运用元交易来吸引客户 （2），作者：知世，本文有1591个文字，大小约为7KB，预计阅读时间4分钟，请您欣赏。知世金融网众多优秀文章，如果想要浏览更多相关文章，请使用网站导航的搜索进行搜索。本站虽然不乏优秀之作，但仅作为投资者学习参考。

接着我们上周谈论的元交易的话题，概括一下，元交易就是我们为用户赞助Ethereum交易费用的方式。整个元交易流程的一个关键组成部分就是我们的代理relayer，它可以代表我们的用户向代理合约发送事务。如果还不懂什么是元交易，可以在文后链接先查看我们上一篇的介绍。

元交易的运用帮助我们吸引了更多的卖家使用我们的平台，也是我们应用程序一个重大的进步和发展，但是最初设计的代理relayer原型在产品正式发布之前还需要进行一些改进。

首先，我们需要能够进一步扩展元交易，支持更大的交易量。我们预估我们最初的代理relayer在产品正式发布时会被淹没，因为它一次只能处理一个事务。我们的代理原型会先发送一个事务，等待事务被挖掘，然后才能继续处理其它事务。

如何解决

我们需要一个帐户抽象层（如下图所示），允许代理relayer同时处理各种事务。这时轮到Purse钱包出场了，Purse是我们relayer的一个开源组件，它提供了一个抽象层面将事务触发到以太网。这样我们的relayer可以获取一个事务的子集({ to: "Alice's proxy", value: 0, data: 0x1234 })，将其交给钱包，并在挖掘事务时回调，钱包将处理所有其他事务。

// "Look at my simple interface!" - Purse
const result = await purse.sendTx({
to: proxy,
value: 0,
data: '0x01'
},
(receipt) => {
if (!receipt.status) {
console.error('Oh no!')
}
})
console.log('tx hash: ', result.txHash)

由于代理合同只关心交易是由所有者签署的，而不是哪个帐户实际发送交易，所以您可以从任何可用的帐户发送。Purse钱包被设计成能够与任意数量的账户一起工作，你可以把它和1到1000个发送者捆绑在一起。它采用“标准” HD钱包可以从单个BIP39助记词中生成出多个账户 ( HD钱包标准参见ERC 84讨论)。这种灵活性使我们能够根据需要进行扩展。

是不是觉得能够从多个帐户并发发送已经是一个显著的改进了，其实我们还可以更上一层楼！通过跟踪每个账户的当前值，我们可以安全可靠地发送任意数量的交易请求，而不必等待它们被挖掘出来。Nonce 随机数跟踪是一项必不可少的要求，因为当您盲目地触发多个事务时，接收节点可能知道也可能不知道这些触发的事务。即使有pending的参数，如果只是依赖eth_getTransactionCount也是存在风险的，因为您可能不会在每个请求上都与同一个节点交互。Nonce随机数跟踪提供了更高的可靠性，并且减少了对JSON-RPC服务端的依赖。

虽然我们可以一次启动多个事务，但它必须是在我们的JSON-RPC服务端所能容纳的事务池的范围之内，我们不能一次从一个账户发出一百万笔交易。go-Ethereum的以太坊客户端默认每个帐户为16个，Parity 钱包使用较复杂的逻辑来决定何时收集pending的垃圾事务。所以在此基础上，我们根据自己的需求调整了一个预估的限制，方便以后的扩展。

Purse钱包的另一个作用就是可以简化子账户自动存款。子账户需要资金来向以太网发送交易时支付费用（gas fee）。我们不想人工将以太币发送到所有的衍生账户里。这对我们的团队来说将是一个负担，并且可能容易出错。Purse钱包将自动把资金纳入一个主账户，在没有任何人工干预的情况下为其所有衍生的子账户提供资金。具体操作上Purse钱包还要跟踪这些子账户的运行余额，并在必要时为它们提供交易资金。

面临的挑战

我们最大的挑战之一是处理JSON-RPC服务端的稳定性问题。即使是最好的网络供应商偶尔也会遇到一些问题，而这些问题可能会使我们的代理relayer陷入停滞，或者让钱包发生错误。我们需要处理丢失的事务、服务端500 errors、连接超时，甚至钱包中的bug等等。这时首要任务就是建立一个可靠的监控和日志记录，我们可以依靠它们来检测各种问题。我们在PostgresDB记录下事务细节和状态，并用Prometheus的metrics 监控来检测代码。然后，我们在Grafana构建了一组操作面板，同时使用元数据库（Metabase ）构建了一组业务面板，这样我们就可以看到系统的行为，并能够在钱包投入使用时快速检测和诊断边缘案例错误。

另一个挑战就是如何能取得优惠的以太坊费用（gas fee）。为了能够处理以上各种错误以及获得优惠的以太坊费用，我们编写了一套自定义的web3.js provider，@origin/web3-provider 建立在web3-provider-engine上，这可能需要另写一篇文章来阐述。有兴趣的话可以去github 上看我们的源代码。

我们发现，Nonce 随机数跟踪也需要进一步完善，尤其当Kubernetes pod 可以随时被摧毁和重建的时候。Purse钱包跟踪着内存以及Redis中的Nonce随机数，如果全都失败，将最后引用JSON-RPC服务端。

另一方面，我们还需要留意由于临时以太坊费用飙涨或因为事务超时进入垃圾收集而导致的事务丢失。具体来说，我们检查我们的 provider是否知道该笔交易(eth_getTransaction)，如果不知道，我们将重新提交给provider。这种情况不常出现，但似乎在某些网络供应商中会比较集中。

目前状况

经过测试期后，Purse钱包现在是Origin平台的稳定组成部分。截至本文撰写之时，我们的relayer现已处理了9000多项交易，平均每个用户有4项请求，创建了2500多份代理合同、213份列表、消耗了1,069,786,764 费用（gas），并为我们的用户节省了近11 个Ether以太币的网络费用。

项目发展

我们将继续不断强化relayer代理，提高用户体验度。随着Origin平台的不断扩大，我们必须相应的改进Purse钱包规模。现在Purse钱包创建的子账户数量，以及每个账户允许的待处理交易数量都已配置。随着我们的成长，relayer代理的负载也会增加。我们需要建立新的要求，比如账户的自动缩放：当负载变高时，Purse钱包可以自行衍生一个新账户，提供资金，并使用它。我们也可以采用不同的主账户建立多个relayer instances。扩展基础架构的这一部分我们还有很多的方法和主意。如果你想参与改进Origin协议平台，欢迎加入我们，在Discord中向我们的#engineer问好。我们一直在寻找有才华的贡献者来帮助我们完成我们的使命，为每个人创建一个真正开源的点对点商业平台！

本文相关推荐： 高端酸奶概念吸引力下降 低温酸奶回归性价比

以上便是知世金融网给大家分享的关于如何运用元交易来吸引客户 （2）/qkl/27474.html的相关信息了，希望能帮助到大家，更多金融相关信息，敬请关注知世金融网！

网站内容均来自互联网，如侵害您的利益联系客服进行删除！