Skip to main content

赞助交易

赞助交易是 Sui 区块链上的一种原语，它使得可以在不让用户支付燃气费用的情况下执行交易。本文还讨论了赞助交易中的角色，以及一些常见的用例。然后，它讨论了赞助交易的流程，主要面向那些有兴趣构建 Gas Station 或与之集成的开发者。最后，它谈到了赞助交易的风险考虑。

概述

在 Sui 上，交易需要支付费用才能执行。这笔支付，也称为燃气费，是一系列 0x2::coin::Coin<0x2::sui::Sui> 对象，支付给 Sui 验证者以维护网络的安全。尽管燃气在 Sui 的代币经济学中起着关键作用，但对于新用户在 Sui 上导航时，尤其是对于 Web 2.0 用户而言，有时可能会增加一些挑战。

赞助交易可以减少用户的入门摩擦，因为该功能简化了最终用户的流程。使用赞助交易，你可以在无需用户自行支付的情况下执行交易。相反，你可以作为交易的赞助商，为该交易提供你自己的燃气支付对象。

赞助交易中的角色​

在赞助交易中有三个角色：用户、加油站和赞助商。

  • 用户是想要执行交易的实体。
  • 加油站是通过提供他们拥有的燃气支付来满足用户交易的赞助请求的实体。
  • 赞助商是为加油站运营提供资金的实体。

加油站和赞助商是同一实体的情况并不罕见。例如，一个 Web3 游戏工作室可以运行自己的加油站，在用户获取阶段为用户赞助真正的免费游戏体验。由于对于任何规模的团队来说，维护一个加油站并不总是简单的，该游戏工作室也可以利用第三方加油站来赞助他们想要推广的交易。

本指南的其余部分假设赞助商使用他们自己的加油站。

用例​

以下部分描述了一些赞助交易提供改进用户体验的常见场景。

应用程序特定赞助​

在这种情况下，赞助商有一组特定的应用程序，他们想要赞助。

  • 如果交易由用户初始化，赞助商会检查交易以确保它在经过批准的应用程序集合内，然后同意提供燃气支付。
  • 如果交易由赞助商提出，用户必须检查交易并决定是否要执行它。此类交易的示例可能包括活动奖励声明交易或“试用一下”广告交易。

通配符赞助​

在这种情况下，赞助商对燃气支付可用于的交易类型没有太多限制。

  • 如果赞助商是一个无燃气费钱包，它可能同意赞助其用户提出的任何有效交易。
  • 作为奖励或折扣的形式，赞助商可以向用户提供通配符燃气支付，明确承诺使用该燃气支付执行任何交易。

赞助交易并不受这些用例的限制。基本上，赞助交易是由用户和赞助商共同进行的任何交易。只要各方可以就交易详细信息达成一致，那么提供赞助交易的可能方式就仅仅受到想象力的限制。然而，由于赞助交易涉及至少两个利益相关方，有一些额外的风险需要采取措施来加以减轻。

赞助交易流程​

本节主要面向那些有兴趣构建 Gas Station 或与之集成的开发者。

交易的数据结构类似于以下形式：


pub struct SenderSignedTransaction {
    pub intent_message: IntentMessage<TransactionData>,
    /// A list of signatures signed by all transaction participants.
    /// 1. non participant signature must not be present.
    /// 2. signature order does not matter.
    pub tx_signatures: Vec<GenericSignature>,
}

pub struct TransactionDataV1 {  // <-- A variant of `TransactionData`
    pub kind: TransactionKind,  // <-- This is the actual transaction details
    pub sender: SuiAddress,
    pub gas_data: GasData,
    pub expiration: TransactionExpiration,
}

pub struct GasData {
    pub payment: Vec<ObjectRef>,
    pub owner: SuiAddress,
    pub price: u64,
    pub budget: u64,
}

代码前的一些注意事项：​

  • TransactionDataV1（TransactionData的一种变体）中的 sender 是用户地址。
  • TransactionDataV1 中的 gas_data 是燃气支付。
  • GasData 允许有一个燃气对象的列表，但是它们必须由同一地址拥有，即 GasData 中的 owner（赞助商）。当 owner 等于 sender 时，它是一个常规/非赞助交易。
  • SenderSignedTransaction 中的 tx_signatures 是签名列表。对于赞助交易，该列表需要包含用户和赞助商的签名，顺序不限。这些签名是针对整个 TransactionData 进行的，包括 GasData。

因此，要构建一个正确的赞助交易，你首先必须构建一个 TransactionData 对象。如果你既不是用户也不是赞助商，那么你将交易传递给双方进行签名。如果你是赞助商，你将对交易进行签名，然后将其与签名一起传递给另一方（以 SenderSignedTransaction 的形式）进行签名。在实践中，后者是更常见的情况。

赞助交易有三种流程。

用户提出的交易

(泳道链接)

赞助商提出的交易

(泳道链接)

通配符燃气支付

(泳道链接)

风险考虑​

因为赞助交易涉及至少两个利益相关方，你应该采取措施来减轻风险。

客户端模棱两可风险​

当在某个版本上同时提交共享至少一个拥有对象（如燃气币对象）的多个合法交易到网络时，会发生客户端模棱两可。在 Sui 上，在执行交易之前，该交易中的拥有对象在特定版本的验证者上被锁定。一个诚实的验证者只接受一个交易并拒绝其他交易。根据验证者接收这些交易的顺序，验证者可能接受不同的交易。在至少有 2/3 的验证者接受不同交易的情况下，拥有对象将被锁定，直到时代结束。

实际上，客户端模棱两可是罕见的，主要由于有缺陷的客户端软件引起。毕竟，没有人有动机锁定自己的对象。然而，赞助交易带有交易对手的风险。例如，恶意用户可能通过提交在相同版本中使用燃气站签名交易中的一个拥有对象的另一个交易来使燃气站的燃气币对象产生模棱两可。同样，拜占庭加油站可能对用户拥有的对象执行相同操作。

尽管这个风险可能看起来微不足道，但了解它是有帮助的。你的燃气站应积极监控用户行为，并对任何异常行为进行警告。无论你是利用赞助交易的用户还是与燃气站集成的开发者，都要考虑你的声誉以最小化客户端模棱两可的风险。

用户和赞助商都需要对整个 TransactionData 进行签名，包括 GasData，否则第三方（如恶意的全节点）可能会剪切部分签名数据，导致客户端模棱两可和拥有对象的锁定。

審查风险​

如果选择将双签名交易提交给赞助商或燃气站而不是全节点，则该交易可能会受到赞助商或燃气站的审查。换句话说，赞助商可能选择不将交易提交到网络，或者延迟提交。

你可以通过直接将交易提交到全节点来减轻这个风险。