PerpDex neden "söndü"? Lighter 4 saatlik çöküşün tamamı

11 Ekim'de, kripto varlıklar piyasası tarihindeki en büyük tasfiye olayını yaşadı, toplam tasfiye miktarı yaklaşık 19 milyar dolar. Bu aşırı piyasa testi sırasında, birçok merkeziyetsizlik vadeli işlem trade platformu (Perp Dex) kesintiye uğradı; bunlar arasında en ciddi kesintiyi yaşayan Lighter oldu ve likidite sağlayıcı fon havuzunun (LLP) zarar görmesi, piyasada PerpDex platformu hakkında geniş bir tartışma yarattı.

Surf Protocol, Tifo.trade gibi birçok Perp Dex'i denetleyen bir Web3 güvenlik şirketi olarak Beosin, bu yazıda yıllardır biriktirdiği teknik ve zincir üzerindeki veri analizi deneyimi ile Lighter'ın çöküş olayının nedenlerini derinlemesine anlamanıza yardımcı olacak.

Lighter teknik çerçevesi

Lighter, sıfır işlem ücreti özelliği ile PerpDex'in yükselişinde öne çıkarak birçok kullanıcıyı platformunda işlem yapmaya çekmiştir. Lighter, işlem performansını ve emir defterinin eşleştirme verimliliğini artırmak için belirli bir ZK Rollup L2 olan zkLight üzerine inşa edilmiştir. Temel çalışma mekanizması aşağıdaki gibi gösterilmektedir:

Sıralayıcı: Kullanıcı etkileşiminin ilk noktası olarak, işlem talimatlarını alır ve işlemleri sıralayıp Batch (işlemlerin toplu veri paketi) haline getirir.

Eşleştirme motoru: Sıralayıcıdan gelen Batch'i alır ve “fiyat önceliği, zaman önceliği” eşleştirme mantığını sıkı bir şekilde takip eder. Her başarılı eşleştirme, sıfır bilgi kanıtı oluşturmak için verileri hazırlar, böylece herkes eşleştirme sürecinin adilliğini sonradan doğrulayabilir ve manipülasyon olasılığını ortadan kaldırır.

Kanıtlayıcı (Prover): Eşleştirme motorunun işlemlerini, eşleştirme yürütme ve durum geçişinin doğruluğunu sonraki doğrulama için basit bir ZK-SNARK kanıtına dönüştürmek.

Ana ağ sözleşmesi: Kanıtlayıcıların sunduğu sıfır bilgi kanıtlarını doğrulamaktan sorumludur. Doğrulama başarılı olduğunda, durum kökü güncellenir ve böylece işlem sonuçları Ethereum üzerinde nihai bir onay almış olur.

Yukarıdaki tasarım dışında, Lighter kullanıcılara bir kasa işlevi sunar; kullanıcılar Lighter Likidite Havuzu'na (LLP) fon yatırabilir. Bu likidite havuzu, likidite sağlama, fiyat oluşturma ve risk üstlenme gibi üçlü işlevi yerine getirir. LLP katılımcıları, platformun gelirine ve karşı tarafın zararından elde edilen gelire ortak olabilirler; aynı zamanda kullanıcı tasfiye olduğunda bazı riskleri üstlenirler ve Lighter'ın tasfiye sistemi ile birlikte, bir risk tampon mekanizması oluştururlar.

Lighter Kesinti Analizi

2025年10月11日，加ımcı piyasa sözleşme tasfiye ölçeği tarihî bir rekor kırdı. Bu aşırı piyasa koşulunda, Lighter birkaç saatlik hizmet kesintisi yaşadı ve kullanıcıların pozisyonlarını yönetememesine neden oldu, LLP yaklaşık %5.35 kaybetti.

Beosin, bu olayın ana zaman dilimini (Pekin Saati ile 2025 yılının 10 Ekim günü 00:17-05:08) zincir üstü veri analizi ile inceleyerek, Lighter'ın Batch#55661'den itibaren 3 Batch kaybettiğini ve 00:17'de Batch üretmeye geri döndüğünü (00:23'te Lighter, kullanıcıların siparişlerinin işlenemediğini veya yerine getirilemediğini bildiren bir duyuru yayınladı) tespit etti.

Lighter platformı, çökmeden önce normalde dakikada yaklaşık 4005 işlem gerçekleştiriyordu, 00:17'den itibaren işlem hacmi patladı, Batch#55665 560 blok içeriyor, işlenen işlem sayısı 196913, dakikada yaklaşık 65638 işlem işlenmesi gerekiyor, bu da normal dönemlerin yaklaşık 16 katı.

Aşağıda 11 Ekim 00:17-05:08 tarihleri arasında her Batch için işlem sayılarının istatistik grafiği bulunmaktadır:

Beosin tarafından istatistiksel olarak hazırlanmıştır

11 Ekim 04:56'da, Batch#55743 işlem sayısı maksimum değere ulaştı ve 2 dakika içinde 639370 işlem tamamlandı, bu da normal dönemlerde her dakika işlenen işlem sayısının 79.8 katıdır. Lighter'ın bu olayla ilgili verilerini istatistiksel olarak incelediğimizde, Lighter'ın Batch'inin en fazla 1600 blok barındırabileceğini, her bloğun en fazla 500 işlem barındırabileceğini ve teorik olarak işlem sayısının 800000/Batch olarak hesaplandığını, ancak ölçülen en yüksek değerin 639370 olduğunu gördük.

Yukarıda Lighter platformunun başarıyla işlediği işlemler var, ayrıca birçok kullanıcı, işlem gönderiminde başarısız olduğu için pozisyonlarını ayarlayamamış (çökmüş) ve zincirde kayıtlı verileri bulunmamaktadır. Teknik mimari açısından, bu çökme ve LLP kaybına neden olan başlıca iki sebep bulunmaktadır:

1. Ön uç sayfasının erişim ve sipariş verme sorunları dışında, Lighter'ın ZK Rollup'ı, işlemleri sıralamak ve paketlemek için tek bir sıralayıcıya bağımlıdır. ZK Proof ile sonuç doğrulaması sağlansa da, sıralayıcının merkeziyeti, tek nokta arızası riskine yol açmaktadır. Düşüş dönemlerinde, sıralayıcı ve veritabanı ani yüklenmeleri taşıyamaz hale gelir, veritabanında indeks hasarı ve işlem tıkanıklığı meydana gelebilir, bu da doğrudan eşleştirme motoru ile kullanıcı tarafı bağlantısının kesilmesine neden olur. 2. ZK-SNARK'ın kanıt üretimi ve başvuru süreci, işlem hacmi aniden arttığında, kanıt üretim düğümü ve veritabanının eşgüdümlü işleme kapasitesi bir darboğaz haline gelir. Aşırı piyasa koşullarında, eş zamanlı olarak artan işlem eşleştirme ve tasfiye işlemleri aynı anda ZK kanıt üretim düğümüne talepler gönderir. Platform, tasfiye gibi yüksek öncelikli işlemler için kaynak rezerve mekanizması ayarlamamış olabilir, bu da normal işlemler ile tasfiye kanıtı üretim talepleri arasında kaynak rekabetine yol açar ve sistem yanıt gecikmesini daha da artırır, bu da tasfiye sürecinin zamanında yürütülememesine ve kullanıcı kayıplarının büyümesine neden olur. Operasyonel düzeyde, Lighter CEO'su Vladimir Novakovski'nin yanıtına göre, “Lighter, bu düşüşün meydana geldiği hafta sonu sürekli artan işlem taleplerini karşılamak için veritabanı güncellemesi yapmayı planlıyordu”. Bu olaydan görüldüğü üzere, bu tür “güncelleme penceresi seçimi hatası”, ekibin piyasa riskine hazırlık eksikliğinden kaynaklanmaktadır; platformun hızlı genişlemesi sürecinde zamanında altyapı güncellemesi tamamlanamamış ve nihayetinde aşırı piyasa koşullarında platformun sistemik arızasına yol açmıştır. Bu olay, PerpDex'in karşılaştığı bir temel zorluğu ortaya koymaktadır: aşırı piyasa koşullarında platformun normal işleyişini nasıl sürdürebiliriz? Akıllı sözleşme güvenliği açısından, Perp Dex alanındaki proje ekipleri, kapsamlı ve profesyonel bir sözleşme güvenlik denetimi gerçekleştirmelidir. Beosin daha önce Surf Protocol, Tifo.trade gibi Perp Dex'ler için güvenlik denetimi hizmeti sunmuş, akıllı sözleşme kodunun güvenliği, iş gerçekleştirme mantığının (kaldıraçlı ticaret, tasfiye, likidite havuzu yönetimi vb.) doğruluğu, sözleşme kodu gaz optimizasyonu, potansiyel güvenlik açıklarının tespiti ve onarılması gibi birçok alanda proje ekiplerinin orta ve yüksek riskli güvenlik açıklarını başarıyla onarmalarına yardımcı olmuştur.

Ayrıca, Perp Dex proje ekibinin mimari yedeklilik ve acil durum mekanizmalarını da göz önünde bulundurması gerekiyor. Gelecekte, çoklu sıralayıcılar, dinamik kaynak planlaması gibi teknolojilerin uygulanmasıyla, Perp Dex mevcut bu darboğazı çözerek daha fazla kullanıcıya hizmet vermeyi ve kripto finansmanın temel altyapısı olmayı umuyor.