...
This opens several security issues, and entails a sweeping change across the code-base, which we shall discuss below.
Technical details
Key pair versioning
We want:
- backwards compatibility. An account registered near genesis should still work 10-20 years later if the network is still up.
- the ability to add new key pair exchange/generation algorithms.
- a method for upgrading key pairs.
As a result, Iroha must support more than one set of algorithms, and more than one kind of storage for accounts.
The versioning could be done either
- by tying the account version to the API version.
- by versioning the account with the key type/exchange algorithm
The first option has the advantage of making full backwards compatibility explicit. A user who registered an account early doesn't need to update the client in order to work with the blockchain.
Address format
Regardless of which address format we (eventually) choose, the address must be derived from the public key.
- The easiest address to implement is exposing the full public key
- For security might prefer to expose a subset of the public key. If we use the first half of the bytes as the address, the probability of two accounts sharing an address is astronomically small (1 in 1024).
- For maximum compatibility with Substrate, we should choose the SS58 format.
Substrate compatibility
The SS58 format allows for secure transit of account data. As an added bonus, the accounts can be identified on different networks (because of the first byte) if we so choose.
Substrate-based networks typically use the same private key to generate multiple public keys. Specifically one is used in the substrate-based network, while the other is used in Ethereum networks. As such we should support three standards Sr25519,Ed25519 andsecp256k1.
We should also consider delineating in-code the difference between stash keys (which are attached to highly secure accounts with most if not all of an individual's assets) and controller keys.
The second option gives us more flexibility.
Account security upgrades
...
This process is either done by a single instruction, or explicitly with instructions for each step.
...
Using a new custom instruction
Pros:
- Encourages frequent security updates.
- Good user experience.
- Eliminates client error in forming the transaction.
- Technically easier to do than transferring each asset one by one.
...
- Complex.
- Adds ways to circumvent transaction fees in public blockchains.
...
Using explicit usage of pre-existing instructions
Pros:
- No extra tooling/permissions.
- Simple.
- Works well with the existing event infrastructure.
...
OPTIONAL: it may be worthwhile to add the option to revert a funds transfer if an account hadn't been claimed in a specified time period. At which point a smartcontract reverts the debit/credit and archives the account.
Key pair versioning (optional)
We want:
- backwards compatibility. An account registered near genesis should still work 10-20 years later if the network is still up.
- the ability to add new key pair exchange/generation algorithms.
- a method for upgrading key pairs.
As a result, Iroha must support more than one set of algorithms, and more than one kind of storage for accounts.
The versioning could be done either
- by tying the account version to the API version.
- by versioning the account with the key type/exchange algorithm
The first option has the advantage of making full backwards compatibility explicit. A user who registered an account early doesn't need to update the client in order to work with the blockchain.
The second option gives us more flexibility.