2021年9月8日 20点热度 0条评论 来源: cumifi2519


TL;DR Check this back end and front end solutions for delegated transactions. It is universal for any token which supports the delegation of its functions. Read more below.

TL; DR检查此后端前端解决方案的委派事务。 对于支持其功能委托的任何令牌,它都是通用的。 在下面阅读更多内容。

This mostly technical article provides a universal framework and a working solution for Ethereum tokens and applications that eliminates the need to pay fees in Ether, a problem that is practically killing the user experience of many blockchain applications.

这篇主要是技术文章,为以太坊令牌和应用程序提供了通用框架和可行的解决方案 ,从而消除了在以太坊中支付费用的需要,这一问题实际上扼杀了许多区块链应用程序的用户体验。

Imagine spending dollars and then being asked to also hand over some Hryvnias as a transaction fee. That's how Ethereum tokens work so far.

想象一下花钱,然后被要求还交纳一些 格里夫纳 作为交易费。 到目前为止,这就是以太坊令牌的工作方式。

In other words, for example, to transfer any Ethereum token (like Tether, DAI, BAT, DREAM, etc.), the user has to also spend some Ether (internal Ethereum platform currency). This introduces a big inconvenience that prevents the mass adoption of DApps: users have to purchase multiple currencies instead of just one to interact with the blockchain network.

换句话说,例如,以传送任何复仇令牌(像系绳DAIBATDREAM等),用户必须也花费一些以太 (内部复仇平台货币)。 这带来了极大的不便,阻止了DApp的大规模采用:用户必须购买多种货币,而不仅仅是一种货币才能与区块链网络进行交互。

问题 (The Problem)

Tokens, as we imagine them today are just fuel for applications and services on top of blockchain networks. Organizations create their own tokens (using ICOs, IEOs, etc) and run services/applications that utilize them, introducing their own micro-economy (widely known as a token economy). But almost every token turns out to be quite a complex currency itself. By design of how blockchain networks work, in order to do something with your tokens, you also need another currency — often Ether (for Ethereum) to be able to transfer tokens.

正如我们今天想象的那样,令牌只是区块链网络之上的应用程序和服务的燃料。 组织创建自己的令牌(使用ICO,IEO等),并运行利用它们的服务/应用程序,从而引入自己的微观经济(被广泛称为令牌经济 )。 但事实证明,几乎每个代币本身都是一种非常复杂的货币。 通过设计区块链网络的工作方式,为了对令牌做一些事情,您还需要另一种货币-通常是以太坊(以太坊(Ethereum)),以便能够传输令牌。

To illustrate the problem, let's look into how users come to use different blockchain-powered services and applications like:


  • Trickle - where you create secure, hourly-based contracts with an untrusted party in any token

    细流 -您可以在任何情况下与不受信任的一方创建安全的,基于小时的合同

  • Loom - where you use Loom tokens to create sidechains in Loom Network

    织机 -在您使用织机令牌创建织机网络侧链

  • Cryptokitties.co - where you breed, trade and transfer kitties (ERC721 tokens)


  • Others (there are a lot!)

    其他 (有很多!)

All these applications use tokens, as well as they require you to purchase Ether. The complexity of using crypto tokens as we know them today is one of the biggest reasons why 99% of crypto startups fail (or avoid adopting real crypto, for example, by replacing it with virtual coins).

所有这些应用程序都使用令牌,并且它们要求您购买以太币。 我们今天所知道的使用加密令牌的复杂性是99%的加密初创企业失败的最大原因之一(或者避免采用真正的加密技术,例如,用虚拟硬币代替)。

As you may already know, the harder it is to use the application, the fewer users it will get right from the beginning. This is something known as The User Onboarding Funnel, which is still a big pain for blockchain-powered applications and services:

您可能已经知道,使用该应用程序越难,从一开始就可以使用的用户越少。 这就是所谓的“用户入门程序” ,对于区块链驱动的应用程序和服务仍然是一个巨大的痛苦:

