솔라나 메인넷의 목표 슬롯 시간이 400밀리초에서 350밀리초로 짧아졌다.
솔라나가 네트워크 출시 당시부터 사용해 온 400밀리초 기준을 처음으로 변경한 것이다. 앞으로 300밀리초와 250밀리초를 거쳐 최종적으로 200밀리초까지 줄이는 단계적 계획도 마련돼 있다.
슬롯 시간이 400밀리초에서 350밀리초로 줄면 블록을 만들 수 있는 기회가 약 12.5% 빨라진다.
하지만 이를 곧바로 솔라나의 거래 처리량이 12.5% 증가했다고 해석하면 안 된다.
이번 업그레이드는 슬롯당 연산량과 데이터 한도를 시간 단축 비율에 맞춰 함께 줄이도록 설계됐다. 네트워크가 1초에 처리하도록 허용한 이론적 연산량은 기존과 비슷하게 유지하면서 확인 지연시간을 줄이는 것이 일차적인 목표다.
슬롯이란 무엇인가
슬롯은 솔라나 네트워크에서 특정 검증인이 블록을 생성할 수 있도록 배정받는 짧은 시간 단위다.
솔라나에서는 검증인들이 정해진 순서에 따라 리더 역할을 맡는다. 리더는 자신의 슬롯 동안 거래를 수집하고 실행한 뒤 블록을 만들어 다른 검증인에게 전파한다.
슬롯 시간이 짧아진다는 것은 다음 리더와 다음 블록 생성 기회가 더 빨리 돌아온다는 의미다.
기존 목표 시간은 슬롯당 400밀리초였다. 이번 변경으로 목표 시간이 350밀리초가 됐다.
| 구분 | 기존 | 변경 후 |
|---|---|---|
| 목표 슬롯 시간 | 400ms | 350ms |
| 1초당 이론적 슬롯 수 | 2.5개 | 약 2.86개 |
| 리더 연속 슬롯 | 4개 | 4개 |
| 리더 담당 시간 | 1.6초 | 1.4초 |
| 에포크 슬롯 수 | 432,000개 | 432,000개 |
| 예상 에포크 시간 | 약 48시간 | 약 42시간 |
슬롯 수 자체를 늘리거나 줄인 것이 아니라 같은 슬롯이 더 빠르게 지나가도록 만든 것이다.
기능 활성화와 실제 적용 시점이 달랐던 이유
350밀리초 기능은 슬롯 440,208,000에서 활성화됐다. 이 슬롯은 에포크 1019가 시작되는 지점이다.
그러나 네트워크가 즉시 350밀리초로 전환된 것은 아니다.
SIMD-0525 설계에 따라 슬롯 시간 변경에는 한 에포크의 유예기간이 적용된다. 기능이 에포크 1019에서 활성화되더라도 실제 시간과 데이터 한도는 다음 에포크인 1020부터 적용된다.
| 단계 | 상태 |
|---|---|
| 에포크 1019 시작 | 350ms 기능 활성화 |
| 에포크 1019 진행 | 기존 400ms 기준 유지 |
| 에포크 1020 시작 | 350ms 기준 실제 적용 |
이런 지연을 두는 이유는 검증인들이 새로운 블록 및 데이터 한도를 동시에 적용하도록 하기 위해서다.
일부 검증인이 먼저 작은 블록 기준을 적용하고 다른 검증인이 과거 기준을 사용하면 정상적인 데이터가 거부되거나 합의에 문제가 발생할 수 있다.
목표 슬롯 시간과 실제 평균은 다를 수 있다
350밀리초는 프로토콜이 설정한 목표 시간이다.
실제 슬롯은 네트워크 지연과 검증인 성능, 블록 전파 상황에 따라 목표보다 조금 길거나 짧아질 수 있다. 적용 직후 관측된 평균 슬롯 시간도 약 360밀리초 수준으로 알려졌다.
따라서 “모든 슬롯이 정확히 0.35초마다 생성된다”고 이해하면 안 된다.
목표 시간은 검증인과 클라이언트가 블록 생성과 투표, 전파를 조정하는 기준이다. 실제 성능을 평가할 때는 일정 기간 동안의 평균 슬롯 시간과 블록 누락률을 함께 확인해야 한다.
350ms가 되면 처리량도 12.5% 증가할까
이번 변경에서 가장 오해하기 쉬운 부분이다.
기존 슬롯당 최대 연산량을 그대로 유지하면서 슬롯만 빠르게 만들면 1초 동안 더 많은 연산을 처리할 수 있다.
예를 들어 슬롯당 최대 연산량이 1억 CU이고 슬롯 시간이 400밀리초라면 이론상 초당 연산량은 다음과 같다.
1억 CU ÷ 0.4초 = 초당 2억5000만 CU
슬롯 시간이 350밀리초로 줄어든 뒤에도 1억 CU를 그대로 허용하면 초당 연산량은 약 2억8571만 CU로 증가한다.
하지만 SIMD-0525는 슬롯당 연산 한도를 8750만 CU로 줄이도록 설계했다.
8750만 CU ÷ 0.35초 = 초당 2억5000만 CU
결과적으로 슬롯은 더 자주 만들어지지만 초당 이론적 연산 한도는 약 2억5000만 CU로 유지된다.
| 목표 슬롯 시간 | 슬롯당 최대 연산량 | 이론적 초당 연산량 |
|---|---|---|
| 400ms | 1억 CU | 약 2억5000만 CU |
| 350ms | 8750만 CU | 약 2억5000만 CU |
| 300ms | 7500만 CU | 약 2억5000만 CU |
| 250ms | 6250만 CU | 약 2억5000만 CU |
| 200ms | 5000만 CU | 약 2억5000만 CU |
이번 변경은 처리량을 무조건 늘리는 업그레이드가 아니라 같은 초당 작업량을 더 짧은 블록 단위로 나누는 변화에 가깝다.
슬롯을 줄이면서 연산 한도도 낮춘 이유
슬롯 시간만 단축하고 작업 한도를 그대로 두면 검증인이 1초 동안 처리해야 할 연산과 데이터가 증가한다.
고성능 서버를 운영하는 검증인은 이를 감당할 수 있더라도 상대적으로 성능이 낮거나 네트워크 환경이 불리한 검증인은 블록을 제때 받지 못할 수 있다.
이 경우 다음과 같은 문제가 생길 수 있다.
- 블록 누락률 증가
- 검증인 투표 지연
- 고성능 검증인에 대한 의존 확대
- 네트워크 중앙화 압력
- 블록 전파 실패
- 검증인 운영비 증가
슬롯당 연산과 데이터 한도를 비례해서 줄이면 1초 기준의 전체 부담을 크게 늘리지 않고 시간 단위를 짧게 만들 수 있다.
그럼 무엇이 실제로 빨라지는가
가장 직접적인 변화는 사용자가 거래 상태를 확인하는 데 걸리는 시간이다.
슬롯을 기준으로 계산되는 확인 단계가 같은 수의 슬롯을 요구한다면 각 슬롯이 빨라질수록 실제 경과시간은 줄어든다.
예를 들어 어떤 상태 확인에 10개 슬롯이 필요하다고 단순 가정해보자.
| 목표 슬롯 시간 | 10개 슬롯 경과시간 |
|---|---|
| 400ms | 4초 |
| 350ms | 3.5초 |
| 300ms | 3초 |
| 250ms | 2.5초 |
| 200ms | 2초 |
실제 거래 확정시간은 네트워크 투표와 합의 상태 등의 영향을 받기 때문에 이 표처럼 정확히 비례하지는 않는다. 하지만 더 짧은 슬롯이 지연시간을 줄이는 방향으로 작용하는 것은 맞다.
가격정보의 최신성을 확인하는 오라클, 짧은 시간 차이가 중요한 마켓메이커, 실시간 거래 애플리케이션에는 이러한 변화가 의미 있을 수 있다.
리더가 블록을 만들 수 있는 시간도 줄어든다
솔라나에서는 한 리더가 연속으로 4개 슬롯을 담당한다.
연속 슬롯 수는 이번 업그레이드에서도 바뀌지 않았다. 대신 슬롯 시간이 짧아졌기 때문에 리더 한 명이 연속으로 블록을 생성할 수 있는 실제 시간은 줄었다.
- 400ms × 4개 = 1.6초
- 350ms × 4개 = 1.4초
- 200ms × 4개 = 0.8초
리더가 거래를 지연하거나 재배열할 수 있는 최대 시간이 줄어든다는 점은 시장 구조상 장점이 될 수 있다.
반면 다음 리더에게 블록을 전파하고 상태를 넘겨줄 시간도 짧아진다. 검증인 입장에서는 더 촘촘한 시간 안에 블록 생성과 전파, 재생, 투표를 마쳐야 한다.
최종 목표는 200ms다
SIMD-0525는 한 번에 400밀리초에서 200밀리초로 전환하지 않는다.
각 단계는 별도의 기능 게이트로 나뉜다.
- 400ms에서 350ms
- 350ms에서 300ms
- 300ms에서 250ms
- 250ms에서 200ms
각 단계에서 네트워크의 블록 누락률과 검증인 성능, 데이터 전파 상태를 확인할 수 있다.
문제가 발견되면 다음 단계의 적용을 미룰 수 있다. 단계적 전환 자체가 네트워크 안전장치인 셈이다.
테스트넷에서는 메인넷보다 빠르게 단축 실험이 진행됐다. 하지만 테스트넷에서 200밀리초에 근접한 성능을 달성했다고 해서 메인넷도 곧바로 같은 상태로 전환되는 것은 아니다.
메인넷은 더 큰 경제적 가치와 다양한 검증인 환경을 가지고 있어 단계별 검증이 필요하다.
에포크도 실제 시간상 짧아진다
솔라나는 에포크당 슬롯 수를 기존과 동일한 432,000개로 유지한다.
슬롯이 빨라지면 하나의 에포크가 끝나는 데 걸리는 실제 시간은 짧아진다.
| 목표 슬롯 시간 | 예상 에포크 시간 |
|---|---|
| 400ms | 약 48시간 |
| 350ms | 약 42시간 |
| 300ms | 약 36시간 |
| 250ms | 약 30시간 |
| 200ms | 약 24시간 |
슬롯 시간을 절반으로 줄이는 최종 단계에서는 에포크도 약 이틀에서 하루로 줄어든다.
이 변화는 보상과 인플레이션 계산에도 영향을 줄 수 있다. 프로토콜은 1년 동안 발생하는 슬롯 수를 조정해 실제 시간 기준 발행량이 의도하지 않게 늘어나지 않도록 설계됐다.
외부 프로그램에는 별도의 문제가 생긴다
솔라나 외부에서 작동하는 일부 프로그램은 슬롯당 400밀리초가 고정값이라고 가정한다.
예를 들어 특정 프로그램이:
경과시간 = 슬롯 차이 × 0.4초
로 계산한다면 350밀리초 전환 이후 실제 시간과 오차가 발생한다.
영향을 받을 수 있는 시스템은 다음과 같다.
- 블록 탐색기
- 지갑과 거래소
- 인덱서
- 데이터 분석 서비스
- 오라클 기반 애플리케이션
- 슬롯을 시간으로 환산하는 스마트계약
- 검증인 모니터링 도구
개발자는 슬롯 수를 고정된 시간으로 환산하지 말고 네트워크가 실제로 사용하는 파라미터를 확인하는 방식으로 수정해야 한다.
검증인이 감당해야 할 부담
초당 연산 한도를 유지하더라도 검증인의 모든 부담이 그대로인 것은 아니다.
슬롯이 더 자주 생성되면 같은 시간 동안 처리해야 하는 투표와 네트워크 메시지 횟수가 늘어난다. 리더 전환도 더 자주 발생한다.
검증인이 확인해야 할 지표는 다음과 같다.
- 블록 누락률
- 투표 도착시간
- 리더 전환 실패
- 블록 전파 지연
- 재생 처리시간
- 네트워크 대역폭
- CPU와 메모리 사용량
최종 200밀리초 단계에서는 현재보다 같은 시간에 발생하는 슬롯 수가 두 배가 된다.
연산량은 비례 조정되더라도 투표와 통신, 리더 교체 빈도에서 발생하는 부담은 커질 수 있다.
TPS만 보면 이번 업그레이드를 오해할 수 있다
이번 변화의 핵심을 ‘솔라나 TPS 상승’으로 설명하면 실제 설계 의도를 놓치게 된다.
슬롯 시간 단축의 우선 목표는 다음과 같다.
- 거래 확인 지연시간 단축
- 더 세밀한 온체인 시간 단위
- 리더 독점시간 축소
- 실시간 금융 애플리케이션의 반응 개선
- 향후 성능 개선을 위한 기반 마련
초당 연산 한도는 기존 수준을 유지하도록 설계됐기 때문에 단축 직후 처리량이 자동으로 증가하는 것은 아니다.
향후 슬롯당 블록 한도를 별도의 업그레이드로 높이면 더 짧은 슬롯과 결합해 처리량이 증가할 수 있다. 그러나 그것은 이번 슬롯 시간 단축과 구분해야 한다.
성공 여부는 실제 네트워크 지표가 결정한다
350밀리초 적용은 솔라나가 출시 당시의 시간 기준에서 벗어난 첫 변화라는 점에서 의미가 크다.
하지만 목표 시간이 줄었다는 사실만으로 업그레이드가 성공했다고 판단할 수는 없다.
앞으로 확인해야 할 것은 다음 네 가지다.
- 실제 평균 슬롯 시간이 350밀리초에 안정적으로 가까워지는가
- 블록 누락률이 증가하지 않는가
- 검증인 성능 격차가 커지지 않는가
- 사용자 체감 확인시간이 실제로 줄어드는가
이 지표가 안정적으로 유지돼야 다음 단계인 300밀리초 전환도 진행될 수 있다.
솔라나는 더 많은 일을 한 번에 처리하는 대신 기존 작업량을 더 짧은 시간 조각으로 나누는 방향을 먼저 선택했다.
따라서 이번 업그레이드의 의미는 ‘TPS가 즉시 늘었다’가 아니라 ‘같은 초당 연산 한도를 유지하면서 네트워크 반응시간을 줄이기 시작했다’는 데 있다.
※ 이 글은 블록체인 프로토콜과 네트워크 데이터에 대한 정보 제공을 목적으로 하며 특정 암호화폐나 금융상품의 매수·매도를 권유하지 않습니다. 메인넷 슬롯 시간과 성능 지표는 네트워크 상태에 따라 달라질 수 있습니다.
