eth_call #35

alita-moore · 2021-04-26T05:11:24Z

No description provided.

…into eth_call

MariusVanDerWijden

Mostly nitpicks,
Some thing that's missing from the spec is overrides I think

MariusVanDerWijden · 2021-04-26T05:47:22Z

json-rpc/eth_call.md

+4.1.2.1   | `eth_call` MUST only accept requests with the `from` parameter defined as a hex string with length 40
+4.1.2.1.1 | `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
+4.1.2.2   | `eth_call` MUST NOT accept `from` hex strings with invalid characters
+4.1.2.2.1 | `eth_call` SHOULD throw error `-32602` [!] on improper hex string and return message `invalid argument 0: json: cannot unmarshal invalid hex string into Go struct field CallArgs.from of type common.Address`


That's pretty golang specific

I don't think the message itself should be explicitly specified at all. The message is for humans, and implementors may want to augment it with additional metadata (which is especially useful in Ganache and other blockchain simulators).

MariusVanDerWijden · 2021-04-26T05:53:02Z

json-rpc/eth_call.md

+4         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its first item containing a [JSON Object](https://tools.ietf.org/html/rfc7159#section-4) with keys known here as the `input parameters`
+4.1       | `eth_call` MUST accept an input parameter `from` of type `DATA` [!]
+4.1.1     | `eth_call` MUST accept requests with the from input parameter undefined
+4.1.1.1   | `eth_call` MUST consider CALLER account to be `0x0000000000000000000000000000000000000000000000000000000000000000` if `from` is not defined


Suggested change

4.1.1.1 | `eth_call` MUST consider CALLER account to be `0x0000000000000000000000000000000000000000000000000000000000000000` if `from` is not defined

4.1.1.1 | `eth_call` MUST consider CALLER account to be `0x000000000000000000000000000000000000000` if `from` is not defined

Adresses are 20 bytes in Ethereum

There are 39 zeros here 😇

MariusVanDerWijden · 2021-04-26T05:53:36Z

json-rpc/eth_call.md

+4.1.2.1.1 | `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
+4.1.2.2   | `eth_call` MUST NOT accept `from` hex strings with invalid characters
+4.1.2.2.1 | `eth_call` SHOULD throw error `-32602` [!] on improper hex string and return message `invalid argument 0: json: cannot unmarshal invalid hex string into Go struct field CallArgs.from of type common.Address`
+4.1.2.3   | `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter


Suggested change

4.1.2.3 | `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter

4.1.2.3 | `eth_call` MUST consider CALLER account to equal a 20 byte hex string [!] of the `from` parameter

MariusVanDerWijden · 2021-04-26T05:54:16Z

json-rpc/eth_call.md

