day6:EIP107,1077,1078

eip107:safe "eth_sendTransaction" authorization via html popup

• abstract

This draft EIP describes the details of an authorization method that if provided by rpc enabled ethereum nodes would allow regular websites to send transactions (via eth_sendTransaction) without the need to enable CORS. Instead, user would be asked to confirm the transaction via an html popup.

Every read only rpc call the dapp wants to perform is redirected to an invisible iframe from the node's domain and for every transaction that the dapp wish to execute, an html popup is presented to the user to allow him/her to cancel or confirm the transaction. This allows the dapp to connect to the node's rpc api without being granted any kind of privileges. This allows users to safely interact with dapps running in their everyday web browser while their accounts are unlocked. In case the account is not unlocked, and the node has allowed the "personal" api via rpc,the html page also allow the user to enter their password to unlock the account for the scope of the transaction.

authorization methodの詳細に関しての提案。既存のウェブサイトがCORSの必要なしにトランザクションを送る(via eth_sendTransaction)。その代わりにユーザーにhtmlのポップアップを使って、トランザクションの商品を得るという仕様に関しての提案。

• motivaiton

現状：既存のブラウザではセキュリティの観点からdappsはデフォルトでrpc apiにアクセスすることができない。CORSを考えないwebsite domainではdappsは動かない。困ったことにCORSを考えると、ユーザーは強制的にdappウスを信用しないといけなし、userconsentの必要なしにアンロックアカウントからsend transactionが可能になる。言い換えると、nodeのdefault settingを変える必要があるだけでなく、それを使うためにユーザーはそのdappsをtrustすることを強制させる。これは受け入れがたいことだし、既存のdappsの立場上よくない。

• 単純なtransactionを行うために、"Mist"のようなwalletを盲目的に信頼するか尋ねられる

• node command line interfaceを経由して、トランザクションをするかどうか尋ねられる

みたいな面倒なケースも考えられる。

そんなわけで、この提案はsafeでuser friendlyを提供することが狙い。
いくつかのscreenshotを元に実装例を提案。

• Account unlocked

• account locked and no "personal" api exposed via rpc:

This is not ideal since this requires the user to know how to unlock an account:

これはuxとして理想的なものではない

• account locked but node exposing the "personal" api via rpc

this is better.

• specification (invisible iframe and popup window).二つのパターンを提案

{
  id:<a an id>, //so responses can be match as there is no guarantee of the order of the response
  payload:<json rpc object> //this is the exact object that usually send to the node
}

• eth_sendTransaction

In all the cases, the iframe/window will send a message back to the dapp using the following object:

{
  id:<id matchign the request>,
  result:<rpc result as is>,
  error:<error object>
}

the error object cannot be a javascript Error object due to postMessage limitation.

{
  message:<a string describing the error>,
  type:<a string defining the type of error> //type="cancel" means the user cancel the transaction
}

• rationale

simplicity and securityのために提案。oauth-likeなプロトコルも検討したが、実装が大変だし、gethの仕様と合わせて話し合う必要がある。そのため、iframe/windowの方が、組み込みが容易だと判断し、こちらを提案。

• source

EIPs/eip-107.md at master · ethereum/EIPs · GitHub

eip-1077:Executable Signed Messages refunded by the contract

• simple summary

  Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them is an emerging pattern being used in many projects. Standardizing a common format for them, as well as a way in which the user allows the transaction to be paid in tokens, gives app developers a lot of flexibility and can become the main way in which app users interact with the Blockchain.

userが実行許可にサインすることはある。しかし、多くのプロジェクトでthird paty relayerがそれらを実行するために扱われるパターンもある。そのため、仕様を統一することによって、トランザクションに対してトークンが支払われることを許可するように、app developerに多くのflexibilityを与えて、アプリケーションをuserとblockchainの連携をすることに集中させたい。

• abstract

##### User pain points:

users don't want to think about ether
users don't want to think about backing up private keys or seed phrases
users want to be able to pay for transactions using what they already have on the system, be apple pay, xbox points or even a credit card
Users don’t want to sign a new transaction at every move
Users don’t want to download apps/extensions (at least on the desktop) to connect to their apps  

##### App developer pain points:

