KAYNAKLAR VE YEDEKLEME
Her fill, her drawdown kontrolü, her lider tablosu sıralaması ve her USDC ödemesi Dexter'ın belirli bir timestamp'te kabul ettiği bir fiyata kadar izlenebilir. Tek bir yayıncının kararması, bir marketin donmasıyla veya bir ödemenin reddedilmesiyle aynı olay olamaz — kaynak katmanı, birincil başarısızlığın aynı tick içinde önceden onaylanmış bir yedek yola geçeceği ve marketi yalnızca hiçbir yol sapma, tazelik ve depth kapılarından geçemediğinde azaltılmış veya yalnızca kapatma durumuna çökerteceği şekilde tasarlanmıştır. Aşağıda tam kaynak merdiveni, mux'un bir yolu nasıl aktif olarak yükselttiği, bir marketi bozulmuş duruşa çeviren tam koşullar ve bu olduğunda açık pozisyonlarınıza ve 30 günlük challenge saatinize ne olduğu yer almaktadır.
Her Dexter marketinde normal operasyon aynı anda iki sağlıklı yol gerektirir: birincil Hermes/Pyth push akışı ve runtime'ın her tick'te birincile karşı poll edip çapraz kontrol ettiği bağımsız bir HTTP oracle mux. Tek kaynaklı operasyon kararlı bir durum değildir — yalnızca runtime başarısızlığı loglamış, politika istisnasını kaydetmiş ve marketi süresince bozulmuş bir duruşa düşürmüş olduğunda devreye giren açık bir liveness override'ıdır. Aşağıdaki merdiven bu nedenle bir sıralı failover planıdır, mux'un seçim yaptığı bir büfe değildir.
| Kaynak yolu | Platformdaki rolü |
|---|---|
| Hermes / Pyth (birincil) | Desteklenen her market için düşük gecikmeli push referans çapası; Pyth'in on-chain doğruladığı yayıncı setini agrege eder |
| HTTP oracle mux (çapraz kontrol) | Mark yükseltilmeden önce her tick'te Hermes ile sapma bandı içinde mutabık olması gereken bağımsız pull yolu |
| Tek yol liveness override'ı | Yalnızca bir aile devre dışı olduğunda ve runtime azaltılmış quorum'u kabul ettiğinde devreye girer; market eş zamanlı olarak azaltılmış veya yalnızca kapatma durumuna düşer |
| Son bilinen kontrollü tutma | Hiçbir yol kabul edilebilir değilse, engine son doğrulanmış mark'ı tutar, yeni yürütmeyi durdurur ve operasyon ile yayınlanmış durum için bir bozulma olayı yayar |
#Bir kaynak nasıl aktif olur
Bir yedek yolun var olması, ona güvenildiği anlamına gelmez. Kaynak mux, her tick'te her market için tek bir karar verir: mevcut yolların hangi kombinasyonu tazelik penceresini geçer, sapma sınırları içinde mutabık olur, market başına lag tavanını geçer ve depth/spread korumasına saygı duyar. Bu karar sezgisel değil politikadır — aynı girdiler her zaman aynı sonucu üretir ve seçilen kaynak seti runtime loguna kaydedilir ve bir sonraki settlement root'una damgalanır.
Açık varsayılan tutuculuktur. Birincil zayıfladığında, mux önce yapılandırılmış tavan içinde gecikme toleransını genişleterek her iki yolu da canlı tutmaya çalışır. Çapraz kontrol hâlâ sapma bandını geçemezse, runtime daha ince bir kaynak setini normal duruşa yükseltmek yerine marketi düşürmeyi tercih eder — azaltılmış'a, sonra yalnızca kapatma'ya, sonra durdurulmuş'a. Rahatlık ve güzel uptime rakamları, politikanın geri kalanının arkasında durmadığı bir yol üzerinde işlem yapmeye devam etmek için geçerli nedenler değildir.
Bir yedek devreye girdiğinde iki şey eş zamanlı olur. İlk olarak, eşleştirme motoru kullanıcıların açık riski yönetebilmesi için hayatta kalan yola karşı reduce-only emirleri fill etmeye devam eder. İkinci olarak, market durumu bozulmuş olarak yayınlanır; böylece bağlı her istemci, kural motoru ve kasiyer aynı duruşu görür. Runtime logunu daha sonra okuyan bir denetçi tek bir soruyu belirsizlik olmadan yanıtlayabilir: her tick'te, hangi yol aktifti, neden ve market hangi duruş altında trade ediyordu?
tick T gelir
-> mux Hermes birincil + HTTP capraz kontrolunu okur
-> tazelik, sapma, gecikme ve derinlik kapilari degerlendirilir
-> ikisi de gecerse: mark yukseltilir, market canli kalir
-> biri kalirsa: mux gecikme tavani icinde yeniden dener
-> hala basarisizsa: market durusu dusurulur
reduced -> close-only -> halted
-> selected source set and posture hash
committed inside the next state root#Kaynak seçiminin settlement için önemi
Aktif kaynak seti operasyonel bir dipnot değildir — on-chain settlement kaydının bir parçasıdır. Runtime, kaynak duruşu meta verisini (aktif yayıncılar, yedek katılımı, gözlemlenen sapma, tazelik marjı, market duruşu) hash'ler ve o hash'i vault kontratının kabul ettiği her state root'una commit eder. Root R'ye karşı sonlandırılan bir çekim, bu nedenle R içindeki bakiyeleri üreten tam oracle yapılandırmasına bağlıdır.
Bu "platform Hermes kullandığını söylüyor" ile "kontrat her ödemenin hangi feed duruşuna bağlı olduğunu kanıtlayabilir" arasındaki farktır. Aynı zamanda fiyat katmanını bakiye defterinin denetlenebilir olduğu anlamda denetlenebilir kılan şeydir: Base üzerindeki durum root'larını okuyan bir olay sonrası denetçi, yalnızca bir hesabın root R'de ne kadar değerli olduğunu değil, hangi kaynak yollarının canlı olduğunu, hangilerinin bozulduğunu ve eşleştirme motoru'in o snapshot mühürlendiğinde hangi duruş altında çalıştığını yanıtlayabilir. Mark oluşum ayrıntıları Mark oluşumu'nda devam eder; seans ve bozulmuş durum geçişleri Seanslar ve bozulmuş durumlar'da belgelenmiştir.