EIP-1077 Executable Signed Message

User Experience
1

As part of the Executable Signed Message, I’ll be calling people that shown interest in this topic for these threads and want to debate specifics of the scheme…

I’ve updated the spec of ERC1077 based on feedback and conversations with the gnosis team. Right now, the best two references for executable signed messages are:

I’ve added Gnosis Operation Type to the standard, so that it comprises both. A normal call is 0, so a contract that doesn’t want to support this option can simply leave it at 0.

I’ve also made a few modifications to make it EIP191 compatible, by request of Dan and Gnosis team and removed the nonce as timestamp thing, that was adding unnecessary complexity (feedback by @arachnid). I have replaced it by adding support for nonce 0 as a nonceless transaction which is more flexible for some cases but uses more memory.

Topics to discuss:

  • How do the multiple deployer parties communicate among each other, specially if you need multiple signatures before posting the message?
  • If there is a competition among the deployers and multiple send at the same time, one or more will have their gas burned and incur in a cost which will increase the price of the service for everyone. Is there a way to create a cooperation among them to prevent this?
  • How to create the initial contracts? There are some tricks that can be done to save gas cost, and there are some schemes where the user can already have an account address to send funds before deploying the contract, so you don’t need to deploy to inactive users
  • What are the gas costs overhead of this scheme and how can we reduce them?
6 Likes
2

Hey all! I approached Alex about this project because we have a bunch of developers learning blockchain and we’re setting this up as a group project.

We’re going to start making a truffle box / npm package that can be used by smaller developers, first as a testnet POC to road-test and find the bumps along the way. Here’s what I’m imagining our first steps will be, open to any and all feedback:

  1. Context-specific ether-less account, public-private keys created client-side — Built in React using Consensys LightWallet
  2. Signs EIP-191 compliant transaction with newly-generated private key
  3. Centralized server wraps up transaction in a relay transaction — (Probably absorbing the cost just for demo sake right now)
  4. Centralized server uses factory pattern to deploy an erc-725 identity contract with relayed transaction from user to testnet
2 Likes
3

EIP191 requires that messages be hash of these parameters:

keccak256(byte(0x19), byte(0), from, whatever);

The initial implementation (based on Status imp) asked the user to sign a string based on this:

keccak256(byte(0x19), byte(0), from, callPrefix, to, value, dataHash, nonce, gasPrice, gasLimit, gasToken);

But upon looking at Gnosis I also added OperationType:

keccak256(byte(0x19), byte(0), from, callPrefix, to, value, dataHash, nonce, gasPrice, gasLimit, gasToken, operationType);

In order to make it future proof, I suggest adding in the end of the hashes an extra parameter (maybe instead of operationType):

keccak256(byte(0x19), byte(0), from, callPrefix, to, value, dataHash, nonce, gasPrice, gasLimit, gasToken, extra);

The purpose of which would be basically making it more future proof.

On solidity, multiple parameters on Keccak are the equivalent of doing concatenation and then hashing… so keccak256(requiredParam1, requiredParam2, extraParam1, extraParam2); is the same hash as keccak256(requiredParam1, requiredParam2, (extraParam1+extraParam2));

This allows anyone to add any amount of parameters at the end of the message, and still make it compatible with previous implementations.

1 Like
4

In light of the last message, I’ve updated the standard to allow more flexibility in multiple implementations:

Now some fields are optional if your contract doesn’t care for them, but if you ignore some fields, you must add an extra hash at the end to make yours compatible with other future implementations. While this thread isn’t getting a lot of attention, I’ve been having conversations via email, skype etc (and keep referring people back to this to keep this alive)

1 Like
5

@alexvandesande Replying to your ERC1077, you talk about user pain points and developer pain points.

I would like to add that, we should always be focusing on achieving the best user experience at all costs. (I assume we are talking about consumer facing applications) User pain points will need to be solved first (or items that drive business goals). Only once that those are satisfied, the developer pain points in creating the best experience should then be addressed. (not saying we shouldn’t think about them but just highlighting the priorities). We should be optimising for the development of great user experiences not just optimising for code to be pushed.

Product trade offs between ux and dev resources are a matter of economics and should be considered aside all together.

Take care when considering the user pain points and the developer pain points.

1 Like
6

Hey All! Julien from Argent here.

We’ve been working on a Wallet with ETH less accounts for the past 6 months and are very excited to see some of these ideas being standardised.

One possible area of improvement that is not addressed by the current version is the possibility for the ‘key’ to be a smart contract itself. The use case is that of e.g. a recovery where User A with WalletA would like to authorise User B with WalletB do to a recovery on its Wallet. In that scenario the signed message would be signed with a key (say keyB) authorised to sign on behalf of WalletB, and WalletA needs to reconcile the signature by keyB with WalletB.

One possible solution is to use the ‘extra’ field to pass the address on behalf of which the message was signed, or add an additional parameter to the call.

1 Like
7

@juniset So the private key would kinda be like beach ball where it is passed back and forth amongst the user dapps to sign transactions?

8

Also @everyone here, what do you think about relying on emails for login / registration? Current systems depend on it for confirmation emails and account recovery. How can we transition people into using new mental models of dealing with signing things etc.

9

Could you be more specific? I generally agree with this sentiment, but most UX challenges are actually deeper than just skin deep and the purpose of this standard is to allow these challenges to be surmounted.

Juni, you don’t need the key to be a smart contract for that. Both Gnosis and Status are doing social recovery keys, where you authorize X users to reset your wallet. The way to do that is that Wallet A, when doing a recovery process, can check if key B that signed the message, is authorized to do so by wallet B. No need to complicate things.

Yes, that’s the idea.

Emails are centralized services. I think one way in which one can use email is actually to add a “central recovery key” option, in which users from company A say they trust keys from company A to reset their keys. That interaction and recovery request can be done via email, and the company can confirm their identity by email.

Of course, as soon as users have enough devices on the system so that they are effectively multisig, they should switch recovery options.

1 Like
10

Another thought I had: How we design these systems and user experiences will change along with cheaper gas execution costs. While it may cost $5 in gas fees to claim an ens or execute a smart contract, it might cost fractions of a cent in the future. Along with this shift, people’s attitudes towards signing transactions might change.

Ether and gas might fade into the background just like internet data. Earlier on, internet data was way more expensive and you paid a monthly subscription for say 15gigabites of data. With expensive data and a low total bandwith, streaming a movie or playing a 2hr youtube video had be a careful consideration. This is the opposite today where we hardly care as much, we use data more liberally and don’t monitor data usages.

Just some food for thought

1 Like
11

How we design these systems and user experiences will change along with cheaper gas execution costs

Good point. We design a lot of things today trying to optmize for cheaper gas. The big drawback of this signed approach is that it might end up in more costly transactions (need to benchmark how much) but it might not matter in the long term

1 Like
12

Hey all! Students at Hatch worked on a very basic way to generate Ethereum addresses and keys without passwords, seed phrases, etc., store them locally and use them to sign messages. We’re hoping to build-out the Solidity side to take notes from Gnosis Identity Relay contract.

It’s a very simple implementation, but we’re hoping to continue working on it (after some great input from @alexvandesande yesterday!) and wrap it up as an npm package or truffle box. Please check out the repo link! Comment, PR, etc. etc.

Please note: These are front-end developers who have learned blockchain concepts & practices over the past five weeks. This was done in a mini-sprint that lasted about a day and half culminating in Alex’s visit!

1 Like
13

I know this thread has been quiet, but I wanted to post another project here:

Austin has built a nice working demonstration of transaction forwarding (a concept I’ve found tricky to explain to students) with a nice UI (which we all love!). I’m going to try and work with him on getting it to EIP-1077 standards, notably getting ERC-191 signed message parameters into the workflow.

4 Likes
14

FYI, I created a link page of projects relating to meta transactions: https://github.com/jpitts/eth-community-discussions/blob/master/meta-transactions.md

2 Likes
15

This is amazing! Thank you.

16

Gave a talk yesterday for 8btc and hyped meta-transactions & universal login. It was written up here (in Mandarin), linked to repos at the bottom!

https://m.8btc.com/article/296078

1 Like