Ana içeriğe geç
Tüm KoleksiyonlarEOS Support Medyası
EOS Node Operatör Toplantı Özeti [Ekim 2023 #2]
EOS Node Operatör Toplantı Özeti [Ekim 2023 #2]

27 Ekim 2023'te yayınlandı

Markus Hinrichs avatar
Yazar: Markus Hinrichs
Bir haftadan uzun bir süre önce güncellendi

Yazar: Markus Hinrichs

Editör: Randall Roland

Çeviri: Taha Ayhan

Düğüm operatörleri, Antelope çekirdek geliştiricileri ve topluluk üyeleri, ağ ve gelişimi hakkında konuşmak için her hafta bir araya gelir. Her Düğüm Operatörü Toplantısının asıl amacı:

“…düğüm operatörleri için Antelope protokolünü (özellikle) geliştirmek.”

Toplantıları her Çarşamba yapılır. Katılma hakkında bilgi almak için Telegram kanalını ziyaret edin . EOS Network Foundation, bir EOS düğümünü çalıştırmanın temellerini öğrenmek isteyenler için eğitimler ve belgeler sağlar.

Aşağıda bu iki aylık özette yer alan toplantılarının bir listesi yer almaktadır:

18 Ekim : İyileştirilmiş CPU Yapılandırması, Erken Bloklar Özelliği Üzerine Tartışma, Ağ Genelinde Yapılandırmayı Basitleştirme ve daha fazlası

25 Ekim: Düğüm Operatörü Çağrı Formatı için Dilekler ve Özlemler, RC3'e Ulaşmak İçin Son Kilometre Taşları

GitHub'da ek toplantı notları ve yorumları aradığınızdan emin olun . Videolar ENF'in YT'sinde bulunur .

18 Ekim: 5.0 Atılımı yolda: Erken Bloklar, Performans İyileştirmeleri ve Topluluk Katkısı

Leap 5.0'ın Yayınlanması ve Test Edilmesi:

● Toplantı, Leap 5.0'ın piyasaya sürülmesiyle ilgili kapsamlı bir tartışmayla başladı.

● Topluluk üyeleri, resmi kararlı sürümden önce herhangi bir sorunu tespit etmek ve ele almak amacıyla sürüm adayı RC2'nin test edilmesine aktif olarak katılmaya şiddetle teşvik edildi.

CPU Çaba Yüzdesi Seçeneğindeki Değişiklikler:

● CPU efor yüzdesi seçeneğiyle ilgili önemli bir değişiklik yapıldı.

● Teklif, yüzde değerlerini kullanmaktan CPU çalışmasını milisaniye cinsinden yapılandırmaya geçişi içeriyordu.

● CPU çaba yüzdesi, son blok CPU çabası, son blok ofseti ve son blok versiyonları gibi mevcut seçeneklerin yerini "blok ofseti ms üret" adlı yeni bir seçenek alacaktı.

Yeni “blok ofseti ms üret” Seçeneğinin ayrıntıları:

● Yeni sunulan “blok ofseti Ms üret” seçeneği, düğüm operatörlerine 12 bloktan oluşan turun tamamı için tahsis etmek istedikleri milisaniye sayısını belirleme olanağı sağlıyor.

● Bu dengeleme, blok üretim gecikmesinin ele alınması için ayrılan sürenin belirlenmesinde çok önemli bir rol oynar.

● Daha da önemlisi, bu değişikliğin fikir birliği mekanizmasını etkilemeyeceği ve blok üretim verimliliğini artırmak için özel olarak tasarlandığı açıklandı.

Erken Blok Üretimi ve Testi:

● Sonraki tartışmalar Leap 5.0'da erken blok üretiminin başlatılması etrafında dönüyordu.

● EOSUSA'dan Michael, sistem saati ayarlarını değiştirme konseptini sundu ve bu, potansiyel sorunlar ve istenmeyen sonuçlarla ilgili endişelere yol açtı.

● Erken blok üretiminin ağı nasıl etkileyeceği ve bunun çatallanmalara veya başka komplikasyonlara yol açıp açmayacağı konusunda endişeler dile getirildi.

Laboratuvar Testlerinde Performans:

● Kevin Heifner, erken blok üretiminin getirdiği potansiyel performans iyileştirmeleri konusundaki heyecanını dile getirdi.

● Tartışmada, erken blok üretiminin, işlemlerin bloklara dahil edilmesi için nasıl daha fazla zaman sağladığını ve sonuçta ağın verimliliğine nasıl fayda sağladığını vurguladı.

● EOS VM OC (Optimize Edilmiş Derleyici), özellikle EOSIO DApp'leri ve sözleşmeleri için önemli bir performans artırıcı olarak kabul edildi.

● Performans artışını karşılamak için artan yükün geçmiş çözümlere kaydırılma olasılığına dikkat çekildi.

" 1,8 günden bugün bulunduğumuz noktaya kadar tonlarca performans artışı oldu, sanki çok daha ayarlanmış bir motor ve bu yüzden gerçekten de yükü kaldırabilecek durumda olmalı" Kevin Heifner, OCI

"Blok ofset ms üret" ve Varsayılanları yapılandırma:

● Konuşma "blok ofseti ms üret" ve önerilen varsayılan değerlerin yapılandırılmasına doğru kaydı.

● Düğüm davranışını etkilemede varsayılan ayarların önemini vurgulayan tartışmalarla "blok ofseti ms üretmek" için 450 milisaniyelik bir varsayılan değer önerildi.

● Esnekliğin, operatörlerin ayarları kendi özel ağ koşullarına uyum sağlayacak şekilde uyarlamalarına olanak tanıyan önemli bir faktör olduğu vurgulandı.

Geç Bloklar ve Saat Senkronizasyonu:

● Geç bloklar ve bunların erken blok üretimi bağlamında yönetimi konusu ele alındı.

● Saat senkronizasyonunun ve ağ gecikmesinin geç bloklar üzerindeki potansiyel etkisi dikkate alındı.

● Kevin, geç blokların mikro çatallara yol açabileceğini açıkladı ve bu bağlamda saat senkronizasyonunun rolünün araştırıldığını belirtti.

“Maksimum İşlem Süresi” ve “Salt Okunur Okuma Penceresi Süresi”nin Ayarlanması:

● Tartışma "Maksimum İşlem Süresi" ayarını ve olası değişiklikleri kapsıyordu.

● Kevin Heifner varsayılan ayarın " bir yerde " olmasını önerdi 500 milisaniye”

● "Salt Okunur Okuma Penceresi Süresi" için ayarları yapılandırmanın önemi vurgulandı ve gelişmiş performans için ağ optimizasyonu vurgulandı.

● Bireysel düğüm operatörlerinin bu değerleri kendi özel kullanım durumlarına göre ayarlaması önerildi.

Zincir İçi Mutabakat Yoluyla Uygulama:

● Ayarların zincir üzerinde fikir birliği yoluyla kontrol edilmesi kavramı, ağ çapındaki konfigürasyon değişikliklerini basitleştirmenin bir yolu olarak tanıtıldı.

“…artık BP'ler bir konsensüs ortamıyla ağ genelinde kontrol edebiliyor” Kevin Heifner

Eşler Arası Akranları Etiketlemek için Halkla İlişkiler Tartışması:

● Eşler arası eşlerin etiketlenmesiyle ilgili bekleyen bir Çekme İsteğinden kısaca bahsedildi.

● Zaman kısıtlılığı ve ekibin önemli üyelerinden Matthew Darwin'in yokluğu nedeniyle, bu konuyla ilgili ayrıntılı tartışma gelecekteki bir toplantıya ertelendi.

Toplantı, topluluğa Leap 5.0 rc2'yi aktif olarak test etme ve kararlı sürüme sorunsuz bir geçiş sağlamak için geri bildirim sağlama çağrısıyla sona erdi.

25 Ekim: Düğüm Operatörü Çağrı Formatı için Dilekler ve Özlemler, RC3'e Ulaşmak İçin Son Dönüm Noktaları

Ana Konu: Düğüm Operatörü Toplantısına Nasıl Devam Edilir?

İçgörüler ve Etkileşim:

● EOS Sphere'den Ross, teknik ekibin görüşlerini takdir etti.

● Shaq, Leap bilgilerine ve teknik içgörülere duyulan ihtiyacı vurguladı.

● EOSUSA'dan Michael, işbirliğinin yazılımın olgunlaşması üzerindeki etkisini fark etti.

● OCI'den Kevin Heifner, düğüm operatörlerinden gelen geri bildirimlerin önemini vurguladı.

Gelecek Toplantı İstekleri:

● Gelecekteki çağrılara belgelerin dahil edilmesi üzerine tartışma.

● Protokol, düğüm operatörü ve geliştirici belgeleri dahil olmak üzere vurgulanan belge türleri.

● Gelişen özelliklerin ve potansiyel değişikliklerin dikkate alınması.

● Yaklaşan özelliklerin daha derinlemesine araştırılmasını gerektirir.

Toplantı Formatları:

● Belirli konular için farklı çağrılar yapılması fikri tartışıldı; katılımcılar, geçici çağrıların mı yoksa kısa süreli çağrıların mı değerli olacağını değerlendirdi.

● Daha geniş formatlara geçişin bu çağrıları istemeden geliştirici odaklı toplantılara dönüştürebileceği ve düğüm operatörlerinin bağlantısının kesilmesine neden olabileceği yönünde endişeler dile getirildi.

Katılımcı Seçimi:

● Katılımcılar, ağır sıklet geliştiricilerin (örn. Nathan James) ara sıra bu çağrılara katılma isteklerini dile getirdiler. Kevin Heifner'ı geliştirici toplantılarına getiren ve Nathan'ın dokümantasyon ve yönlendirme konusundaki uzmanlığından yararlanan iki yönlü bir değişim fikri önerildi.

● Katılımcılardan oluşan “rüya takım”da Kevin Heifner, Nathan James ve düzenli katkıda bulunanlar (Michael EOSUSA, Ross (EOS Sphere), Matthew Darwin) yer alacaktı. Altyapı ağırlıklı düğüm operatörleri, Aaron Cox (Greymass) ve EOS Amsterdam'dan Stan gibi L2 uzmanları da dahil edilebilir.

Toplantı Sıklığı:

● Haftalık bir program sürdürmeye yönelin.

Toplantı Süresi:

● Toplantıların bir saatte tutarlı tutulması önerisi.

● Derinlemesine tartışmalar için genişletmenin değerlendirilmesi.

Alternatif Toplantı Saatleri:

● Rutinleri bozma ve katılımı parçalama zorluğu.

● Farklı zamanlarda önerilen ek aramalar.

Gündem İyileştirmeleri:

● Durum güncellemeleri ve ana konularla önerilen esnek gündem.

Toplantı Notlarının Değerlendirilmesi:

● Toplantı notlarının yeterliliği konusunda tartışma.

● Bulunmayan kişilerden geri bildirim alınması önerilir.

Toplantı Kayıtları:

● Toplantıları kaydetme konusunda endişeniz yok.

Yapay Zeka Tarafından Oluşturulan Notlar ve Transkriptler:

● Aktif kayda bağlı olarak yapay zeka tarafından oluşturulan notlar memnuniyetle karşılandı.

Katılımın Artırılması:

● Son konu, bu değerli tartışmalara katılımı genişletmek amacıyla katılmayanların aktif olarak katılımının sağlanması önerisiyle birlikte katılımın artırılmasıyla ilgiliydi.

Leap Yükseltmesi RC2 → RC3 ile ilgili Kilometre Taşları etrafında dönen bölüm

Bir yapılandırma parametresine, "blok ofseti üretmeye" ve bunu maksimum performans için optimize etmeye yönelik stratejilere özel bir referansla, işlem imzalama için CPU kullanılabilirliğine odaklanıldı.

Bir sonraki sürüm adayı için sorunların düzeltilmesine odaklanılarak kilometre taşları ana hatlarıyla belirtildi.

ARM yapılarında başarısız olan BLS testleri de dahil olmak üzere bazı kritik sorunlar tartışıldı ve bunları çözmeye yönelik çalışmalar devam ediyor.

Yapılandırma Parametreleri:

"Blok ofseti üretme" parametresinin sağlıklı ayarı önemli bir konuydu; bu soru Ross tarafından gündeme getirildi ve Kevin, önümüzdeki sürümde bunun nasıl iyileştirildiğine dair derinlemesine bir açıklama yaparak devreye girdi.

RC2'nin varsayılan değeri %90 veya 600 milisaniyeydi ve bu da çok ihtiyatlı kabul ediliyordu.

Yeni sürümde, yeni ayar ofseti milisaniye cinsinden ifade ederek daha ince ayar yapılmasına olanak sağladı. Katılımcılar çeşitli ayarları ve gelişmiş işlem işleme ve azaltılmış gecikme gibi potansiyel faydaları tartıştılar.

"12. bloğa ulaşan işlemler için gecikmede potansiyel bir artış var, ancak yalnızca son bloğa ulaşan işlemler için, yani biliyorsunuz ki oldukça küçük bir negatif, diğer her şey için oldukça büyük bir pozitif" Kevin Heifner

En önemli avantaj zincirin sıkışık olduğu dönemlerde ortaya çıkıyor. Ayrıca, genel verimi olumsuz etkilemeden değerlendirmeleri için ek süre sağlayarak başarısız işlemlerin daha etkili bir şekilde ele alınmasına yardımcı olur. Temelde CPU kullanımını optimize eder.


Kaynaklar ve Referanslar

Bu cevap sorunuzu yanıtladı mı?