Is it possible to encode uint256 values? If so, how would I achieve this? Thank you.

just tried to clone a TopicFilter and now i need to manually do it

let me know and i'll create a PR

currently it is:

fn foo<T0: Into<Uint>, T1: Into<Vec<Address>>>(
    &self, 
    n: T0, 
    a: T1
) -> Bytes

instead it should be:

fn foo<T0: Into<Uint>, T1: Into<Address>>(
    &self, 
    n: T0, 
    a: Vec<T1>
) -> Bytes

@tomusdrw do you agree❓

I've tested this now on two machines (Ubuntu 16.10 and Bash on Windows). Also tested by someone else on a Mac.

nanexcool@aurora-VirtualBox:~/utils/ethabi$ ./target/release/ethabi encode params -v bool 1
nanexcool@aurora-VirtualBox:~/utils/ethabi$

If I git checkout 3b7284b then it works...

nanexcool@aurora-VirtualBox:~/utils/ethabi$ ./target/release/ethabi encode params -v bool 1
0000000000000000000000000000000000000000000000000000000000000001
nanexcool@aurora-VirtualBox:~/utils/ethabi$

ContractFunction::output takes a Vec<u8>:

https://github.com/paritytech/ethabi/blob/7b9cca375986b948d84530442d6bd27d480b24c8/ethabi/src/lib.rs#L76

it could easily take a &[u8] which would make it more general and prevent cloning in many cases.

concrete example:
in sol-rs i have a evm::ReturnData which dereferences without any copy to a &[u8].
in order to pass it into ContractFunction::output i currently need to call .to_vec()...

I am using ethabi library and I don't succeed to encode negative parameters for "int" Solidity type. Is there a way to do this? Thank you.

the runtime parsing happens here:

https://github.com/paritytech/ethabi/blob/75c2d9b18d61dcc41b0dcbea137ba62e36984713/derive/src/lib.rs#L119-L126

same as in paritytech/jsonrpc#222

When I am trying to encode big uint256 value I got this error

Cannot parse uint256

Caused by:
  number too large to fit in target type

I'am trying to do

ethabi encode function abi.json mint -p f3eb3b7d01416d22fdc051c313af5634afac316e -p 10000000000 --lenient

or simply

ethabi encode params -v uint256 10000000000 --lenient

If I trying to encode smaller number like 1000 it works fine (up to 10 ** 9) but starting from 10 ** 10 it raises error. Why? uint256 can store values up to 2 ** 256 - 1 as I understand

Is it a bug or I am using ethabi incorrectly?

This is useful for Rust codegen over ABIs.
Perhaps using heck?

starting from ethabi 2.0, token type_check is too strict. it should be less strict to guarantee backwards compatibility with version 1.x.

Hey,
We need to bump the version number in order to get rid of the old version of error-chain in parity!

│   ├── ethabi v5.1.1
│   │   [dependencies]
│   │   ├── error-chain v0.11.0
│   │   │   [dependencies]
│   │   │   └── backtrace v0.3.5 (*)
│   │   ├── ethereum-types v0.3.2 (*)
│   │   ├── rustc-hex v1.0.0 (*)
│   │   ├── serde v1.0.37 (*)
│   │   ├── serde_derive v1.0.37 (*)
│   │   ├── serde_json v1.0.9 (*)
│   │   └── tiny-keccak v1.4.2 (*)

More details: https://github.com/ethcore/parity/issues/4122#issue-199917015

It would probably be faster to put ops in a hash map (maybe even a PHF map) by name and look them up in O(1) time.

See https://solidity.readthedocs.io/en/develop/abi-spec.html#types

Ran across this as part of openethereum/parity-ethereum#7162. The casper contract is written in vyper and uses the decimal type. In the abi generated by the vyper compiler it is aliased as decimal10.

However there is an ongoing discussion going on to instead use a fixed<M>x<N> type instead (specifically fixed168x10).

PR in eth-abi (python)

Hey guys, do you support the experimental ABIEncoderV2?

That would allow passing arrays and structs as Solidity function parameters.

Thanks!

Solidity contracts can of course use contracts as parameters.

