Mayıs 2023'ten 'inv-to-send kümelerinin çok büyümesi nedeniyle DoS' hakkında notlar
Ekim 2024'te, Bitcoin Core projesi, benim de yazarı olduğum ve v25.0'dan önceki Bitcoin Core sürümlerini etkileyen, inv-to-send kümelerinin çok büyümesi nedeniyle oluşan bir Hizmet Reddi (Denial-of-Service) sorununu açıkladı. O zamanki araştırmamdan birkaç not ve ekran görüntüsünü burada saklamak istiyorum. Mayıs 2023'ün başlarında, izleme altyapım bu hatanın mainnet düğümlerini etkilediğini fark etti ve bu da sorunun nereden kaynaklandığını belirlememi sağladı. Düzeltme üzerinde çalıştığı için Anthony Towns'a teşekkürler.
Gözlem
2 Mayıs 2023'te, izleme düğümlerimden birinde, gelen bağlantıların yaklaşık iki gün içinde 190'dan1 sadece 35'e düştüğünü fark ettim. Normalde, bir düğüm yeniden başlatılana veya ağ bağlantısı kesilene kadar dolu gelen yuvalarını korur.
Bitcoin Core düğümümün gelen ve giden bağlantı sayısını izlemek için kullandığım Grafana panosunun ekran görüntüsü. Sarı çubuklar, gelen bağlantı sayısını gösteriyor. Bunlar grafiğin sonunda düşüyor.
Diğer katkıda bulunanlarla kontrol ettiğimde, düğümün %100 CPU kullanımına sahip olduğunu fark ettim. Bu, düğümü akranlarıyla iletişim kuramaz hale getirdi, bu da gelen bağlantıların zaman aşımına uğramasına ve düşmesine neden oldu. Düğüm sürecinde perf top kullanarak, b-msghand iş parçacığında CTxMemPool::CompareDepthAndScore() üzerinde çok fazla CPU zamanı harcandığını görebiliyordum. CompareDepthAndScore()'u çağıran make_heap()'in, sürecin CPU zamanının %45'inden fazlasını kullandığını gösteren aşağıdaki alev grafiğini kaydettim.
Bitcoin Core sürecinin CPU zamanının nerede harcandığını gösteren bir alev grafiği. Bu alev grafiğiyle etkileşim kurmak için yeni bir sekmede açın.
Aynı zamanda, Bitcoin Core'un hata ayıklama modu derlemeleriyle ilgili açık ve ilgisiz bir %100 CPU kullanımı sorunu vardı. Bu, hata ayıklama modu derlemeleri çalıştırmayan ancak düğümlerinde yüksek CPU kullanımı fark eden bazı katkıda bulunanları ve kullanıcıları şaşırttı. Hata ayıklama modu sorunu muhtemelen yalnızca bazı geliştiricileri etkilerken, diğer yüksek CPU kullanımı sorunu tüm ağı etkiledi. Buna, örneğin, AntPool ve diğerleri gibi madencilik havuzları da dahil olmak üzere, alınan blokları zamanında işleyemeyen düğümleri nedeniyle madencilik operasyonlarında sorunlar bildirenler de dahildi.
Etki
Ağ genelinde ping zamanlamalarını gözlemlemek, bu Hizmet Reddi'nin etkisini ortaya koyuyor. Bitcoin Core'un mesaj işleme özelliği tek iş parçacıklı olduğundan, aynı anda yalnızca bir mesaj oluşturulabilir veya işlenebilir, yani diğer tüm akranların beklemesi gerekir. Daha uzun bekleme süreleri, bir ping'in yanıt süresini etkiler. KIT DSN Bitcoin izleme, ICMP ve Bitcoin protokolü ping'leri hakkında verilere sahiptir. Bunları karşılaştırmak, düğüm yazılımının mesaj işlemeye ayak uydurmakta ne zaman sorun yaşadığını belirlememizi sağlar. Veriler, ana bilgisayara yapılan ICMP ping'inin etkilenmediğini, ancak Bitcoin düğümü yazılımına yapılan ortalama ping'in Nisan sonu ile Mayıs başı arasında yaklaşık 25ms'den 50ms'den fazlaya neredeyse iki katına çıktığını gösteriyor. Ortalama Bitcoin ping'i 8 Mayıs'ta 200ms'ye yükselirken, ICMP ping'i etkilenmedi.
Ortalama Bitcoin protokolü ping'i ve ICMP ping'i. DSN KIT'ten alınan verilere dayanmaktadır (https://www.dsn.kastel.kit.edu/bitcoin/)
Etki, KIT DSN Bitcoin izleme tarafından toplanan blok yayılma gecikmesi verilerine bakılarak da görülebilir. 8 Mayıs 2023 civarında, blok yayılma gecikmesinde bir artış görülebilir. Erişilebilir düğümlerin %50'sinin bloğu izleme düğümlerine duyurmasının aldığı süre, bir saniyeden daha azdan beş saniyeden fazlaya çıktı. Benzer şekilde, %90 ölçümü yaklaşık iki saniyeden 20 saniyeden fazlaya yükseldi.
Blok yayılma gecikmesi: ağın %50'sinin ve %90'ının bir bloğu duyurmasına kadar geçen ortalama süre. DSN KIT'in verilerine dayanmaktadır (https://www.dsn.kastel.kit.edu/bitcoin/)
Kötü blok yayılımı ayrıca, madencilik havuzları eski blokları üzerinde daha uzun süre madencilik yaparken, henüz görmedikleri yeni bir blok zaten ağda mevcut olduğundan, daha fazla eski bloğa neden olur. Eski blok veri kümemden elde edilen verilere göre, 3 Mayıs (788016 eski bloğuyla başlayarak) ile 10 Mayıs (ve 789147 bloğuyla sona ererek) arasındaki hafta boyunca on eski blok gözlemlendi. Bu, 1000 blok başına yaklaşık 8,84 eski blok oranına denk geliyor. Karşılaştırma için, 800000 ile 900000 blok arasında (yaklaşık iki yıl), 73 eski blok gözlemlendi. Bu, 1000 blok başına 0,73 eski blok oranına denk geliyor. Eski blok oranındaki bu 10 kat artışın, blok yayılımının önemli ölçüde etkilenmesinden kaynaklanması muhtemeldir.
Neden
CTxMemPool::CompareDepthAndScore() fonksiyonu, düğümü P2P mesajlarını işlemekte zorlanacak kadar neden yavaşlattı? Bitcoin Core'da, b-msghand iş parçacığı P2P mesajlarını işler. Örneğin, yeni alınan blokları doğrulamaya geçirmek, ping'lere yanıt vermek, işlemleri diğer akranlara duyurmak ve çok daha fazlası.
CTxMemPool::CompareDepthAndScore() fonksiyonu, bir akrana hangi işlemlerin duyurulacağına karar verirken kullanılır. Bitcoin P2P protokolünde, işlemler inv (envanter) mesajları aracılığıyla duyurulur. Bir Bitcoin Core işleminin bir akrana duyurusu genellikle 35 adede kadar wtxid girişi içerir. Bir akrana hangi işlemlerin duyurulacağını takip etmek için, akran başına bir m_tx_inventory_to_send kümesi vardır. Bu, düğümün akranın henüz görmediğini düşündüğü işlemleri içerir. Bir akran için bir envanter mesajı oluşturulurken, yüksek ücretli işlemlere öncelik vermek ve düğümün işlemler hakkında bilgi edindiği sırayı sızdırmamak için küme, işlem bağımlılıklarına ve ücret oranına göre sıralanır. Bunun için CTxMemPool::CompareDepthAndScore() karşılaştırma fonksiyonu kullanılır.
Mayıs 2023'ün başlarında, BRC-20 token'leriyle ilgili çok sayıda işlem yayınlandı. Bu, m_tx_inventory_to_send kümelerinin normalden daha hızlı ve normalden daha büyük büyümesi anlamına geliyordu. Sonuç olarak, kümeleri sıralamak daha uzun sürdü. 7 Mayıs akşamı (UTC), VMPX BRC-20 token'inin basımı başladı ve bu da diğer devam eden BRC-20 token basımlarının yanı sıra 6 saat içinde 300 binden fazla işlemin yayınlanmasına neden oldu. Bu, 8 Mayıs'ta gözlemlenen ortalama ping ve blok yayılma sürelerindeki artışlara neden oldu.
Etki, yalnızca inv mesajlarını dinleyen ve kendi başlarına işlem duyurmayan sözde casus düğümler tarafından da artırılır. Bir akran bir düğüme bir işlem duyurduğunda, düğüm bunu m_tx_inventory_to_send kümesinden kaldırabilir, çünkü akran tarafından bilinir ve artık duyurulmasına gerek yoktur. Bu, casus düğümler için kümelerin daha da büyük olduğu ve daha yavaş boşaltıldıkları için sıralamanın daha da uzun sürdüğü anlamına geliyordu. Örneğin, LinkingLion ve diğerleri gibi casus düğümler yaygındır ve genellikle bir düğüme paralel olarak birden fazla bağlantı açarlar. Zaman zaman, düğümlerime casus olmayan düğüm bağlantılarından daha fazla varsayılan casus düğüm sayıyorum.
Yayınlanan çok sayıda işlem, casus düğümler tarafından artırılması ve büyük m_tx_inventory_to_send kümelerinin CTxMemPool::CompareDepthAndScore() tarafından optimal olmayan şekilde sıralanmasıyla birleştiğinde, düğümlerin işlem aktarımı için yeni envanter mesajları oluşturmak için çok fazla zaman harcamasına neden oldu. Mesaj işleme tek iş parçacıklı olduğundan, diğer akranlarla iletişim önemli ölçüde yavaşladı. Bu, blokların zamanında işlenmediği ve bazı bağlantıların zaman aşımına uğradığı bir noktaya ulaştı.
Düzeltme
Düzeltme iki yönlüdür. İlk olarak, zaten çıkarılmış veya başka bir nedenle mempool'da olmayan duyurulacak tüm işlemler, m_tx_inventory_to_send kümesi sıralanmadan önce kaldırıldı. Daha önce, bu işlemler yalnızca küme sıralandıktan sonra kaldırılıyordu. Bu, hiçbir zaman duyurulmayacak işlem girişlerini sıralamaya zaman harcamayı önler ve sıralanacak kümenin boyutunu küçültür. İkincisi, m_tx_inventory_to_send kümeleri büyük olduğunda, kümeden boşaltılacak giriş sayısı, küme boyutuna göre dinamik olarak artırılır. Bu, birçok işlem yayınlandığında, bir düğüm kümeler tekrar küçülene kadar akranlarına daha fazla işlem duyuracağı anlamına gelir. Düzeltme, Mayıs 2023'ün sonunda v25.0 sürümü için zamanında geri taşındı.
Yansıma
Düzenli katkıda bulunanlardan oluşan bir grup bunun olduğunu bilmesine rağmen, bu sorun kamuoyuna açıkça iletilmedi. Aynı anda tartışılan hata ayıklama moduyla ilgili %100 CPU kullanımı sorunu, düzenli Bitcoin Core katkıda bulunanlar arasında bile kafa karışıklığına neden oldu. O zamanlar, bunun sessizce düzeltilebileceği ve belki de düzeltilmesi gerektiği ve şimdilik çok fazla tanıtıma ihtiyaç duymadığı hissine kapılmıştım. Geriye dönüp baktığımda, sorunla ilgili daha açık ve şeffaf olmak da işe yarayabilirdi. Yüksek sayıda BRC-20 yayını yalnızca yaklaşık bir hafta sürdü (ancak bu önceden bilinmiyordu) ve düğümü yeniden başlatmak bir süre yardımcı olabilirdi. Örneğin, düzeltme içeren bir sürüme hemen yükseltemeyen (özel yamalarla çalıştıkları için) madencilik havuzları için sorunu hafifletmek amacıyla, bir casus düğüm yasaklama listesi hazırlandı, ancak bunun hiç kullanılıp kullanılmadığını bilmiyorum.
Bu olay için özel bir iletişim kanalı olmamasına rağmen, P2P katkıda bulunanlarla birlikte listelenmemiş bir IRC kanalı kullanıldı ve ilgili katkıda bulunanlar doğrudan mesajlar yoluyla olaylar hakkında davet edildi veya bilgilendirildi. Bildiğim kadarıyla, bir olay müdahale kanalı yoktu ve Bitcoin geliştirmenin geçici ve merkezi olmayan doğası göz önüne alındığında, bir tanesinin yardımcı olup olmayacağını bilmiyorum. Hiçbir katkıda bulunan olay müdahalesinden sorumlu değildir, ancak herkes yardımcı olabilir.
Şahsen, izlememin bu konuda faydalı olduğunu kanıtlamasından memnunum. O zamanlar düşen bağlantılar için uyarı kurmamış olsam ve bunu yalnızca panoya bakarak fark etsem de, sahip olmak yardımcı oldu. Sorunu belirlemek için, etrafta oynamak ve örneğin perf top çalıştırmak için birkaç düğüme sahip olmak yardımcı oldu. Gelecekteki izleme, ping sürelerini ve düşen bağlantılarla ilgili uyarıları içermelidir.