Example: ethereum/go-ethereum#3339

参数：[
{
来自：“0xb60e8dd61c5d32be8058bb8eb970870f07233155”，
到：“ “0x9AF2C395d87D17c23ec8B01c6624b92493ec5dF9”，
气体：“0x76c0”，// 30400
汽油价格：“0x9184e72a000”，// 1000000000000
值：'0x9184e72a'，// 2441406250
数据：
'0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675'，
}，
]]；

以太坊
.request（{
方法：“eth_sendTransaction”，
参数，
})
.then((结果) => {
// 结果因 RPC 方法而异。
// 例如，此方法在成功时将返回事务散列十六进制字符串。
})
.catch((error) => {
// 如果请求失败，Promise将错误地拒绝。
});

I am currently working on eth-contract-lib. This is a java library to interact with smart contracts.

I've implemented a first backend with EthereumJ and I would like to be able to use RPC as well. This way, it is possible to create applications that don't need to sync to work and can even be used on mobile.

One of the feature I have already implemented for the EthereumJ version is to get the returned value from a sendTx function call.

In EthereumJ, you have access to the executionResult in the transaction receipt that can be decoded and converted into a returned value(s).

It would be great to have the same functionality in the RPC API.

summary

eth_simulateTransaction should be introduced to replace eth_call and eth_estimateGas

eth_simulateTransaction can provide information including:

• return value
• gas consumption
• if an error was thrown

This helps solve the problem of trying to differentiate between correct response and error response with eth_call and eth_estimateGas

spec

eth_simulateTransaction

Executes a new message call without creating a transaction on the block chain.

Parameters

1. Object - The transaction call object

• from: DATA, 20 Bytes - (optional) The address the transaction is sent from.
• to: DATA, 20 Bytes - The address the transaction is directed to.
• gas: QUANTITY - (optional) Integer of the gas provided for the transaction execution. eth_call consumes zero gas, but this parameter may be needed by some executions.
• gasPrice: QUANTITY - (optional) Integer of the gasPrice used for each paid gas
• value: QUANTITY - (optional) Integer of the value send with this transaction
• data: DATA - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI

2. QUANTITY|TAG - integer block number, or the string "latest", "earliest" or "pending", see the default block parameter

Returns

Object - A transaction summary object

• returnValue: DATA, 32 Bytes - hash of the transaction.
• gasUsed : QUANTITY - The amount of gas used by this specific transaction alone.
• contractAddress : DATA, 20 Bytes - The contract address created, if the transaction was a contract creation, otherwise null.
• logs: Array - Array of log objects, which this transaction generated.
• errorCode: null or string - (needs spec) Whether or not an error such as a top-level OOG, invalid jump, or other vm-halting error occurred. Code should indicate the status in this way:
  • (successful)
  • out of gas
  • stack overflow
  • stack underflow
  • invalid jump (no JUMPDEST present)
  • invalid instruction
  • possibly the INVALID instruction could have its own code
  • stop by REVERT

Example

// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_simulateTransaction","params":[{"to": "0xCD111aa492a9c77a367C36E6D6AF8e6f212E0C8E"}],"id":1}'

// Result
{
  "id":1,
  "jsonrpc": "2.0",
  "result": {
    "returnValue": "0x4242",
    "gasUsed": "0x5208",
    "contractAddress": null,
    "logs": [],
    "errorCode": null
  }
}

params: [
{
from: '0xb60e8dd61c5d32be8058bb8eb970870f07233155',
to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
gas: '0x76c0', // 30400
gasPrice: '0x9184e72a000', // 10000000000000
value: '0x9184e72a', // 2441406250
data:
'0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675',
},
];

ethereum
.request({
method: 'eth_sendTransaction',
params,
})
.then((result) => {
// The result varies by by RPC method.
// For example, this method will return a transaction hash hexadecimal string on success.
})
.catch((error) => {
// If the request fails, the Promise will reject with an error.
});

Abstract

This is the API for a standalone signer daemon, which will handle private keys and signing and deliver support for HD and hardware wallets.
This daemon will have its own IPC connection and will be separate from any running node.

NOTE This is API v 1.0 for a signer daemon without UI!

Connection

JSON RPC 2.0 over IPC.

This signer should open its own IPC connection.
e.g. on ~/Library/Ethereum/signer.ipc

Binary flags

--datadir /path/to/keystore

API

IN PROGRESS

account_list ( )
> [{
        type: "account |hd|ledger|trezor",
        url: "...",
        accounts: ['0x234567','0x2134567'] // maybe HD path?
    }, {
      ...
    }]

account_new ( string: password) 
> {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        accounts: ['0x234567'] // only one for "normal" accounts
    }

account_newHDWallet ( string: newPassword ) 
> {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        mnemonic: "hello world iam here ...",
        accounts: ['0x234567'] // first account generated
    }

account_newHDWallet ( string: newPassword ) 
> {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        mnemonic: "hello world iam here ...",
        accounts: ['0x234567'] // first account generated
    }

