Generalized MetaTransaction Contest #2
Comments
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done This issue now has a funding of 20.0 ETH (2783.64 USD @ $139.18/ETH) attached to it as part of the MetaMask fund.
|
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done Work has been started. These users each claimed they can complete the work by 2 years, 1 month ago. 1) craze3 has started work. Been wanting to code this for one of my dApps already :) With my current team (RAPID) and previous experience on uPort (helped pioneer MetaTX) we will analyze the current options and bring together the best solutions/approaches to create a generalized MetaTransaction standard that best matches the bounty requirements. I will be working to build a contract wallet system that aims to completely remove the need for EOAs (externally owned accounts). Out team (Biconomy) have been working in providing the meta transaction relayer infrastructure and already supports the contract wallet approach and native meta-tx approach. I had created a meta TX standard protocol called Lava Protocol that allows users to offchain-sign a meta transaction such that they can specify the address of an arbitrary execution contract. When the meta tx is submitted to the Ethereum Network by a relay (or anyone), the receiveApproval method of that arbitrary execution contract is called. This allows for the meta TX to execute arbitrary code (specified by contract address) and that I strongly believe that that functionality be part of any official metaTX protocol. I have 3 year experience on this, actually, was me that started it all in jan-2018. I was surprised I was not mentioned at all, or called to be a Judge, so perhaps I should participate hacker? For this contest I will be updating my work at "Gas Token refunds" in "Gnosis Safe", to now use the new EIP-1077 standard, a generalized (future proof) and overall better "meta transaction" gas relay interface for account contracts. I will also add a version of EIP-1077 that uses EIP-712 to support the signTypedData_v4, and this might become the standard if EIP-1344 fits well into EIP-712. I have been working on an ERC for native meta-tx for quite some time now: EIP-1776 (ethereum/EIPs#1776) solves the problems faced by metatx, including proper gas accounting for relayer, gasPrice control for the user. It also ensure that the user tx get executed as intended which many other, even live metatx implementation fails to do. I'd like to take the opportunity with this hackathon to get feedback and ensure the solution provided fit everybody problems. Been working on account based meta-tx for quite a while, I think this idea of generic meta-transaction, which is quite different can be a very good complement. Despite it requiring some effort on the dapp developpement side, it will be faster for end user with just metamask to benefit from the meta-tx paradigm. Still account based meta-tx offer the added security of multisig accounts (depending on the account used) and are compatible with any app ... But lets explore this other point of view. Build a generalized solution to enable metatransactions for all contracts that wish to use the new way. try to complete question before end time I will complete several tasks to complete this ticket. I have some ideas and I will implement it. I think GSN from OpenZeppelin is the best approach to MetaTransactions, but they do not have a GSNRecipient implementation compatible with signTypedData_v4 signatures. I'm going to create one. Reviewing all existing solutions as well as EIP712 requirement and work on proposing a more standardized approach toward enabling metatransactions. I will complete several tasks to complete this ticket. I will complete several tasks to complete this ticket. I am creating a standard that fulfills the requirements of this task. We have focused on designing a single function that can be included in any smart contract to support meta-transactions. We propose 3 relay protection mechanisms & compare them. Leveraging GSN to create a Metamask-friendly meta transaction standard Leveraging GSN to create a MetaMask-friendly generalized meta transaction standard We built a Moloch DAO on Kovan Testnet into a Telegram Chat Bot using MetaTx facilitated by the Abridged SDK, an architecture pioneered by James Young and Stanislaw Glogowski. Eric Chung and Alok Tiwari also assisted heavily in this project. Our team (Biconomy) have been working in providing the meta transaction relayer infrastructure and already supports the contract wallet approach and native meta-tx approach. Plan is to make a standard which can be used by any contract to support native meta tx capability in any function and that too in gas effective way. Standard should support different use cases of meta tx eg rewarding the relayer back in some tokens. And it supporting the Signed Typed Messages so on client side while taking the signature user don't see the scary hex code but a well formatted human readable message. Will try to create few meme as per my ability https://github.com/gombin?tab=projects 0x3dd011AbAe12A8df732ac54c8f67CCF9BD3842aE 0x3dd011AbAe12A8df732ac54c8f67CCF9BD3842aE 0x3dd011AbAe12A8df732ac54c8f67CCF9BD3842aE 0x3dd011AbAe12A8df732ac54c8f67CCF9BD3842aE Learn more on the Gitcoin Issue Details page. |
|
The Gas Station Network has made efforts at a generalized standard, but it is currently oriented at ephemeral accounts, and not the portable, user-held keys that MetaMask makes possible, and so it’s possible their standard could be used or extended for this purpose. |
|
Another former ERC that could serve as the basis of some exploration is here: |
|
Here's a ConsenSys academy class on MetaTransactions!: |
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done Work for 20.0 ETH (3418.99 USD @ $170.95/ETH) has been submitted by:
@danfinlay please take a look at the submitted work:
|
Looking forward it may be desirable in the future to add improved support for contract-based accounts that can be controlled by multiple instances of metamask (e.g., mobile and desktop browser) for example. In that use case the keys are only ephemeral in the sense that the account contract has to be able to deal with a lost device. To be clear, exploring trade-offs of various key management schemes would be strictly outside the scope of GSN and our goal is keep the GSN as simple as possible by only adding the minimum amount of complexity required to support such schemes at the meta-transaction level. |
|
Somehow work submitted doesn't show up on my submission. Here's my work link https://github.com/bcnmy/metatx-standard |
|
|
Due to the number of excellent submissions, our judges have asked for more time. The prize will be announced next week. See this Medium article for more details! |
|
Issue Status: 1. Open 2. Started 3. Submitted 4. Done The funding of 20.0 ETH (3587.94 USD @ $179.4/ETH) (plus a crowdfund of 1001.0 DAI worth 1001.0 USD) attached to this issue has been approved & issued to @wighawag. Thanks to @ferittuncer, @thowar2, @vs77bb, @vs77bb for their crowdfunded contributions to this bounty.
|
|
This hackathon has concluded! You can read a summary by the judges here: |
Prize Bounty
20 Ether
Challenge Description
MetaMask would like to see someone implement a generalized MetaTransaction standard that could be added to any smart contract to allow MetaTransactions from any externally-owned (key-based) account.
We’d like to see a working implementation of a method that could be added to any smart contract that allows MetaMask users (and users of any key-based accounts) to interact with that contract without gas, by signing a message that is submitted by another account that does hold ether to pay gas.
You can find a more complete description of the context of this bounty on our blog.
Submission Requirements
Strong Suggestions
We’d like to see a standard that leverages the signTypedData_v4 method, which is what the Maker permit() method does. You can see some sample JS usage of the permit signature here.
The difference is that instead of only invoking the allowance method, as this essentially does, we’d like a generalized method that could invoke any method on the contract, probably using that method’s 4-byte method identifier, which would allow wallets like MetaMask to render nice confirmation screens for users signing messages using this approach.
At the very least, we would like to see a proposed standard interface for processing these messages, but working code demonstrating these signatures both from MetaMask and being validated in an EVM smart contract would be ideal.
Looser Suggestions
This method may allow some mechanism for repaying the submitter/relayer (to allow paying them back in an asset other than Ether, for example). This may be more than we should strive for in a first spec, but it would definitely make a proposal stand out!
This method may make use of a nonce, but for some use cases, allowing these messages to be submitted in any order may be an advantage, and so another replay-protection measure may be preferable!
If you want to get deeper into the mad science, there is a thread of speculation where a standard like this could evolve here.
Submission Deadline
All bounty submissions must be received no later than 11:59 PM EDT on Jan 23 2020 to be considered.
Resources
An intro to the contest
The metamask.developers Keybase Team for live support
Judging Criteria
Submissions will be judged on the plausibility of this standard reaching widestream adoption. If a submission is strong enough, the MetaMask team is interested in funding a security audit of it, and possibly even implementing improved user interface for contracts using the winning method.
This means stability and obvious safety are more valuable than excessive features (like fee repayment). The judges will be consulting with the authors of various MetaTransaction libraries for their opinions on the submissions.
A working demo is one of the most essential tools for proving the method works, and we’d love to see you use MetaMask and our signTypedData_v4 method in that demo ;)
Winner Announcement Date
The winner will be announced no more than 24 hours after the contest ending time, no later than 11:59 PM EDT on Jan 24 2020.
The text was updated successfully, but these errors were encountered: