Hyperliquid'in teknik yapısı ve güvenlik risklerinin derinlemesine incelenmesi

Son zamanlarda büyük ilgi gören Hyperliquid, en etkili zincir içi emir defteri borsa platformlarından biridir ve toplam kilitli değeri 2 milyar doları aşmıştır. Sektörde "zincir içi bir ünlü merkezi borsa" olarak değerlendirilmekte ve aynı zamanda Layer3 ve uygulama zincirleri hakkında tartışmaları yeniden gündeme getirmiştir. Bir ay içinde proje değerinin 30 milyar dolara ulaşmasıyla Hyperliquid geniş bir ilgi kazanmıştır. Şu anda piyasada Hyperliquid hakkında birçok analiz raporu mevcut, ancak çoğu ürün işlevselliği ve ticaret mekanizması üzerine odaklanmakta, teknik mimarisi ve olası güvenlik riskleri üzerine derinlemesine bir analiz eksikliği bulunmaktadır.

Bu makale, tamamen teknik ve güvenlik açısından Hyperliquid'i analiz ederek bu boşluğu doldurmayı amaçlamaktadır. Okuyucuların bu yıldız projenin iç yapısını ve prensiplerini daha iyi anlamalarına yardımcı olacaktır. Hyperliquid'in çapraz zincir köprü sözleşmesinin tasarımı ve riskleri ile HyperEVM ve HyperL1'in çift zincir mimarisini analiz etmeye odaklanacağız ve arkasındaki teknik uygulama yöntemlerini derinlemesine inceleyeceğiz.

Hyperliquid Çok Zincirli Köprü Analizi

Hyperliquid, temel bileşenlerini açık kaynak yapmadığı için, ancak ilgili köprü sözleşmelerini açık kaynakladığı için, köprü sözleşmeleriyle ilgili riskler hakkında daha fazla bilgiye sahibiz. Hyperliquid, kullanıcıların yatırdığı USDC varlıklarını depolamak için bir Layer2 ağında bir köprü sözleşmesi dağıttı; Bridge bileşeni aracılığıyla Hyperliquid düğümlerinin bazı davranışlarını gözlemleyebiliriz.

doğrulayıcı seti

Düğüm kimliği açısından bakıldığında, Hyperliquid'in hotValidatorSet, coldValidatorSet, finalizers ve lockers olmak üzere 4 grup doğrulayıcısı vardır ve her biri farklı sorumluluklar üstlenir. hotValidatorSet, kullanıcıların yüksek frekanslı işlemlerine, örneğin para çekme gibi, yanıt vermekten sorumludur ve genellikle kullanıcı taleplerini zamanında işlemek için sıcak cüzdan kullanılır.

coldValidatorSet, sistem yapılandırmasını değiştirmek için kullanılır; diğer doğrulayıcı setlerinin listesini güncellemek veya köprü sözleşmesinin kilitleme durumunu işlemek gibi ve bazı para çekme taleplerini doğrudan geçersiz kılma yetkisine sahiptir.

lockers, Layer2'de yaygın olarak bulunan "güvenlik komitesi" benzeri özel yetkilere sahip bir grup doğrulayıcıdır; acil durumlarda köprü işlemlerinin durdurulup durdurulmayacağına oy verebilirler. Şu anda Hyperliquid köprüsünün lockers koleksiyonu 5 adres içermektedir ve köprü sözleşmesini durdurmak için sadece 2 locker oyu yeterlidir.

finalizers da, kullanıcıların para yatırma ve çekme gibi işlemlerini doğrulamak için kullanılan özel bir doğrulayıcı grubudur. Hyperliquid'in çapraz zincir köprüsü "gönder- doğrula" mekanizmasını kullanır, kullanıcı bir para çekme işlemi başlattıktan sonra bir "itiraz süresi" beklemek zorundadır, süresi dolduktan sonra finalizers para çekme işlemini gerçekleştirir.

Bir sorunla karşılaşıldığında, eğer bir çekim talebi kullanıcının mevcut bakiyesini aşarsa, Hyperliquid düğümü ihtilaf süresi içinde lockers üzerinden oylama yaparak köprü sözleşmesini duraklatabilir veya coldValidatorSet doğrudan sorunlu çekimi geçersiz kılabilir.

Şu anda Hyperliquid'in yalnızca 4 doğrulayıcı düğümü bulunmaktadır, bu nedenle hotValidatorSet ve coldValidatorSet her biri 4 zincir üzerindeki adrese karşılık gelmektedir. Başlangıçta, Hyperliquid otomatik olarak hotValidatorSet içindeki adresleri lockers ve finalizers üyeleri olarak kaydederken, coldValidatorSet resmi olarak kontrol edilir ve anahtarları soğuk cüzdanda saklar.

para yatırma

Hyperliquid'in köprü akdi, kullanıcı mevduatlarını EIP-2612'nin Permit yöntemiyle işler ve yalnızca USDC varlığını destekler. Geleneksel Onayla-Taşıma modeliyle karşılaştırıldığında, Permit daha basit ve toplu işlemleri kolaylaştırır.

Köprü akdi, birden fazla mevduatı toplu işleme almak için batchedDepositWithPermit fonksiyonunu kullanır, süreç basit ve fon güvenliği riski yoktur, esasen Permit yöntemini kullanarak kullanıcı deneyimini optimize eder.

Para Çekme

Mevduata kıyasla, çekim yüksek riskli bir işlemdir, bu nedenle mantığı daha karmaşıktır. Kullanıcı çekim talebinde bulunduktan sonra, Hyperliquid düğümleri köprü sözleşmesinin batchedRequestWithdrawals fonksiyonunu çağırır. Bu aşamada her bir çekim talebinin hotValidatorSet'in 2/3 imza ağırlığını alması gerekmektedir, burada "2/3 imza ağırlığı" ifadesine dikkat edilmelidir, "2/3 imza sayısı" değil. Şu anda Hyperliquid'de eşit ağırlığa sahip 4 düğüm bulunmaktadır, bu nedenle imza ağırlığı ve imza sayısının kontrolü geçici olarak uyumlu görünmektedir, ancak gelecekte yüksek ağırlıklı düğümler dahil edilebilir.

Çekim talebi yapıldıktan sonra, çapraz zincir köprüsü USDC'yi hemen transfer etmeyecek, bunun yerine 200 saniyelik bir "tartışma süresi" olacaktır. Bu süre zarfında iki durum ortaya çıkabilir:

1. Lockers, çekim taleplerinde ciddi sorunlar olduğunu düşünüyorsa, sözleşmeyi doğrudan dondurmak için oy kullanabilir;

2. Düğüm, bazı çekimlerin sorunlu olduğunu düşünüyorsa, coldValidatorSet üyeleri invalidateWithdrawals fonksiyonunu çağırarak bu çekimi geçersiz kılabilir.

Eğer itiraz süresi içinde anormallik yoksa, sürenin dolmasının ardından finalizers üyeleri batchedFinalizeWithdrawals fonksiyonunu çağırarak nihai durumu onaylayabilir, bu aşamada USDC, kullanıcının Layer2 cüzdan adresine aktarılacaktır.

Güvenlik modeli açısından bakıldığında, kötü niyetli bir saldırganın Hyperliquid çekim sürecinde kötü niyetli faaliyetlerde bulunabilmesi için üç savunma hattını aşması gerekmektedir:

1. hotValidatorSet'in 2/3 imza ağırlığını kontrol edin, yani yeterli özel anahtar elde edin veya komplo kurun. Şu anda yalnızca 4 doğrulayıcı var, kontrol edilme veya komplo kurma olasılığı düşük değil;

2. İhtilaf süresi içinde kötü niyetli işlemlerin tespit edilmesinden kaçının, aksi takdirde lockers sözleşmesi kilitlenebilir;

3. En az bir finalizers üyesinin özel anahtarını alın, para çekmeyi onaylayın. Şu anda finalizers, hotValidatorSet üyeleriyle temel olarak aynıdır, koşul 1'i karşılamak koşuluyla koşul 3'ü de karşılamaktadır.

Köprü Sözleşmesi'nin Kilitlenmesi

Hyperliquid, köprü sözleşmesini kilitleme işlevini ayarladı. Özellikle, kilitleyici üyelerin voteEmergencyLock fonksiyonunu oylaması gerekiyor, şu anda 2 kilitleyicinin oylaması köprü sözleşmesini kilitlemek ve durdurmak için yeterlidir.