account_getHDWalletAddress ( string: id, number: index?? ) 
> 0x1234567654321234567...

account_export ( string: address|id|publicKey)  // works also of HD wallets
> { web3 keystore json }

account_import ( Object: web3 keystore json) 
>  {
        id: 0,
        type: "account|hd|ledger|trezor",
        url: "...",
        mnemonic: "hello world iam here ...",
        accounts: ['0x234567', '0x234567', '0x234567']
    }

account_importPrivateKey (string privateKey)
> {
        id: 0,
        url: "...",
        type: "account|hd|ledger|trezor",
        accounts: ['0x234567']
    }

account_signTransaction (object: txObject, array: JSONInterface, string: password)
> 0x123456789876543212345678..
// OR
> {
   hash: '0x234567890',
   r: '0x456789',
   s: '0x234678',
   v: '0x02',
   signature: '0x1234567654321234567' // full RLP encoded signature, passable to eth_sendRawTransaction
}

account_sign (string: message, array: JSONInterface, string: password)
> 0x123456789876543212345678..
// OR
> {
   message: 'Hello',
   hash: '0x234567890',
   r: '0x456789',
   s: '0x234678',
   v: '0x02',
   signature: '0x1234567654321234567' // full signature, passable to personal_ecRecover
}

account_recover (string/Object: RLPencodedsig|ObjectWithSignatureValues)
> '0x23456789876543212' // Ethereum address

// Is the below needed, or can "is transaction" be auto detected in "personal_recover"

account_recoverTransaction (string/Object: RLPencodedsig|ObjectWithSignatureValues)
> '0x23456789876543212' // Ethereum address

account_unlock (string: address|id|publicKey, string: password)
> true

account_lock (string: address|id|publicKey)
> true

Addition we could add support for subscriptions for key adding etc.

Abstract

This draft is to discuss the ethereum API, an object exposed by ethereum native browsers and tools like Mist, MetaMask and status.im.

The API should be small and clean and allow all kind of libraries to attach to it.

The class of the object should be EthereumProvider, the object name ethereum.

API

The ethereum should inherit from a EventEmitter type class, and provide add/removeListener, on/once/off etc.

// callback: a error first callback
ethereum.send(methodName, params, callback)
> undefined

// CALLBACK return
> err, result

// returns subscription notification,
ethereum.on(subscriptionType, handler)

subscriptionType = `eth_subscription`

// HANDLER return
> {
       "subscription":"0x2acffa11d68280c2954daeb77cb849d9",
       "result": {...}
    }

// react on connection start
ethereum.on('connect', handler)

// HANDLER return
null

// react on connection end
ethereum.on('end', handler)

// HANDLER return
Error Object with message (timeout, error, drop, etc)

params: [
{
from: '0xb60e8dd61c5d32be8058bb8eb970870f07233155',
to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
gas: '0x76c0', // 30400
gasPrice: '0x9184e72a000', // 10000000000000
value: '0x9184e72a', // 2441406250
data:
'0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675',
},
];

ethereum
.request({
method: 'eth_sendTransaction',
params,
})
.then((result) => {
// The result varies by by RPC method.
// For example, this method will return a transaction hash hexadecimal string on success.
})
.catch((error) => {
// If the request fails, the Promise will reject with an error.
});

Making the network id accessible on the RPC will allow dapps to know on which network they are right now.

We would need that in mist to know the difference between networks and store accounts accordingly.

@bas-vk @debris @chriseth

JSON-RPC doesn't specify a transport layer. It relies on the transport protocol (HTTP) to do that. This however is missing in certain use cases, such as Unix socket based IPC.

There is no consistent way defined between Ethereum clients to deal with this:

• geth uses a streaming JSON decoder which can detect the end of the input
• soltest (solidity) looks for the first new line (\n), which is obviously dangerous
• cpp-ethereum waits for a big enough input

There are some proposals to define a transport layer:

• open a new connection every single time (not really suitable for our use)
• use an encapsulation format (proposes netstrings)
• rely on the JSON decoder

Since there is no widely adopted standard, I propose to have a single length field preceding the JSON request and the response.

For the encoding I propose to use either:

• number as a string terminated with new line (this valid JSON)
• a single member array with the length as the only member ([1234] - this is valid JSON too and is easy to search for the closing bracket ])
• RLP or CBOR encoded number

Choosing a JSON compatible encoding would mean that clients could support backwards compatibility by reading another JSON message if the first message is not JSON-RPC (e.g. it is a single number in an array as above)

I've seen an increasing number of Dapp developers asking how they can allow web3-enabled visitors to authenticate by signing a terms of service to register.

This would allow a site to verify account ownership, without costing any gas fee, and allowing off-chain relationships to continue.

The reason this is different than the other current sign methods, is that it would be implied that the contents to be signed are human-readable text, (maybe styled, like markdown) so that web3 browsers and wallets can display the site's terms with the specified encoding, before hashing, prefixing, and signing as usual.

Anyone else interested in such a method?

The naming for the RPC call eth_sendRawTransaction is misleading as this call allows to send a signed transaction. The term raw is used in the context of transactions for unsigned data (raw transaction hash). Changing the RPC name to eth_sendSignedTransaction would make the usage more clear and prevent misuse.

Hi

I had used JSON schema once or twice and I guess, there is a good chance, that we could build a validator on the client side with that information. Would be convenience, but give developers a chance for good validation, automatically.

With the changes proposed in this PR (ethereum/go-ethereum#2940), the signing of transactions with eth_sign becomes impossible as a transaction incompatible prefix is added to every signed data.

The option to sign transactions without sending them immediately to the network is important as it allows to sign transactions offline, which can increase security significantly.

Proposed function signature:
eth_signTransaction(tx_object)

The transaction object has the same JSON structure as eth_sendTransaction.

https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_sendtransaction

Summary

At present two RPCs allow dapps clients to ascertain a default account from which to send transactions: eth_coinbase and eth_accounts. Neither are well-suited. eth_coinbase is the already defined as the preferred block author for mining/sealing and in certain setups this may collide with the account from which transactions should be signed by default.
eth_accounts returns a list of available accounts with not a single one being necessarily favourite.

This proposal is to create a new RPC for the sole duty of determining a default transaction signing account.

Spec

• defaultAccount() -> address: Returns the account that the node owner would prefer to see used. This can be contextual if the node supports multiple calling contexts. Should generally be a member of the set of accounts returned by eth_accounts().

Notes

To be as backwards compatible as possible, client authors should consider:

• implementing eth_coinbase to return the same value as defaultAccount while not mining/sealing;
• implementing eth_accounts to always have the first value of the list returned equivalent to eth_defaultAccount.

Incubation

We propose the final RPC endpoint for this be eth_defaultAccount; if an incubation period is required, we suggest arb_defaultAccount be adopted initially.

This issue is a reminder and discussion thread for the following improvements:

• eth_call should return an RPC error, if the call throws in the EVM (Another option would be to return null instead of 0x, as of right now)
• eth_estimateGas should return an RPC error if the all the gas was used
• eth_getTransactionReceipt should contain a outOfGas property, so that devs can see if a tx threw.

Error code EIP ethereum/EIPs#136

Currently there are a couple of tests scattered around in:

• Solidity
• web3.js
• ethereumjs-abi
• ethjs-abi

It would be nice to create a test suite as JSON files, which can be used by all these implementations to validate against.

cc @SilentCicero

Per EIP 1, I am opening discussion here for a new "Wallet Permissions" API.

Primary discussion is posted at ethereum-magicians.

params: [
{
from: '0xb60e8dd61c5d32be8058bb8eb970870f07233155',
to: '0xd46e8dd67c5d32be8058bb8eb970870f07244567',
gas: '0x76c0', // 30400
gasPrice: '0x9184e72a000', // 10000000000000
value: '0x9184e72a', // 2441406250
data:
'0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675',
},
];

ethereum
.request({
method: 'eth_sendTransaction',
params,
})
.then((result) => {
// The result varies by by RPC method.
// For example, this method will return a transaction hash hexadecimal string on success.
})
.catch((error) => {
// If the request fails, the Promise will reject with an error.
});

With the availability of various test tools, different methods for accomplishing the same testing features were implemented.

cpp-ethereum (complete list):

• test_setChainParams(genesis) - resets the blockchain to the provided genesis
• test_mineBlocks(n) - mine n blocks
• test_modifyTimestamp(time) - change timestamp
• test_addBlock(block)
• test_rewindToBlock(number) - revert to the block number

go-ethereum (complete list and probably outdated here):

• admin_importChain(path-to-file) - Imports the blockchain from a marshalled binary format. Note that the blockchain is reset (to genesis) before the imported blocks are inserted to the chain.
• admin_exportChain(path-to-file) - Exports the blockchain to the given file in binary format.
• admin_sleepBlocks(n) - Sleeps for n blocks.
• debug_setHead(number) - Sets the current head of the blockchain to the block referred to by blockNumber.

It has a lot more under debug.

parity:
?

testrpc:

• evm_snapshot: Snapshot the state of the blockchain at the current block. Takes no parameters. Returns the integer id of the snapshot created.
• evm_revert: Revert the state of the blockchain to a previous snapshot. Takes a single parameter, which is the snapshot id to revert to. If no snapshot id is passed it will revert to the latest snapshot. Returns true.
• evm_increaseTime: Jump forward in time. Takes one parameter, which is the amount of time to increase in seconds. Returns the total time adjustment, in seconds.
• evm_mine: Force a block to be mined. Takes no parameters. Mines a block independent of whether or not mining is started or stopped.

It would be nice defining a common set implemented by the clients.

WIP

API spec will be added later....

This method works like "eth_sendTransaction", but accepts the accounts password as the second parameter. It will then unlock the account internally, send the transaction and locks it again.

• geth: must rename its method from "personal_signAndSendTransaction" to "personal_sendTransaction" (in 1.5)
• cpp: not implemented?
• parity: not implemented?
• ethereumj: not implemented?