To understand why I put 0.001% of users prior to the service use, let's see what exactly purchasing some Ether means:


  • Creating a crypto wallet


  • Registering on Exchange (and learning all the exchange rules, including country policies!)


  • Passing KYC (though it's getting easier, still, many countries have limited access to exchanges)


  • Purchasing a minimum allowed amount of Ether (usually, it's whopping $50 while you need just nearly $0.05 to perform one or two transactions)

    购买最低允许数量的以太 (通常,它高达50美元,而您只需要近0.05美元即可执行一两次交易)

  • Withdrawing Ether to your wallet


  • Not to mention reading lengthy guides on how to perform all these steps properly


Instead of just:


  • Creating a crypto wallet


Of course, it highly depends on how the application or service is made. But, so far, there was no better simplification of the onboarding flow as just cutting crypto tokens from there, or making them fake, "virtual" currency with deposit and withdrawal function. Unfortunately, the latter approach is now the common one across all startups and companies adopting crypto, for many good reasons. Another reason could be a monetization strategy, but this is another big story worth a dedicated article (Interested? Comment out!).

当然,这在很大程度上取决于应用程序或服务的制作方式。 但是,到目前为止,没有什么比简化注册流程更好的了,仅仅是从那里切断加密代币,或者使它们成为具有存款和取款功能的伪造“虚拟”货币。 不幸的是,出于多种原因,后一种方法现在已成为所有采用加密技术的初创公司和公司中的通用方法。 另一个原因可能是货币化策略,但这是另一个值得撰写专门文章的大故事(感兴趣吗?请注释掉!)。

Getting back to the transaction fees problem, we can state the following, which is hard to argue with.


It is natural for the user to purchase only the cryptocurrency they really need (for instance, tokens: Tether, DAI, BAT, DREAM, etc.), and they would normally expect to pay any transaction fees in this cryptocurrency.

用户自然购买他们真正需要的加密货币(例如代币: Tether DAI BAT DREAM 等),他们通常希望以这种加密货币支付任何交易费用。

So why not just allow them to do so? Because it's quite complex indeed. Let's see why, and how this has just got easier with our open-sourced solution (at least for Ethereum).

那么,为什么不让他们这样做呢? 因为确实很复杂。 让我们看看为什么,以及通过我们的开源解决方案(至少对于以太坊而言)如何变得更加容易。

现有方法 (Existing Approaches)

From the very beginning of blockchain existence, there were a couple of solutions that could simplify the user onboarding flow to the flow depicted below, avoiding the step of purchasing an intermediate currency like Ether. Still, creating a blockchain wallet is not an easy step, but some users who do understand the value of the application/service go through this step quite well.

从区块链存在的一开始,就有两种解决方案可以将用户的入职流程简化为以下所示的流程,从而避免了购买像以太这样的中间货币的步骤。 尽管如此,创建区块链钱包仍然不是一个容易的步骤,但是一些确实了解应用程序/服务价值的用户可以很好地完成这一步骤。

The solution which allows to avoid using intermediate currencies (Ether for Ethereum) is called "delegated transactions", or "meta transactions".


In short, delegated transaction, or "meta transaction" in blockchain is the type of transaction which performs an intended action on one account's behalf, while it is conducted (published) by another account (delegate), who actually pays fees for the transaction.


There are multiple approaches around the internet of the generalized concept of delegated transactions I am presenting in this article. But it seems that none of them are still widely adopted, as these approaches are quite complex by its nature, very specific as for the implementation, as well as some of them are quite complex to standardize. To be more constructive, existing approaches can be divided into 3-4 groups: those which use proxy smart contracts, those which embed delegation into a smart contract itself and, theoretically, there is an opportunity for the blockchain-native implementation (say, Ethereum 2.0).

多种 方法 周围 互联网委托交易,我在这篇文章中提出的广义的概念。 但是,似乎这些方法中的任何一种都没有被广泛采用,因为这些方法从本质上来说非常复杂,对于实现来说非常具体,并且其中一些标准化非常复杂 。 为了更具建设性,现有方法可以分为3-4组:使用代理智能合约的方法,将委托嵌入智能合约本身的方法以及从理论上讲,有机会进行区块链本机实施(例如以太坊) 2.0)。

1.使用代理合同的委托交易方法 (1. Delegated transactions approaches which use proxy-contracts)

Proxy contracts, or, in this context, identity contracts are tiny contracts deployed to replace the user account which wants to avoid paying fees. This smart contract is programmed to act as a wallet, as well as a "caller" (sender) of other smart contract's functions. The key is that it is a delegate account that triggers all the actions, while the true "owner" of this smart contract is another user. The user just generates correct signatures in order to control their funds stored on a smart contract address (= in their wallet).

代理合同,或者在这种情况下,身份合同,是为避免用户付费而部署的微型合同,用以替换用户帐户。 该智能合约被编程为充当钱包,以及其他智能合约功能的“呼叫者”(发送者)。 关键是它是触发所有操作的委托帐户,而此智能合约的真正“所有者”是另一个用户。 用户只需要生成正确的签名即可控制存储在智能合约地址(=在他们的钱包中)中的资金。

Pros of this approach:


  • It works with any tokens and contracts which are already deployed to the network


Cons of this approach:


  • Users don't see tokens in their wallet, because they are physically on an identity smart contract


  • As a result, a need to develop custom UIs and custom tools/wallets


  • Identity smart contract deployment and assignment initial fees, as opposed to no fees at all


  • Requires a comprehensive standard to be widely adopted


2.通过“运营商”模式进行半授权交易( ERC777 ) (2. Semi-delegated transactions via "Operator" pattern (ERC777))

There is a token standard that describes this approach — ERC777. In short, any token holder can authorize any other account to freely manage their tokens. I won't call it delegated transactions but nevertheless, I need to mention that, as here we somewhat delegate control over your tokens to other accounts.

有一个描述此方法的令牌标准-ERC777 。 简而言之,任何令牌持有者都可以授权任何其他帐户自由管理其令牌。 我不会称其为委托交易,不过,我需要提及的是,在这里,我们在某种程度上将对令牌的控制权委托给了其他帐户。

Pros of this approach:


  • Standardized


Cons of this approach:


  • Highly centralized around the "operator" accounts


  • Weak security due to operators have 100% control over your tokens


  • Initial fees for approval transaction


  • Requires additional UIs/tools development

    需要其他UI /工具开发

3.直接嵌入(令牌)智能合约中的委托交易 (3. Delegated transactions embedded directly into a (token) smart contract)

Just the same as it is possible to implement custom fees in a proxy smart contract, paying fees in tokens can be implemented directly in a token smart contract. For example, using the approach I described in my previous article, it is possible to implement a function in a smart contract, which will transfer tokens accepting the user's signature, instead of requiring the user to call this function directly. We have implemented this approach in our DREAM Token, which is used on our dreamteam.gg platform.

就像可以在代理智能合约中实现自定义费用一样,以代币支付的费用也可以直接在代币智能合约中实现。 例如,使用我在上一篇文章中描述的方法,可以在智能合约中实现一个功能,该功能将转移接受用户签名的令牌,而不是要求用户直接调用此功能。 我们已经在Dreamteam.gg平台上使用的DREAM令牌中实现了这种方法。

As you may notice, in contrast to the previous approach there is no identity contract anymore, and there is an optional way to call other smart contracts directly from the token contract.


Pros of this approach:


  • Users see their tokens as usual on their wallet's balance


  • No initial fees for account initialization


  • May not even require a standard (continue reading)


Cons of this approach:


  • If you have a (token) smart contract that is already deployed to the network, you cannot apply this approach to it directly. While you can always deploy a new token and, for example, a "migration" utility, which will allow other users to swap tokens (burn the old token and mint a new one)

    如果您已经有一个(令牌)智能合约已经部署到网络上,则不能直接将此方法应用于它。 虽然您始终可以部署一个新令牌,例如一个“迁移”实用程序,它将允许其他用户交换令牌(刻录旧令牌并铸造一个新令牌)

  • Because a standard for this approach is yet not well-defined, implementation can drastically vary


  • A need to develop custom UI/tools for delegated transactions (continue reading — solved!)

    需要为委托事务开发自定义UI /工具(继续阅读-解决了!)

4.(区块链)平台级别的委托交易 (4. Delegated transactions on the (blockchain) platform level)

This is far the best one of all the described approaches above but also the one which is not implemented anywhere yet (by anywhere I mean the most popular blockchain platforms). There is a hope that its support comes with Ethereum 2.0 release, or at least I've heard from Vitalik that they are in progress with something cool there.

这是上述所有方法中最好的方法之一,也是尚未在任何地方(我指的是最受欢迎的区块链平台) 尚未实现的方法 。 希望它的支持随以太坊2.0版本一起提供,或者至少我从Vitalik那里听说他们正在开发一些很棒的东西。

Theoretically, we can imagine this approach as being able to make an "offline" signature of two transactions at a time: one which does something useful for the signing account which wants to avoid paying fees (for example, transferring tokens) and another one which does something useful for the delegate (for example, paying fee in tokens to the account which executes these two transactions).


But the problem is, regarding Ethereum 2.0, this feature has a chance to land only in 2022 or even later. I also suppose that this feature will still require a dedicated back end (similar to the one which is introduced within this article), as it is hard to imagine how miners will accept fees in tokens. Simply put, if some of them refuse to accept fees in tokens than it makes little sense to do it on a "mining" level at all, not to mention how much would it take to track all token prices and volumes across exchanges, in a decentralized manner.

但是问题在于,就以太坊2.0而言,此功能只有在2022年或更晚才有机会登陆。 我还假设此功能仍将需要专用的后端(类似于本文介绍的后端),因为很难想象矿工将如何接受代币收费。 简而言之,如果其中一些人拒绝接受代币收费,那么在“挖矿”层面上完全没有意义,更不用说跟踪一次交易所中所有代币价格和交易量需要多少钱。分散的方式。

Pros of this approach:


  • No need to change smart contracts that were already deployed


  • No initial fees for account initialization


  • May not even require a custom UI/tools if standardized

    如果标准化,甚至可能不需要自定义UI /工具

Cons of this approach:


  • Most likely, will still require a centralized back end (the "delegate")


  • Not yet implemented on a platform level (as of 2019)


解决方案 (The Solution)

From the four approaches above, except for the platform-level approach which is yet to be implemented and standardized in 2022+, the most appealing one is the third approach, where we embed delegated functions directly to the token smart contract. Thus, we save the standard token paradigm allowing wallets to normally work with the smart contract and have no need to wait until delegated transactions will land natively in one of the top blockchain platforms. We will stick to this approach and make it universal just below.

从上面的四种方法中,除了2022年以后仍将要实施和标准化的平台级方法之外,最吸引人的一种是第三种方法 ,我们将委托功能直接嵌入到令牌智能合约中。 因此,我们保存了标准令牌范式,该范式允许钱包正常使用智能合约,而无需等待委托交易将本机降落在顶级区块链平台之一中。 我们将坚持这种方法,并使其在下面通用

Delegated transactions support programmed right in the token smart contract is awesome. But how to deal with its cons? In fact, the only problem which is tough to deal with (as you cannot modify existing smart contracts), you will need to deploy a new token smart contract if you have already deployed it without delegated functions (for instance, standard ERC20 or ERC721 tokens). The next step, in this case, would be adding a way to migrate tokens from one smart contract to another. For example, you can decide to implement one more function in the new smart contract that will allow token holders to migrate their assets from the old smart contract.

令牌智能合约中已编程的委托交易支持非常棒。 但是如何应对它的弊端呢? 实际上,唯一一个很难处理的问题(因为您无法修改现有的智能合约), 如果您已经部署了没有委托功能的新令牌智能合约 (例如,标准ERC20或ERC721令牌), 则需要部署该新令牌)。 在这种情况下,下一步将是添加一种将令牌从一个智能合约迁移到另一个智能合约的方法。 例如,您可以决定在新的智能合约中实施另一个功能,该功能将允许令牌持有者从旧的智能合约中迁移其资产。

