옵티미즘(OP) 메인넷의 서브블록 생산 간격이 250밀리초에서 200밀리초로 줄었다. 거래 피드백 주기는 더 짧아졌지만 일부 원시 데이터 필드가 0값으로 내려오면서 애플리케이션과 RPC 제공자의 검증 부담이 커졌다는 평가다.
옵티미즘 상태 페이지는 OP 메인넷의 '200ms subblocks' 전환이 9월 1일 오전 5시16분 한국시간 완료됐다고 밝혔다. 이번 작업은 250밀리초 플래시블록 생산에서 200밀리초 서브블록 생산으로 옮기는 시퀀서 인프라 전환의 일부로 진행됐다.
이번 변화의 핵심은 속도 자체보다 데이터 해석에 있다. 퀵노드 상태 공지는 OP 스택 서브블록 전환 과정에서 state_root, block_hash, withdrawals_root, withdrawals 네 필드가 zero value로 바뀐다고 밝혔다. receipts_root와 logs_bloom은 실값을 유지한다고 설명했다.
페이로드 형식이 유지되면 파싱 오류가 곧바로 발생하지 않을 수 있다. 그러나 개발자가 0값으로 내려온 필드를 실제 상태값처럼 받아들이면 잔액 확인, 상태 증명, 출금 관련 처리에서 조용한 호환성 문제가 생길 수 있다.
서브블록은 최종 확정 블록이 아니다. OP 스택 사양은 플래시블록 기본 시간을 200밀리초로 제시하고, 프리컨펌 단계에서 blockHash 같은 값이 placeholder가 될 수 있다고 설명한다. 이는 사용자가 거래 결과를 더 빨리 확인하도록 돕는 장치이지만 최종 상태 검증에는 별도 처리가 필요하다는 뜻이다.
플래시블록은 거래가 완전히 확정되기 전 블록 일부 정보를 짧은 주기로 흘려보내는 구조다. 통상 레이어2 네트워크는 사용자의 체감 지연을 줄이기 위해 프리컨펌 신호를 제공하지만, 이 신호는 최종 블록 데이터와 같은 신뢰 수준으로 다루기 어렵다.
공용 접속 경로에도 제한이 있다. 옵티미즘 공식 문서는 OP 메인넷 플래시블록 웹소켓 주소를 공개하면서 해당 공용 URL이 강한 속도 제한을 받는다고 안내했다. 공용 RPC URL은 웹소켓 연결을 지원하지 않으며, 웹소켓 기능이 필요하면 자체 노드를 운영하거나 제3자 RPC 제공자를 이용하라고 설명했다.
외부 인프라 업체 문서도 같은 방향을 가리킨다. 알케미(Alchemy)는 OP 메인넷 플래시블록을 200밀리초마다 부분 블록 업데이트를 제공하는 기능으로 설명했다. 퀵노드(QuickNode)는 pending 태그를 통해 최신 플래시블록 상태를 조회할 수 있고, 웹소켓으로 실시간 플래시블록 데이터를 받을 수 있다고 안내했다.
운영 현장에서는 공개 엔드포인트와 클라이언트 호환성이 변수로 드러났다. 옵티미즘 개발자 깃허브 토론에는 플래시블록 웹소켓 주소를 묻는 질문과 공개 WSS 접속 제한을 지적하는 반응이 올라왔다. 공개 엔드포인트보다 외부 RPC 제공자를 쓰라는 답변도 확인됐다.
별도 깃허브 이슈에서는 op-reth 도커 이미지가 플래시블록 WSS에 연결할 때 TLS support not compiled in 오류를 냈다는 보고가 있었다. 속도 개선이 체감되더라도 클라이언트 배포판, TLS 지원, 웹소켓 연결 방식이 실제 서비스 적용의 병목이 될 수 있다는 의미다.
이번 전환은 네트워크 장애라기보다 데이터 품질과 전달 경계의 문제에 가깝다. 옵티미즘 상태 페이지는 전환 뒤 OP 메인넷을 정상 운영 상태로 표시했다. 문서들도 이번 변화를 성능 개선과 호환성 조정으로 설명한다.
시장 구조상 이런 변화는 RPC 제공자와 지갑, 블록 탐색기, 온체인 데이터 서비스에 먼저 영향을 준다. 최종 블록만 읽는 일반 이용자 서비스보다 서브블록 스트림을 직접 소비하거나 원시 페이로드를 고객에게 전달하는 서비스가 더 민감하다.
국내 이용자에게도 접점은 있다. 국내 거래소나 지갑이 OP 메인넷 입출금, 잔액 표시, 컨트랙트 호출 상태를 외부 RPC 제공자에 의존한다면 프리컨펌 데이터와 최종 데이터의 경계를 구분해야 한다. 다만 자료상 국내 사업자의 장애나 입출금 중단 사례는 제시되지 않았다.
옵티미즘은 최근 거버넌스와 생태계 재편 이슈도 이어왔다. 본지는 앞서 사용자 에어드롭 잔여 배정분 5억4690만 OP를 전략 생태계 펀드로 재지정하는 안건이 승인됐다는 내용을 전했다. 이번 서브블록 전환은 토큰 배분 이슈와 별개로 OP 메인넷의 실행 인프라를 조정한 사안이다.
서비스 운영자는 네 필드의 0값이 상태, 잔액, 증명 입력으로 흘러가지 않도록 처리해야 한다. 특히 pending 상태와 최종 블록 데이터를 같은 기준으로 표시하거나 저장하는 구조라면 플래시블록 수신 경로, 웹소켓 연결 방식, RPC 제공자별 응답 형식을 함께 점검해야 한다.
<저작권자 ⓒ TokenPost, 무단전재 및 재배포 금지>
많이 본 기사