igloo:~*$ ethabi encode params -v address 4444444444444444444444444444444444444444
0000000000000000000000004444444444444444444444444444444444444444
igloo:~*$ ethabi encode params -v MyContract 4444444444444444444444444444444444444444
error: Param(InvalidType)

Would it be reasonable to just interpret any type starting with a capital letter as being synonymous with address? Otherwise I'll have to mogrify my abi JSON and do that substitution myself.

Error: No available formula with the name "multirust" (dependency of paritytech/paritytech/ethabi)

ethabi encode params -v uint256 200000000000000000000 -v uint256 200000000000000000 -v uint256 2713998 -v 2813898
thread 'main' panicked at 'assertion failed: (left == right) (left: 4, right: 3)', /Users/rstorm/.cargo/registry/src/github.com-1ecc6299db9ec823/ethabi-cli-2.0.1/src/main.rs:135
note: Run with RUST_BACKTRACE=1 for a backtrace.

...along with a switch to quote for codegen and breaking dependency on ethcore-util. This will ease the transition to procedural-macro based native contract wrappers when macros are more evolved.

The hard part is abstracting over functions that return lists of items: we have some contracts that return a Vec<Address> currently, and returning a Vec<[u8; 20]> instead would break compatibility and require us to reallocate when converting. FromIterator<[u8; 20]> could be used, but there's no implementation of FromIterator<T> for Vec<U> where U: From<T> (at least until specialization stabilizes), so we'd have to write wrapper types in Parity.

Trying this

$ ethabi encode function out/datafeeds/DataFeed.abi update -p [] [] -l 
# expects address[], followed by uint[]

I get

Cannot parse address[]

Caused by:
  Cannot parse address

Caused by:
  Invalid data

• Contract code

• ABI that I used

Note that:

# this seems to work
$ ethabi encode function out/datafeeds/DataFeed.abi update -p \
  [00248d782b4c27b5c6f42feb3f36918c24b211a5] [2] -l

2c10e90c00000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000248d782b4c27b5c6f42feb3f36918c24b211a500000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000002

the documentation should be placed above ethabi encode and decode functions

related #69

tests for issue fixed in #71

related https://github.com/paritytech/ethabi/pull/62#issuecomment-341708679

https://github.com/paritytech/ethabi/blob/master/cli/src/main.rs#L221

It shouldn't require nearly as many allocations as it currently does in order to get the param types and tokens.

