Add `L1AddressOrAlias`
Clarification and motivation
At the moment, we have a AddressOrAlias kind
type, along with these two type synonyms:
type ImplicitAddressOrAlias = AddressOrAlias 'AddressKindImplicit
type ContractAddressOrAlias = AddressOrAlias 'AddressKindContract
This type is meant to be used to parse CLI options. When an option is supposed to take an address/alias of either a contract or an implicit account, we've taken the approach of splitting it in two options: one that parses an address/alias of a contract and another of an implicit account.
As an example, see the --to-implicit
and --to-contract
options in the morley executable.
The problem with this approach is that when your CLI has many such options (as is the case of stablecoin), doubling the number of options may make the tool harder to use than needed.
Ideally, we'd want to use a parser similar to tezos-client's. A rough description of its behavior:
- It is capable of parsing contract addresses, as well as implicit addresses.
- It is capable of parsing aliases:
- When both a contract and an implicit account exist with the same alias "some-alias":
- The user can use "key:some-alias" to unambiguously refer to the implicit account.
- The user can use "some-alias" to unambiguously refer to the contract.
- When only of them exists, then "some-alias" is already unambiguous.
- When both a contract and an implicit account exist with the same alias "some-alias":
However, tezos-client doesn't use this convention consistently across the board, which makes it error-prone (see previous discussions here and here).
-
tezos-client sign bytes
only accepts addresses/aliases of implicit accounts. For consistency with the other commands, it would make sense to acceptkey:some-alias
, but it doesn't, it fails with an error. -
tezos-client reveal key
also only accepts addresses/aliases of implicit accounts. There are 2 problems here:- As opposed to
sign bytes
, it does acceptkey:some-alias
. - When given a
some-alias
, ifsome-alias
is assigned to both a contract and an implicit account, one might reasonably expect the command to assume the alias refers to the implicit account, since that's the only valid option. However, it does the opposite; it assumes the alias refers to the contract and fails with:only implicit accounts can be revealed
.
- As opposed to
We've decided to take a more principled approach:
Options that accept addresses/aliases of either a contract or an implicit account will accept the following inputs:
- "KT1STb2aG7NpoBBNRggvummqsxNQZmuAVFvG": an address belonging to a contract
- "tz1hZ7o4bhFTo6AXpWZsXzbnddEK3dSCv1S8": an address belonging to an implicit account
- "contract:some-alias": an alias that is expected to be associated with a contract.
- If it's associated with an implicit account,
resolveAddress
will fail. - If it's associated with both a contract and an implicit account,
resolveAddress
will return the contract address.
- If it's associated with an implicit account,
- "implicit:some-alias": an alias that is expected to be associated with an implicit account.
- If it's associated with a contract,
resolveAddress
will fail. - If it's associated with both a contract and an implicit account,
resolveAddress
will return the implicit account address.
- If it's associated with a contract,
- "some-alias": an alias that is expected to be associated with either a contract or an implicit account.
- If it's associated with both a contract and an implicit account,
resolveAddress
will fail.
- If it's associated with both a contract and an implicit account,
Options that accept addresses/aliases of implicit accounts only:
- "tz1hZ7o4bhFTo6AXpWZsXzbnddEK3dSCv1S8": an address belonging to an implicit account.
- "implicit:some-alias" or "some-alias": an alias that is expected to be associated with an implicit account.
- If it's associated with a contract,
resolveAddress
will fail. - If it's associated with both a contract and an implicit account,
resolveAddress
will return the implicit account address.
- If it's associated with a contract,
Options that accept addresses/aliases of contracts only: similar strategy as the above.
Acceptance criteria
- We have 3 "address or alias" types:
ContractAddressOrAlias
,ImplicitAddressOrAlias
,L1AddressOrAlias
- Their CLI parsers and
resolveAddress
behave according to the spec above.
UPDATE: !1260 (merged) addressed the points above; one issue remains to be addressed in a separate MR: getAlias
needs to be overloaded to also work on SomeAddressOrAlias
, similar to resolveAddress
. We also need to add tests for getAlias
.