Archethic network through the usage of TransactionChains is leveraging an adaptative and quantum-safe cryptography.
Non-Discolure of public keys
Archethic TransactionChains uses a non-disclosure mechanism of public keys using chains of cryptography. Each transaction contains an address, which is a hash of the next public key and the previous public key. Therefore, we don't have way to know which public key is used for a given transaction until a next one is coming.
In order to build a transaction, we need to known multiple temporary private keys a key to provide a signature based on the previous private key and a signature based on an origin device private key. Origin device can be categorized in several families: software, hardware, biometrics. (See Proof of Work)
So to be allowed to generate a transaction, the task of a quantum computer potentially capable of breaking private keys should be considerably more complex
In order to be backward compatible and to evolve the network as the cryptographic research progesses and to provide the choice of cryptographic algorithms to people, organizations or countries, Archethic is a versioned cryptography or metadata cryptography.
While this word sounds complex, it's not hard to get it.
Each public key is prepended by some additional bytes to inform some metadata or algorithm versioning. This includes:
- a byte to indicate the elliptic curve used (i.e Ed25519, NIST, secp256k1)
- a byte to indicate the origin of the generation (i.e software, hardware, ...)
Like the public keys, cryptographic hashes are also versioned with a byte of to identify which algorithms is used (i.e SHA-256). This information helps to determine the length of a hash and to perform some checks for the validition and for the encoding/decoding of the data.
While transaction addresses are often represented as hashes, Archethic provide a new level of information inside the transaction's address. A byte is prepending the hash with an information regarding the elliptic curve used to generate the public key related.
You may be wondering why would we need this kind of information.
So, in order to be really adaptative and based on the non-disclosure mechanism offered by the transaction chain, we need to know which elliptic was used for a previous transaction to be able to reproduce the previous public key.
For example, imagine we have a transaction address encoded in that way, using a
Reminder: a transaction address is the hash of the next public key
For a new transaction coming after, if now, we want to use the
ed25519 elliptic curve, we need to know which was used before. For this reason, we have two possibility:
- keep an history of the previous transaction and curves (not really pratical and not scalable)
- add a byte in front of each transaction's address to the curve used
So with a new model:
|Curve type||Hash algorithm||Digest|
Now we are able to compute the previous public key, with the curve
secp256k1 and continues with new elliptic curve along the way.
This will be even more pratical with On-Chain Decentralized Wallet (
Keychain) to support multiple derived keys and custom algorithms.
Except for hardware compatability issues (HSM, etc..), EdDSA signatures, Curve25519 and AES256 will be used by default on the network.