190억 달러 청산 당일, 라이터는 왜 "폐쇄"했는가?

10월 11일, 암호화폐 시장은 역사상 최대 규모의 마진 콜을 기록하며 총 약 190억 달러 규모의 청산을 단행했습니다. 이 극심한 시장 상황 속에서 여러 탈중앙화 무기한 스왑 거래 플랫폼(PerpDex)이 마비되었고, 특히 Lighter가 가장 큰 피해를 입었습니다. 이로 인해 유동성 공급자 풀(LLP)의 손실이 발생하면서 PerpDex 플랫폼에 대한 시장의 광범위한 논의가 촉발되었습니다.

Surf Protocol과 Tifo.trade를 포함한 여러 Perp Dex 플랫폼을 감사한 Web3 보안 회사인 Beosin은 수년간 축적된 기술과 온체인 데이터 분석 경험을 활용하여 이 기사에서 모든 사람이 Lighter 서비스 중단의 원인을 더 잘 이해할 수 있도록 도울 것입니다.

더 가벼운 기술 프레임워크

Lighter는 PerpDex 열풍 속에서 거래 수수료가 없다는 장점으로 두각을 나타내며 수많은 사용자를 플랫폼으로 유치했습니다. Lighter는 거래 성능과 주문장 매칭 효율성을 향상시키기 위해 특수 ZK Rollup L2인 zkLight를 기반으로 구축되었습니다. 핵심 운영 메커니즘은 다음과 같습니다.

분류기: 사용자 상호작용의 첫 번째 단계로서, 거래 지시를 수신하고, 거래를 분류하고, 이를 일괄 처리(거래의 일괄 데이터 패킷)로 패키징하는 역할을 합니다.

매칭 엔진은 시퀀서로부터 배치를 수신하고 "가격 우선, 시간 우선" 매칭 로직을 엄격히 준수합니다. 각 매칭이 성공할 때마다 영지식 증명을 생성하기 위한 데이터를 준비하여, 누구나 매칭 과정의 공정성을 검증할 수 있도록 하고 조작을 방지합니다.

증명자: 매칭 엔진의 연산을 간결한 ZK-SNARK 증명으로 생성하여 이후 매칭 실행과 상태 전환의 정확성을 검증합니다.

메인넷 컨트랙트: 증명자가 제출한 영지식 증명을 검증하는 역할을 합니다. 검증이 완료되면 상태 루트가 업데이트되고, 거래 결과가 이더리움에서 최종적으로 확인됩니다.

위의 기능 외에도 Lighter는 사용자에게 금고 기능을 제공하여 Lighter 유동성 풀(LLP)에 자금을 예치할 수 있도록 합니다. 이 유동성 풀은 유동성 공급자, 가격 생성기, 그리고 위험 관리 플랫폼 역할을 합니다. LLP 참여자는 플랫폼 수익과 거래상대방 손실을 공유하는 동시에, 사용자의 마진콜 발생 시 일부 위험을 감수하여 Lighter의 청산 시스템과 연계된 위험 완충 메커니즘을 형성합니다.

더 가벼운 다운타임 검토

2025년 10월 11일, 암호화폐 시장에서 기록적인 계약 청산이 발생했습니다. 이러한 극심한 시장 상황 속에서 Lighter는 수 시간 동안 서비스 중단을 경험하여 사용자들이 포지션을 운영할 수 없게 되었고, 이로 인해 약 5.35%의 LLP 손실이 발생했습니다.

Beosin은 이 사건이 발생한 주요 기간(2025년 10월 11일 베이징 시간 00:17-05:08) 동안 온체인 데이터를 분석한 결과 Lighter가 배치 #55661부터 시작하여 3개의 배치를 손실했고 00:17에 배치 생산을 재개한 것을 발견했습니다(00:23 Lighter는 사용자의 주문을 처리하거나 실행할 수 없다는 공지를 발표했습니다).

서비스 중단 전 Lighter 플랫폼은 일반적으로 분당 약 4,005건의 거래를 처리했습니다. 00:17부터 거래량이 급증했습니다. 배치 #55665는 560개의 블록을 포함하고 196,913건의 거래를 처리했습니다. 평균적으로 분당 약 65,638건의 거래가 처리되었는데, 이는 평소 거래량의 약 16배에 달합니다.