Many apps use their own token and would prefer to use those as the main accounting
Apps want to be able to have apps in multiple platforms without having to share private keys between devices or have to spend transaction costs moving funds between them
Token developers want to be able for their users to be able to move funds and pay fees in the token
While the system provides fees and incentives for miners, there are no inherent business model for wallet developers (or other apps that initiate many transactions)
Using signed messages, specially combined with an identity contract that holds funds, and multiple disposable ether-less keys that can sign on its behalf, solves many of these pain points.

Using signed messages, specially combined with an identity contract that holds funds, and multiple disposable ether-less keys that can sign on its behalf, solves many of these pain points.

資金を保持するID契約と特別に結合された署名付きメッセージと、それに代わって署名することができる複数の使い捨てether-less keyを使用することで、これらのpoin pointsの多くが解決されます。

• implementation
  signed messagesにはこれらが必要

- To: the target contract the transaction will be executed upon
- From: the account that will be executed on behalf of
Value: the amount in ether to - be sent
Data: the bytecode to be executed
- Nonce: a nonce or a timestamp
- GasToken: a token in which the gas will be paid (leave 0 for ether)
- Gasprice: the gas price (paid in the selected token)
- GasLimit: the maximum gas to be paid

• Signing the message
  以下の順番で連結されないといけない。

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

• backwards and forwards capability:

Not all executable signed messages contracts will have the same requirements, therefore some fields are optional. Fields byte(0x19), byte(0), from, to, value, dataHash are obligatory while nonce, gasPrice, gasLimit, gasToken, callPrefix, operationType are optional, but must be hashed in this order.

• Multiple signatures

  If multiple signatures are required, then all signed messageHashes should then be ordered by account and sent to the receiveing contract which then will execute the following actions:

• Supported functions

If multiple signatures are required, then all signed messageHashes should then be ordered by account and sent to the receiveing contract which then will execute the following actions:

• similar implementaions この辺が似通った提案らしい

EIP 877 An attempt of doing the same but with a change in the protocol Status Aragon (this might not be the best link to show their work in this area) Token Standard Functions for Preauthorized Actions Token Standard Extension 865 Iuri Matias: Transaction Relay uPort: Meta transactions uPort: safe Identities Gnosis safe contracts

おそらく結構重い提案というか、初期から肉付けされて巨大化したeipっぽい。他の関連部分も読み返しながら、あとで振り返って改めて読み返そうと思う。

• source

github.com

eip-1078:Universal login / signup using ENS subdomains

• abstract

  This presents a method to replace the usual signup/login design pattern with a minimal ethereum native scheme, that doesn’t require passwords, backing up private keys nor typing seed phrases. From the user point of view it will be very similar to patterns they’re already used to with second factor authentication (without relying in a central server), but for dapp developers it requires a new way to think about ethereum transactions.

signup/loginをデザインパターンとして、パスワード不要、private keyもseed typeも必要なしにする提案。ユーザーにとってはsecond factor authentication (without relying in a central server),として慣れしんだものだが、dapps developersにとってethereum transactionに関して言えば新しく考える必要のある方法である。

• simple summary
  user accountをauth tokens, rather than unique keysとして扱う。

• login process

1.  Request a name from the user  
 
2.  a) create a new identity  


2-1.Generate a private key which it will keep saved locally on the device or browser, the safest way possible.  

2-2.Create (or set up) an identity contract which supports both ERC720 and ERC1077  

2-3.Register the private key created on step 1 as the only admin key of the contract (the app must not add any app-controlled key, except as recovery option - see 5)  

2-4.Register the requested subdomain and transfer its ownership to the contract (while the app controls the main domain and may keep the option to reassign them at will, the ownership of the subdomain itself should belong to the identity, therefore allowing them to transfer it)  

2-5.(Optionally) Register a recovery method on the contract, which allows the user to regain access to the contract in case the main key is lost.  

  2.b) Connect to an existing identity

続きはeipを直に読んだ方が良い。
EIPs/eip-1078.md at master · ethereum/EIPs · GitHub

現状まだdraftのため、実装例はないが、アプリケーションをもっと軽くして、サインアップ手続きを減らしたり、既存のwebのようにもっと簡単に触れるようにしようということが狙い。