Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] ABI #26

Closed
wants to merge 7 commits into from
Closed

[WIP] ABI #26

wants to merge 7 commits into from

Conversation

mpapierski
Copy link
Contributor

@mpapierski mpapierski commented Sep 23, 2018

This is a WIP PR for adding ABI support in Clarity.

Reference: https://solidity.readthedocs.io/en/develop/abi-spec.html#abi-json

  • Parsing a Contract with "JSON ABI" (with custom validation of types)
  • Encoding function parameters
  • Constructors
  • Events

This introduces a separate "abi" module which will make it easier to structure the code, as ABI certainly needs a lot of different types.

This type holds information whether a specific item in JSON ABI is a
function, constructor, event, or a fallback.

It contains a custom deserialization method that validates possible set
of inputs.
@mpapierski mpapierski added this to In progress in Althea Development via automation Sep 23, 2018
The structure is made of items, and its very simple for now.
This getter is meant to be a "builder" kind of structure that will make
encoding input parameters easy.
@jkilpatr
Copy link
Member

@mpapierski why exactly don't we use Ethabi from parity?

@mpapierski
Copy link
Contributor Author

@mpapierski why exactly don't we use Ethabi from parity?

In guac the dependencies related to ethabi/parity/primitives/ethereum-types etc are very tangled and builds breaks often after cargo update, as you noticed it will be easiest to just expose helper functions in clarity to do the parameter padding and just do the encoding manually on guac. Also check out my reply on IM - I agree its not worth it to continue this PR for a full fledged encoder, nonetheless the knowledge is valuable and will make it faster to getting the contract calls to work.

@mpapierski
Copy link
Contributor Author

@ttk2 I'll just close this one for now, it might make sense at some point in future to continue it once we have a lot of contract calls and it will make our life easier. Instead, a simplier approach will be exposed based on helper functions to build the parameters 'manually' so we can push the payments with what we have.

Speaking of ethabi I was also curious if it works on MIPS properly, but I don't have confidence it will be safe to use it on MIPS:

failures:

---- encoder::tests::encode_int stdout ----
thread 'encoder::tests::encode_int' panicked at 'assertion failed: `(left == right)`
  left: `[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0]`,
 right: `[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4]`', ethabi/src/encoder.rs:455:3
note: Run with `RUST_BACKTRACE=1` for a backtrace.

---- encoder::tests::encode_uint stdout ----
thread 'encoder::tests::encode_uint' panicked at 'assertion failed: `(left == right)`
  left: `[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0, 0, 0]`,
 right: `[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4]`', ethabi/src/encoder.rs:446:3

---- function::tests::test_function_encode_call stdout ----
thread 'function::tests::test_function_encode_call' panicked at 'assertion failed: `(left == right)`
  left: `[184, 47, 19, 120, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]`,
 right: `[205, 205, 119, 192, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1]`', ethabi/src/function.rs:79:3

---- signature::tests::test_signature stdout ----
thread 'signature::tests::test_signature' panicked at 'assertion failed: `(left == right)`
  left: `[205, 205, 119, 192]`,
 right: `[184, 47, 19, 120]`', ethabi/src/signature.rs:38:3


failures:
    encoder::tests::encode_int
    encoder::tests::encode_uint
    function::tests::test_function_encode_call
    signature::tests::test_signature

test result: FAILED. 66 passed; 4 failed; 0 ignored; 0 measured; 0 filtered out

Ran with cross test --target mips-unknown-linux-gnu --all

@mpapierski mpapierski closed this Sep 26, 2018
Althea Development automation moved this from In progress to Done Sep 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants