General Economic Abstractions on Ethereum

Editor's Note: This article is from:Ethereum enthusiasts (ID: ethfans)Editor's Note: This article is from:

Ethereum enthusiasts (ID: ethfans)

For the better part of the last two years at Astro Wallet (recently acquired by Coinbase), we've been working on various forms of economic abstraction. We want to share our findings with more colleagues in the blockchain industry, hoping to provide some guidance for many user experience issues facing dApps today.

definition

While economic abstraction is not a new concept, there have been few viable use cases before. In this article, we discuss how to implement a common set of economic abstractions.

first level title

definition

Given the widespread use of this term, we wish to give a clear definition before the discussion begins.

Let's take a few examples to further clarify what it means:

The user wants to transfer USDC, but suffers from the fact that there is no ETH in the wallet to pay the transaction fee.

The user wants to buy a CryptoKitty through the 0x v3 repeater, which requires the use of ZRX to pay the relay fee, and the seller of the CryptoKitty only accepts DAI, but the user only has USDC in hand.

secondary title

composition

In fact, economic abstraction on most blockchains is divided into two components: fee abstraction and token abstraction. If both can be achieved, we have a complete economic abstraction.

Token abstraction - the ability to atomically use any asset on the blockchain to complete a transaction.

accomplish

first level title

accomplish

In order to implement fee and token abstraction, we need two core blockchain functions: fee delegation and multi-operation transactions. Most blockchains do not natively support these two features (Ethereum is no exception), so additional construction is required to achieve our prerequisites. We will primarily build on the Ethereum platform, but the same applies to most other smart contract platforms.

secondary title

basic building blocks

The key to implementing these core functions on Ethereum is the use of smart contract wallets. Traditional address-based wallets do not have these functions, but we can add additional logic to them through smart contracts to achieve new core functions.

Most of today's smart contract wallets use Gas repeaters to implement fee delegation. The user does not need to directly enter the Ethereum into his smart contract wallet to pay the transaction fee, but can complete the relay of the transaction by signing the message (the relay will package the message into the transaction, and then send the message as the sender) transactions). Since the user's account is actually a smart contract, both approaches work as long as the wallet can verify the contract call.

Multi-operation transaction - that is, multiple atomic function calls are completed within a single transaction.

Unlike fee delegation, multi-operation transactions have not yet been widely used. This feature is indispensable to complete multiple operations within a single atomic transaction. Some people have tried to use Wrapper contracts to solve this problem, and achieved some results, but the hiding of metadata such as msg.sender makes them difficult to be a general solution. Fortunately, integrating this functionality in smart contract wallets is fairly simple, but so far only one smart contract wallet supports it, Dapper.

secondary title

Implement fee abstraction

Using multi-operation transactions, we can construct another layer of message transmission protocol on the standard Gas repeater architecture to realize the abstraction of handling fees. Below we use a simple case to illustrate how the protocol can extend the wallet to provide additional functionality.

Step 0: The client wallet wants to send a transaction consisting of a set of operations [1…n].

Step 1: The client wallet informs the Gas relayer which transaction it wants to send and which asset it wants to pay the transaction fee with.

Step 2: The relayer replies with a signed quote message specifying a price for the transaction requested by the relaying user, calculated in terms of the assets specified by the user (used to pay the fee).

Step 4: The transaction finally composed of operations [1…n+1] is sent back to the relayer along with the signed offer message.

Step 5: The relayer verifies the transaction and quote message, and then sends the transaction to the blockchain.

With this feature, client wallets can ask many Gas relayers to provide quotations separately, and finally choose the relayer with the lowest quotation to send the transaction.

secondary title

Once there is the blessing of multi-operation transactions, it is easy to realize token abstraction. The key difficulty lies in transaction analysis. Client wallets need to be able to analyze underlying transactions in order to know which assets will be spent (or received) and how much will be spent (or received) when performing the actions in the transaction.

We built a modified Ethereum node in Astro to run the above analysis, but since this is largely an engineering challenge rather than an algorithmic one, we leave it as an exercise for the reader.

Once we can determine the assets required and generated in this set of operations, the wallet can easily connect to each DEX to complete the exchange of this set of assets for users. Aggregators such as 0x API are ideal for aggregating the exchanges these users need, or wallets can choose to use simpler but less slippage efficient solutions such as Uniswap. With this set of swap transactions, the wallet can add the exchange operations of the required and obtained assets before and after the user's operation to complete the final transaction.

first level title

Let's fit together!

Now we have realized the abstraction of fees and tokens at the same time, and the combination of the two can realize economic abstraction!