Kaspa 해설: blockDAG, 초당 10개 블록, 그리고 멀티시그의 작동 방식

대부분의 작업 증명 체인은 블록을 한 번에 하나씩 만듭니다. 채굴자가 블록을 찾으면 모두가 그 위에 이어서 쌓고, 같은 순간에 발견된 경쟁 블록은 버려집니다. Kaspa는 다른 질문에서 출발합니다. 병렬로 만들어진 블록을 전혀 낭비하지 않는다면 어떨까요?

그 답이 blockDAG이며, Kaspa가 작업 증명을 유지하면서도 매초 10개의 블록을 만들어 낼 수 있는 이유입니다. SSP에 Kaspa 지원이 곧 추가되는 만큼, Kaspa가 무엇이 다른지, 그리고 그 위에서 멀티시그가 어떻게 작동하는지 살펴보겠습니다.

체인에서 DAG로

비트코인에서는 두 채굴자가 거의 동시에 블록을 찾으면 네트워크가 일시적으로 갈라집니다. 결국 한 블록이 이기고 다른 블록은 고아 블록이 되며, 그 뒤에 들어간 작업은 그대로 사라집니다. 고아 블록을 드물게 유지하기 위해 비트코인은 10분마다 블록 하나를 목표로 합니다. 다음 블록이 발견되기 전에 각 블록이 네트워크 전체에 도달하기에 충분한 시간입니다.

Kaspa는 이 제약을 없앱니다. 새 블록은 하나가 아니라 여러 이전 블록을 참조할 수 있어서, 병렬로 만들어진 블록이 모두 원장의 일부가 됩니다. 구조는 더 이상 하나의 체인이 아니라 방향성 비순환 그래프, 즉 DAG가 됩니다.

하지만 DAG만으로는 문제가 있습니다. 병렬 블록 두 개에 서로 충돌하는 트랜잭션이 들어 있다면 어느 쪽을 인정해야 할까요? Kaspa의 합의 프로토콜인 GHOSTDAG는 모든 블록을 일관되게 정렬해 이 문제를 해결합니다. 정직한 채굴자들이 만든, 서로 잘 연결된 다수의 블록을 식별하고 모든 것을 합의된 단일 순서로 배열하므로, 모든 노드가 어느 트랜잭션이 먼저인지에 대해 같은 결론에 도달합니다.

그 결과 Kaspa는 초당 10개 블록(2025년 Crescendo 업그레이드 이후의 속도)으로 운영될 수 있으며, 이 속도라면 일반 체인을 마비시켰을 고아 블록 낭비도 없습니다. 원장을 보호하는 데는 여전히 작업 증명을 사용합니다.

실제로는 무엇을 의미할까

• 빠른 확인. 트랜잭션은 1초 남짓이면 블록에 담깁니다. 다른 체인과 마찬가지로 큰 금액이라면 확인 깊이가 여전히 중요합니다. 위에 블록이 쌓일 때마다 트랜잭션을 되돌리기가 더 어려워지지만, 그 깊이는 빠르게 쌓입니다.
• 계정이 아니라 코인. Kaspa는 비트코인처럼 UTXO 모델을 사용합니다. 잔액은 개별 코인들의 집합이며, 지출할 때는 그중 일부를 합치고 잔돈을 다시 본인에게 돌려보냅니다.
• 프루닝. Kaspa 노드는 전체 기록을 영원히 보관하지 않습니다. 오래된 블록 데이터는 약 하루 반이 지나면 정리됩니다. 현재 상태는 언제나 검증할 수 있지만, 장기적인 거래 기록은 모든 노드가 아니라 인덱서와 탐색기가 보관합니다.
• 작은 단위. 1 KAS는 Kaspa의 최소 단위인 100,000,000 sompi입니다.

수수료는 '질량'으로 측정된다

비트코인은 블록 공간의 가격을 바이트 단위로 매깁니다. Kaspa는 여러 비용을 합친 질량(mass)으로 가격을 매깁니다.

