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

Ethereum enthusiasts (ID: ethfans)

This article is Bloxis' response to Metamask's competition to generalize metatransactions on Gitcoin. As we plan to incorporate this functionality into our upcoming products, we have invested a lot of time and effort in this area, and as such, we really want to be able to participate in the discussion in this area. If you have any objections to my views, please point them out and I'd be more than happy to discuss them with you.

introduction

- Source: Gitcoin -

introduction

As long as you are willing to spend money, you can perform any operation (not exceeding the Gas limit) in an Ethereum transaction-on an almost completely decentralized borderless blockchain network. Sounds very cool doesn't it? that's the truth. but! The problem is that it takes Gas to execute a transaction, and Gas is paid with Ethereum, but who has Ethereum for new users? (What? You said there are cyberpunks, coin hoarding parties, and MLM organizations? Come on, those are not normal people)

image description

- Image source: This emoticon package is my own P: ) -

The future of DeFi, blockchain games and dApp ecology depends on the scale of players entering the market. This means that we need to solve the onboarding problem for new players and lower the knowledge threshold for safe operation. The two main problems at the moment are that players need to have a digital wallet and some ether to get started - which is what many people in the industry are working hard to solve.

Before the advent of meta-transactions, pre-funding was required to complete the above services, that is, depositing Ether into the end-user's account first to facilitate the transaction. Lambda Sensui from Uport is a typical application in this regard.

accomplish

If you want to learn more about meta transactions, you can read the following article, the author of which is a benchmark in the community - Austin Griffith.

