diff --git a/assets/sass/custom.scss b/assets/sass/custom.scss index 24330cf..4aaf93f 100644 --- a/assets/sass/custom.scss +++ b/assets/sass/custom.scss @@ -37,6 +37,7 @@ table { } .hexdump { + padding-top: 16px; font-family: monospace; font-size: 12px; padding-bottom: 1rem; diff --git a/content/protocol/blockchain/address.md b/content/protocol/blockchain/address.md index 5a537af..8659813 100644 --- a/content/protocol/blockchain/address.md +++ b/content/protocol/blockchain/address.md @@ -26,11 +26,34 @@ The resulting byte array is then converted into a bech32m[^first] string. ## Address Type -The address type specifies the type of the address and its defined as below: +The address type specifies the type of the address and its defined as below +(see [PIP-8](https://pips.pactus.org/PIPs/pip-8)): - 0: Treasury address - 1: Validator address -- 2: Account address +- 2: BLS Account address +- 3: Ed25519 Account address +- 4: secp256k1 Account address + +## Address Derivation + +An address is derived from the compressed public key as follows: + +```text +hash_256 = Blake2b_256(compressed_public_key) // 32 bytes +hash_160 = RIPEMD160(hash_256) // 20 bytes +raw_addr = [address_type] + hash_160 // 21 bytes +address = Bech32m("pc", address_type, hash_160) +``` + +The address type is chosen based on how the address will be used: + +| **Public Key** | **Address Type** | **Prefix** | +| ------------------------------ | ---------------- | ---------- | +| BLS (G2, 96 bytes) → validator | `1` | `pc1p...` | +| BLS (G2, 96 bytes) → account | `2` | `pc1z...` | +| Ed25519 (32 bytes) | `3` | `pc1r...` | +| secp256k1 (33 bytes) | `4` | `pc1y...` | ## Treasury Address diff --git a/content/protocol/blockchain/cryptography.md b/content/protocol/blockchain/cryptography.md index 0da7fc9..710fd16 100644 --- a/content/protocol/blockchain/cryptography.md +++ b/content/protocol/blockchain/cryptography.md @@ -3,28 +3,68 @@ title: Cryptography weight: 7 --- -The Pactus blockchain employs various advanced cryptographic algorithms, including hashing and signature schemes, -to protect user data and transactions. +The Pactus blockchain uses various cryptographic algorithms, including hashing and digital signature schemes, +to protect user data and secure transactions. ## Hashing Algorithm -Pactus uses a hashing algorithm called [Blake2b](https://www.blake2.net/). -This algorithm is known for being a fast and secure way of creating unique digital fingerprints of data. +Pactus uses the [Blake2b](https://www.blake2.net/) hashing algorithm. +Blake2b is a fast and secure cryptographic hash function that produces unique digital fingerprints of data. -## Digital Signature +## Signature Schemes -To ensure secure transactions, Pactus uses a signature scheme called -[BLS](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/) (Boneh–Lynn–Shacham) -threshold signature for cryptographic signing and verification. +Pactus supports several signature schemes for different purposes. -### Signature Aggregation +### BLS Signatures -One of the advantages of BLS signatures is signature aggregation. BLS individual signatures can be -combined into one single aggregated signature, so that the overall size does not grow beyond one -signature. +[BLS](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bls-signature/) (Boneh–Lynn–Shacham) is the primary signature scheme +used by validators and BLS-based accounts. +BLS public keys are 96 bytes and use the G2 subgroup of the BLS12-381 curve. +BLS is a threshold signature scheme with two notable properties: -### Non-Malleability +#### Signature Aggregation -BLS signatures have an important property called non-malleability, -which means that it is impossible to generate two valid signatures for the same message. -In other words, each message has a unique signature, and signatures cannot be altered without invalidating the signature. +BLS signatures can be aggregated — multiple individual signatures can be combined into a single signature +without increasing the overall size. This is useful for consensus where many validators sign the same message. + +#### Non-Malleability + +BLS signatures are non-malleable: it is impossible to produce two different valid signatures for the same message. +Each message has exactly one valid signature. + +### Ed25519 Signatures + +[Ed25519](https://www.rfc-editor.org/rfc/rfc8032.txt) is supported for account addresses +(see [PIP-52](https://pips.pactus.org/PIPs/pip-52)). +Ed25519 provides strong security with compact 32-byte public keys and fast performance. +Ed25519 account addresses start with `pc1r...`. + +### secp256k1 Signatures + +[secp256k1](https://www.secg.org/sec2-v2.pdf) (ECDSA) is supported for account addresses +(see [PIP-53](https://pips.pactus.org/PIPs/pip-53)). +This is the same curve used by Bitcoin, with 33-byte compressed public keys, enabling compatibility with existing wallet tools. +secp256k1 account addresses start with `pc1y...`. + +## Address Types + +Addresses in Pactus include a type that indicates their intended usage +(see [PIP-8](https://pips.pactus.org/PIPs/pip-8)): + +| **Type** | **Usage** | **Address Prefix** | **Derivation Path** | +| -------- | ----------------- | ------------------ | ------------------------------- | +| 1 | Validator | `pc1p...` | `m/12381'/21888'/1'/index` | +| 2 | BLS Account | `pc1z...` | `m/12381'/21888'/2'/index` | +| 3 | Ed25519 Account | `pc1r...` | `m/44'/21888'/3'/index'` | +| 4 | secp256k1 Account | `pc1y...` | `m/44'/21888'/4'/index'` | + +## HD Key Derivation + +Pactus supports Hierarchical Deterministic (HD) key derivation for wallets. +This allows a single master seed to generate a tree of keys in a predictable way. + +BLS HD derivation follows [PIP-11](https://pips.pactus.org/PIPs/pip-11), +which defines a standard for BLS12-381 HD key chains based on +[BIP-0032](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). +Ed25519 and secp256k1 HD derivation follow +[SLIP-10](https://github.com/satoshilabs/slips/blob/master/slip-0010.md).