API eth_sign properties

This is more of a design choice, but was there a reason we decided to implement eth_sign as such: https://github.com/aionnetwork/aion/blob/843761824132b2dfe2a6e8dbc5b755167f571718/modApiServer/src/org/aion/api/server/rpc/ApiWeb3Aion.java#L614-L636

Functionally it works, but the use of keccak256 when we (probably?) use blake2b elsewhere doesn’t make sense. I vote we switch to blake2b because:

• There are no compatibility issues, the VM does not support either hashing algorithm right now
• It’s more consistent with what developers and users expect when using Aion

For context, I stumbled on this adding the offline signing feature for aion-keystore

[ali-sharif]

I vote to completely remove eth_sign from the json rpc api. It’s confusing, since people think this function let’s you sign a raw transaction (which it doesn’t) and most people don’t know about the payload signature scheme to validate random data (which this endpoint was designed for)

[AionJayT]

the aion web3 support the sign feature.