키와 계정 유형
ZooBC 계정은 사용자 이름, 비밀번호, API 키가 아니라 언제나 서명으로 통제됩니다. 어떤 서명인지는 계정의 유형에 따라 다릅니다. ZooBC는 네이티브 Ed25519 계정 외에도 Bitcoin, Ethereum, Solana, Polkadot, Cardano, Ripple, Tron, Tezos가 쓰는 방식으로 주소를 적는 계정을 받아들이며, 각 체인 고유의 방식으로 그 서명을 검사합니다. 따라서 Bitcoin이나 Ethereum 키는 원래 체인에서와 같은 주소로 ZooBC 계정을 통제할 수 있습니다. 그 계정은 ZooBC 자체 원장 위의 별개 계정이며, ZBC를 보유합니다.
주소는 유형과 페이로드입니다
주소는 4바이트 유형 번호(리틀엔디언)와, 그 유형이 의미와 길이를 정하는 페이로드로 이루어집니다(계정과 주소). 네이티브 계정의 페이로드는 Ed25519 공개 키 그 자체이고, Ethereum 계정은 키의 Keccak-256 해시의 마지막 20바이트이며, Bitcoin P2PKH 계정은 키의 HASH160입니다.
| 유형 | 계정 | 표기 | 서명 가능 |
|---|---|---|---|
| 0 | ZooBC, Ed25519 | ZBC_… | 예 |
| 1 | Bitcoin 레거시 (HASH160) | — | 예 |
| 2 | Empty ("수신자 없음") | — | 아니요 |
| 3 | Estonia eID (예약됨) | — | 아니요 |
| 4 | Ethereum | 0x… | 예 |
| 5 | Bitcoin P2PKH | 1… | 예 |
| 6 | Bitcoin P2SH, P2SH-P2WPKH로 검증 | 3… | 예 |
| 7 | Bitcoin P2WPKH | bc1q…, 42자 | 예 |
| 8 | Bitcoin P2WSH (스크립트) | bc1q…, 62자 | 아니요 |
| 9 | Bitcoin Taproot | bc1p… | 예 |
| 10 | 데이터셋 객체 | ZBS_… | 아니요 |
| 11 | Solana | Solana에서와 같음 | 예 |
| 12 | Polkadot | Polkadot에서와 같음 | 예 |
| 13 | Cardano | addr1… | 예 |
| 14 | Ripple | r… | 예 |
| 15 | Tron | T… | 예 |
| 16 | Tezos | tz1… | 예 |
키 없는 주소도 서명할 수 없습니다. 프로토콜의 풀, 계정 그룹, 다중서명 계정에는 키가 없으므로, 그 자금은 프로토콜 규칙에 따라서만 움직입니다.
네이티브 텍스트 형태는 ZBC_ 뒤에 8자씩 7개 그룹으로 된 base32 문자 56자를 붙인 것입니다. 32바이트 키에, 접두사도 포함하는 3바이트 SHA3-256 체크섬을 더한 것입니다. 읽을 때는 구분자, 공백, 대소문자를 무시합니다. 같은 32바이트 키를 노드 키(ZNK_), 릴레이 키(ZBR_), 게이트웨이 키(ZBG_)로도 적을 수 있습니다.
모든 방식에 하나의 다이제스트
모든 계정 유형은 같은 체인 결속 다이제스트에 서명합니다.
digest = SHA3-256("ZBC-TX" ‖ genesis hash ‖ unsigned transaction bytes)
이 다이제스트만 받아들여지며, 바이트 자체에 대한 서명은 거부됩니다. 제네시스 해시가 모든 서명을 하나의 체인에 묶습니다(체인 결속 서명). 일부 방식은 원래 체인이 요구하는 대로 다이제스트를 한 번 더 해시합니다.
서명 방식
- Ed25519: 32바이트 다이제스트에 대해, ZooBC(유형 0)와 Solana(11)에 씁니다. Cardano(13)와 Tezos(16)도 Ed25519로 서명하지만, 그 주소가 해시이므로 서명 필드에 키도 함께 담습니다. 2바이트 길이, 키, 서명으로 된 98바이트입니다. 키는 BLAKE2b-28(Cardano)이나 BLAKE2b-20(Tezos)으로 주소에 묶입니다.
- Bitcoin 방식 secp256k1 ECDSA: 유형 1, 5, 6, 7과 Ripple(14)에 씁니다. 서명 필드에 키를 담습니다. 2바이트 길이, 33바이트 또는 65바이트 키, 그다음 64바이트 서명(r과 s)입니다. 키의 HASH160은 주소와 같아야 하고, 서명하는 메시지는 다이제스트의 이중 SHA-256이며, low-s 서명만 받아들입니다.
- Ethereum 방식 secp256k1 ECDSA: Ethereum(4)과 Tron(15)에 씁니다. 다이제스트의 Keccak-256 해시에 대한 65바이트 서명(r, s, v)입니다. 키는 서명에서 복원하여 그 주소를 비교하며, high-s 서명은 거부합니다.
- BIP-340 Schnorr: Taproot(9)에 x-only 출력 키로 씁니다. Taproot 조정은 지갑이 적용합니다.
- sr25519: Polkadot(12)에 서명 컨텍스트 "substrate"로 씁니다.
Taproot 계정은 모든 체인에서 제네시스부터 SendZBC로 ZBC를 받을 수도 있습니다.
저장되지 않은 키 검증하기
Ethereum 방식 주소는 20바이트 해시일 뿐이며, 공개 키는 체인 어디에도 저장되어 있지 않습니다. Ethereum 서명은 복원 가능합니다. 서명된 메시지와 65바이트 서명으로부터 누구나 그 서명을 만든 단 하나의 공개 키를 계산할 수 있습니다. 노드는 바로 그렇게 하여, 복원한 키의 Keccak-256 해시의 마지막 20바이트를 취하고, 그것이 주소와 같을 때만 서명을 받아들입니다. high-s 서명은 거부되므로, 서명을 두 번째 유효한 형태로 바꿀 수 없습니다. 등록 단계도 외부 조회도 필요 없으며, 0x 계정은 받는 것만큼 자유롭게 보낼 수 있습니다.
안에 실린 외부 트랜잭션
외부 계정을 가진 송신자는 원래 체인의 네이티브 트랜잭션을 ZooBC 트랜잭션의 메시지 필드에 넣을 수도 있습니다. 이 경로에서 노드는 ZooBC 다이제스트 대신 외부 트랜잭션과 그 서명을 검사합니다.
- Ethereum(유형 4): 액세스 목록이 비어 있는 EIP-1559, EIP-2930, 또는 레거시(EIP-155) 트랜잭션. 복원된 서명자는 송신자여야 하고,
to는 수신자여야 하며, wei 단위 값을 10^10으로 나눈 것이 금액이어야 합니다(MetaMask와 Ethereum 방식 접근). - Solana(유형 11): lamports가 금액과 같은 System 전송
- Bitcoin(유형 7과 5): 입력 하나, 출력 하나나 둘, 채굴자 수수료 0. 출력 0은 수신자에게 지급하고, 출력 1이 있다면 송신자에게 잔돈을 돌려줍니다.
이런 운반 메시지는 최대 4,096바이트까지 될 수 있으며, 트랜잭션은 생존 결제를 담을 수 없습니다(트랜잭션 봉투).
네이티브 키 도출
네이티브 키는 BIP-39 복구 문구에서 도출합니다. 2,048라운드의 PBKDF2-HMAC-SHA512를 거친 뒤, 모든 단계를 강화(hardened) 방식으로 하여 m/44'/883'/n'를 따라 SLIP-0010 Ed25519로 도출합니다. 883은 ZooBC의 코인 유형입니다.