Layer 2 transaction abstraction

[barryWhiteHat]

A major problem in the current system is who pays for the gas for the withdrawal. While the prefect solution to this is to allow the smart contract to pay for gas. This is not possible at the moment. There for we provide layer two transaction abstraction where a depositor can define a fee that gets paid to whoever pays the gas of a transaction. Future work should formalize a communication channel where people can advertise these transactions so that others can pay the gas for them and recive a reward.

We need to find a communication channel to broadcast proofs and some software to monitor this channel and broadcast a proof if it is profitable.

[lsaether]

Sounds similar to the Ethereum Alarm Clock's second layer market of executioners (aka TimeNodes). For that, the new scheduled transaction addresses are sent as an event, so that the TimeNodes only have to watch a single contract to know about new ones and can query those contracts to check the bounty and determine the profitability. Not sure if a scheme like that could work by sending the proof as an event log.

What kind of security do we need around this proof? Can it be public or must it remain private (ie between only the depositor and the account which will withdraw on their behalf)?

[barryWhiteHat]

But in order to send an event you need some gas. So this will not work here.

What kind of security do we need around this proof? Can it be public or must it remain private (ie between only the depositor and the account which will withdraw on their behalf)?

the proof can be made public. But if there are multiple "broadcaster" accounts only the first one to get mined will get a reward. The rest will end up reverting and costing them gas.

[HarryR]

Why not use Whisper?

If the contract is modified so the destination address is specified by the coin owner and is unchangeable by whoever submits the transaction, and specifies the amount of ETH that the msg.sender is given upon submission of the transaction, then you can broadcast your withdraws to a Whisper topic with slowly increasing 'incentive fees' until somebody decides it's worth submitting the transaction for you.

To avoid the wasted gas problem with multiple submitters the protocol could be interactive, you broadcast enough information for the proof to be verified, then the willing and available nodes reply back to you on a different topic - you then choose one and submit a missing piece of information which is required for them to submit the on-chain transaction.

There would need to be some kind of protection mechanism to prevent people from deliberately wasting the transaction submitters gas.

There's also projects like https://github.com/iurimatias/TransactionRelay

I think it should be able to make a simple PoC of the transaction submitter and an incentive layer. Then add Whisper support. Then figure out the 'deliberately wasting peoples gas' problem and add it on later.

[barryWhiteHat]

I was considering whisper as well. Do you know about its anonymity properties? Is it possible to leak info about who is sending a withdraw request? Is it just based upon proof of work ? Or do you need to make an account to deposit?

The wasted gas is definitely a problem. I was thinking of doing a two step process but I wanted to withdrawer to be able to drop offline after sending a single whisper message.

Oh nice Transaction Relay looks really interesting for this.

[davidp94]

Here is a current implementation of a transaction relay https://github.com/iurimatias/TransactionRelay Here are the properties of whisper https://ethereum.stackexchange.com/a/47170

…

On Tue 10 Jul 2018 at 02:44 barryWhiteHat ***@***.***> wrote: I was considering whisper as well. Do you know about its anonymity properties? Is it possible to leak info about who is sending a withdraw request? Is it just based upon proof of work ? Or do you need to make an account to deposit? The wasted gas is definitely a problem. I was thinking of doing a two step process but I wanted to withdrawer to be able to drop offline after sending a single whisper message. Oh nice Transaction Relay looks really interesting for this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYtbNaU-966CNmk-UrIH7CjvEZ1a2aXLks5uFAb4gaJpZM4Uyg0l> .

[HarryR]

But, if Whisper provides the anonymity layer, why would zkSNARKs be needed?

[davidp94]

Whisper is just an anonymous communication layer.

It would be used to give some note to be redeemed via the smart contract.

If the owner of the note would like to withdraw the money and give let says 2% of the 1ETH to the transaction sender -- he will send the note and the recipient of it to all the people listening on Whisper -- anyone of them would be able to run the transaction with the zkProof on Miximus.

It is a win-win game, we have:

• A random person making 2% of 1 ETH to pay gas on fee
• The sender of the input/output not being related to the actual input/output
  Hence it does increase anonymity/privacy.

[barryWhiteHat]

Does an EIP exist for this? It seems like a general problem.

[kosecki123]

If the owner of the note would like to withdraw the money and give let says 2% of the 1ETH to the transaction sender -- he will send the note and the recipient of it to all the people listening on Whisper -- anyone of them would be able to run the transaction with the zkProof on Miximus.

I think there will a need for some kind of the coordination layer here. Otherwise, nodes listening to Whisper messages will swarm (n nodes trying to execute at the asme block) the execution (especially given 15s blocks) making them (in theory) 1/n times profitable. This is the same problem Ethereum Alarm Clock has to solve, I did some analysis on current claiming protocol for EAC, here

[HarryR]

swarm (n nodes trying to execute at the asme block) the execution (especially given 15s blocks) making them (in theory) 1/n times profitable.

Hi, I was thinking about a two-phase protocol where you advertise details of the transaction you want relayed, then the relayers acknowledge it, then you choose one of those to send the full transaction to.

The 1/n times profitable is worse than 1/n if you consider failure penalties, if you submit a transaction you pay Gas upon failure - inflicting a penalty upon any relayer. So if, from each transaction you relay, you only make enough to cover that transaction and an additional 10%, but another transaction you relay fails because somebody else relayed it, then you're losing money by relaying duplicate transactions.

With the 'advertise/acknowledge/confirm' pattern a malicious actor can still cause relayers to submit duplicate transactions (at their loss), by not adhering to the protocol. Can you think of any ways around that, or would that be a good compromise in the interim?

[HarryR]

In order to avoid a malicious actor from causing the 'honest' others to lose money by, while adhering to the protocol, picking multiple people to offer their transaction to, is to have the honest ones communicate with each other about which of them has been picked.

If there it as least one other honest player who, upon being picked to broadcast a transaction, relays that information to other players, then the malicious actors ability to deceive multiple people depends on at least one of them being honest.

So, with the protocol for transaction relay:

• Alice broadcasts she wants to relay transaction X
• Bob and Charlie acknowledge that they can reveal that transaction
• Alice picks one, say Bob, and acknowledges to Bob that he has been picked
• Bob broadcasts to everybody, including Charlie, that he has been picked for that transaction

If Bob is malicious doesn't broadcast Alice's acknowledgement then Charlie will lose out.

If Alice is malicious and acknowledges both transactions, but either Bob or Charlie are honest, then neither will lose out.

If [Evil] Eve acknowledges all transactions that she's picked for but doesn't submit it, then Alice will lose out.

If [Evil] Eve is malicious and doesn't acknowledge that she's been picked but does submit it then Alice or Bob may lose out if their gas price is lower, otherwise Eve will lose out.

I think it would be worth spending more time thinking about how this works together with the priority queue of the mempool vs gas price, because I think it's close to a zero-sum game if we can account for some other factors:

• reputation, if Bob has made 1000 successful transaction relays, he's more trustworthy than somebody who's made 0 successful transactions. But I think somebody with 500 is just as trustworthy as somebody with 1000 or even 2000 (they must have equal financial incentive), so maybe logarithmic scoring of some sort.