Token migration function implementation can vary, starting from implementing receiveApproval in the new token, if the previous token supports approveAndCall, or ending with utilizing approve + transferFrom framework if you have just a bare minimal ERC20 (the user approves tokens to the new token contract address and then calls a function in the new contract which burns old tokens and mints new ones — but this requires a standard fee for the user for the approval transaction). Actually, there is more: you can decide not to burn old tokens but to "lock" them on a new token smart contract, minting new tokens — this opens an opportunity to implement two-sided token migration, which is awesome — you won't need to list the "new" token on the exchange, while the users will still be able to send the old token to exchanges without fees in Ether! If you are interested, please fill the issue here if you want to know more details on how to do it, because this approach is worth a whole new article.

令牌迁移功能的实现可以有所不同,在新的令牌实施receiveApproval开始,如果先前的令牌支持approveAndCall,或利用结尾批准 + transferFrom框架,如果你只有一个光秃秃的最小ERC20(用户批准小号令牌以新令牌合同地址,然后在新合同中调用一个函数,该函数将燃烧旧令牌并铸造新令牌-但这需要用户支付批准交易的标准费用)。 实际上,还有更多:您可以决定不刻录旧令牌,而是将它们“锁定”在新令牌智能合约上,铸造新令牌-这为实现双向令牌迁移提供了机会,这真是太棒了- 您会赢的。无需在交易所上列出“新”令牌 ,而用户仍然可以在Ether中免费将旧令牌发送到交易所! 如果您有兴趣,请在此处填写问题以了解更多有关操作方法的详细信息,因为这种方法值得一本全新的文章。