Ethereum Meta Transactions: Lowering the Barriers to Popularization of Ethereum (Editor's Note: See end of article for Chinese translation)

accomplish

On-chain, implementing meta-transactions requires an encoding standard to encode the transaction data sent by the original sender - so that the target contract can recover their signature and data without being affected by msg.sender (ie, the relayer). However, off-chain, end users must be connected to relayers through an API or communication protocol. And the relayer itself must have some ether and infrastructure to fetch and forward meta transactions.

A solution that is very suitable for the specific scenario, such as the permit() method used in Dai's ERC-20 token contract, which elegantly solves the problem on the chain - this is a kind of problem that needs to be directly submitted by the end user approve method. Additionally, this approach implements EIP-712, the standard for representing and signing message data for on-chain use. Arguably, Dai only needs to support this one meta-transaction, as all other use cases (such as sending Dai and coordinating DeFi operations) can be implemented using this solution.

Contract Wallet

A number of organizations such as Dapper Labs, Gnosis, and Argent are launching contract wallets that aim to balance user experience and security. The contract wallet hosts the user's funds in the smart contract, and the functions of sending transactions and protecting account security in the contract can far exceed the level of the Ethereum protocol itself.

image description

- Source: Dapper Labs -

With this approach, transactions can be sent even without Ether in the account, and there is no need for the industry to accept the same standard - the contract wallet can be like an external owner account (i.e. a normal user address controlled by a standard key pair, EOA) to call other contracts. In addition, it also brings a series of security features, such as Authereum's transaction firewall.

image description

- Source: Authereum -

The troubles brought by the contract wallet

For contract wallets and innovations such as the Ethereum Naming Service (ENS), there is a lot of buzz within the Ethereum community. However, with many users using ENS domains as identities for all their on-chain activity (and using real names for the readable portion of the domains), huge privacy and security concerns begin to emerge.

Ethereum wallet addresses themselves are "pseudo-anonymous" (and thus somewhat private), but many wallet software providers are now encouraging their users to obtain ENS addresses without informing them of the consequences of doing so. In short, the transaction records of the Ethereum account (including its investment portfolio and interaction records with dApps) are public on the chain. After an address registers an ENS domain name, these transaction activities are associated with this ENS domain name. The ENS name registered by the user is likely to be the name that the user has already used in other services or in real life. This is the main reason I'm skeptical about binding ENS to contract wallet addresses (for personal use).

However, I'm all for contract wallets/multisig wallets using ENS for identifying smart contracts to prevent fraud, and for organizations that could benefit from transparent operations 🙌

Through the Hierarchical Deterministic Wallet (HD wallet for short), users can use a single private key to generate many EOA addresses to store different assets; use multiple addresses to operate separately, even if the user knows how to use dApp and DeFi protocols And initiate a large number of transactions, and still maintain a certain degree of anonymity. Using this set of rules, users can even hold only one private key, and then create an EOA address for each dApp and token to be used for interaction. Although contract wallets can also do this, because of the existence of Gas fees, it is very expensive and impractical to create a contract wallet for each dApp/token used by the user. Even if the gas fee is not considered, doing so will cause network congestion.

image description

- Hierarchical deterministic wallets are a privacy solution in their own right, and also apply to Ethereum wallets. Source: Casa-

Assuming that all users in the Ethereum ecosystem have a corresponding contract wallet for each dApp that interacts with them, so that they can use the meta-transaction function and protect their privacy - then it will be more reasonable for smart contracts to adopt a common standard .

Towards Universal Standards

Whatever your stance on contract-based and contract-wallet-based solutions, there is currently no definitive standard — method calls vary from contract to contract, and systems for relaying transactions vary. Gas Station Network has done a lot of basic work, but it is still not flexible enough. The payee contract may not pay the gas fee. So how do users use their assets to pay relayers? How do we get the other party to pay the gas fee for this transaction? These are the kinds of questions we hope to address in the race to generalize metatransactions — really worthwhile proposals confront these questions.

• Based on the idea we put forward, our general counsel Vincent proposed an idea: let dApp developers pre-deposit funds for users to pay gas fees, and users exchange them with legal currency; in order to avoid dApp projects being identified as exchanges, These ethers can only be used inside the dApp. This is the mechanism we hope to support in a future generalized metatransaction standard (this was something we came up with a year ago when we were working on another thing). The Gas Station Network supports this idea with a custom implementation of the acceptRelayedCall() method.

• In addition, allowing relayers to batch process transactions, will it also reduce Gas fees?

• Mechanisms in place to support alternative relayer reimbursement/payment methods

A method suitable for running in smart contracts for asset dApps and DeFi (rather than contract wallet standards)

Mechanisms to support transaction batching within the target contract or the contract used to relay transactions

ethereum/EIP-1613：Gas Station Network

ethereum/EIP-712

Overview of our proposal

As you can see, we strongly support the ideas proposed by the Gas Station Network. The getSender() and getMessageData() methods provided by RelayRecipient implement a unified interface, making meta-transactions of all contracts compatible with each other. However, these approaches in their current form suffer from two shortcomings - inability to protect against phishing and replay attacks. Details:

In order to prevent phishing, EIP-712 proposes an ingenious solution - domain name separator. This object contains the details of the contract (that the user signs the transaction to be forwarded to) — that is, the address, and the name and version of the dApp. This data is included in the signature and presented to the end user in a very friendly way along with all other transaction data. This limits the way users can sign transactions, preventing them from initiating unexpected types of transactions (such as intentionally sending transactions to the wrong contract).

Makerdao/dss：https://github.com/makerdao/

image description

- Metamask interface for signing data using the signTypedData_v4 method. Source: Metamask -

Contracts supporting EIP-712 need to verify that the domain name separator matches the contract itself, and reject the transaction if they do not match. You can see this in the code for the Dai contract listed below. We'd like to integrate EIP-712 into getSender() and getMessageData() so that this check can be performed on every method call - if the signature doesn't match, reject the transaction. You can click on the link below to view the code for this function. (Sorry, the format of the embedded code of the article cannot be displayed properly)

Additionally, in the code above, you can also see that MakerDAO implements replay protection itself with the nonce attribute - without this attribute, authorized parties could drain users' funds by replaying transactions.

A metatransaction is often part of a set of operations that may depend on previous transactions. For example, in the proof-of-concept case we built, users can deposit xDai into the Compound protocol. On mainnet, this means we grant the cDai contract access to user funds, and then call the mint() method to deposit that fund into the lending protocol.

If the user's account is not a contract wallet, a series of operations are required to complete this process: first, the approve()/permit() method must be called through the transaction, and then the mint() method must be called after the transaction is packaged. With the contract wallet, you can batch process these transactions by calling a special contract method.

It would certainly be a major innovation if there were a generalized meta-transaction batching method available to everyone. This will greatly simplify the activities on the chain, just like the various examples mentioned above. Additionally, the method would allow users to sign and forward multiple unrelated transactions at the same time.

However, in some cases, users may wish to send multiple meta transactions to a single contract. For example, when an EOA that only holds one asset wants to pay salaries in batches. A system that batches meta-transactions must be designed with this in mind and ensure that the order in which transactions are sent is preserved.

In addition, batch processing also allows relayers to centrally collect fees through user-signed transactions, that is, adding a transfer transaction to the relayer in a batch of transactions, and the method can also be customized. This could be by transferring ERC-20 tokens to the relayer, or having the user's target contract pay the fee.

Relay aggregators should support transaction batching and complement sendRawTransaction() with a sendRawTransactionSet() method for sending multiple transactions by the same user. The sendRawTransactionSetPlural() method should also be utilized to facilitate relay batching transactions from multiple users to minimize gas costs.

- Source: Tabey -

Summarize

If it can be funded by a transaction in the transaction set, this can be achieved with only a small change to the current workflow of the relay aggregator. The relayer can pass the gasPrice and fee parameters acceptRelayCall() are set to 0. The relayer can continuously extract transactions from the transaction set and process them according to the standard until it is completed.

The real challenge we face is how to create a standard for packaging transactions into transaction sets, and unpacking and executing transactions (while ensuring transaction atomicity). If transaction atomicity cannot be guaranteed, relayers can get away with it by only forwarding paid transactions, while ignoring other transactions in the set. That's the real work! I'm currently clueless on how to do this, but stay tuned for my next post! Hopefully I can turn this into a viable solution for the competition.

Summarize