트랜잭션 인증 개요

Sui의 transaction 인증은 세 가지 핵심 개념을 포함한다: 사용자가 제어하는 cryptographic key, 온체인 계정을 식별하는 address, 그리고 소유권을 증명하는 signature이다. Sui는 널리 받아들여진 wallet specification과 여러 서명 방식(signature scheme)을 사용해 이 개념들을 구현한다.

키와 주소

Sui는 사용자 key 관리를 돕기 위해 암호화폐 업계에서 널리 받아들여지는 wallet specification인 BIP-32와 그 변형인 SLIP-0010, BIP-44, BIP-39을 따른다. Sui는 서명된 transaction을 위해 pure Ed25519, ECDSA Secp256k1, ECDSA Secp256r1, 다중 서명(multisig)을 지원한다.

Key derivation schemes

Ed25519(EdDSA) signing scheme을 지원하는 wallet을 관리하기 위해 Sui는 SLIP-0010을 따르며, 이 방식은 wallet이 hardened key path를 사용해 parent private key에서만 child private key를 항상 파생하도록 강제한다.

Sui는 ECDSA Secp256k1 및 ECDSA Secp256r1 signing scheme을 지원하는 wallet을 관리하기 위해 BIP-32를 따른다.

BIP-32는 key 집합을 논리적으로 연관시키는 hierarchical deterministic wallet 구조를 정의한다. 이 방식으로 key를 그룹화하면 많은 수의 private key를 추적해야 하는 부담이 줄어든다. 이 방법은 또한 custodian이 하나의 제어 원천 아래에서 각 사용자 account마다 구별되는 관리 address를 발급할 수 있게 해준다. BIP-32를 사용하면 private key derivation과 public key derivation이 분리되므로 public key의 chain과 그 address는 파생하면서도 private key는 서명을 위해 오프라인에 보관할 수 있는 watch-only wallet 사용 사례가 가능해진다.

Key derivation paths

BIP-44는 derivation path의 5개 level과 그 정확한 의미를 추가로 정의한다:

$$m / purpose' / coin_type' / account' / change / address_index$$

이 구조에서 slash는 계층의 level을 나타낸다.

purpose level은 서로 다른 signing scheme을 구분한다:

• Ed25519에는 44

• ECDSA Secp256k1에는 54

• Secp256r1에는 74

예를 들어 BIP-49와 BIP-84는 Bitcoin에서 script type을 식별하는 데 사용된다. Sui는 54 아래에 기존 BIP가 없기 때문에 ECDSA Secp256k1을 나타내는 값으로 54를 선택했으며, 이렇게 하면 어떤 Bitcoin standard와도 혼동되지 않는다.

coin_type 값은 다른 암호화폐 전체를 위한 repository로 관리된다. 두 서명 방식은 모두 Sui에 등록된 coin_type인 784를 사용한다.

account level은 사용자 account를 논리적으로 분리하고 특정 account 범주를 만드는 데 사용된다.

Account 기반 currency는 처음 3개 level만 정의하는 반면, UTXO 기반 currency는 change와 address level 정의를 추가한다. Sui의 object 지향 데이터 모델은 UTXO도 account 기반도 아니며(둘을 결합한다), 최대 호환성을 위해 5개 level을 모두 사용한다.

Scheme	Path	Comments
Ed25519	m/44'/784'/{account}'/{change}'/{address}'	derivation path의 각 level은 hardened된다.
ECDSA Secp256k1	m/54'/784'/{account}'/{change}/{address}	처음 3개 level은 hardened된다.
ECDSA Secp256r1	m/74'/784'/{account}'/{change}/{address}	처음 3개 level은 hardened된다.

Mnemonics support

Sui가 seed에서 master key를 파생하는 deterministic한 방법을 정의한 뒤에는 BIP-39가 도입되어 mnemonic을 사용함으로써 seed를 사람이 더 읽기 쉽고 기억하기 쉽게 만든다. Sui는 올바르게 checksum된 BIP-39 word list에서 12, 15, 18, 21, 24개 단어를 받아들이며, 이는 각각 128, 160, 192, 224, 256비트 entropy에 해당한다.