+4.1.2.2.1 | `eth_call` SHOULD throw error `-32602` [!] on improper hex string and return message `invalid argument 0: json: cannot unmarshal invalid hex string into Go struct field CallArgs.from of type common.Address`
+4.1.2.3   | `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter
+4.1.2.3.1 | `eth_call` MUST accept a `from` account that does not exist on-chain
+4.1.2.3.2 | `eth_call` MUST consider CALLER account to equal the `from` parameter if the account does not exist on-chain 


Isn't that the same as 4.1.2.3.?

MariusVanDerWijden · 2021-04-26T05:56:09Z

json-rpc/eth_call.md

+4.2       | `eth_call` MUST accept an input parameter `to` of type `DATA` [!]
+4.2.1     | `eth_call` MUST accept requests with `to` equal to null
+4.2.1.1   | `eth_call` MUST return empty hex string [!] if `to` input parameter is equal to null
+4.2.2     | `eth_call` MUST only accept hex encoded address strings as specified by [!] 


As specified by?

MariusVanDerWijden · 2021-04-26T05:59:52Z

json-rpc/eth_call.md

+4.3.4.1   | `eth_call` SHOULD throw exception `-32000` with message `err: intrinsic gas too low: have 13107, want 21000 (supplied gas 13107)`[!] if the `gas` input parameter is less than `implicit gas`[!]
+4.3.4.2   | `eth_call` SHOULD throw exception `-32000` with message `out of gas`
+4.3.5     | `eth_call` MUST NOT accept requests if the `gas` input parameter is not properly formatted
+4.3.5.1   | `eth_call` SHOULD throw exception `-32602` with message `invalid argument 0: json: cannot unmarshal hex number with leading zero digits into Go struct field CallArgs.gas of type hexutil.Uint64`[!] if the `gas` input parameter does not meet `hex encoded`[!] specifications


Again, error message go-specific

MariusVanDerWijden · 2021-04-26T06:00:12Z

json-rpc/eth_call.md

+4.3.5     | `eth_call` MUST NOT accept requests if the `gas` input parameter is not properly formatted
+4.3.5.1   | `eth_call` SHOULD throw exception `-32602` with message `invalid argument 0: json: cannot unmarshal hex number with leading zero digits into Go struct field CallArgs.gas of type hexutil.Uint64`[!] if the `gas` input parameter does not meet `hex encoded`[!] specifications
+4.3.6     | `eth_call` MUST NOT accept requests if the `gas` input parameter is greater than `2^64 - 1` or `0xffffffffffffffff`
+4.3.6.1   | `eth_call` SHOULD throw exception `-32602` with message `invalid argument 0: json: cannot unmarshal hex number > 64 bits into Go struct field CallArgs.gas of type hexutil.Uint64` if the `gas` input parameter is greater than the hex string encoded decimal `2^64 - 1`


go specific

MariusVanDerWijden · 2021-04-26T06:01:09Z

json-rpc/eth_call.md

+4.4.1.1   | `eth_call` MUST consider `GASPRICE`[!] as equal to 0 if `gasPrice` input parameter is equal to `null`[!]
+4.4.2     | `eth_call` MUST consider `GASPRICE`[!] as equal to `gasPrice` input parameter if `gasPrice` input parameter is not equal to null and meets `Quantity` requirements
+4.4.2.1   | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address {from} have {from account balance} want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than the balance of the account associated with the `from` input parameter
+4.4.2.2   | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null


Suggested change

4.4.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null

4.4.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address {from} have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null

MariusVanDerWijden · 2021-04-26T06:03:44Z

json-rpc/eth_call.md

+4.5.1.2.1 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for transfer: address {from} (supplied gas {gas || 25000000[!]})` if the value of `BALANCE`[!] of `CALLER`[!] on-chain is less than the `value` input parameter AND `to` input parameter is equal to `null`[!]
+4.5.1.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for transfer: address {from} (supplied gas {gas || 25000000[!]})` if the `value` input parameter is greater than 0 AND the `from` input parameter is equal to `null`[!]
+5         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its second item (index = 1) containing a `Block Identifier`[!] parameter that specifies the block height of the best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) to assume the state of
+5.1       | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height minus one.


Suggested change

5.1 | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height minus one.

5.1 | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.

MariusVanDerWijden · 2021-04-26T06:04:17Z

json-rpc/eth_call.md

+4.5.1.2.2 | `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for transfer: address {from} (supplied gas {gas || 25000000[!]})` if the `value` input parameter is greater than 0 AND the `from` input parameter is equal to `null`[!]
+5         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its second item (index = 1) containing a `Block Identifier`[!] parameter that specifies the block height of the best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) to assume the state of
+5.1       | `eth_call` MUST assume the on-chain state of the latest best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "latest"; the latest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height minus one.
+5.2       | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf))  if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.


Suggested change

5.2 | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.

5.2 | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height plus a block with the best pending transactions.

MicahZoltu · 2021-04-26T06:10:12Z

json-rpc/eth_call.md

+Specification | Description 
+--|--
+1         | `eth_call` MUST NOT affect on-chain state|
+2         | `eth_call` MUST NOT accept requests that are not in valid JSON format


I think this is implicit, since the RPC is JSON-RPC so it is unnecessary to repeat it here. Similar to how we don't specify how TCP or HTTP works in this specification as it is handled at the transport layer.

MicahZoltu · 2021-04-26T06:10:40Z

json-rpc/eth_call.md

+--|--
+1         | `eth_call` MUST NOT affect on-chain state|
+2         | `eth_call` MUST NOT accept requests that are not in valid JSON format
+3         | `eth_call` MUST return a response in valid JSON format


Same as above, this is redundant with JSON-RPC specification.

MicahZoltu · 2021-04-26T06:16:58Z

json-rpc/eth_call.md

+2         | `eth_call` MUST NOT accept requests that are not in valid JSON format
+3         | `eth_call` MUST return a response in valid JSON format
+4         | `eth_call` MUST accept a `params` parameter [JSON Array](https://tools.ietf.org/html/rfc7159#section-5) of length 2, and its first item containing a [JSON Object](https://tools.ietf.org/html/rfc7159#section-4) with keys known here as the `input parameters`
+4.1       | `eth_call` MUST accept an input parameter `from` of type `DATA` [!]


It appears the specification is worded with a target audience of server developers in mind. This API is bi-directional and this document is likely to be read by both client developers and server developers. In this case, the from property is optional but this line makes it sound like it is required if you are reading from the point of view of a client. Consider trying to phrase things in this document in a way that is neutral to whether the reader is a server or client developer.

The from property is optional, but if present its type MUST be 20 byte DATA.

MicahZoltu · 2021-04-26T06:19:11Z

json-rpc/eth_call.md

+4.1.2.1.1 | `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
+4.1.2.2   | `eth_call` MUST NOT accept `from` hex strings with invalid characters


