2023년 5월 11일과 12일 이더리움에서는 거래 최종성에 일시적인 지연이 발생했습니다. Prysm 개발팀의 사후 보고서는 블록 생성 감소와 최종화 지연을 구분해 설명했습니다. 이 사건을 체인이 완전히 멈췄다는 한 문장으로 요약하면 실제 상태를 놓칠 수 있습니다. 블록이 보이는 것, 거래가 포함된 것, 경제적 최종성을 얻은 것은 서로 다른 단계이기 때문입니다.

Wikimedia Foundation Servers-8055 08.jpg · Victorgrigas · CC BY-SA 3.0 · 대표 이미지용 중앙 3:2 자르기, 크기 조정 및 WebP 변환
포함과 최종화의 구분
이용자는 보통 지갑에 성공 표시가 나오면 처리가 끝났다고 생각합니다. 그러나 성공 표시는 거래 실행 결과를 뜻할 수 있으며 네트워크의 최종화 상태와 같지 않을 수 있습니다. 이더리움의 지분증명은 검증자 투표를 통해 체크포인트를 확정하는 구조를 갖습니다. 분석에서 확정이라는 단어를 사용할 때는 단순한 블록 포함인지 최종화인지 먼저 정의해야 합니다.
가상의 전송이 블록 A에 포함되었지만 마지막 최종화 체크포인트가 그보다 앞에 있다면 두 정보가 동시에 참일 수 있습니다. 탐색기에 거래가 보인다는 사실만으로 모든 외부 서비스가 자금을 사용할 수 있게 했다고 말할 수 없습니다. 거래소나 브리지는 자체 확인 정책을 적용할 수 있습니다. 이용자 입장에서 완료 여부는 체인의 상태와 서비스의 반영 상태를 함께 확인해야 하는 문제입니다.
당시 보고서에서 확인할 사실
Prysm 팀은 두 차례 사건과 복구 경과를 공개했고, 원인 조사 및 클라이언트 수정 내용을 남겼습니다. 보고서의 블록 누락 수나 보상 손실 추정은 해당 팀이 설명한 범위의 수치입니다. 이를 모든 이용자의 금전 손실로 바꾸어 인용해서는 안 됩니다. 특히 검증자 미수령 보상, 실제 부과된 페널티, 사용자 자산 손실은 서로 다른 항목입니다.

public/content/developers/docs/consensus-mechanisms/pos/attestations/attestation_schematic.png · ethereum.org contributors · MIT · 원본 비율 유지, 크기 조정, 흰 배경 합성 및 WebP 변환
같은 사건을 보도한 자료마다 에포크 수가 다르게 보인다면 계산 시작점과 최종성 지연의 정의를 비교해야 합니다. 최초 이상 감지 시각, 정상적인 확정이 예상된 시각, 복구가 확인된 시각은 다를 수 있습니다. 단순히 가장 큰 숫자를 골라 장애 시간을 정하기보다 공식 보고서의 시간축을 먼저 읽고 어떤 구간을 측정했는지 설명하는 편이 재현 가능합니다.
응용 서비스에 전파되는 영향
최종성을 기다리는 서비스는 블록이 계속 생성되어도 자산 반영을 늦출 수 있습니다. 반대로 자체 정책상 더 이른 단계에서 처리하는 서비스도 있을 수 있습니다. 따라서 한 브리지가 멈췄다고 모든 이더리움 거래가 불가능했다고 일반화하지 않습니다. 서비스별 영향은 해당 운영자의 공지와 실제 상태 기록을 대조해야 하며, 체인 지표만으로 모두 추론할 수는 없습니다.
시장 가격 역시 기술 상태와 별도의 관측입니다. 거래소에서 ETH가 거래되었다고 최종성 문제가 없었다는 뜻은 아니고, 가격이 움직였다고 그 변화 전부가 장애 때문이라는 뜻도 아닙니다. 같은 시간대의 전체 시장 변화와 공지 전달 시차를 함께 확인해야 합니다. 문제를 처음 알게 된 시각과 네트워크에서 실제로 발생한 시각이 달랐을 가능성도 고려합니다.

public/content/developers/docs/nodes-and-clients/client-diversity/client-diversity.png · ethereum.org contributors · MIT · 원본 비율 유지, 크기 조정, 흰 배경 합성 및 WebP 변환
클라이언트 다양성 읽기
여러 구현체를 사용하는 구조는 동일한 소프트웨어 문제가 모든 참여자에게 퍼지는 위험을 줄이는 데 중요합니다. 하지만 구현체 이름의 개수가 많다는 것만으로 충분한 분산을 증명하지는 못합니다. 실제 검증 지분의 분포, 공통 의존성, 운영 방식이 함께 영향을 줍니다. 특정 팀의 수정 버전 발표는 대응의 증거이지만 네트워크 전체가 즉시 업데이트했다는 증거와는 구분해야 합니다.
운영자가 클라이언트를 바꿀 때에도 복구를 서두르는 것과 안전하게 전환하는 것은 별개의 과제입니다. 동시에 같은 검증자 키를 여러 곳에서 가동하는 등 잘못된 전환은 새로운 위험을 만들 수 있습니다. 일반 독자는 직접 검증자를 운영하지 않더라도 사후 보고서가 원인, 영향, 수정, 재발 방지 항목을 나누어 공개하는지 확인할 수 있습니다. 공개의 상세함과 완벽한 안전을 같은 의미로 보지는 않습니다.
이 사건을 복기하는 표에는 최신 블록 시각, 최종화된 체크포인트, 참여 지표, 서비스 공지를 나란히 놓습니다. 각 행의 단위와 조회 시각을 맞추면 일부 기능의 유지와 일부 확정 과정의 지연이 동시에 일어날 수 있음을 이해하기 쉽습니다. 2023년 사례에서 얻을 교훈은 정상과 장애를 이분법으로 표시하는 대신 어떤 단계가 지연되었는지 묻는 것입니다. 현재 가동 상태나 미래 가격을 예측하는 분석은 아닙니다.
Bình luận 0
Đang kiểm tra trạng thái đăng nhập.
Đăng nhập với Google · Chia sẻ ý kiến liên quan và lịch sự.