PerpDex는 왜 "플레임 아웃"되었나요? 4시간 동안 라이터 다운 전체 리뷰

10월 11일, 암호화폐 시장은 총 청산가치가 약 190억 달러에 달하는 역사상 최대 규모의 폭락을 경험했습니다. 이 극심한 시장 시련 동안 여러 탈중앙화 무기한 계약 거래 플랫폼(Perp Dex)이 다운되었고, 다운타임 사고로 가장 심각한 영향을 받은 것은 라이트였으며, 유동성 공급자 풀(LLP)은 손실을 경험하면서 PerpDex에 대한 광범위한 논의가 이어졌습니다. 플랫폼에 대한 광범위한 논의가 이루어졌습니다.

서프 프로토콜, Tifo.trade 등 여러 퍼덱스의 감사인으로서 웹3.0 보안 기업 베오신이 다년간 쌓아온 기술 및 온체인 데이터 분석 경험을 통해 이 다운타임 이벤트의 원인을 심층적으로 분석하는 데 도움을 드리고자 이 기사를 작성했습니다.

라이터 기술 프레임워크

Lighter는 거래 수수료 제로로 PerpDex 열풍에서 두각을 나타내고 있습니다. 많은 사용자가 플랫폼에서 거래하도록 유도했습니다. Lighter는 거래 성능과 오더북 집계 효율성을 개선하기 위해 특정 ZK 롤업 L2인 zkLight를 기반으로 구축되었습니다. 핵심 운영 메커니즘은 다음과 같습니다:

Sequencer: 사용자 상호작용의 첫 번째 지점으로, 트랜잭션 명령을 수신하고 트랜잭션을 배치로 정렬 및 패키징하는 역할을 담당합니다.

요약 엔진: 시퀀서에서 Batch를 수신하고 "가격 우선, 시간 우선" 요약 로직을 엄격하게 따릅니다. >. 집계가 성공할 때마다 영지식 증명을 생성하기 위한 데이터를 준비하여 누구나 사후에 집계 과정의 공정성을 검증할 수 있도록 함으로써 조작의 가능성을 차단합니다.

Prover: 요약 엔진의 연산을 간결한 ZK-SNARK 증명으로 생성합니다. 요약 실행 및 상태 전환의 정확성에 대한 후속 검증을 위해 사용됩니다.

메인넷 컨트랙트: 증명자가 제출한 영지식 증명의 검증을 담당합니다. 검증이 완료되면 상태 루트가 업데이트되고 트랜잭션 결과가 이더리움에서 최종적으로 확정됩니다.

위와 같은 설계 외에도, 라이트는 사용자에게 라이트 유동성 풀(LLP)에 자금을 예치할 수 있는 기능을 제공합니다. 유동성 풀은 유동성을 제공하고 호가를 생성하며 위험을 감수합니다; LLP 참여자는 플랫폼의 수익과 거래 상대방 손실을 공유하고, 균형이 맞지 않는 포지션이 발생할 경우 일부 위험을 감수하여 Lighter의 청산 시스템과 함께 위험 완충을 형성합니다.

라이터 다운타임 요약

2025년 10월 11일, 암호화폐 시장 계약이 기록적인 규모로 청산되었습니다. 이 극심한 장세에서 라이트는 갑작스러운 수 시간 동안의 서비스 중단으로 인해 사용자들이 포지션을 운영할 수 없었고 LLP는 약 5.35%의 손실을 입었습니다.

보싱은 이 사건의 주요 시간대(2025년 10월 11일 00:17-05:08 BST)의 온체인 데이터 분석을 통해 다음과 같은 사실을 발견했습니다. 라이터는 배치#55661 이후 3개의 배치를 잃었으며, 00:17에 배치 생산을 재개하기 시작했습니다(00:23 라이터는 사용자의 주문을 처리하거나 실행할 수 없다는 공지를 올렸습니다).

다운타임 전 Lighter 플랫폼에서 처리된 정상적인 거래량은 분당 약 4005건이었으며, 00:17 이후부터 거래량이 급증했습니다, 배치#55665에는 다음 내용이 포함되었습니다. 배치#55665는 560개의 블록을 포함하고 196,913개의 트랜잭션을 처리했으며, 이는 분당 평균 약 65,638개의 트랜잭션으로, 평상시보다 약 16배 많은 수치입니다.

10월 11일 00:17-05:08의 각 배치 제출 시간대에 처리된 트랜잭션 수를 보여주는 차트입니다:

제공: Beosin Statistics 생산

