Use array-bytes for array/bytes/hex operations

[aurexav]

Reasons: paritytech/substrate#12111
Substrate PR: paritytech/substrate#12190

[aurexav]

As you can see, it has some really friendly APIs.

And it will handle the "0x" prefix and errors.

[acatangiu]

Looks ok to me, but it is incomplete (good to merge once it passes CI)

[aurexav]

Looks ok to me, but it is incomplete (good to merge once it passes CI)

Fixed. And it looks like there are some new errors in your CI script.

[aurexav]

And I made some algorithm optimization these days.

Check the benchmark results here.
https://github.com/hack-ink/array-bytes#benchmark-results

Not only it has blockchain-developer-friendly API.

I think it's also 1.2x ~ 4x faster than the hex crate.

[aurexav]

Hi! Any plan for this?

[acatangiu]

Can you resolve the merge conflict?
@ordian wanna also take a look?

[ordian]

I've taken a look before and remained unconvinced.

One of the benefits advertized:

And it's completely no-std.

We could also use rustc-hex without it's std feature and call it completely no-std this way.

By switfly looking at https://github.com/hack-ink/array-bytes/blob/main/src/lib.rs I see a few problems:

1. It's using unidiomatic function naming: https://rust-lang.github.io/api-guidelines/naming.html
2. Unwraps and safe unchecked methods.
3. It's not audited.

So what's the benefit, really?

[ordian]

^^^

[aurexav]

I've taken a look before and remained unconvinced.

One of the benefits advertized:

And it's completely no-std.

We could also use rustc-hex without it's std feature and call it completely no-std this way.

By switfly looking at https://github.com/hack-ink/array-bytes/blob/main/src/lib.rs I see a few problems:

1. It's using unidiomatic function naming: https://rust-lang.github.io/api-guidelines/naming.html
2. Unwraps and safe unchecked methods.
3. It's not audited.

So what's the benefit, really?

1. IMHO, the API is much easier to understand: x2y.
2. It did provide some unchecked functions, but to use it, it's totally up to you. Maybe you are writing some off-chain tools or unit tests, then you might want to get rid of the Result.
3. True. But I'd love to push this.
   1. It has fuzzy tests.
   2. It was used by Substrate.
4. It's faster than rust-hex.
5. It handles the 0x prefix.
6. And it provides some *_into functions which are pretty convenient/handy for Substrate/blockchain development.
7. Also, some serde support.

For me, I want to bring these to other blockchain developers.

It's really an honor and a good example to be a part of the parity-common (one of the most frequently used blockchain library).

Would you consider this?