Support signing typed data

[davidyuk]

closes #1781

found issues aeternity/aepp-calldata-js#215 aeternity/aepp-calldata-js#216 aeternity/aesophia#461

This PR is supported by the Æternity Crypto Foundation

[codecov]

Codecov Report

Patch coverage: 78.57% and project coverage change: +0.03 🎉

Comparison is base (b14fe12) 82.38% compared to head (cf8365f) 82.41%.

❗ Current head cf8365f differs from pull request most recent head 03e54bc. Consider uploading reports for the commit 03e54bc to get more accurate results

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1843      +/-   ##
===========================================
+ Coverage    82.38%   82.41%   +0.03%     
===========================================
  Files           93       94       +1     
  Lines         3252     3292      +40     
  Branches       648      655       +7     
===========================================
+ Hits          2679     2713      +34     
- Misses         267      269       +2     
- Partials       306      310       +4     

Impacted Files	Coverage Δ
src/account/Base.ts	100.00% <ø> (ø)
src/account/Generalized.ts	62.50% <0.00%> (-2.02%)	⬇️
src/account/Ledger.ts	76.11% <0.00%> (-1.16%)	⬇️
src/aepp-wallet-communication/rpc/types.ts	100.00% <ø> (ø)
src/aepp-wallet-communication/schema.ts	88.46% <ø> (ø)
src/AeSdkWallet.ts	81.30% <42.85%> (-2.70%)	⬇️
src/account/Rpc.ts	68.42% <66.66%> (-0.33%)	⬇️
src/account/Memory.ts	88.23% <80.00%> (-1.42%)	⬇️
src/utils/typed-data.ts	94.44% <94.44%> (ø)
src/AeSdkBase.ts	80.43% <100.00%> (+0.88%)	⬆️
... and 2 more

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[davidyuk]

Should prefix the calculated hash with a magic number? I see that Ethereum developers care to have not overlapped signing payloads for transactions and other messages, but I don't understand the reasoning. For example,

The initial 0x19 byte is intended to ensure that the signed_data is not valid RLP

https://eips.ethereum.org/EIPS/eip-191

[hanssv]

Yes I think there should be a prefix, though maybe not 0x19 since that was chosen because Ethereum Signed Message: happens to be 0x19 bytes long...

[davidyuk]

I propose to define 0x1a00 prefix, with the second byte as a signature type (0x00 for typed data). E.g. 0x1a61 would be a prefix of a signed message the same as in EIP-191. This won't overlap with transaction signatures because they are prefixed with network id that can't contain ASCII control characters (0x1a, substitute).