THE CHAIN IDENTIFIER IN HAQQ WALLET

THE CHAIN IDENTIFIER
Every chain must have a unique identifier or chain-id. Tendermint requires each application to define its own chain-id in the genesis.json fields (opens new window).

However, in order to comply with both EIP155 and Cosmos standard for chain upgrades, Haqq-compatible chains must implement a special structure for their chain identifiers.

STRUCTURE
The Haqq Chain ID contains 3 main components

Identifier: Unstructured string that defines the name of the application.
EIP155 Number: Immutable EIP155 (opens new window)CHAIN_ID that defines the replay attack protection number.
Version Number: Is the version number (always positive) that the chain is currently running. This number MUST be incremented every time the chain is upgraded or forked in order to avoid network or consensus errors.
THE FORMAT
The format for specifying and Haqq compatible chain-id in genesis is the following:

{identifier}_{EIP155}-{version}
The following table provides an example where the second row corresponds to an upgrade from the first one:

HAQQ ACCOUNTS
Haqq defines its own custom Account type that uses Ethereum’s ECDSA secp256k1 curve for keys. This satisfies the EIP84 (opens new window)for full BIP44 (opens new window)paths. The root HD path for Haqq-based accounts is m/44’/60’/0’/0.

ADDRESSES AND PUBLIC KEYS
BIP-0173 (opens new window)defines a new format for segregated witness output addresses that contains a human-readable part that identifies the Bech32 usage.

Haqq uses the following HRP (human readable prefix) as the base HRP:

Network Mainnet Testnet Regtest
Haqq haqq haqq

There are 3 main types of HRP for the Addresses/PubKeys available by default on Haqq:

Addresses and Keys for accounts, which identify users (e.g. the sender of a message). They are derived using the eth_secp256k1 curve.
Addresses and Keys for validator operators, which identify the operators of validators. They are derived using the eth_secp256k1 curve.
Addresses and Keys for consensus nodes, which identify the validator nodes participating in consensus. They are derived using the ed25519 curve.
ADDRESS FORMATS FOR CLIENTS
EthAccount can be represented in both Bech32 (opens new window)(haqq1...) and hex (0x...) formats for Ethereum’s Web3 tooling compatibility.

The Bech32 format is the default format for Cosmos-SDK queries and transactions through CLI and REST clients. The hex format on the other hand, is the Ethereum common.Address representation of a Cosmos sdk.AccAddress.

Address (Bech32): haqq1z3t55m0l9h0eupuz3dp5t5cypyv674jj7mz2jw
Address (EIP55 (opens new window)Hex): 0x91defC7fE5603DFA8CC9B655cF5772459BF10c6f
Compressed Public Key: {"@type":"/ethermint.crypto.v1.ethsecp256k1.PubKey","key":"AsV5oddeB+hkByIJo/4lZiVUgXTzNfBPKC73cZ4K1YD2"}
TRANSACTION LIFECYCLE ON HAQQ WALLET
ROUTING

Haqq needs to parse and handle transactions routed for both the EVM and for Cosmos SDK modules. We attempt to achieve this by mimicking geth’s (opens new window)Transaction structure and treat it as a unique Cosmos SDK message type.

An Ethereum transaction is a single sdk.Msg (opens new window). All relevant Ethereum transaction information is contained in this message. This includes the signature, gas, payload, amount, etc.

Being that Haqq implements the Tendermint ABCI application interface, as transactions are consumed, they are passed through a series of handlers.

Once such handler, the AnteHandler, is responsible for performing preliminary message execution business logic such as fee payment, signature verification, etc.

This is particular to Cosmos SDK routed transactions. Ethereum routed transactions will bypass this as the EVM handles the same business logic.

All EVM transactions are RLP encoded using a custom tx encoder.

SIGNERS
The signature processing and verification in Ethereum is performed by the Signer interface. The protocol supports different signer types based on the chain configuration params and the block number.

// Signer encapsulates transaction signature handling. The name of this type is slightly
// misleading because Signers don't actually sign, they're just for validating and
// processing of signatures.
//
// Note that this interface is not a stable API and may change at any time to accommodate
// new protocol rules.
type Signer interface {
// Sender returns the sender address of the transaction.
Sender(tx *Transaction) (common.Address, error)

// SignatureValues returns the raw R, S, V values corresponding to the
// given signature.
SignatureValues(tx *Transaction, sig []byte) (r, s, v *big.Int, err error)
ChainID() *big.Int

// Hash returns 'signature hash', i.e. the transaction hash that is signed by the
// private key. This hash does not uniquely identify the transaction.
Hash(tx *Transaction) common.Hash

// Equal returns true if the given signer is the same as the receiver.
Equal(Signer) bool

Haqq supports all Ethereum Signers up to the latest go-ethereum version (London, Berlin, EIP155, Homestead and Frontier). The chain will generate the latest Signer type depending on the ChainConfig.

READ MORE ABOUT ISLAMIC COIN AND HAQQ BY CLICKING ON THE LINKS BELOW.
WEBSITE : https://islamiccoin.net/

TWITTER : https://twitter.com/Islamic_coin

TELEGRAM : https://t.me/islamiccoin_int

DISCORD : https://discord.gg/islamic-coin

MEDIUM : https://medium.com/islamic-coin