In my previous article, I provided an example of the token smart contract which supports delegation of such functions like transfer, transferFrom, approve and approveAndCall. Exactly these "delegated" functions allow users to pay fees in tokens, instead of Ether.

在我的上一篇文章中 ,我提供了令牌智能合约的示例,该合约支持诸如以下功能的委托: transfertransferFromapproveapproveAndCall 。 正是这些“授权”功能允许用户以代币而不是以太币支付费用。

But that wasn't enough to start the mass adoption. In this article, I am providing a complete universal back end solution (Transaction Publisher in the picture above), as well as a configurable widget (check it here), which allows you to replace Ether fees for token fees today.

但这还不足以开始大规模采用。 在本文中,我将提供一个完整的通用后端解决方案 (如上图所示),以及一个可配置的小部件 ( 在此处检查 ),您可以用它代替Ether的代币费用。

Some key points before we dive in:


  • This delegated transactions back end is made to be universal, or standard-free, meaning that you can have any implementation of delegated functions and use any signature standard(s) in your token. From the back end standpoint, you just need to write a manifest file for your token, describing its usage.

    该委派事务后端是通用的或不包含标准的 ,这意味着您可以实现委派函数的任何实现 ,并在令牌中使用任何签名标准 。 从后端的角度来看,您只需要为令牌编写一个清单文件,说明其用法。

  • Currently, converting collected fees in tokens back to Ether is a manual action on exchanges. But it could be a potential improvement for automation in the future (if needed).

    当前,将代币中收取的费用转换回以太币是交易所的手动操作。 但这可能是将来自动化的潜在改进(如果需要)。