Dikkate değer bir nokta, Hyperliquid köprüsünün unvoteEmergencyLock fonksiyonu sunmasıdır; bu, kilitleyenlerin oylamalarını geri çekmelerine izin verir. Köprü sözleşmesi kilitlendiğinde, yalnızca emergencyUnlock fonksiyonu ile açılabilir ve coldValidatorSet üyelerinin 2/3'ünden fazla imza ağırlığı toplanması gerekir.

emergencyUnlock ile birlikte hotValidatorSet ve coldValidatorSet doğrulayıcı adres kümesi güncellenecek ve hemen etkili olacaktır.

Doğrulayıcı kümesi güncellemesi

Çekim süreci savunmasını aşmaktan ziyade, doğrudan updateValidatorSet fonksiyonunu kullanarak doğrulayıcı setini güncellemek daha etkili bir saldırı yöntemidir. Bu, tüm hotValidatorSet üyelerinin imzasını gerektirir ve 200 saniyelik bir itiraz süresi vardır.

İtiraz süresi sona erdikten sonra, finalizers üyelerinin finalizeValidatorSetUpdate fonksiyonunu çağırarak nihai güncellemeyi tamamlaması gerekmektedir.

Hyperliquid köprü sözleşmesinin aşağıdaki riskleri vardır:

1. Hackerlar coldValidatorSet'i kontrol ettiklerinde, kullanıcı varlıklarını çalmaktan alıkoyan engelleri hiçe sayabilirler. Çünkü coldValidatorSet acil açma yetkisine sahiptir, bu da locker'ların kilidinin geçersiz olmasını sağlar ve düğüm listesini anında günceller. Şu anda yalnızca 4 doğrulayıcı düğüm var, özel anahtarların çalınma riski düşük değil;

2. finalizers, kullanıcıların para çekme işlemlerini onaylamayı reddederek inceleme saldırısı gerçekleştirir. Bu durumda, kullanıcı varlıkları güvendedir ancak çekilemeyebilir;

3. locker'ların kötü niyetli olarak çapraz zincir köprülerini kilitlemesi, tüm çekim işlemlerinin gerçekleştirilmesini engeller, sadece coldValidatorSet'in kilidinin açılmasını beklemek gerekir.

HyperEVM ve Çift Zincir Etkileşim Mimarisi

Sipariş defteri işlemlerinin programlanabilirliğini sağlamak için, gizli işlemler gibi akıllı sözleşme desteği gerektiren senaryoların tanıtılmasıyla, Hyperliquid HyperEVM çözümünü piyasaya sürdü. Bu, geleneksel EVM'ye göre iki büyük avantaja sahiptir: Hyperliquid sipariş defteri durumunu okuyabilir ve dahili akıllı sözleşmeler sipariş defteri sistemiyle etkileşimde bulunabilir, bu da uygulama senaryolarını önemli ölçüde genişletir.

Örneğin, kullanıcı eğer emir gizliliğini sağlamak istiyorsa, HyperEVM üzerinde Tornado Cash benzeri bir sözleşme aracılığıyla gizlilik katmanı ekleyebilir ve ardından belirli bir arayüz aracılığıyla Hyperliquid emir defteri sisteminde emir tetikleyebilir.

Hyperliquid, HyperEVM için özel bir mimari tasarladı. Özelleştirilmiş bir emir defteri sisteminin EVM ortamından çok daha iyi performans gösterdiği göz önüne alındığında, hız kaybını önlemek için Hyperliquid "çift zincirli bir çözüm" benimsemiştir: her düğüm, aynı anda iki zincir çalıştırır, her iki zincirin verilerini yerel olarak depolar ve işlemleri ayrı ayrı işler.

Hyperliquid, özel bir zincir (HyperL1 oluşturarak bir emir defteri sistemi kurmaktadır, izinli ), ayrıca EVM uyumlu bir zincir (HyperEVM eklemektedir, izinsiz ). İki zincirin verileri aynı konsensüs protokolü ile yayılır ve tek bir durum olarak var olur, ancak farklı ortamlarda çalışır. HyperL1, HyperEVM'den daha hızlı blok oluşturur, ancak bloklar yine de sırayla işlenir. EVM zincirindeki sözleşmeler, geçmiş L1 blok verilerini okuyabilir ve gelecekteki L1 bloklarına veri yazabilir.

HyperL1 ve HyperEVM etkileşimi esas olarak Ön Hesaplamalar ve Olaylar aracılığıyla gerçekleştirilir.

Önceden Derlenmişler

