RUNTIME VE YAYIN
Runtime, canlı işlem durumunun sahibi olan tek yazarlı motordur — pozisyon, sermaye, fonlama birikimi, gerçekleşmeler, likidasyon geçişleri. Yayın, bu canlı durumu Base kontratlarının karşı uzlaştığı commit edilmiş root'lara dönüştüren disiplindir. Birlikte, bir trader'ın geçmişinin, lider tablosu sırasının ve 90/10 ödeme miktarının olaydan sonra sessizce yeniden yazılamamasının nedenidir: her durum geçişi tek sıralı bir sequence'a iner, her root sequence'a ve onu üreten yapılandırma ve oracle duruşuna bağlanır ve her çekim, bir gezgine sahip herkesin doğrulayabileceği bir root'a karşı uzlaşır.
Runtime, gateway'den gelen imzalı akışı doğrular, risk ve market-state kurallarını uygular, bakiyeleri ve pozisyonları günceller, fonlamayı ilerletir (8h pencerede $1.000 üzerinde %1 admin dilimi ile peer-to-peer) ve zorunlu rutinleri çalıştırır — likidasyon, ADL, 50/50 keeper-ve-sigorta artık bölünmesi. Her durum geçişi, kontrat katmanının daha sonra karşı uzlaştığı referansları üretir. Aşağıdaki tablo her commit ile birlikte gönderilen şeydir; bu bağlamlar olmayan bir root vault tarafından reddedilir.
| Yayınlanan öğe | Neyi bağlar |
|---|---|
| Durum root'u | Base üzerinde settlement ve çekim kanıtları için hesap durumunu sabitler |
| Root id ve zaman damgası | Durumu açık bir yayın geçmişinin içine yerleştirir; ikisi de monotonik |
| Sequence commit'i | Olay sıralamasını commit edilen duruma bağlar — yeniden sıralanmış gerçekleşmeler yok |
| Oracle-kaynak hash'i | State ilerlerken kullanılan fiyat-kaynak duruşunu bağlar |
| Order-batch commit'i | O state etrafındaki kabul edilen batch'i bağlar — eklenen veya kaldırılan emir yok |
| Config hash'i ve sürümü | Aktif risk ve platform kurallarını bağlar — ücret çizelgesi, margin kademesi, market listesi |
#Tek yazarlı borsa durumu
Dexter tek bir yazma yolu çalıştırır. Funding güncellemeleri, likidasyon geçişleri, dengesizlik rutinleri, market-state değişiklikleri ve yayın, hepsi tek sıralı runtime akışından geçer — asla rekabet eden yazıcılardan geçmez. Bir türev platformunda yanlış sıralama yanlış fiyatlama kadar pahalıdır: sırasız uygulanan bir funding tick'i sermayeyi tahrif edebilir, bir fill ile yarışan bir likidasyon yanlış mark'a karşı settle olabilir. Tek yazarlı model, bir runtime'ı sistemin geri kalanının okuduğu durum geçiş sequence'ının tek yazarı yaparak iki hata sınıfını da ortadan kaldırır.
Bakiyeleri güncelleyen aynı runtime, yayının daha sonra sabitlediği malzemeyi hazırlar. Bu yüzden uzlaşma bağlamı ve trading durumu çelişemez — aynı süreçten, aynı sırada, aynı commit'in arkasından gelirler.
imzali IOC emir
-> kabul ve risk kontrolleri
-> fiyatlama ve fill karari
-> defter, pozisyon, ucret ve funding guncellemeleri
-> snapshot ve read-model yazimi
-> precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment)
-> commitStateRootWithConfig(root, schemaVersion, configHash, configVersion)
-> vault root'u yalnizca yayin korumalari saglanirken kabul eder#Settlement bağlamı olarak yayın
Yayın, kontrat katmanının runtime durumu hakkında muğlak bir operatör iddiasına asla güvenmek zorunda kalmaması için var. Runtime, bir root'u sequence, oracle, batch ve yapılandırma referansları ile birlikte gönderdiğinde, Base üzerindeki vault, state ilerlediği anda platformun neye inandığının somut bir tanımını alır. Bu tanım, çekimlerin, itirazların, dolandırıcılık kanıtlarının, uzlaştırmanın ve sonradan incelemenin dayandığı şeydir. Onsuz, kontrat yalnızca off-chain bir sürecin bir bakiye iddia ettiğini bilirdi; onunla, kontrat belirli bir runtime görünümünü sabitleyebilir, geçmişte koruyabilir ve her settlement eyleminin somut bir şeye geri işaret etmesini zorunlu kılabilir.
Yayın yalnızca bir runtime eylemi olarak ele alınmaz. Vault bir root'u kabul etmeden önce, sequencer commit'i, oracle-kaynak hash'i ve order-batch commit'i precommitSequencerCommitment(seqCommitment, oracleSourcesHash, orderBatchCommitment) ile zaten precommit edilmiş olmalıdır. Root daha sonra commitStateRootWithConfig(...) ile gönderilir, bu da onu aktif configHash ve configVersion'a bağlar. Precommit edilen malzeme root ile örtüşmezse veya kontrat tarafı yönetişim kilidi karşılanmazsa, yayın reddedilir ve root asla uzlaşma bağlamı olmaz.
Üretim duruşu yalnızca bir root commit'inden daha katıdır. Yönetişim kilidi, denetim anchor'ının aktif olmasını, setOrderCommitRequired(true)'un yürürlükte olmasını ve yayın yolunun en az bir dayanıklı kanıt rayını sürdürmesini gerektirir — ya bir arşiv gereksinimi ya da bir DA attestor gereksinimi. İzole olarak var olan bir root üretim düzeyinde değildir; durumun nasıl yayınlandığını açıklayan denetim zincirine ve onu üreten emir akışını üreten aynı kabul disiplinine bağlı kalmalıdır. Bu, off-chain runtime'ı on-chain custody'ye karşı sabitlemeyi güvenli kılan şeydir.