다음은 10월 11일 00:17부터 05:08까지 각 배치 제출 시점에 처리된 거래 수에 대한 통계 차트입니다.

 Beosin Statistics에서 제작

10월 11일 오전 4시 56분, 배치 #55743은 최대 거래 수에 도달하여 2분 만에 639,370건의 거래를 완료했습니다. 이는 분당 평균 거래량의 79.8배에 달하는 수치입니다. 이 사고에서 Lighter의 데이터를 분석한 결과, Lighter의 배치는 최대 1,600개의 블록을 수용할 수 있으며, 각 블록은 최대 500건의 거래를 수용할 수 있습니다. 배치당 이론적 최대 거래 수는 800,000건이지만, 실제 처리된 최대 거래 수는 639,370건이었습니다.

위 거래는 Lighter 플랫폼에서 성공적으로 처리된 거래입니다. 그러나 많은 사용자가 거래 제출 실패(다운타임)로 인해 포지션을 조정하지 못하여 체인에 데이터가 기록되지 않았습니다. 기술 아키텍처 관점에서 볼 때, 이러한 다운타임과 이로 인한 LLP 손실은 주로 두 가지 원인으로 인해 발생합니다.

1. 프런트엔드 페이지 접근 및 주문 제출 문제 외에도 Lighter의 ZK Rollup은 거래 정렬 및 패키징을 위해 단일 시퀀서를 사용합니다. ZK Proof가 결과 검증에 사용되지만, 시퀀서의 중앙 집중화로 인해 단일 장애 지점 위험이 발생합니다. 가격 하락 기간에는 시퀀서와 데이터베이스가 갑작스러운 부하를 감당하지 못해 데이터베이스 인덱스 손상 및 거래 차단이 발생하고, 이는 매칭 엔진과 클라이언트 간의 직접적인 단절로 이어집니다.

2. 거래량이 급증하면 증명 생성 노드와 데이터베이스의 조율된 처리 능력이 ZK-SNARK 증명 생성 및 제출 프로세스에 병목 현상을 일으킵니다. 극한의 시장 상황에서는 거래 매칭 및 청산 작업이 동시에 급증하여 ZK 증명 생성 노드에 요청이 동시에 발생합니다. 플랫폼이 청산과 같이 우선순위가 높은 작업에 대한 리소스 예약 메커니즘을 구현하지 않았을 수 있습니다. 이로 인해 일반 거래와 청산 증명 생성 요청 간에 리소스 경쟁이 발생하여 시스템 응답 지연이 더욱 심화되고 청산 프로세스가 신속하게 실행되지 못하여 사용자 손실이 심화됩니다.

운영 측면에서 Lighter CEO 블라디미르 노바코브스키는 "Lighter는 원래 최근 폭락 주말에 거래 수요 증가에 대응하기 위해 데이터베이스를 업그레이드할 계획이었습니다."라고 답했습니다. 이 사건은 이 "잘못된 업그레이드 기간"이 시장 위험에 대한 팀의 미흡한 준비에서 비롯되었음을 시사합니다. 플랫폼의 급속한 확장 과정에서 적시에 인프라 업그레이드를 완료하지 못하여 극심한 시장 상황에서 시스템 장애가 발생했고, 이는 결국 시스템 장애로 이어졌습니다.

이 사건은 PerpDex가 직면한 핵심 과제, 즉 극한의 시장 상황에서 플랫폼 운영을 정상적으로 유지하는 방법을 보여줍니다. 스마트 계약 보안과 관련하여 PerpDex 프로젝트 팀은 포괄적이고 전문적인 계약 보안 감사를 수행해야 합니다. Beosin은 이전에 Surf Protocol 및 Tifo.trade와 같은 PerpDex 프로젝트에 보안 감사 서비스를 제공했습니다. 이러한 감사는 스마트 계약 코드의 보안, 비즈니스 구현 로직의 정확성(레버리지 거래, 청산, 유동성 풀 관리 등), 계약 코드 가스 최적화, 그리고 잠재적 취약점의 발견 및 해결을 다룹니다. Beosin은 프로젝트 팀이 여러 중위험 및 고위험 취약점을 해결하는 데 성공적으로 지원했습니다.