(via https://github.com/paritytech/ethabi/issues/79#issuecomment-368421077)

https://github.com/paritytech/ethabi/blob/master/cli/src/main.rs#L81
.deserialize() takes abnormally long to compute; computing time grows exponentially with number of arguments

ethabi encode params --lenient -v uint256 1 -v uint256 1 -v uint256 1 -v uint256 1

# hangs a couple seconds on .deserialize()

ethabi encode params --lenient -v uint256 1 -v uint256 1 -v uint256 1 -v uint256 1 -v uint256 1

# hangs with 100% cpu and a lot of memory usage for at least several minutes (had to kill the process)

Looks unresolved in #70 as well

$ brew install ethabi
==> Installing ethabi from paritytech/paritytech
==> Cloning https://github.com/paritytech/ethabi.git
Updating ~/Library/Caches/Homebrew/ethabi--git
==> Checking out branch master
==> rustup update stable
Last 15 lines from ~/Library/Logs/Homebrew/ethabi/01.rustup:
2018-05-27 09:35:15 -0400

rustup update stable


If reporting this issue please do so at (not Homebrew/brew or Homebrew/core):
https://github.com/paritytech/homebrew-paritytech/issues

$ ethabi
-bash: ethabi: command not found

ran into this while working on sol-rs. also see my comment there openethereum/sol-rs#31 (comment)

there's a solidity function that returns an address:
https://github.com/paritytech/sol-rs/blob/2053fe1d805dc2eb5d43abf8de81abe1a401fcb4/tests/contracts/test.sol#L2

ethabi generates to correct return type Address for Outputs:

though for the generated *WithInput type the Output is () which is incorrect:

@axelchalon would be great if you could have a look since you're more familiar with the code involved. let me know in case you want me to dig in myself

i find the name ContractFunction misleading.
the trait is not implemented by contract functions but rather by types representing the encoded inputs.

how about renaming it to EncodedInputs?

https://github.com/paritytech/ethabi/pull/85#issuecomment-393501097

additionally i find the function name ContractFunction::output misleading.
it doesn't return an output, as one could easily assume, it decodes the output.

can we rename it to decode_output?

ContractFunction::encoded is fine. i'd find ContractFunction::encoded_input a bit more descriptive

brew tap paritytech/paritytech && brew install ethabi always not install .
and cargo install ethabi-cli will cause
error: failed to compile ethabi-cli v4.0.0, intermediate artifacts can be found at /var/folders/z_/kgzp56mj0hz5skx2q_vrvyzm0000gn/T/cargo-install.PK2PFRGy2U11
To learn more, run the command again with --verbose.

this is more a nitpick but something that's personally bugging me every time i use ethabi.

ethabi aliases a bunch of types:
https://github.com/paritytech/ethabi/blob/7b9cca375986b948d84530442d6bd27d480b24c8/ethabi/src/lib.rs#L56

among them type Bytes = Vec<u8>;
every time i come back to ethabi after a while i assume that Bytes is something special only to find that it's a plain and simple Vec<u8>. i'd like for me and others to get rid of this surprise.
(this is made worse when using ethabi with rust-web3 (common case) which also has a Bytes type which is just a pub struct Bytes(pub Vec<u8>))

similarly type Hash = ethereum_types::H256;. using many crates that use H256 i've become pretty accustomed to seeing/using it. seeing Hash breaks that familiarity. i find that it's unnecessary indirection.

i'd prefer to get rid of these indirections unless they add something crucial i'm missing.
i understand that using the aliases it's possible to exchange the actual types without having to do renames in consuming code. i'd argue renaming is the least work required (easily automated) in changing the actual type implementations.

as i said it's nitpicky and might just annoy me personally.
what are your thoughts?

Solidity events (non-anonymous) include the Keccak hash of the event signature as part of the first topic.

ethabi doesn't verify that decoded log entries actually match the provided event signature.

As far as I can tell, we only need to verify signature(name, params) == topics.get(0).unwrap().0[0..4].

I've done that in my own program outside ethabi, but it seems to me like ethabi should do this as part of the event decoder.

To avoid a breaking change, we could also expose a separate method for verifying the event interface.

If you agree, I could work on it early next week. If not, my own code is already working, so no worries. :)

Basically make this test work.

Using web3 version 0.1.0 and ethabi verion 4.0.0/4.2.0.

Traced back error message form rust-web3 to ethabi (received the same result from ethabi-cli):

Message("Error(InvalidName(\"DLL.Data storage\"), State { next_error: None, backtrace: None })")

DLL.abi throws InvalidName due to the following snippet from the JSON file:

{
		"constant": true,
		"inputs": [
			{
				"name": "self",
				"type": "DLL.Data storage"
			},
			{
				"name": "_curr",
				"type": "uint256"
			}
		],
		"name": "getNext",
		"outputs": [
			{
				"name": "",
				"type": "uint256"
			}
		],
		"payable": false,
		"stateMutability": "view",
		"type": "function"
	}

It seems like it cannot handle "type" being DLL.Data storage. Once changed to a different type such as uint256, error subsides.

DLL.abi.txt
DLL.bin.txt
DLL.sol.txt

Update from this repo on windows causes the error:
Cargo update failed on Windows because of 'res/con.abi'
It's because of the file name 'con'. On Windows you can't name the file like this.
So, could you please rename the file?