通用解决方案背后的概念 (The Concept Behind the Universal Solution)

What does it mean that the token supports delegated transactions? Let's look at it using the ERC20 standard token as an example.

令牌支持委托交易是什么意思? 让我们以ERC20标准令牌为例进行查看。

智能合约 (Smart Contract)

As for the token smart contract, the approach is quite straightforward. In addition to every method like transfer(to, value) which we want to be "delegatable", we add a companion function which, instead of inspecting msg.sender, accepts the signature of a user and does the same what the original function meant to do by validating this signature inside the smart contract. Thus, for example, for transfer(to, value) function we can add transferViaSignature(to, value, ...aditionalParams) function. As you know from public-key cryptography, no one can create a valid signature except private key owner, so that's why this approach is as secure as Ethereum itself.

对于令牌智能合约,该方法非常简单。 除了我们希望“可委托”的每个方法(例如transfer(to,value))之外 ,我们还添加了一个伴随函数,该函数无需检查msg.sender而是接受用户的签名,并且与原始函数的含义相同通过验证智能合约中的签名来完成。 因此,例如,对于transfer(to,value)函数,我们可以添加transferViaSignature(to,value,... aditionalParams)函数。 从公钥加密中可以知道,除了私钥所有者之外,没有人可以创建有效的签名,因此这就是为什么这种方法与以太坊本身一样安全的原因。

