작동 원리2026-10-22약 4분

Cronos v1.8: 빈 대기 거래 목록을 읽는 법

Cronos의 업그레이드 목표 높이가 탐색기에 기록됐다. 선택적으로 켜는 애플리케이션 mempool은 대기 거래가 보이는 곳과 빈 응답의 의미를 바꾼다.

AI로 생성한 개념 삽화. 기술자가 빈 칸 옆의 봉투가 든 칸으로 시선을 돌린다. 대기 거래를 보는 경로의 차이를 상징하며, 실제 장애나 Cronos 화면을 재현한 장면이 아니다.

핵심 요약

Chainstack은 10월 22일 08:00 UTC에 업그레이드 유지보수 완료를 기록했다. Cronos 탐색기는 목표 블록 101,485,000의 시각을 07:52:24 UTC로 표시하며 다음 블록과의 연결을 보여 준다.
애플리케이션 측 mempool은 선택 사항이다. 이를 켜면 일부 기존 대기 거래 조회는 비어 있고, txpool 메서드가 애플리케이션 대기열을 읽는다.
대기열 관리, 병렬 실행, 실험적 네트워킹은 별개의 변경이다. 목표 높이를 지났다는 사실만으로 모든 노드의 설정이나 실측 성능을 알 수는 없다.

사건의 흐름 한눈에 보기

2026-09-24v1.8.0 바이너리 공개

릴리스는 Pre-release로 표시되며 즉시 바이너리를 교체하지 말라는 안내를 담았다.

2026-10-14메인넷 업그레이드 설명

Cronos는 10월 22일을 예고하고 선택형 mempool, 병렬 실행, 실험적 libp2p를 구분했다.

2026-10-22탐색기에서 목표 높이 확인

블록 101,485,000의 시각은 07:52:24 UTC, Chainstack의 유지보수 완료 기록은 08:00 UTC다. 두 기록의 의미는 다르다.

목표 높이를 지났지만 기록의 의미는 다르다

Cronos는 EVM v1.8 메인넷 업그레이드를 2026년 10월 22일로 예고했다. 이제 일정 외의 기록도 확인할 수 있다. Chainstack의 공지는 목표 높이 101,485,000을 명시하고 08:00 UTC에 유지보수 완료를 기록했다. Cronos 탐색기는 해당 블록의 시각을 07:52:24 UTC로 표시하며, 다음 블록 101,485,001의 부모 해시는 그 블록을 가리킨다. 탐색기의 이력에서는 예고된 목표 높이를 지난 셈이다.^[1][3][4][5]

각 관측이 증명하는 범위는 다르다. 블록 시각은 체인 기록이고, 08:00은 운영사의 유지보수 기록이지 네트워크 전체의 정확한 활성화 순간을 측정한 값이 아니다. CoinYQ는 검증자들의 실제 실행 버전을 독립적으로 확인하지 않았다. 릴리스 페이지에는 v1.8.0이 여전히 Pre-release로 표시된다. 이 표기나 유지보수 완료 표시 하나만으로 모든 운영자가 어떤 옵션을 켰는지 판단할 수는 없다.^[3][4][5][6]

한 노드의 대기실을 보는 두 창

거래 목록을 읽는 사람이 놓치기 쉬운 변화는 선택형 대기열에 있다. mempool은 블록에 들어가기를 기다리는 거래를 담는 공간이다. 기존 Cronos에서는 합의 계층인 CometBFT가 이를 관리했지만, v1.8에서는 운영자가 그 일을 애플리케이션에 맡길 수 있다. 이전 지침은 이를 선택 사항으로 설명하며 기존 설정도 계속 작동한다고 명시한다.^[2]

이 선택에 따라 대기열을 들여다보는 창이 달라진다. 지침에 따르면 app 모드에서는 CometBFT의 /unconfirmed_txs와 /num_unconfirmed_txs에 대기 항목이 나오지 않으며, eth_newPendingTransactionFilter와 pending 필터도 결과를 반환하지 않는다. 대신 txpool_content와 txpool_status가 애플리케이션 대기열을 읽는다. flood 모드에서는 CometBFT의 대기 거래 조회가 작동하고, 해당 txpool 메서드는 비어 있는 애플리케이션 대기열을 본다. 따라서 어느 한 인터페이스의 빈 응답만으로 그 노드에 대기 거래가 없다고 결론 내릴 수 없다.^[2]

블록 앞의 일을 옮기고, 블록 안의 일을 나눈다

대기열을 옮기는 이유는 무엇일까. Cronos의 발표는 거래 접수와 블록 구성 과정에서 처리 작업을 공유해 중복 검증을 줄인다고 설명한다. 블록 처리 뒤의 재검증도 합의 경로에서 경쟁하는 대신 백그라운드에서 수행할 수 있다. 다음 블록을 준비하는 일을 배치하는 방식의 변화이며, 제출한 거래가 이미 블록에 포함되거나 확정됐다는 증거는 아니다.^[1][2]

Block-STM은 다른 단계를 맡는다. 블록 안의 거래를 병렬로 실행하고 충돌이 발견되면 영향을 받은 거래를 다시 실행하는 방식이다. 이전 지침은 이를 권장하지만 문서에 적힌 block-executor 기본값은 sequential이다. 소프트웨어 버전, 대기열 선택, 실행 모드는 각각 확인해야 한다. 애플리케이션 대기열을 켤 때도 호환되는 용량 설정이 필요하며, 대기열을 비활성화하는 문서상의 값 max-txs = -1은 app 모드와 함께 쓸 수 없다.^[1][2]

업그레이드만으로 정해지지 않는 것

다른 릴리스 항목도 적용 조건을 읽어야 한다. 10월 14일 발표는 libp2p 지원을 실험적 기능으로 설명하며 당시 메인넷에서는 활성화하지 않았다고 밝혔다. v1.8에 코드가 있다는 사실만으로 이후 활성화를 확인할 수는 없다. 이전 지침 역시 거래당 가스 상한 16,777,216은 업그레이드 높이에서 자동 적용되는 것이 아니라 별도의 거버넌스 변경이 필요하다고 설명한다. 이 글에서는 두 항목의 후속 변경을 확인하지 않았다.^[1][2]

대시보드를 만들거나 기다리는 거래를 조사한다면 먼저 해당 엔드포인트가 어느 대기열을 보여 주는지 확인해야 한다. 지침은 기존 대기 거래 조회가 필요한 이용자를 위해 flood 모드를 유지하거나, txpool 네임스페이스를 활성화하고 이용 측 조회를 그 메서드로 옮기도록 안내한다. 목표 높이를 지난 지금 이 차이가 실무적으로 중요해졌다. 빈 목록이 한산한 네트워크의 증거가 되는 것은 아니며, 실제 실행·조회 지연 측정까지 대신해 주지도 않는다.^[2][3][4]

다음 질문으로