ubuntu install ethab-eth is failed/
logs:
error: struct field shorthands are unstable (see issue #37340)
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/ethabi-2.0.0/src/contract.rs:41:13
|
41 | constructor,
| ^^^^^^^^^^^

error: struct field shorthands are unstable (see issue #37340)
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/ethabi-2.0.0/src/contract.rs:42:13
|
42 | events,
| ^^^^^^

error: struct field shorthands are unstable (see issue #37340)
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/ethabi-2.0.0/src/contract.rs:43:13
|
43 | functions,
| ^^^^^^^^^

error: aborting due to 3 previous errors

error: failed to compile ethabi-cli v2.0.1, intermediate artifacts can be found at /tmp/cargo-install.LdT7tF0eMvCF

Caused by:
Could not compile ethabi.

how to continue....compile

Currently the provided function arguments (tokens) are not validated against the function interface. An error should be returned if the types of the provided arguments do not match the interface.

What's the correct way to decode an anonymous event using ethabi?

I'm trying

ethabi decode log ./note.json LogNote -l \
d8ccd0f300000000000000000000000000000000000000000000000000000000 -l \
0000000000000000000000006f2a8ee9452ba7d336b3fba03cac27f7818aead6 -l \
00000000000000000000000000000000000000000000005f14b0a748ca7a4b79 -l \
0000000000000000000000000000000000000000000000000000000000000000 \
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000024d8ccd0f300000000000000000000000000000000000000000000005f14b0a748ca7a4b79

where note.json is

[
  {
    "anonymous": true,
    "inputs": [
      {
        "indexed": true,
        "name": "sig",
        "type": "bytes4"
      },
      {
        "indexed": true,
        "name": "guy",
        "type": "address"
      },
      {
        "indexed": true,
        "name": "foo",
        "type": "bytes32"
      },
      {
        "indexed": true,
        "name": "bar",
        "type": "bytes32"
      },
      {
        "indexed": false,
        "name": "wad",
        "type": "uint256"
      },
      {
        "indexed": false,
        "name": "fax",
        "type": "bytes"
      }
    ],
    "name": "LogNote",
    "type": "event",
    "topic": "0x644843f351d3fba4abcd60109eaff9f54bac8fb8ccf0bab941009c21df21cf31"
  }
]

but I get Invalid data

while working on the bridge i found that using ethabi, web3 and tokio together results in a lot of boilerplate.

the call to fetch a signature for example is a one liner in nodejs (https://github.com/poanetwork/bridge-nodejs/blob/a23ecb78572f3e1928d9129eff8d4118b2618b57/src/processCollectedSignatures.js#L80)
and this in rust
https://github.com/paritytech/parity-bridge/blob/0090447e7768ff2b49cec13dd03a743b55444100/bridge/src/bridge/withdraw_relay.rs#L61,
https://github.com/paritytech/parity-bridge/blob/0090447e7768ff2b49cec13dd03a743b55444100/bridge/src/bridge/withdraw_relay.rs#L86
https://github.com/paritytech/parity-bridge/blob/0090447e7768ff2b49cec13dd03a743b55444100/bridge/src/bridge/withdraw_relay.rs#L184
https://github.com/paritytech/parity-bridge/blob/0090447e7768ff2b49cec13dd03a743b55444100/bridge/src/bridge/withdraw_relay.rs#L235

: /

in rust (with tokio) the input and output part concerned with one call
are far apart as they are separated by the async state machine.

when dealing with lots of calls and transactions this becomes hard to reuse spaghetti...

i started writing higher level wrappers around the auto generated (ethabi) contracts:
https://github.com/paritytech/parity-bridge/blob/snd-refactor/bridge/src/main_contract.rs
https://github.com/paritytech/parity-bridge/blob/snd-refactor/bridge/src/side_contract.rs

now code concerning a specific call is in one place, reusable and the relay code (using it) not cluttered with it:
https://github.com/paritytech/parity-bridge/blob/snd-refactor/bridge/src/main_to_side_sign.rs#L60

now the thought ocurred to me that we could automate (derive) this.

we could start by simply generating futures implementations for each call and transaction
that present an easy to use API similar to nodejs.

example:

let future = ForeignBridge::default()
    .functions()
    .has_authority_signed_side_to_main()
    .async(transport, contract_address, authority_address, message_hash);

// no manual calls to input and output
let has_signed: bool = try_ready!(future.poll());

(call would be nicer but is already taken by ethabi)

this would make it much easier in general to interact with contracts from rust with tokio.

@folsen @debris would love to hear your thoughts on this :)

should this be a feature gated part of ethabi (clutters ethabi) or a separate crate (needs access to intermediary data used by ethabi-derive)?

Hi,
I am having trouble getting response from ethabi

I have tried

1. cargo install (v1.0.0)
2. brew install (v0.2.0)
   and
   when I execute both bin files, the terminal recognise the command but nothing happens. Please could you let me know if this is a known issue?

Thanks!