And the coolest part is that the delegated function implementation, as well as its signature doesn't matter much, from the delegate back end standpoint. You can even decide to implement one "call by signature" function for all other functions that the smart contract supports. Delegate back end just need to know how to call this function, which is solved by providing an off-chain contract manifest for the delegate back end. For example, the argument additionalParams in transferViaSignature can vary and can include anything from this list, if not more: fee, fee recipient address, expiration timestamp, a signature standard used, a signature itself, nonce number or any other unique delegated transaction ID and so on. Regarding the smart contract design, in order to understand why exactly these arguments, read my previous article.

最酷的部分是,从委托后端的角度来看,委托函数的实现及其签名并不重要。 您甚至可以决定为智能合约支持的所有其他功能实现一个“按签名调用”功能。 委托后端只需要知道如何调用此函数,这可以通过为委托后端提供脱链合同清单来解决。 例如,在transferViaSignature参数additionalParams可以变化,并且可以包括从该列表中任何东西,如果不是更多:费,手续费收件人地址,到期时间标记,用来签名的标准,一个签名本身,随机数号码或任何其他独特的委托事务ID和以此类推。 关于智能合约设计,为了准确理解这些论点,请阅读我以前的文章

We also want to allow "delegates" to earn something in order to cover their Ether spending, as well as to be profitable. Thus, we have to add a fee, but a much more natural fee than Ether: a fee in the token itself. So that, for example, if you need to transfer 100 tokens, you pay 3 more tokens to the delegate depending on its price and network conditions to perform a transfer, and this should be preserved in a smart contract logic.

我们还希望允许“代表”赚钱,以支付其以太坊的支出,并实现盈利。 因此,我们必须增加一个费用,但是比以太坊更自然的费用:令牌本身中的费用。 这样,例如,如果您需要转移100个令牌,则根据委托人的价格和网络条件向委托人再支付3个令牌,以执行转移,这应该保留在智能合约逻辑中。

后端 (Back End)

All right, now we have a token that allows transferring someone else's tokens by using their signature. Now, the crucial part is to automate the process of requesting and publishing such transactions. And here where our open-sourced back end (and a front end) kicks in.

好了,现在我们有了一个令牌,该令牌允许使用他人的签名来转移他人的令牌。 现在,关键的部分是使请求和发布此类事务的过程自动化。 在这里,我们开放源代码的后端 (和前端 )开始发挥作用。

Below is the sequence diagram describing how front end (client) communicates with the back end from the delegated transaction request to its publishing to the network:


  1. (hidden on the diagram) The client requests information from the delegated back end to understand which contracts does it support, as well as which functions can it delegate.


  2. The client requests a particular smart contract's function to be delegated. Most importantly, the back end returns the fees it charges and a data to be signed by the client.

    客户端请求委托特定的智能合约功能。 最重要的是,后端返回其收取的费用和要由客户端签名的数据。

  3. The client signs the data in their wallet. Signing is a free operation, unlike publishing transaction to the network.

    客户在他们的钱包中签名数据。 签名是一项免费操作,与将交易发布到网络不同。

  4. The client sends their signature back, thus confirming their intent to perform this particular delegated transaction. The back end validates this transaction against the current network.

    客户将其签名发回,从而确认其执行此特定委托事务的意图。 后端根据当前网络验证此事务。

  5. Finally, the back end publishes a transaction to the network.


  6. (hidden on the diagram) The client constantly polls the back end for the delegated request status until it receives a mined status. Note: it is important to poll the back end instead of using a transaction hash to understand when the transaction is mined. It is a very common case when the gas price suddenly increases, and, in order for the transaction to be mined quickly, the back end may republish it with a higher gas price. Though it is currently not implemented, it is very likely to be implemented soon.

    (隐藏在图中)客户端一直在轮询后端以获取委托的请求状态,直到接收到已开采状态为止。 注意:重要的是轮询后端,而不是使用事务哈希来了解何时挖掘事务。 当汽油价格突然上涨时,这是一种非常常见的情况,为了快速进行交易,后端可能会以更高的汽油价格重新发布。 尽管目前尚未实施,但很有可能很快实施。

This approach is universal, and only requires the manifest file for the back end to understand how to calculate fees and which signature standard to use on the client side. Here is another visualization of the components of the system and their interaction sequence:

这种方法是通用的,并且只需要后端的清单文件即可了解如何计算费用以及在客户端使用哪种签名标准。 这是系统组件及其交互顺序的另一种可视化形式:

We've provided a comprehensive documentation for this solution. You can check how the back end API is structured, as well as find the token manifest file which describes how to work with a particular token contract. We encourage you to contribute your own tokens there!

我们为该解决方案提供了全面的文档 。 您可以检查后端API的结构 ,以及找到描述如何使用特定令牌合约的令牌清单文件 。 我们鼓励您在那里贡献自己的代币!

And you don't need much setup: it's already there with the universal front end!


前端 (Front End)

Open-sourced front end part of the delegated transactions is the user interface which is set up for every token: just run your delegated transactions back end and you are ready to go!


It is made to be an embeddable widget, which will guide the user through the procedure of sending tokens. You can plug any back end, token or call any token function with it by utilizing additional URL parameters you can specify.

它被做成可嵌入的小部件,它将引导用户完成发送令牌的过程。 您可以利用您可以指定的其他URL参数来插入任何后端,令牌或调用任何令牌函数。

Using this widget, and by implementing something similar to widely used, but not standardized approveAndCall function in your token smart contract, you will be able to call other smart contracts with arbitrary data by paying fees in tokens!


Here is a quick guide for you if you want to play with this UI yourself:


  1. Access the widget via this link.


  2. It will ask you to switch to the Kovan test network.


  3. Get some test Ether using any available Kovan faucet.


  4. Use test Ether to mint some test tokens: call mintTokens function in a token smart contract which will give you 10 test tokens.

    使用测试以太铸造一些测试令牌 :在令牌智能合约中调用mintTokens函数,这将为您提供10个测试令牌。

  5. Now, get back to the widget and try to transfer these tokens!


If you open up the browser's developer tools, you may notice that there are a couple of back ends connected by default — they provide the front end with all required information to make a delegated request according to given widget URL parameters. All backends are requested during the widget load and, if any of them can provide a delegation for a particular contract's function, then the widget requests additional information: fees, supported signatures, etc. If there are multiple back ends which can delegate the same contract function, all of them are requested and the back end which provides the best fee will be used for the transaction.

如果打开浏览器的开发人员工具,您可能会注意到默认情况下有几个后端连接-它们为前端提供所有必需的信息,以根据给定的小部件URL参数进行委托请求。 在窗口小部件加载期间会请求所有后端,如果它们中的任何一个都可以为特定合同的功能提供委托,则窗口小部件会请求其他信息:费用,支持的签名等。如果有多个后端可以委派同一份合同功能,所有这些都将被请求,并且提供最佳费用的后端将用于交易。

Transaction mining time is seemingly fixed, but it can vary because of the network conditions. The back end uses an actual network fee when calculating the token fee, however, it may change before the user decides to execute the transaction. Thus, the "underpriced" transaction is submitted to the network and can be pending for a while. While the back end is currently not programmed to deal with this case, it might be implemented in future — transactions will be republished with higher gas fees in case of the network fee increases. But, we will also need to count this into the token fee.

事务挖掘时间看似固定,但是由于网络条件的不同,可能有所不同。 后端在计算令牌费用时会使用实际的网络费用,但是,在用户决定执行交易之前,它可能会更改。 因此,“低价”交易会提交给网络,并且可能会等待一段时间。 尽管后端当前未编程为处理这种情况,但它可能会在将来实施-如果网络费用增加,交易将以更高的汽油费重新发布。 但是,我们还需要将其计入令牌费用中。

签名标准 (Signature Standards)

The last question which you may be wondering is — which signature standard to use for your token. There are several available: eth_sign (deprecated), eth_personalSign (note that old Trezor and Ledger produce a different signatures because of ambiguity in a standard, so you may want to include both), eth_signTypedData (deprecated), eth_signTypedData_v3 and so on. I would recommend supporting at least two: ageless eth_personalSign and new eth_signTypedData_v3 (as of 2019).

您可能想知道的最后一个问题是-用于令牌的签名标准。 有几种可供选择:eth_sign(不推荐),eth_personalSign(注意,旧Trezor莱杰产生歧义,因为一个不同的签名在一个标准的,所以你可能要包括),eth_signTypedData(不推荐), eth_signTypedData_v3等。 我建议至少支持两个:永恒的eth_personalSign和新的eth_signTypedData_v3 (截至2019年)。

The front end is programmed to always prefer the user-readable standard like eth_signTypedData_v3 to any others eth_personalSign. So if your token supports many signature standards, and you added all of them to the manifest file of your token, it will display eth_signTypedData_v3 prompt first.

前端被编程为始终喜欢诸如eth_signTypedData_v3之类的用户可读标准,而不是其他任何eth_personalSign。 因此,如果令牌支持许多签名标准,并且已将所有签名标准都添加到令牌的清单文件中,它将首先显示eth_signTypedData_v3提示。

结论 (Conclusion)

Delegated transactions are great: they solve one of the biggest problems of blockchain application adoption, which eases the mass adoption of crypto overall. I will put a couple of thesis in a Q&A format here for you to answer the last questions that you may still have after reading this article:

委托交易很棒:它们解决了区块链应用采用的最大问题之一,从而简化了整体加密货币的大规模采用。 我将在此处以问答形式发表几篇论文,供您回答阅读本文后可能仍然遇到的最后一个问题:

  • Our open-source solution is free to use and production-ready, feel free to apply it to your applications or tokens!


  • The described approach does not compromise security nor centralization. Think this way: the centralized back end is only a helper for someone who wants to transfer tokens without fee in Ether. If the back end is hacked, or it is just unavailable, there's no problem to interact with the network just as it was before, by paying fees in Ether. As well as the back end cannot harm or trick the user to steal their tokens when a proper signature standard is used (it's up to your token implementation).

    所描述的方法不会损害安全性或集中性。 这样想:对于想要在Ether中免费传输令牌的人来说,集中式后端只是一个帮助者。 如果后端被黑客入侵,或者后端不可用,则可以通过在Ether中付费来与网络交互,就像以前一样没有问题。 当使用适当的签名标准时(后端取决于您的令牌实现),后端也不会伤害或欺骗用户窃取其令牌。

  • There is a way to support delegated transactions for existing, already-deployed tokens. However, it requires the additional Ether-consuming step to migrate existing tokens to a new token contract. And, by programming a new token contract properly, as well as designing your application to work with both tokens you can even avoid a need to list a new token on exchanges.

    有一种方法可以支持现有的,已经部署的令牌的委托事务。 但是,这需要额外的以太坊消耗步骤,才能将现有令牌迁移到新的令牌合约。 而且,通过正确地编程新的令牌合约,以及将应用程序设计为可同时使用两个令牌,您甚至可以避免在交易所中列出新的令牌。

  • By using the existing tokens as an example, which is available in delegated transactions back end and front end repositories, you can produce your own manifest for your own token.

    通过使用现有令牌作为示例 (可在委派事务后端前端存储库中使用),您可以为自己的令牌生成自己的清单。

  • Read the instructions on how to set up your own back end for a token, and then add it to the URL of your widget (or commit to the open-source repository).

    阅读有关如何为令牌设置自己的后端的说明 ,然后将其添加到小部件的URL(或提交到开源存储库)。

  • Have a token which already supports delegated transactions? Plug it into our UI with these three quite simple steps: (1) create a manifest for your token and put your token abi file while setting up the delegate back end, (2) run this back end, exposing a public API URL and (3) use URL parameters in a widget to reference your back end or commit it directly to our open-source repository. Read more about it in GitHub's readme file.

    是否有已经支持委托交易的令牌? 通过以下三个非常简单的步骤将其插入我们的用户界面 :(1)为您的令牌创建清单,并在设置代理后端时放入令牌abi文件,(2)运行此后端,公开公共API URL,并( 3)在小部件中使用URL参数来引用您的后端,或将其直接提交到我们的开放源代码存储库。 在GitHub的自述文件中了解有关它的更多信息。

I hope that was a really helpful piece of information for all the searchers of incredible. Feel free to contact me or fill the issue here if I missed something. Have fun, let the token economy be simple!

我希望这对于所有难以置信的搜索者来说都是非常有用的信息。 如果我错过了任何事情,请随时与联系或在此处填写问题。 玩得开心,让代币经济变得简单!

翻译自: https://www.freecodecamp.org/news/universal-ethereum-delegated-transactions-no-more-ethereum-fees/


    原文地址: https://blog.csdn.net/cumifi2519/article/details/108154265