Address format

32-byte Sui address를 파생하기 위해 Sui는 서명 방식 flag 1-byte와 public key byte를 이어 붙인 값을 BLAKE2b (256 bits output) hashing 함수로 해시한다. 현재 Sui address는 pure Ed25519, Secp256k1, Secp256r1, 그리고 다중 서명인 다중 서명를 지원하며, 각각에 대응하는 flag byte는 0x00, 0x01, 0x02, 0x03이다.

서명

사용자가 서명된 transaction을 제출할 때는 serialized signature와 serialized transaction data가 함께 제출된다. serialized transaction data는 struct TransactionData의 Binary Canonical Serialization serialized bytes이며, serialized signature는 flag || sig || pk byte를 이어 붙인 것으로 정의된다.

Signature structure

Sui signature는 세 구성 요소를 이어 붙인 형태로 이루어진다:

• flag: 서명 방식에 대응하는 1-byte 표현이다.

• sig: signature의 compressed bytes 표현이다(DER encoding이 아님).

• pk: signature에 대응하는 public key의 bytes 표현이다.

Supported signature schemes

다음 표는 각 서명 방식과 그에 대응하는 flag, signature 형식, public key 형식을 나열한다:

Scheme	Flag	Signature Format	Public Key Format
Pure Ed25519	0x00	Compressed, 64 bytes	Compressed, 32 bytes
ECDSA Secp256k1	0x01	Non-recoverable, compressed, 64 bytes	Compressed, 33 bytes
ECDSA Secp256r1	0x02	Non-recoverable, compressed, 64 bytes	Compressed, 33 bytes
multisig	0x03	BCS serialized all signatures, size varies	BCS serialized all participating public keys, size varies
zkLogin	0x05	BCS serialized zkLogin inputs, max epoch and ephemeral signature, size varies	Concatenation of iss length, iss bytes, address seed padded to 32-bytes, size varies
passkey	0x06	BCS serialized passkey inputs (authenticatorData, clientDataJson, userSignature), size varies	Compressed, 33 bytes

Signature requirements

signature는 transaction data의 intent message hash에 commit해야 하며, 이를 위해 BCS serialized transaction data 앞에 3-byte intent를 덧붙여 구성할 수 있다. intent가 무엇이고 intent message를 어떻게 구성하는지 더 알아보려면 인텐트 서명을 참조한다.

signing API를 호출할 때는 먼저 transaction data의 intent message를 Blake2b를 사용해 32 byte로 해시해야 한다. 이 외부 해싱은 signing API 내부에서 수행되는 해싱과는 별개이다. 기존 standard와 hardware secure module(HSM)에 호환되도록 signing algorithm은 내부적으로 추가 해싱을 수행한다. ECDSA Secp256k1과 Secp256r1의 경우 내부 해시 함수로 SHA-2 SHA256을 사용해야 한다. pure Ed25519의 경우에는 SHA-512를 사용해야 한다.

ECDSA signature requirements

허용되는 ECDSA Secp256k1 및 Secp256r1 signature는 다음을 따라야 한다:

1. ECDSA가 사용하는 내부 해시는 transaction data에 대한 SHA256 SHA-2 해시여야 한다. Sui가 SHA256을 사용하는 이유는 Apple, HSM이 지원하고 Bitcoin에서 널리 채택되었기 때문이다.

2. signature 길이는 [r, s] 형식의 64 byte여야 하며, 앞 32 byte는 r, 뒤 32 byte는 s이다.

3. r 값은 0x1 이상 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364140 이하일 수 있다.

4. s 값은 curve order의 lower half에 있어야 한다. signature가 너무 높으면 대응하는 curve order를 사용해 BIP-0062에 따라 order - s로 더 낮은 s로 변환한다. Secp256k1의 curve order는 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141이다. Secp256r1의 curve order는 Standards for Efficient Cryptography에 정의된 0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551이다.

