솔라나가 검증자 간 조정에 적용되는 목표 슬롯 시간을 250밀리초(ms)로 단축했다. 이번 조정은 9월 18일 Epoch 1037부터 적용됐다. 블록 생성 간격이 짧아지면서 거래가 블록에 포함될 기회는 늘어나지만, 검증자가 리더 교체 과정에서 거래를 받고 데이터를 전달한 뒤 블록 생성을 시작할 수 있는 시간도 함께 줄어든다. 네트워크의 핵심 과제는 평균 지연시간을 낮추는 데 그치지 않고, 더 좁아진 시간 안에 리더 교체와 거래 반영, 장애 복구를 안정적으로 수행하는 데 있다.
SOL은 현재 109.89달러로, 24시간 기준 0.90% 하락했으며 30일 기준으로는 20.71% 상승했다. 다만 슬롯 시간 조정 자체를 토큰 가격 신호로 해석할 수는 없다. 시장은 이번 변경이 네트워크 가용성, 거래 확인 경험, 검증자 운영비용에 장기적으로 어떤 영향을 미치는지 지켜볼 필요가 있다.
Epoch 1037 초기 수치…평균 슬롯은 약 266ms
솔라나 엔지니어링 업데이트에 따르면 250ms 목표 슬롯 시간은 Epoch 1037에서 활성화됐으며, 전환 시점은 9월 18일 05시 06분(UTC) 전후였다. 9월 20일 1분 단위 60개 구간을 대상으로 한 초기 표본에서 실제 생성된 슬롯의 평균 간격은 약 266ms로 집계됐다. 해당 Epoch에서 예정된 슬롯 중 건너뛴 슬롯의 비율은 약 0.05%였다.
전환 직후 단기 운용에서는 건너뛰기 비율이 뚜렷하게 악화되지 않았다는 의미다. 그러나 관측 기간이 짧아 장기 성과를 판단하기에는 부족하다. 보다 유의미한 평가는 일정 기간 동안의 슬롯 지속시간, 건너뛰기 비율, 거래 반영률, 리더 교체 상태를 함께 확인해야 한다. 가능하다면 클라이언트 유형과 인프라 제공업체별로 데이터를 나눠야 네트워크 전체 평균이 특정 검증자 집단의 취약성을 가리는 문제를 피할 수 있다.
솔라나는 조건이 충족될 경우 슬롯 시간을 200ms까지 추가로 단축하는 방안도 검토하고 있다. 9월 20일 이전까지 200ms의 메인넷 적용일은 확정되지 않았으며, Anza의 기능 플래그 일정에도 구체적인 출시일은 제시되지 않았다. 솔라나가 공개한 슬롯 시간 단축 설명에서도 네트워크 성능과 건너뛰기 비율이 추가 조정의 주요 조건으로 언급됐다.
슬롯이 짧아져도 초당 처리량이 자동으로 늘지는 않아
슬롯 시간이 줄어드는 데 맞춰 SIMD-0525 설계 초안은 개별 슬롯에 허용되는 계산 작업 한도를 낮췄다. 250ms 단계에서는 슬롯당 예산이 6,250만 컴퓨트 유닛으로 설정된다. 200ms 단계로 넘어가면 이 예산은 5,000만 컴퓨트 유닛으로 줄어든다. 두 설정 모두 명목상 프로토콜 처리 한도는 초당 약 2억5,000만 컴퓨트 유닛에 가깝다.
따라서 이번 조정은 단순히 단위 시간당 계산 용량을 늘리는 변화라기보다, 거래가 블록에 들어가는 속도와 지연시간을 바꾸는 조치에 가깝다. 블록 생성 빈도는 높아지지만 각 블록에 담을 수 있는 작업량은 줄어든다. 실제 처리량은 거래 수요, 스케줄링 방식, 리더가 가용 블록 공간을 얼마나 효율적으로 채우는지에 따라 달라진다.
리더가 연속으로 4개 슬롯을 맡는 규칙은 그대로 유지된다. 250ms 기준으로 각 리더에게 주어지는 명목상 블록 생성 창은 약 1초다. 슬롯 시간이 200ms로 줄면 이 창은 800ms로 단축된다. 이용자에게는 거래가 블록에 포함될 기회가 더 자주 돌아오지만, 검증자는 더 짧은 시간 안에 트래픽 수신과 데이터 전파, 생성 주체 전환을 모두 완료해야 한다.
지리적 거리가 리더 교체 시간을 잠식
솔라나 재단의 엔지니어링 분석에 따르면 연속된 리더 간 거리가 500km 미만일 때 첫 번째 슬롯은 뒤따르는 슬롯보다 중간값 기준 약 28ms 짧았다. 거리가 8,000km를 넘으면 이 차이는 약 122ms로 확대됐다. 이는 200ms 목표 슬롯 시간의 61%에 해당한다.
이 지표는 리더가 담당하는 첫 번째 슬롯과 이후 슬롯을 비교한 것으로, 순수한 네트워크 전송 지연만을 의미하지는 않는다. 그럼에도 슬롯 시간이 짧아질 때 발생하는 현실적인 절충을 보여준다. 검증자를 지리적으로 분산하면 특정 지역에 대한 의존도를 낮출 수 있지만, 장거리 리더 교체가 전체 블록 생성 시간에서 차지하는 비중은 커질 수 있다.
솔라나는 9월 18일 엔지니어링 업데이트에서 교체 시간 창을 보호하기 위한 두 가지 작업을 언급했다. Agave 개발자들은 거래가 원래 지정된 목적지에 제때 도착하기 어려울 가능성이 있을 때 다음 리더에게 미리 전달하는, 보다 보수적인 전파 방식을 검토하고 있다. 또한 여러 클라이언트 팀은 일관된 바이너리를 사용해 서로 다른 구현과 버전에서 블록 실행 및 거래 실행 결과를 시험하고 있다.
장애 복구에도 시간 제약이 따른다. SIMD-0525 초안은 200ms 단계에서도 250ms의 복구 지연 임계값을 유지하도록 했다. 이 지연시간은 목표 슬롯 하나보다 길다. 이는 현재 네트워크에 장애가 발생했다는 뜻이 아니라 엔지니어링 설계상 여유를 남겨둔 것이다. 다만 더 낮은 지연시간을 구현하려면 복구와 전파, 실행 과정도 더 빨라져야 한다는 점을 보여준다.
TeraSwitch 장애가 드러낸 인프라 집중도
8월 12일 TeraSwitch에서 발생한 라우팅 장애는 250ms 조정보다 앞서 발생했으며, 슬롯 시간 단축 때문에 발생한 사건도 아니다. 다만 여러 검증자가 동일한 호스팅 또는 네트워크 라우팅 인프라에 의존할 경우, 겉으로는 독립된 노드들이 동시에 영향을 받을 수 있다는 점을 보여줬다.
TeraSwitch 사고 기록에 따르면 12개 사이트가 네트워크 연결성을 잃었고, 이 가운데 마이애미의 한 사이트는 격리를 위해 제거됐다. Solana Compass의 추산으로는 약 33분 동안 네트워크 스테이킹 물량의 약 28.83%가 연결이 끊겼거나 비활성 상태에 놓였다. 솔라나 재단은 이 기간에도 블록 생성이 계속됐고 거래도 네트워크에 반영됐다고 밝혔다.
네트워크가 중단되지는 않았지만, 이 사건은 검증자 수만으로 탈중앙화 수준을 충분히 설명하기 어렵다는 점을 보여준다. 9월 7일의 한 독립 데이터에서는 솔라나의 스테이킹 기준 나카모토 계수를 18로 제시했으며, 최대 검증자는 활성 스테이킹 물량의 약 4%를 차지했다. 같은 날 호스팅 기준으로는 TeraSwitch와 연관된 활성 스테이킹 물량의 비율이 22.1%로 집계됐다.
솔라나 재단은 별도 설명에서 TeraSwitch가 ‘지난해’ 한때 약 38%의 스테이킹 물량을 호스팅했지만 이후 30% 아래로 낮아졌다고 밝혔다. 각 수치의 기준일과 산출 방식이 완전히 같지는 않기 때문에, 9월 7일의 22.1%는 과거 수치와 직접 연결해 연속적인 추이를 만들기보다는 현재 시점에 대한 독립적인 관측치로 보는 편이 적절하다.
소프트웨어 클라이언트 구성은 또 다른 잠재적 장애 영역이다. 9월 20일 스테이킹 가중치 기준으로 조회한 결과, 약 87.4%의 스테이킹 물량이 4.x 클라이언트 버전을 사용했고 7.3%는 0.x 버전, 5.3%는 26.x 버전을 사용했다. 대버전 번호는 Agave 계열, Frankendancer, Firedancer 소프트웨어를 대략적으로 구분하는 표지일 뿐, 모든 스케줄러 변형이나 하위 빌드 버전까지 식별하지는 못한다.
세 가지 수치는 서로 다른 질문에 답한다. 검증자 스테이킹 집중도는 어느 정도의 리더가 장애를 일으키거나 공동으로 행동해야 눈에 띄는 영향이 발생하는지를 보여준다. 클라이언트 계보는 검증자들이 공통 소프트웨어 결함에 얼마나 노출돼 있는지를 나타낸다. 호스팅업체 비중은 특정 서비스 제공업체나 동일한 라우팅 영역의 장애로 동시에 영향을 받을 수 있는 스테이킹 물량을 보여준다. 250ms 슬롯이 이러한 집중도를 만든 것은 아니지만, 더 짧아진 리더 교체 및 복구 시간은 관련 장애의 결과를 키울 수 있다.
200ms 적용에는 더 긴 운용 데이터가 필요
현재 250ms 단계의 초기 데이터에서 건너뛰기 비율이 갑자기 악화된 징후는 나타나지 않았다. 그러나 단일 Epoch와 약 60분의 표본만으로 200ms 도입을 판단하기에는 충분하지 않다. 보다 신중한 평가는 더 긴 운용 기간을 대상으로 하면서 네트워크 부하, 지역별 분포, 클라이언트 구성, 인프라 조건에 따른 결과를 함께 살펴봐야 한다.
Alpenglow는 별도의 기술 일정에 속한다. 이 합의 업그레이드는 약 150ms의 최종 확정 시간을 목표로 하지만, 슬롯 시간은 블록 생성 기회의 간격을 통제하는 지표이므로 두 수치는 같은 개념이 아니다. 솔라나 공식 페이지에 제시된 일정도 완전히 일치하지 않는다. 3분기 목표가 언급되는 한편, Agave 4.3을 통해 10월에 진행하는 일정도 제시돼 현재로서는 정확한 활성화 날짜가 확정되지 않았다.
앞으로 시장과 검증자가 확인해야 할 지점은 단기 테스트에서 나온 평균 속도만이 아니다. 더 작은 시간 여유 안에서 거래 전파, 리더 전환, 블록 복구, 서로 다른 클라이언트 구현이 계속 동기화될 수 있는지가 핵심이다. 지리적 거리와 호스팅업체, 소프트웨어 버전 때문에 일부 스테이킹 물량이 동시에 응답하지 못하는 상황에서 200ms 단계가 낮은 건너뛰기 비율을 유지할 수 있는지는, 솔라나가 슬롯 시간을 추가로 줄이기 전에 확인해야 할 실제 과제로 남아 있다.