수이(Sui)는 초기 메인넷에서 Narwhal이 거래 데이터를 인증된 방향성 비순환 그래프(DAG)로 퍼뜨리고, Bullshark가 그 그래프의 순서를 합의하는 구조를 썼습니다. 2024년 메인넷에서는 Mysticeti로 전환해 별도의 DAG 인증 단계를 없애고, 검증자가 서명한 블록들로 이뤄진 그래프에서 곧바로 커밋을 결정하도록 바꿨습니다. 따라서 지금의 수이 지연 시간을 Bullshark 라운드로 설명해서는 안 되며, 논문 속 Mysticeti-C·FPC 설계, 실제 메인넷 활성화, 이후 기능 제안을 서로 구분해야 합니다.
먼저 연대표를 고정합니다
수이의 초기 합의 설명은 Narwhal과 Bullshark를 함께 다룹니다. Narwhal의 작업자(worker)와 주 노드(primary)가 거래 묶음을 퍼뜨리고 가용성 인증서로 그래프를 만들면, Bullshark가 그 인증된 그래프에서 결정론적인 순서를 정했습니다. 데이터 전파와 순서 결정을 나눠 높은 처리량을 노린 구조였습니다.
Mysten Labs는 2024년 7월 수이 메인넷의 합의 엔진을 Mysticeti로 바꿨다고 발표했습니다. 확인일 현재 수이 공식 문서도 Mysticeti를 현행 합의 엔진으로 설명합니다. 따라서 Narwhal·Bullshark는 배경과 전환 이전 동작을 설명할 때 과거형으로 쓰고, 지금의 거래 최종성을 그 구성 요소가 직접 처리한다고 서술하지 않습니다.
Mysticeti를 정확히 읽으려면 더 빠르다는 수치보다, 어느 단계가 과거에 있었고 현재 경로에서 빠졌는지를 먼저 봐야 합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 먼저 연대표를 고정합니다
수이의 초기 합의 설명은 Narwhal과 Bullshark를 함께 다룹니다.
- Narwhal·Bullshark는 두 층으로 나뉘어 있었습니다
Narwhal의 핵심은 데이터 전파와 가용성 보장입니다.
- Mysticeti는 인증서 단계를 없앤 그래프를 씁니다
Mysticeti-C에서도 검증자는 블록을 전파하고 그래프 안의 다른 블록을 참조합니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
Narwhal·Bullshark는 두 층으로 나뉘어 있었습니다
Narwhal의 핵심은 데이터 전파와 가용성 보장입니다. 검증자가 거래 묶음을 공유하고 충분한 지분의 확인 응답을 모아 인증서를 만들면, 이 인증서들이 라운드별 그래프를 이룹니다. Bullshark는 이 그래프의 인과 이력과 리더 규칙을 이용해 인증서의 순서를 합의했습니다.
이렇게 나누면 처리량에는 유리하지만, 인증서를 만들기 위한 추가 메시지와 서명 검증이 지연 경로에 끼어듭니다. 옛 문서의 ‘Narwhal 멤풀’이라는 표현을 두고, 지금의 수이가 같은 작업자-주 노드 구조와 인증서 처리 흐름을 그대로 쓴다는 증거로 넓혀 읽으면 안 됩니다. 어디까지나 역사적 설계를 비교할 때의 기준입니다.
| 구조 | 시기·상태 | 핵심 경로 |
|---|---|---|
| Narwhal + Bullshark | 초기 메인넷, 과거 구조 | 인증된 그래프 생성 뒤 순서 결정 |
| Mysticeti-C | 2024 메인넷 전환 뒤 현행 계열 | 서명 블록 그래프에서 바로 커밋 |
| Mysticeti-FPC | 논문에 제시된 빠른 경로 설계 | 단독 소유 객체 거래의 저지연 경로 |
| 후속 최적화·제안 | 버전별로 따로 확인 | 문서와 릴리스 활성화 확인 필요 |
Mysticeti는 인증서 단계를 없앤 그래프를 씁니다
Mysticeti-C에서도 검증자는 블록을 전파하고 그래프 안의 다른 블록을 참조합니다. 차이는 각 블록을 먼저 정족수 인증서로 바꾸는 별도 단계 없이, 서명만 하고 인증하지 않은 블록들의 그래프에 커밋 규칙을 적용한다는 점입니다. 파이프라인과 다중 제안자 구조로 정상 경로의 지연을 줄입니다.
논문은 실제 운영 수준 구현끼리 비교했을 때 Bullshark보다 낮은 p50·p95 지연을 보고합니다. 하지만 이는 명시된 검증자 수·부하·실험 환경에서 나온 결과일 뿐, 지금 모든 거래의 체감 확정 시간을 보장하는 서비스 수준 약속이 아닙니다. 네트워크 지연, 에포크 재구성, 거래 유형, 어떤 확정 단계를 관측하느냐가 실제 지연에 영향을 줍니다.
- 자료 발행일과 메인넷 활성화 날짜를 먼저 확인합니다.
- Narwhal의 인증서 그래프와 Mysticeti의 서명 블록 그래프를 구분합니다.
- 논문 벤치마크를 인용할 때는 검증자 수·초당 거래 수·백분위 조건을 함께 적습니다.
- 현재 프로토콜 버전·릴리스 노트·RPC 확정 단계로 실제 경로를 확인합니다.
합의 경로와 빠른 경로를 구분합니다
수이는 단독 소유 객체처럼 소유권 하나로 충돌을 관리할 수 있는 거래와, 공유 객체처럼 전역 순서 합의가 필요한 거래를 나눠 설명해 왔습니다. Mysticeti 논문은 합의 프로토콜인 Mysticeti-C와, 비잔틴 일관 브로드캐스트를 바탕으로 한 빠른 경로 Mysticeti-FPC를 함께 제안합니다. 두 이름을 뭉뚱그려 모든 거래가 같은 경로를 탄다고 말하면 안 됩니다.
공식 현행 문서가 특정 빠른 경로의 메인넷 활성 상태와 적용 범위를 밝힐 때만 운영 사실로 씁니다. 논문에서 구현·평가됐다는 사실, 코드에 들어갔다는 사실, 메인넷에서 기능이 켜졌다는 사실은 서로 다른 증거입니다. 탐색기에서 본 거래 하나의 지연 시간만으로 경로를 거꾸로 추정하지 않습니다.
전환이 합의의 안전 가정을 버렸다는 뜻은 아닙니다
인증서 단계를 없앴다는 말은 정족수와 비잔틴 장애 가정까지 없앴다는 뜻이 아닙니다. Mysticeti의 커밋 규칙은 그래프의 참조 관계와 투표권을 이용해 안전한 순서를 정하고, 진행성을 위해 라운드·제안자 규칙을 둡니다. 인증되지 않은 블록이 검증 없는 블록이라는 뜻도 아닙니다. 검증자 서명과 프로토콜 유효성 검사는 그대로 남습니다.
Bullshark 인증서가 보이지 않게 됐다고 해서 데이터 가용성이 필요 없어진 것도 아닙니다. 검증자는 커밋에 필요한 블록과 그 조상 블록을 받아야 하고, 누락이나 이중 서명을 다루는 규칙도 필요합니다. 없어진 것은 별도의 인증서 생성 단계이지 분산 합의의 증거 전체가 아닙니다.
현재 상태를 안전하게 쓰는 문장
확인일 기준으로는 ‘수이 메인넷은 2024년 Mysticeti로 전환했고, 공식 문서는 Mysticeti를 현재 합의 엔진으로 설명한다’고 쓸 수 있습니다. ‘Narwhal·Bullshark가 지금도 수이 합의를 맡는다’는 문장은 과거 구조를 현재 일처럼 만듭니다. 반대로 논문에 나온 Mysticeti 구성 요소가 모두 같은 범위로 메인넷에 켜졌다고 넓히는 것도 피해야 합니다.
새로운 합의 제안이나 릴리스가 나오면 발표, 코드 병합, 테스트넷, 메인넷 활성화의 네 상태로 나눠 갱신합니다. 성능 수치는 같은 조건에서 잰 값끼리만 비교하고, 최종성이라는 말이 합의 커밋, 체크포인트, 사용자 API 응답 중 무엇을 가리키는지 밝힙니다. 이 연대표와 증거의 경계가 전환을 설명하는 핵심입니다.
자주 묻는 질문
수이는 지금도 Bullshark를 쓰나요?
공식 발표와 현행 문서 기준으로 수이 메인넷은 2024년 Mysticeti로 전환했습니다. Bullshark는 초기 메인넷의 과거 구조로 구분해야 합니다.
Mysticeti가 그래프 구조를 없앤 것인가요?
아닙니다. 서명 블록 그래프는 그대로 쓰되, Narwhal 계열의 별도 인증서 생성 단계를 없앤 것이 핵심입니다.
Mysticeti 논문의 빠른 경로가 모두 지금 메인넷에서 쓰이나요?
논문의 설계·구현 평가와 메인넷 기능 활성화는 각각 별도의 증거가 필요합니다. 현행 공식 문서와 릴리스 상태로 적용 범위를 확인해야 합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