10월 11일 04시 56분, 배치#55743은 2분 동안 최대 거래량인 639,370건을 처리해 평상시 분당 거래량 처리량의 79.7%를 기록했습니다. 분당 처리되는 트랜잭션 수의 79.8배. 이번 이벤트에 대한 Lighter의 데이터를 집계한 결과, Lighter의 배치는 최대 1,600개의 블록을 보관할 수 있고, 블록은 최대 500개의 트랜잭션을 보관할 수 있으며, 이론적인 트랜잭션 수는 배치당 800,000개이지만 측정된 최대치는 639,370개입니다.

이것은 Lighter의 배치가 사용된 첫 번째 사례입니다. p>

위는 Lighter 플랫폼에서 성공적으로 처리된 거래이며, 거래 제출 실패(다운타임)로 포지션 조정에 실패하여 체인에 데이터를 기록하지 못한 사용자들이 여전히 많이 있습니다. 기술 아키텍처의 관점에서 볼 때, 이러한 다운타임과 이로 인한 LLP 손실의 원인은 크게 두 가지입니다.

1. 프론트엔드 페이지에 액세스하고 주문을 제출하는 문제 외에도 라이트의 ZK 롤업은 거래 시퀀싱과 패키징을 위해 단일 시퀀서에 의존하며, 결과 검증은 ZK Proof를 통해 이루어지지만 시퀀서의 중앙 집중성으로 인해 단일 장애 지점 위험으로 이어집니다. 충돌이 발생하는 동안 시퀀서와 데이터베이스는 갑작스러운 부하를 감당할 수 없으며, 데이터베이스는 인덱스 손상 및 트랜잭션 차단을 경험할 수 있으며, 이는 집계 엔진과 사용자 측 간의 연결 중단으로 직결됩니다.

2. ZK-SNARK의 증명 생성 및 제출 프로세스 거래량이 갑자기 증가하면 데이터베이스와 연동하는 증명 생성 노드의 기능이 병목현상을 일으킵니다. 극단적인 조건에서는 거래 집계와 청산 작업이 동시에 급증하여 ZK 증명 생성 노드에 동시에 요청됩니다. 플랫폼이 청산과 같은 우선순위가 높은 작업에 대한 자원 예약 메커니즘을 설정하지 않았을 수 있으며, 일반 거래와 청산 증명 생성 요청 간에 자원 경쟁이 발생하여 시스템 응답 지연이 더욱 악화되고 청산 프로세스가 적시에 실행될 수 없으며 사용자의 손실이 확대될 수 있습니다. 운영적인 측면에서, 라이터 CEO 블라디미르 노바코브스키의 답변에 따르면 "라이터는 원래 거래 수요의 지속적인 증가를 수용하기 위해 충돌이 발생한 주말 동안 데이터베이스 업그레이드를 수행할 계획이었다. " 이번 사건에 비추어 볼 때, "업그레이드 기간을 잘못 선택한 것"은 팀이 시장 위험에 대한 준비가 부족하고 플랫폼의 급격한 확장 과정에서 인프라 업그레이드를 적시에 완료하지 못했기 때문에 궁극적으로 극심한 시장 상황에서 플랫폼의 시스템 장애로 이어진 것입니다. 이 사건은 퍼덱스가 직면한 핵심 과제 중 하나인 극한의 시장 상황에서 플랫폼을 제대로 작동시키는 방법을 보여줍니다. 스마트 컨트랙트 보안 측면에서 퍼프덱스 트랙의 프로젝트 팀은 포괄적이고 전문적인 컨트랙트 보안 감사를 수행해야 합니다. 베오신은 이전에 서프 프로토콜, 티포트레이드 등 퍼프덱스에 보안 감사 서비스를 제공했으며, 스마트 컨트랙트 코드의 보안, 비즈니스 구현 로직의 정확성(레버리지 거래, 청산, 유동성 풀 관리 등)을 다뤘습니다. 퍼펙트 덱스는 스마트 컨트랙트 코드 보안, 비즈니스 구현 로직(레버리지 거래, 청산, 유동성 풀 관리 등)의 정확성, 컨트랙트 코드 가스 최적화, 잠재적 취약점 발견 및 복구 등을 포괄하는 보안 감사 서비스를 제공하며 프로젝트 팀이 다수의 중-고위험 취약점을 성공적으로 복구할 수 있도록 지원했습니다.

또한 Perp Dex 프로젝트 팀은 아키텍처 이중화 및 비상 대책 메커니즘을 고려해야 했습니다. 향후 다중 시퀀서 및 동적 리소스 스케줄링과 같은 기술을 적용하여 Perp Dex는 현재의 병목 현상을 해결하고 더 많은 사용자에게 서비스를 제공하며 암호화폐 금융의 핵심 인프라가 될 것으로 기대됩니다.