As mentioned above, I think parsing errors like this should be generalized at a higher layer, otherwise we'll have to re-specify them over and over again. We should define an ADDRESS type for the JSON-RPC protocol and define how parsing errors should be handled in a top level spec, then in the individual specs like this one we can just say "from MUST be of type ADDRESS and not have to specify all of the details of what that means.

lightclient · 2021-04-26T21:08:25Z

This is just a general comment, but I think the way this spec is laid out is really verbose. I think it would be helpful to discuss things in terms of the inputs and outputs. The JSON-RPC spec sort of does this: https://www.jsonrpc.org/specification

alita-moore · 2021-04-29T07:09:04Z

@lightclient from the perspective of requirement definition, it's important to be very clear. While verbose, it also minimizes ambiguity. Which, is the goal of the specification. It's not necessarily meant to be readable by anyone other than someone implementing a JSON RPC. At least that's how I understand the task, but I'm happy to reconsider the approach of course.

ryanschneider · 2021-05-10T00:36:19Z

json-rpc/eth_call.md

+5.2       | `eth_call` MUST assume the on-chain state of the current best block with the greatest height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf))  if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "pending"; the pending best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to the current best block height.
+5.3       | `eth_call` MUST assume the on-chain state of the genesis best block ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) if the `Block Identifier` parameter is equal to the [JSON String](https://tools.ietf.org/html/rfc7159#section-7) of "earliest"; the earliest best block height ([yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)) is equal to 0.
+5.4       | `eth_call` MUST assume the on-chain state of the best blockchain block with height equal to the `Quantity`[!] value of the `Block Identifier` parameter if the `Block Identifier` parameter is equal to a hex encoded `Quantity`[!] value. Height is equal to the number of blocks after the genesis block on the best blockchain (block number).
+5.5       | `eth_call` SHOULD throw exception `-32602` [1] with message `invalid argument 1: hex string without 0x prefix` if the provided `Block Identifier` parameter is neither a [JSON String](https://tools.ietf.org/html/rfc7159#section-7) value equal to `earliest`, `latest`, `pending` nor a hex encoded `Quantity`[!] value.


EIP-1898 allows more block identifiers such as the block hash.

timbeiko · 2021-06-02T15:56:45Z

Is this PR still relevant, @alita-moore ?

SamWilsn · 2021-08-11T14:35:06Z

Should be migrated to https://github.com/ethereum/eth1.0-apis

* chore: add grammar check automation files * docs: fix grammar in consume plugin files (#20) Fix grammar issues in consume plugin docstrings and comments: - "A dictionary caches" -> "A dictionary that caches" (missing "that") - "Definers" -> "Defines" (typo) - "Un-expected" -> "Unexpected" (incorrect hyphenation) - "older version" -> "older versions" (subject-verb agreement) Co-authored-by: Claude <noreply@anthropic.com> * chore(docs): fix grammar in filler plugin docstrings (#21) - Fix subject-verb agreement: "The forks is" -> "The fork is" - Fix preposition: "value to each" -> "value for each" - Fix sentence structure: "(which) ... occurs" -> ", which ... that occurs" Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in execute plugin files (#22) - Fix "using in live networks" -> "on live networks" (execute.py:2) - Fix missing spaces between concatenated help strings in execute.py - Fix "using for test filling" -> "used for test filling" (pre_alloc.py:1) - Fix missing spaces in concatenated help strings in remote.py Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in forks, shared, and help plugin files (#23) Fixed 9 grammar issues: - forks/__init__.py: Added missing "and" in docstring - forks/forks.py: Fixed "ran" -> "run" (passive voice) - forks/forks.py: Removed space in URL fragment - forks/forks.py: Fixed double "any any" -> "any" - test_bad_command_line_options.py: Fixed article/noun agreement - test_bad_validity_markers.py: Fixed article/noun agreement - shared/helpers.py: Fixed verb tense for parallel structure - shared/execute_fill.py: Added missing article "A" - help/help.py: Fixed double article "the a" -> "a" Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in pytest_commands/plugins root files (#24) Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in cli/pytest_commands root files (#25) Remove extra space after newline in watcher.py watch mode message. Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in cli/gentest and cli/fuzzer_bridge (#26) - Fix article "An provider" → "A provider" (test_context_providers.py) - Fix subject-verb agreement "generates" → "generate" (test_providers.py) - Add missing preposition "for" in "A request manager for Ethereum RPC calls" (request_manager.py) Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in cli/eest, cli/input, and cli/fillerconvert (#27) * docs: fix grammar in cli/eest, cli/input, and cli/fillerconvert Fix missing space in string concatenation in quotes.py where "that" and "experience" were joined without a space. Flag one low-confidence issue in verify_filled.py for manual review regarding informal verb usage. * docs: apply manual grammar fix in verify_filled.py Improve docstring clarity by: - Adding missing articles ("the original", "the refilled test") - Replacing informal "Regex" verb with "Extract" - Reformatting for better readability --------- Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in packages/testing/src/execution_testing/cli/*.py (#28) - gen_index.py: Add missing space between sentences in help text - modify_static_test_gas_limits.py: Remove duplicate word "files files" - tox_helpers.py: Remove extra space in error message - show_pre_alloc_group_stats.py: Fix capitalization mid-sentence Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in packages/testing/src/execution_testing/cli/tests (#29) - Fix "allows to actually fill" → "allows actually filling" (missing verb form) - Fix "uses the a temporary" → "uses a temporary" (double article) Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in test_types module (#30) - Fix double space in helpers.py docstring - Complete incomplete sentence in trie.py module docstring Co-authored-by: Claude <noreply@anthropic.com> * docs: grammar check specs module (round 12) (#31) Reviewed 28 files in packages/testing/src/execution_testing/specs/**/*.py for grammar issues. Fixed 1 grammar issue: - blockchain.py:167-168 - fixed sentence fragment "encoding. included" Co-authored-by: Claude <noreply@anthropic.com> * docs: grammar check round 13 (fixtures + client_clis) (#32) Reviewed packages/testing/src/execution_testing/fixtures/**/*.py (16 files) - No grammar issues found Reviewed packages/testing/src/execution_testing/client_clis/**/*.py (20 files) Fixed 4 grammar issues: - ethereum_cli.py:158 - Added missing space after "0!" - evmone.py:207 - "an select" -> "and select" - nethermind.py:209 - "an select" -> "and select" - geth.py:383 - "an select" -> "and select" Flagged 1 item for manual review: - clis/__init__.py:1 - "CL interfaces" may be typo for "CLI interfaces" Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in base_types module (#33) - Fix "it can added" -> "it can be added" in mixins.py - Fix "and returns" -> "and return" for consistent imperative form in composite_types.py - Fix "an hexadecimal numbers" -> "hexadecimal numbers" in base_types.py Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in forks module (#34) base_fork.py: - precompiles(): "Return list precompiles" -> "Return list of precompiles" - system_contracts(): "Return list system-contracts" -> "Return list of system contracts" forks/forks/forks.py: - Standardize "pre-compiles" -> "precompiles" (no hyphen) in: - Frontier.precompiles() - Homestead.precompiles() - Byzantium.precompiles() - Istanbul.precompiles() - Cancun.precompiles() - Prague.precompiles() - Osaka.precompiles() - Standardize "system-contracts" -> "system contracts" in Frontier.system_contracts() - Fix subject-verb agreement: "pre-compile for BLS operations are" -> "precompiles for BLS operations are" - Fix max_initcode_size(): merge standalone string into docstring with proper formatting - Add missing article "a" before "precompile for" in Istanbul, Cancun, and Osaka Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in tools and exceptions modules (#35) Fix typos and grammar issues: - Fix "defniitions" -> "definitions" in engine_api.py - Fix "it's" -> "its" (possessive) in eof.py and exceptions.py - Fix "an stack" -> "a stack" for underflow/overflow in eof.py and exceptions.py Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in vm, rpc, and config modules (#36) Remove duplicate text in error message in opcodes.py Co-authored-by: Claude <noreply@anthropic.com> * docs: fix grammar in execution_testing core modules (logging, execution, checklists, benchmark) and root files (#37) Fixed "were request" -> "were requested" in blob_transaction.py comment. Co-authored-by: Claude <noreply@anthropic.com> * docs: fix docstring in client_clis module Corrected terminology from "CL interfaces" to "EL clients" - these are Execution Layer client implementations, not Consensus Layer. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * docs: fix grammar in exceptions module - block.py: "is calculated incorrect" → "is calculated incorrectly" - transaction.py: "is exceeds" → "exceeds" (removed double verb) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * docs: fix punctuation in checklists module Changed period to colon in DataPortionVariables docstring to properly introduce the list of test cases (Top, Bottom, Middle). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * chore: remove files used for llm automation --------- Co-authored-by: Claude <noreply@anthropic.com>

alita-moore added 3 commits April 26, 2021 00:10

add sepcifications

aa646be

rfc-2119

b4e7116

Update eth_call.md

ffd3b4e

alita-moore mentioned this pull request Apr 26, 2021

eth_blockNumber #27

Closed

alita-moore added 5 commits April 26, 2021 00:39

reformat

6ac6270

Merge branch 'eth_call' of https://github.com/alita-moore/eth1.0-specs …

b2f8d15

…into eth_call

move rfc

998b5b7

fix headers

b24905c

capitalize column headers

e22a860

MariusVanDerWijden suggested changes Apr 26, 2021

View reviewed changes

MicahZoltu reviewed Apr 26, 2021

View reviewed changes

ryanschneider reviewed May 10, 2021

View reviewed changes

alita-moore mentioned this pull request May 19, 2021

eth_call #62

Closed

alcuadrado mentioned this pull request Jun 9, 2021

WTF NomicFoundation/hardhat-boilerplate#9

Closed

SamWilsn added the A-spec-rpc Area: Specification JSON RPC label Aug 5, 2021

SamWilsn closed this Aug 11, 2021

MansurovB-source mentioned this pull request Sep 3, 2021

Support various eth_call invocations post 1559 NethermindEth/nethermind#3317

Closed

12 tasks

	4.1.1.1 \| `eth_call` MUST consider CALLER account to be `0x0000000000000000000000000000000000000000000000000000000000000000` if `from` is not defined
	4.1.1.1 \| `eth_call` MUST consider CALLER account to be `0x000000000000000000000000000000000000000` if `from` is not defined

	4.1.2.3 \| `eth_call` MUST consider CALLER account to equal a 32 byte hex string [!] of the `from` parameter
	4.1.2.3 \| `eth_call` MUST consider CALLER account to equal a 20 byte hex string [!] of the `from` parameter

	4.4.2.2 \| `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address 0x0000000000000000000000000000000000000000 have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null
	4.4.2.2 \| `eth_call` SHOULD throw exception `-32000` with message `err: insufficient funds for gas * price + value: address {from} have 0 want {gas * gasPrice + value} (supplied gas {gas})` if the `gasPrice` input parameter multiplied by `gas` input parameter added to `value` input paremeter are greater than 0 and the `from` input parameter is equal to null

		4.1.2.1.1 \| `eth_call` SHOULD throw error `-32602` [!] on improper length with message as `invalid argument 0: hex string has length {length}, want 40 for common.Address`
		4.1.2.2 \| `eth_call` MUST NOT accept `from` hex strings with invalid characters

eth_call #35

eth_call #35

Uh oh!

Conversation

alita-moore commented Apr 26, 2021

Uh oh!

MariusVanDerWijden left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lightclient commented Apr 26, 2021

Uh oh!

alita-moore commented Apr 29, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

timbeiko commented Jun 2, 2021

Uh oh!

SamWilsn commented Aug 11, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants