Jinjin Finance Blockchain, 10 Haziran Bu hafta Arbitrum'un sıralayıcı kodundaki bir hata, ağın toplu işlem gönderme işlevinin geçici olarak kesintiye uğramasına ve işlemlerin ana zincirde onaylanamamasına neden oldu. Güvenlik açığı o zamandan beri düzeltildi ve işlem toplu gönderme işlevi geri yüklendi. 10 Haziran'da Arbitrum Vakfı, Arbitrum sıralayıcı hatasının olay sonrası analiz raporunu yayınladı. Şimdi durumu gözden geçirelim ve bu hata olayının neden kullanıcı fonlarının kaybolmasına neden olmadığını görelim.
Arbitrum Sorter Hata Olay Zaman Çizelgesi
7 Haziran 2023 06:04:53'te, toplu düzenleyici, Arbitrum harmanlayıcı L1 düğümündeki geçici bir sorun nedeniyle L1 durum görünümünü güncelleyemedi. Temel neden sorunu nedeniyle, Arbitrum sıralayıcısı önceki L1 görünüm bloğu numarasının durumunu sorgulamaya devam etti. Bu, geçici L1 düğümü sorununun kendi kendine çözülmesinden sonra bile toplu yayımcının eski L1 blok numarasının durumunu sorgulamaya çalışacağı ve L1 düğümünün bir arşiv düğümü olmadığı için artık kendi durumuna sahip olmayacağı anlamına gelir.
7 Haziran 2023 tarihinde 09:38:28'de, Arbitrum'un toplu posteri, mempool limitiyle aynı olan, yapılandırılmış maksimum kuyruğa alınmış işlem limitine (256) ulaştığı için işlemleri yayınlamayı durdurdu. Bu sınıra ulaşılmazsa, toplu gönderi her zamanki gibi devam edecektir.
7 Haziran 2023 günü saat 11:09'da yayınlanmayan partiler nedeniyle Sequencer Inbox akıllı sözleşmesinde yeni partileri kontrol etmek için bir uyarı tetiklendi ve Slack kanalına bir uyarı gönderildi.
Saat 11:10'da, son toplu sürümlerin olmaması, günlük tabanlı bir uyarıyı tetikledi ve Slack kanalına kritik düzeyde bir uyarı gönderdi.
Sabah 11:13'te topluluk ekibinin bir üyesi, olayı derhal kabul eden ve yanıt vermeye başlayan SRE ekibinin bir üyesiyle PagerDuty'yi başlattı.
Sabah 11:19:02'de, SRE ekibi toplu posteri yeniden başlattı, ancak daha önce belirtilen maksimum kuyruğa alınmış işlem limiti nedeniyle toplu posterin işlemleri yayınlaması engellendi. SRE ekibi bu sorunu fark etti ve sorunu azaltmak için üçüncü taraf bir L1 RPC sağlayıcısına geçmeye başladı.
Grup posteri başladıktan 5 dakika sonra 11:24:16 AM'de L1 durum görünümünü güncelledi ve ilk işlem grubunu yayınladı.
11:25:09 AM'de, toplu poster yapılandırması üçüncü taraf bir L1 RPC sağlayıcısı kullanacak şekilde değiştirildi ve SRE ekibi zaten bu değişikliği yapmaya başladığı ve toplu işlemi fark etmediği için yeniden başlatıldı. Yeniden başlatmanın ardından toplu işlemler gerçekleşmeye devam eder.
Sabah 11:30:21'de, grup posteri başladıktan 5 dakika sonra, L1 durumu görünümü güncellendi ve bu da L1 durumunun senkronize olmamasını tetikledi ve bu aynı zamanda sorunun temel nedeniydi. L1 durumu, son blok numarası 17428199'a güncellendi, ancak durumunda depolanan son blok yerine o sırada en son bloğa karşılık gelen nonce 178078'i kullandı ve Redis'te kuyruğa alınmış tüm işlemlerin silinmesine neden oldu. çünkü Redis bu işlemleri onaylanmış kabul etmektedir.
Saat 11:30:26'da grup posteri yeni bir grup yayınladı. Redis, neyin yayınlanacağını belirlemek için L1 durum görünümüne güvenir, ancak bu noktada Redis kuyruğu boştur, daha önce belirtildiği gibi, L1 durumu yanlıştır ve 178078 durumunda rastgele bir sayı ile bir toplu iş yayınlanmıştır, ancak toplu iş, 17428199 alakasız bir blok numarası kullanılarak yayınlanacak, bunun sonucunda seri numarası 229209 olan eski bir toplu iş yayınlanacak, bu aslında daha önce 11:24:16'da yayınlandı ve ardından toplu iş posteri yeniden başlatıldı. 229209 eski toplu iş zaten yayınlanmış olduğundan, toplu iş tarafından gönderilen L1 işlemi geri alındı.
11:36:35 AM'de, gas ücretini iade etmediği için toplu poster adresinin Ether'i tükendi, bu nedenle yayınlamayı durdurdu. kurtarma toplu maliyeti.
Sabah 11:46'da Nitro ekibinin bir üyesi, toplu kurtarma ile ilgili bir yazılım sorununu çözmek için bir çağrı aldı.
Sabah 11:58 civarında Arbitrum, bazı kullanıcıların sıralayıcıda bir sorun olduğunu (yeni sıralanan işlemlerin RPC düğümlerine yayınlanması) bulduklarına dair raporlar almaya başladı; zincirde, bu sorun öncelikle zayıf internet bağlantısına veya yetersiz bellek tahsisine sahip akış istemcilerini etkiler, çünkü bunların kopma ve yeniden bağlanma sorunları yaşama olasılıkları daha yüksektir. Arbitrum, birden çok RPC düğümü çalıştıran kullanıcıların gerekli harici bant genişliğini azaltmak için yerel bir besleme rölesi çalıştırmasını önerir.
Saat 12:03'te Arbitrum, internet bağlantısı nedeniyle bağlantısı kesildikten sonra yeniden bağlanmaya çalışan müşterilerin hız sınırına ulaşması sorununu hafifletmek için Cloudflare'in besleme hızı sınırlamasını kaldırdı.
Öğleden sonra 12:05'te Arbitrum, düğümleri akış bağlantılarını sürdürmekte sorun yaşayanlar için daha fazla genel RPC kullanımına izin vermek için tüm Cloudflare hız sınırlamasını kaldırdı.
12:12:09 PM'de, hatalı toplu iş posteri kapatıldı ve Redis sıra deposu kötü durumu kaldırmak için temizlendi.
Akşam 12:12:40 da eski sürüm v2.0.14 de toplu poster başladı ve root sorunu yoktu.
Saat 12:21:56'da yeni açılan toplu afişlerin ilk partisi başarılı oldu ve o zamandan beri aralıksız çalışıyorlar.
Arbitrum sıralayıcı hata olayı dersleri öğrenildi
Bu hataya toplu iş posterindeki bir hata neden oldu. Sıralayıcının kendisi etkilenmedi veya kesintiye uğramadı ve süreç boyunca işlemleri işlemeye devam etti. Sıralayıcının parasının bittiğine dair raporlar yanlış. Arbitrum fon mekanizması iki cüzdandan oluşur, yani: "sıralayıcı" cüzdanı ve "gaz iadesi" cüzdanı. Sadece sıralayıcı grubu başarılı bir şekilde serbest bıraktığında iade edilecektir. Arbitrum ağı sıralayıcıya bunun için geri ödeme yapmadı. başarısızlık, fonlar ve ilgili sorunlar sıralayıcının fonlarının bitmesinden kaynaklanmıyordu, dolayısıyla hiçbir kullanıcı fonu risk altında değildi.
Arbitrum, geçici çözüme eklenen yapılandırma seçeneklerini temizleyecektir. Daha sonra, işlem birikmelerinde ağ güvenilirliğini artırmak için sıralayıcı istemci ve sunucu zaman aşımı sorunlarını yeniden değerlendirmeyi planlamaktadır. Yeni bir "v2.1.0-beta" .2" beta sürümü. Ek olarak, Arbitrum, hizmetle ilgili sorunlar olması durumunda karışıklığı azaltmak için bir genel ağ durumu sayfası oluşturacaktır.
Bu makale, Arbitrum Vakfı'nın resmi web sitesinden alınmıştır.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Altın Gözlem | Arbitrum sıralayıcı hata olayının gözden geçirilmesi
Yazar: Altın Finans Jason
Jinjin Finance Blockchain, 10 Haziran Bu hafta Arbitrum'un sıralayıcı kodundaki bir hata, ağın toplu işlem gönderme işlevinin geçici olarak kesintiye uğramasına ve işlemlerin ana zincirde onaylanamamasına neden oldu. Güvenlik açığı o zamandan beri düzeltildi ve işlem toplu gönderme işlevi geri yüklendi. 10 Haziran'da Arbitrum Vakfı, Arbitrum sıralayıcı hatasının olay sonrası analiz raporunu yayınladı. Şimdi durumu gözden geçirelim ve bu hata olayının neden kullanıcı fonlarının kaybolmasına neden olmadığını görelim.
Arbitrum Sorter Hata Olay Zaman Çizelgesi
7 Haziran 2023 06:04:53'te, toplu düzenleyici, Arbitrum harmanlayıcı L1 düğümündeki geçici bir sorun nedeniyle L1 durum görünümünü güncelleyemedi. Temel neden sorunu nedeniyle, Arbitrum sıralayıcısı önceki L1 görünüm bloğu numarasının durumunu sorgulamaya devam etti. Bu, geçici L1 düğümü sorununun kendi kendine çözülmesinden sonra bile toplu yayımcının eski L1 blok numarasının durumunu sorgulamaya çalışacağı ve L1 düğümünün bir arşiv düğümü olmadığı için artık kendi durumuna sahip olmayacağı anlamına gelir.
7 Haziran 2023 tarihinde 09:38:28'de, Arbitrum'un toplu posteri, mempool limitiyle aynı olan, yapılandırılmış maksimum kuyruğa alınmış işlem limitine (256) ulaştığı için işlemleri yayınlamayı durdurdu. Bu sınıra ulaşılmazsa, toplu gönderi her zamanki gibi devam edecektir.
7 Haziran 2023 günü saat 11:09'da yayınlanmayan partiler nedeniyle Sequencer Inbox akıllı sözleşmesinde yeni partileri kontrol etmek için bir uyarı tetiklendi ve Slack kanalına bir uyarı gönderildi.
Saat 11:10'da, son toplu sürümlerin olmaması, günlük tabanlı bir uyarıyı tetikledi ve Slack kanalına kritik düzeyde bir uyarı gönderdi.
Sabah 11:13'te topluluk ekibinin bir üyesi, olayı derhal kabul eden ve yanıt vermeye başlayan SRE ekibinin bir üyesiyle PagerDuty'yi başlattı.
Sabah 11:19:02'de, SRE ekibi toplu posteri yeniden başlattı, ancak daha önce belirtilen maksimum kuyruğa alınmış işlem limiti nedeniyle toplu posterin işlemleri yayınlaması engellendi. SRE ekibi bu sorunu fark etti ve sorunu azaltmak için üçüncü taraf bir L1 RPC sağlayıcısına geçmeye başladı.
Grup posteri başladıktan 5 dakika sonra 11:24:16 AM'de L1 durum görünümünü güncelledi ve ilk işlem grubunu yayınladı.
11:25:09 AM'de, toplu poster yapılandırması üçüncü taraf bir L1 RPC sağlayıcısı kullanacak şekilde değiştirildi ve SRE ekibi zaten bu değişikliği yapmaya başladığı ve toplu işlemi fark etmediği için yeniden başlatıldı. Yeniden başlatmanın ardından toplu işlemler gerçekleşmeye devam eder.
Sabah 11:30:21'de, grup posteri başladıktan 5 dakika sonra, L1 durumu görünümü güncellendi ve bu da L1 durumunun senkronize olmamasını tetikledi ve bu aynı zamanda sorunun temel nedeniydi. L1 durumu, son blok numarası 17428199'a güncellendi, ancak durumunda depolanan son blok yerine o sırada en son bloğa karşılık gelen nonce 178078'i kullandı ve Redis'te kuyruğa alınmış tüm işlemlerin silinmesine neden oldu. çünkü Redis bu işlemleri onaylanmış kabul etmektedir.
Saat 11:30:26'da grup posteri yeni bir grup yayınladı. Redis, neyin yayınlanacağını belirlemek için L1 durum görünümüne güvenir, ancak bu noktada Redis kuyruğu boştur, daha önce belirtildiği gibi, L1 durumu yanlıştır ve 178078 durumunda rastgele bir sayı ile bir toplu iş yayınlanmıştır, ancak toplu iş, 17428199 alakasız bir blok numarası kullanılarak yayınlanacak, bunun sonucunda seri numarası 229209 olan eski bir toplu iş yayınlanacak, bu aslında daha önce 11:24:16'da yayınlandı ve ardından toplu iş posteri yeniden başlatıldı. 229209 eski toplu iş zaten yayınlanmış olduğundan, toplu iş tarafından gönderilen L1 işlemi geri alındı.
11:36:35 AM'de, gas ücretini iade etmediği için toplu poster adresinin Ether'i tükendi, bu nedenle yayınlamayı durdurdu. kurtarma toplu maliyeti.
Sabah 11:46'da Nitro ekibinin bir üyesi, toplu kurtarma ile ilgili bir yazılım sorununu çözmek için bir çağrı aldı.
Sabah 11:58 civarında Arbitrum, bazı kullanıcıların sıralayıcıda bir sorun olduğunu (yeni sıralanan işlemlerin RPC düğümlerine yayınlanması) bulduklarına dair raporlar almaya başladı; zincirde, bu sorun öncelikle zayıf internet bağlantısına veya yetersiz bellek tahsisine sahip akış istemcilerini etkiler, çünkü bunların kopma ve yeniden bağlanma sorunları yaşama olasılıkları daha yüksektir. Arbitrum, birden çok RPC düğümü çalıştıran kullanıcıların gerekli harici bant genişliğini azaltmak için yerel bir besleme rölesi çalıştırmasını önerir.
Saat 12:03'te Arbitrum, internet bağlantısı nedeniyle bağlantısı kesildikten sonra yeniden bağlanmaya çalışan müşterilerin hız sınırına ulaşması sorununu hafifletmek için Cloudflare'in besleme hızı sınırlamasını kaldırdı.
Öğleden sonra 12:05'te Arbitrum, düğümleri akış bağlantılarını sürdürmekte sorun yaşayanlar için daha fazla genel RPC kullanımına izin vermek için tüm Cloudflare hız sınırlamasını kaldırdı.
12:12:09 PM'de, hatalı toplu iş posteri kapatıldı ve Redis sıra deposu kötü durumu kaldırmak için temizlendi.
Akşam 12:12:40 da eski sürüm v2.0.14 de toplu poster başladı ve root sorunu yoktu.
Saat 12:21:56'da yeni açılan toplu afişlerin ilk partisi başarılı oldu ve o zamandan beri aralıksız çalışıyorlar.
Arbitrum sıralayıcı hata olayı dersleri öğrenildi
Bu hataya toplu iş posterindeki bir hata neden oldu. Sıralayıcının kendisi etkilenmedi veya kesintiye uğramadı ve süreç boyunca işlemleri işlemeye devam etti. Sıralayıcının parasının bittiğine dair raporlar yanlış. Arbitrum fon mekanizması iki cüzdandan oluşur, yani: "sıralayıcı" cüzdanı ve "gaz iadesi" cüzdanı. Sadece sıralayıcı grubu başarılı bir şekilde serbest bıraktığında iade edilecektir. Arbitrum ağı sıralayıcıya bunun için geri ödeme yapmadı. başarısızlık, fonlar ve ilgili sorunlar sıralayıcının fonlarının bitmesinden kaynaklanmıyordu, dolayısıyla hiçbir kullanıcı fonu risk altında değildi.
Arbitrum, geçici çözüme eklenen yapılandırma seçeneklerini temizleyecektir. Daha sonra, işlem birikmelerinde ağ güvenilirliğini artırmak için sıralayıcı istemci ve sunucu zaman aşımı sorunlarını yeniden değerlendirmeyi planlamaktadır. Yeni bir "v2.1.0-beta" .2" beta sürümü. Ek olarak, Arbitrum, hizmetle ilgili sorunlar olması durumunda karışıklığı azaltmak için bir genel ağ durumu sayfası oluşturacaktır.
Bu makale, Arbitrum Vakfı'nın resmi web sitesinden alınmıştır.