• 크기: 트랜잭션이 차지하는 바이트 수.
• 서명 연산: 서명 검증 한 번마다 고정된 양이 더해지므로, 멀티시그 지출은 단일 키 지출보다 무겁습니다.
• 저장: KIP-9라는 규칙은 아주 작은 출력을 많이 만드는 트랜잭션의 비용을 높여, 원장이 더스트로 가득 차는 것을 막습니다.

일상적인 송금에서는 이를 느낄 일이 없습니다. 수수료가 적기 때문입니다. 하지만 이것으로 Kaspa의 몇 가지 특이점을 설명할 수 있습니다. 예를 들어 아주 적은 잔돈을 자신에게 돌려보내는 트랜잭션이 거부될 수 있는 이유, 그리고 지갑이 큰 결제 전에 작은 코인 여러 개를 합쳐야 할 때가 있는 이유입니다.

Kaspa에서 멀티시그가 작동하는 방식

Kaspa는 의도적으로 주소 유형을 적게 두었습니다. kaspa:q 주소는 단일 키로 제어됩니다. kaspa:p 주소는 스크립트 해시 지불(P2SH) 주소로, 특정 스크립트에 커밋하며, 지출하려면 그 스크립트를 공개하고 조건을 충족해야 합니다.

멀티시그 볼트는 "이 N개 키 중 M개가 서명해야 한다"고 명시한 스크립트를 가진 kaspa:p 주소입니다. Kaspa는 Schnorr 서명을 사용하고, 합의 수준에서 스크립트당 최대 20개의 키를 지원하며, 최대 15개 키까지의 표준 트랜잭션을 중계합니다. 다루기 편한 이유가 두 가지 있습니다.

• 트랜잭션 ID에 서명이 포함되지 않습니다. 누군가 서명하기 전에 이미 트랜잭션의 최종 ID를 알 수 있어, 여러 기기 간의 서명 조율이 더 간단해집니다.
• SegWit이나 Taproot 계층이 없습니다. Kaspa의 표준 출력 유형은 단일 키, 그 ECDSA 변형, 스크립트 해시 지불의 세 가지뿐입니다. 그래서 제대로 만들어야 할 멀티시그 볼트도 한 종류뿐입니다.

보안상 중요한 미묘한 점이 하나 있습니다. Kaspa 서명은 모든 입력의 금액이 아니라, 자신이 서명하는 특정 입력의 금액에만 커밋합니다. 따라서 신중하게 설계된 멀티시그 지갑은 다른 기기가 제공한 금액을 믿는 대신, 각 서명자가 지출되는 코인을 직접 조회하도록 합니다.

SSP의 Kaspa

SSP는 다른 모든 체인과 같은 2-of-2 모델로 Kaspa를 추가하고 있습니다. 볼트는 SSP Wallet의 키 하나와 SSP Key의 키 하나로 만든 kaspa:p 주소이며, 각 기기는 자신이 무엇에 서명하는지 독립적으로 확인합니다. SSP Enterprise는 M-of-N 승인 방식의 Kaspa 볼트를 지원할 예정입니다.

아직은 사용할 수 없습니다. Kaspa 지원은 최종 테스트 단계에 있으며, 출시될 때 릴리스 노트와 함께 발표될 예정입니다. 그 기반이 되는 라이브러리 @runonflux/kaspa-core는 이미 오픈 소스로 공개되어 있어 누구나 읽거나 재사용할 수 있습니다.

솔직한 요약

Kaspa는 작업 증명으로 UTXO 원장을 보호한다는 익숙한 아이디어를 가져와, 블록이 DAG를 이루도록 허용함으로써 '한 번에 한 블록'이라는 병목을 없앴습니다. 그 결과 빠른 블록, 바이트가 아닌 질량에 기반한 수수료, 그리고 단일 스크립트 유형을 중심으로 한 깔끔한 멀티시그 설계가 탄생했습니다.

어느 체인에서나 마찬가지로, 코인을 안전하게 지키는 것은 블록 속도가 아닙니다. 누가 키를 통제하는지, 그리고 멀티시그라면 그중 몇 개의 키가 동의해야 하는지입니다.