Yazar: Markus Hinrichs
Editör: Randall Roland
Çeviri: Taha
Toplantıda alınan kararlar üzerine Leap 3.2 yayınlandı. Ayrıca, Devlet Veritabanının asıl sorunu olan yüksek RAM kullanımı tartışıldı. Potansiyel uzun ve kısa vadeli düzeltmeler ve takaslar araştırıldı.
Ayrıca, toplantının sonunda ENF'den Net Plugin Enhancements ayrıntılarının kısa bir özeti verildi: Leap 4.0'ın Prometheus Exporter'ı kara kutu nodEOS için istatistikler içeriyor . Toplantıda 13 katılımcı vardı.
Yazılım geliştirme, haftalık EOS Node Operatörü Toplantısı oturumlarındaki ana tartışma konusudur. EOS geliştirme süreci hakkında daha fazla bilgi edinmek isteyen geliştiriciler, Blok Yapımcıları, blockchain mühendisleri ve topluluk üyelerinin tümü, sağladığı bilgilerden yararlanır.
Bir ekosistem, sıklıkla paylaşarak ve etkileşim kurarak sağlıklı ve doğal bir şekilde büyüyebilir. EOS Network Foundation, ilerleme durumu hakkında BP'lerden ve geliştiricilerden olumlu yorumlar aldı. EOS Topluluğu, artık sesinin takdir edildiğinin ve duyulduğunun bilincindedir. Son olarak, topluluk endişelerine yanıtlar veriliyor.
Toplantının video kaydı için tıklayınız (Şifre: 1Gx@h=9e)
Stephen Diesel'den (ENF, Leap Üretim Müdürü) Antelope Leap Güncellemelerinin Özeti yakında
GÜNCELLEMELER | YAYINLAMA ZAMANI |
Leap 3.2 son sürümü | Github'da yayınlandı |
Sistem sözleşmesi güncellemeleri | yakında |
DUNE'un piyasaya sürülmesi | Aralık 2022 |
Bu toplantının başında Stephen, Leap 3.2'nin Github'da yayınlandığını, ancak bunun bir fikir birliği yükseltmesi olmadığını ve bu nedenle isteğe bağlı olduğunu duyurdu.
Brian Hazzard, yükseltmeyle ilgili tüm sorular için çeşitli kanallarda hazır bulunmayı kabul etti. Son toplantı harika fikirleri topladığından ve birikim için bazı yeni potansiyel özellikleri tanımladığından, önümüzdeki hafta Net Plugin Enhancements belgesinin bir güncellemesi yapılacak.
Veritabanı Durumu Değiştirildi: Geçmişi depolamak için çok fazla RAM kullanıldı
EOSUSA'dan Michael toplantıya katılamadı, ancak bu toplantının konusunu önerdi: Durum Veritabanı Kırpma. Katılımcılar, asıl sorunun çok fazla RAM kullanılması olduğu konusunda hemfikirdi. Per Stephen, RAM sorununu araştırmak için araştırma yapmak amacıyla bir RFP taslağı hazırlanmaktadır.
Takas Performansı ve RAM Boyutu.
Ana soru Kevin Heifner tarafından soruldu: "RAM boyutu için ne kadar performanstan ödün vermeye razısınız? Verileri RAM'e yüklemek için (bir ısıtma bloğu gibi) 1 blok üretim döngüsünden ödün vermeye istekli misiniz?" Ancak, bu çözümde yüksek bir spam riski vardır.
RAM için asla karşılanamayacak kadar büyük bir talep var. Şu anda WAX durum veritabanını sorunsuz çalıştırmak için 128 GB RAM gerekiyor. Sorun, normal cihazların daha fazla RAM için yeterli alana sahip olmamasıdır. Güçlü CPU'lara ve bol miktarda RAM'e sahip cihazları bulmak zordur. Belki de grafik tasarımcı/animatör cihazları gelecekteki gereksinimleri karşılayabilir.
Tanımlanmış kısa ve uzun vadeli fırsatlar (alıntı)
Kısa vadeli fırsatlar
Bu konuyu araştırmak için Antelope koalisyonu tarafından bir RFP taslağı hazırlanmaktadır.
Yığın modunun başlatılmasını ve kapanmasını daha hızlı yapın
Tmpf'leri kutunun dışında yapmak için bir fırsat var mı?
Hesap sorgularını devre dışı bırakmak, RAM'de tasarruf sağlayabilir (ağ operatörü yapılandırması için fırsat)
Hesap sorgularını diskte depolayın (14 milyon WAX hesabı 4 GB tasarrufta bulunulabilir, muhtemelen buna değmez)
Uzun vadeli fırsatlar
Akıllı sözleşmeler, RAM ve Disk depolamayı belirtmek için teşvik edilebilir mi?
Donanım satıcılarının yüksek miktarda RAM içeren çok hızlı CPU çekirdekleri sunmaya başlaması gerekiyor
P2P İyileştirmeleri (Net Eklentisi) (Brain Hazzard tarafından)
Brian Hazzard, aşağıdaki endişelere hızlı bir şekilde değindi ve ev sahibi Daniel Keyes'in yakın zamanda tartışılan Net Plugin'in geliştirilmesine yönelik belirli önerilerin kısa bir özetini verip veremeyeceğini sorduktan sonra bunları bir sonraki toplantıda daha ayrıntılı olarak sunmayı teklif etti.
Geçişteki bloklar için oluşan daha hafif doğrulamalar yapma olasılığı olacaktır. Bu, zamandan tasarruf sağlayabilir ve geçişi daha hızlı hale getirebilir
Bir bloğun dolu olup olmadığını (yerleşik CPU süresi açısından) yayınlıyorsa ve bir sonraki blokta başlıyorsa kodlamak mümkün olacaktır.
Gecikmeyi optimize etmek için eşleri otomatik olarak yapılandırma (BP'ler şu anda bunu manuel olarak yapıyor).
program için optimize et (Hangi BP önce, hangisi sonra gelir?)
gecikme açısından optimize et
Gelecek Haftanın Gündemi
EOS Nation'dan Matthew tarafından önerilen bir sonraki Leap 4.0'da prometheus ihracatçısına hangi verilerin dahil edilmesi gerektiğine dair bir müzakere:
nodeEOS bir kara kutu gibidir, birçok ağ operatörünün içinde neler olduğu hakkında hiçbir fikri yoktur. Bununla ilgili bazı istatistikler verilmesi isteniyor.
Ağ toplantısının katılımcıları, bir sonraki toplantıda prometheus için istekleri konuşulacak.
Toplantının katılımcıları (13):
Randall Roland | EOSsupport.io
Dario | EOSsupport.io
Kevin Heifner | OCI
Matt Witherspoon | ENF
Brian Hazzard
Jannis - Rakeden (Jannis)
Max Cho | KOREOS
Daniel Keyes | EOS Nation
Stephen Diesel | ENF
Matthew Darwin | EOS Nation
Corvin Meyer auf der Heide | liquiid.io
Patrick Burns | Aloha EOS
Ross Dold | EOSphere
Kaynaklar & Referanslar
Github: Antelope Leap 3.2.0 RC1
Toplantının Video Kaydı (Şifre: 1Gx@h=9e)
Görsel Kaynaklar
Banner by EOS Support Grafikleri