🔒🖼️ Yeni gönderi: Şifreli Çerçeve İşlemleri 🔒🖼️ Özet; dr: Şifreli çerçeve işlemleri, blok sıralaması kilitlenene kadar yürütme parametrelerini (hedef, çağrı verisi, miktarlar) gizlemek için LUCID ve EIP-8141 üzerine inşa edilir. Bu tasarım, aynı yuvada şifrelenmiş yürütme, iç içe girmiş düz metin/şifreli işlemleri açar ve PQ şemalarıyla gelecek uyumludur. 👇🧵
Günümüzde şifreli mempool tasarımları (örneğin LUCID) yürütmeyi bir sonraki slota geciktirir ve şifreli işlemler için özel bir blok üstü şeridi kullanır. Bu yazı, sıralamayı uygulamadan ayırarak aynı slotta şifrelenmiş yürütme öneriyor. Yapımcı, herhangi bir anahtar ortaya çıkmadan önce tam sıralı işlem setine bağlanır ve ardından aynı slotta taahhüt edilen siparişi uygular.
Standart ePBS'de, üretici teklifi önceden hesaplanmış bir block_hash uygular. Burada bu işe yaramıyor çünkü nihai sonuç hangi şifrelenmiş tx'lerin ortaya çıktığına ve neye çözüldüğüne bağlı. Bunun yerine, teklif tx_ordering_root taahhüdü verir ve açıklamadan önce tüm işlem listesini kilitler. Yürütmeye bağlı çıktılar (state_root, BAL, makbuzlar) sadece sonrasında bağlanır.
Bu, LUCID'den temel fark. LUCID'de, anahtarlar N slotunda serbest bırakılır ve N+1 yuvasında blok üstte gerçekleştirilir. Bir sonraki yapımcı, blokun geri kalanını yerleştirirken şifresi çözülen işlemleri zaten bilir. Burada, bağlanma açıklanmadan önce gerçekleşir, uygulama aynı yuvada kalır ve şifrelenmiş mesajlar tek bir sırayla açık metinle karıştırılır.
Her şifrelenmiş çerçevenin bir kamuya açık VERIFY çerçevesi ve gizli şifreli bir yürütme aşaması vardır. Zarf, exec_params_binding = H(exec_params) olarak bağlanır. Hedef, çağrı verileri, tutarlar ve isteğe bağlı olarak öncelikli ücret, açıklanana kadar gizli kalabilir. Bir anahtar, inşaatçının tanıtım son tarihinden önce gelmezse, şifrelenmiş aşama atlanır. VERIFY hâlâ çalışıyor, nonce tüketilir ve gönderen halka açık kısmı öder. Gizli infaz gazı iade edilir. Sipariş her halükarda sabit kalıyor.
Müteahhit, sınır sınırına yakın gösterimler üzerinde hâlâ takdir yetkisine sahip. Bunu sınırlamak için, tasarım FOCIL'e benzer bir doğrulamacı görünüm-birleştirme yöntemi kullanıyor: doğrulamacılar, kendi dondurma tarihinden önce anahtarı gözlemledilerse açıklamayı eksik olarak işaretleyen yük için oy kullanmazlar.
(Diğer) ücretsiz opsiyon problemi hakkında: Kendi kendini şifreleyen gönderici, taahhüt edilen siparişi gözlemleyebilir ve pozisyon elinde olduğunda açıklamayı seçebilir; böylece uygulamada serbest bir opsiyon elde edilir. Şifreli txs için ek ücretler veya atlama cezaları gibi önlemler var ama nihai kararları vermek için daha fazla keşif yapılması gerektiğini düşünüyorum.
92