Skip to content

[TM-81] Support tz2 and tz3 address

Ivan Gromakovskii requested to merge gromak/tm81-crypto-curves into master

Description

Problem: Tezos has three types of public key addresses: tz1, tz2 and tz3 addresses. All of them store public key hashes:

  • tz1 addresses store hash of ed25519 public key.
  • tz2 addresses store hash of secp256k1 public key.
  • tz3 addresses store hash of P256 public key. Currently we support only ed25519 crypto primitives and tz1 addresses (apart from contract addresses). It is bad because we fail to work with some valid addresses, keys, signatures.

Solution:

  1. We used to have single Crypto.hs for all the crypto present in Tezos (well, not in Tezos, but in our simplified model of Tezos). Now we have one module per curve, one module for hashing, one utility module. On top of that we have Crypto.hs module with primitives that are not specific to a particular curve. Usually one should use Crypto.hs directly, but in some cases functions of particular curve should be used.
  2. I have spent quite a lot of time to properly support all required crypto operations, but haven't succeeded yet. At this point we mostly care about serialization and don't care about CHECK_SIGNATURE operation. So:
  • secp256k1 is mostly implemented, except for decoding. I've asked about it here: https://github.com/haskell-crypto/cryptonite/issues/302 Also it may work incorrectly, so it should be tested carefully (I can't test it against reference implementation without decoding). I've added a hack to make it work fine with serialization: we store optional bytestring inside, so that decode . encode === id holds.
  • p256 is implemented in absolutely stupid way: it only carries bytestrings and signature check always fails. But decode . encode === id holds and that's all we want. Since the commit si already quite large and the issue is quite urgent, I've decided to deal with it in a separate issue later: #18 (closed)
  1. Address.hs didn't change at all, because all necessary changes are handled by KeyHash.

Related issue(s)

https://issues.serokell.io/issue/TM-81

✅ Checklist for your Merge Request

Related changes (conditional)

  • Tests (see short guidelines)

    • If I added new functionality, I added tests covering it.
    • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

  • Documentation

    • I checked whether I should update the docs and did so if necessary:

Stylistic guide (mandatory)

Edited by Ivan Gromakovskii

Merge request reports