5. 이상적으로 signature는 RFC6979에 따른 결정적 논스(nonce)로 생성되어야 한다.

Ed25519 signature requirements

허용되는 pure Ed25519 signature는 다음을 따라야 한다:

1. signature는 RFC 8032에 따라 생성되어야 한다. 내부 해시는 SHA-512를 사용한다.

2. signature는 ZIP215에 따라 유효해야 한다.

Special signature schemes

고급 서명 방식에 대한 더 자세한 정보는 다음을 참조한다:

• zkLogin: zero-knowledge login signature에 대한 자세한 내용은 zkLogin 통합을 참조한다.

• Passkey: passkey 구현 세부 사항은 SIP-8을 참조한다.

• Multisig: 다중 서명 transaction은 다중 서명를 참조한다.

• Offline Signing: transaction을 오프라인으로 서명하는 구체적 예시는 오프라인 서명을 참조한다.

Authority signatures

Sui의 collection of validators는 서로 다른 목적을 위해 세 종류의 key pair를 가진다.

Protocol key pair

protocol key pair는 검증된 사용자 서명 transaction에 대해 authority signature를 제공한다. 사용자 transaction에 signature를 제공한 authority의 stake가 필요한 2/3 임계값을 넘으면 Sui는 transaction을 실행한다. Sui는 정해진 수의 authority에 대한 aggregated signature를 빠르게 검증하기 위해 BLS12381 scheme을 사용한다. 특히 Sui는 minSig BLS 모드를 사용하며, 각 개별 public key는 96 byte이고 signature는 48 byte이다. 후자는 validator가 보통 각 epoch 시작 시점에 key를 한 번 등록한 뒤 transaction에 계속 서명한다는 점에서 중요하며, 따라서 Sui는 최소 signature 크기에 최적화한다.

BLS scheme과 마찬가지로 서로 독립적인 signature를 하나의 BLS signature payload로 집계할 수 있다. Sui는 또한 어떤 validator가 서명했는지를 나타내는 bitmap을 집계 signature와 함께 제공한다. 이로써 authority signature 크기를 (2f + 1) × BLS_sig 크기에서 단 1개의 BLS_sig payload로 효과적으로 줄인다. 이는 validator set의 크기와 무관하게 압축된 transaction certificate를 만들 수 있게 해 네트워크 비용 측면에서 큰 이점을 준다.

BLS12381 aggregated signature에 대한 잠재적인 rogue key attack에 대응하기 위해 authority 등록 중에 secret key의 proof of knowledge(KOSK)를 사용한다. authority가 validator set에 추가되기를 요청할 때 proof of possession이 제출되고 검증된다. proof of possession을 만드는 방법은 인텐트 서명을 참조한다. 대부분의 standard와 달리 Sui proof of knowledge scheme은 address에도 commit하며, 이는 다른 악의적인 validator가 validator BLS key를 재사용하는 공격에 대한 추가 보호를 제공한다.

Account key pair

staking reward 지급을 받기 위해 authority가 사용하는 account는 account key pair로 보호된다. Sui는 signing scheme으로 pure Ed25519를 사용한다.

Network key pair

private key는 consensus networking에 필요한 TLS handshake를 수행하는 데 사용된다. public key는 validator identity에 사용된다. scheme으로는 pure Ed25519가 사용된다.

authority key tooling에 대한 더 자세한 내용은 Validator Tool을 참조한다.

Examples

Sui CLI tool과 Sui SDKs는 다양한 signing scheme으로 transaction에 서명할 수 있는 유연한 인터페이스를 제공한다.

CLI

$ sui keytool import "TEST_MNEMONIC" ed25519 "m/44'/784'/0'/0'/0'"

$ sui client new-address ed25519 "m/44'/784'/0'/0'/0'"

TypeScript

const keypair = Ed25519Keypair.deriveKeypair(TEST_MNEMONIC, `m/44'/784'/0'/0'/0'`);
const address = keypair.getPublicKey().toSuiAddress();

pure Ed25519 또는 ECDSA Secp256k1에 대한 더 많은 test vector를 참조한다.