Önceden derlenmiş ( Önceden Derlemeler ) karmaşık işlemleri doğrudan alt seviyede gerçekleştirmek için C/C++ gibi dilleri kullanarak Solidity ile dost olmayan hesaplamaları işler. Önceden derleme esasen özel bir akıllı sözleşmedir, diğer sözleşmeler bu sözleşmeleri çağırabilir ve yürütme sonuçlarını alabilir. Şu anda yerel EVM, ( 0x01 adresi için ecRecover komutunu önceden derlenmiş olarak gerçekleştirmiştir ).

HyperEVM ayrıca, Hyperliquid order book sisteminin durumunu okumak için önceden derlenmiş kod ekledi. Bilinen bir önceden derlenmiş adres 0x0000000000000000000000000000000000000800'dür ve bu adres, en son L1 bloklarındaki kullanıcı sürekli sözleşme pozisyonlarını okuyabilir.

Etkinlikler

HyperEVM, HyperL1'e veri yazmak için Events'e dayanır. Events, EVM'nin yerel bir kavramıdır ve sözleşmelerin dışa günlük bilgileri göndermesine izin verir. Örneğin, ERC-20 transferi sırasında Transfer olayı fırlatılır, dinlemeyi kolaylaştırır. Birçok çapraz zincir senaryosu da parametreleri iletmek için Events kullanır.

HyperLiquid düğümü, 0x3333333333333333333333333333333333333333 adresinden atılan Events'i dinler, bilgiyi kullanarak kullanıcı niyetini anlar ve bunu işlem hareketine dönüştürerek gelecekteki L1 bloğuna yazar. Eğer bu adres bir fonksiyon sağlıyorsa, çağrıldığında IocOrder olayını atar, L1 blok çıktığında düğüm yeni IocOrder olayını tespit ettiğinde bunu L1 içi bekleyen emir işlemi olarak dönüştürür.

HyperBFT

Konsensüs protokolleri açısından, Hyperliquid, HotStuff'tan türetilmiş HyperBFT protokolünü kullanmaktadır. Başlangıçta Tendermint algoritması kullanılmıştır, ancak verimlilik düşüktür, her aşamada All-to-All mesaj alışverişi gerektirir, karmaşıklık O(n²).

Merkezi borsa hızına ulaşmak için, ekip HyperBFT'yi geliştirdi ve Rust ile uyguladı; teorik olarak, saniyede 2 milyon işlem işleyebilir. HyperBFT'deki tüm mesajlar Lider tarafından toplanıp yayımlanır, bu da düğümler arasında mesaj alışverişini ortadan kaldırarak karmaşıklığı büyük ölçüde azaltır.

Kısacası, HyperBFT mevcut liderin blok oluşturduğu, tüm düğümlerin oy kullandığı ve sonuçları liderle birleştirip sonraki liderin konsensüs protokolünü döndürdüğü bir sistemdir.

Geliştirici Dikkat Edilecek Hususlar

1. Precompiles'a dayalı veri okuma mekanizması oldukça gelişmiştir, ancak msg.sender sorununa dikkat edilmelidir. Kullanıcı ile L1 sistem sözleşmesi arasındaki etkileşim dolaylı olarak EVM işlemlerini tetiklediğinde, EVM içindeki msg.sender L1 sistem sözleşmesinin adresi olup, kullanıcı adresi değildir.

2. EVM ile L1 etkileşiminde atomiklik olmayan bir sorun vardır. Örneğin, kullanıcı EVM üzerinden L1'de emir verirse ancak varlıkları yetersizse, işlem başarısız olur ancak işlev çağrılırken hata mesajı gösterilmez. Geliştiricilerin, EVM sözleşmesi tarafında emir verme başarısızlığını ele alması ve fonların geri alınması için bir işlev ayarlaması gerekir.

3. EVM sözleşme adresinin L1'de bir eşleşen hesabı olmalıdır. EVM sözleşmesi dağıtıldıktan sonra, L1 eşleşen adresine az miktarda USDC göndererek bir hesap oluşturulmalıdır.

4. Token bakiyeleri gibi özel durumlara dikkat edin. L1, varlıkların çapraz zinciri için özel bir adrese sahiptir, ancak çapraz zincir işleminden sonra EVM zamanında blok üretemeyebilir, bu durumda kullanıcılar bakiyelerini geçici olarak göremez. Geliştiricilerin bu tür durumları ele alması ve kullanıcı paniklerini önlemesi gerekir.