Jinjin Finance Blockchain, 10 червня Помилка в коді сортувальника Arbitrum цього тижня призвела до короткого переривання здатності мережі надсилати транзакції пакетами, і транзакції не могли бути підтверджені в основному ланцюзі. Відтоді вразливість усунуто, а функцію пакетної подачі транзакцій відновлено. 10 червня фонд Arbitrum опублікував звіт про аналіз помилки сортувальника Arbitrum. Далі розглянемо та з’ясуємо, чому ця помилка не призвела до втрати коштів користувачів.
Хронологія подій про помилку Arbitrum Sorter
О 06:04:53 7 червня 2023 року емітент пакету не зміг оновити своє подання стану L1 через тимчасову проблему з вузлом L1 сортувальника Arbitrum. Через проблему основної причини сортувальник Arbitrum продовжував намагатися запитати стан свого попереднього номера блоку перегляду L1. Це означає, що навіть після того, як тимчасова проблема вузла L1 вирішиться сама собою, пакетний видавець продовжуватиме запитувати стан старого номера блоку L1, а вузол L1 більше не матиме свого стану, оскільки він не є вузлом архіву.
О 09:38:28 7 червня 2023 року пакетний постер Arbitrum припинив публікацію транзакцій, оскільки досяг налаштованого максимального ліміту транзакцій у черзі (256), який дорівнює ліміту mempool. Якщо цей ліміт не досягнуто, масове опублікування продовжуватиметься, як зазвичай.
Об 11:09 ранку 7 червня 2023 року через неопубліковані пакети в смарт-контракті Sequencer Inbox було активовано сповіщення, щоб перевірити наявність нових пакетів, і попередження було надіслано на канал Slack.
Об 11:10 ранку відсутність останніх пакетних випусків викликала сповіщення на основі журналу та надіслало сповіщення про критичний рівень на канал Slack.
Об 11:13 ранку член команди спільноти ініціював PagerDuty з членом команди SRE, який негайно визнав інцидент і почав реагувати.
Вранці об 11:19:02 команда SRE перезапустила пакетний плакат, але через згаданий раніше максимальний ліміт транзакцій у черзі пакетному плакату не вдалося опублікувати транзакції. Команда SRE помітила цю проблему та почала перемикатися на стороннього постачальника L1 RPC, намагаючись пом’якшити проблему.
Об 11:24:16, через 5 хвилин після запуску пакетного плаката, він оновив перегляд стану L1 і опублікував першу партію транзакцій.
Об 11:25:09 конфігурацію пакетного плаката було змінено на використання стороннього постачальника L1 RPC і перезапущено, оскільки команда SRE вже почала вносити цю зміну та не помітила пакетування. Після перезапуску пакетні транзакції продовжують відбуватися.
Вранці об 11:30:21, через 5 хвилин після запуску пакетного плаката, перегляд стану L1 було оновлено, що спричинило розсинхронізацію стану L1, що також було основною причиною проблеми. Стан L1 було оновлено до останнього блоку з номером 17428199, але він використовував останній одноразовий номер 178078, що відповідає останньому блоку на той час, замість останнього блоку, який зберігається в його стані, в результаті чого всі транзакції в черзі в Redis були стерті, за винятком оскільки Redis вважає ці транзакції підтвердженими.
Об 11:30:26 плакат партії опублікував нову партію. Redis покладається на перегляд стану L1, щоб визначити, що публікувати, але на даний момент черга Redis порожня, як зазначено раніше, стан L1 неправильний, і пакет було опубліковано з випадковим числом у стані 178078, але для визначення пакет для публікації з використанням нерелевантного номера блоку 17428199, у результаті чого буде опубліковано старий пакет із серійним номером 229209, який фактично був опублікований об 11:24:16 раніше, а потім перезапуск плаката пакета. Оскільки старий пакет 229209 уже опубліковано, транзакцію L1, надіслану пакетом, було відкочено.
Об 11:36:35 ранку на адресі партійного плаката закінчився ефір, оскільки він не відшкодовував плату за газ, тому він припинив публікацію. Це навмисний механізм, щоб запобігти споживанню партійним плакатом усього газу, що зберігається в вартість партії відновлення.
Об 11:46 ранку член команди Nitro отримав дзвінок для вирішення проблеми програмного забезпечення з пакетним відновленням.
Близько 11:58 ранку Arbitrum почав отримувати повідомлення про те, що деякі користувачі виявили проблему з сортувальником (трансляція нещодавно відсортованих транзакцій на вузли RPC), тому що все більше і більше замовлених транзакцій відбувалося через проблеми з пакетним плакатом, а не через публікацію до ланцюжка, ця проблема в першу чергу стосується клієнтів каналу з поганим підключенням до Інтернету або недостатнім виділенням пам’яті, оскільки вони, швидше за все, відпадуть і виникнуть проблеми з повторним підключенням. Arbitrum рекомендує, щоб користувачі, які працюють з декількома вузлами RPC, запускали локальний ретранслятор, щоб зменшити необхідну зовнішню пропускну здатність.
О 12:03 Arbitrum зняв обмеження швидкості подачі Cloudflare, щоб полегшити проблему досягнення клієнтами ліміту швидкості під час спроби повторного підключення після відключення через Інтернет-з’єднання.
О 12:05 Arbitrum скасував усі обмеження на швидкість Cloudflare, щоб збільшити використання загальнодоступного RPC для тих, чиї вузли мали проблеми з підтримкою підключення до каналів.
О 12:12:09 несправний пакетний плакат було вимкнено, а сховище черги Redis очищено, щоб видалити поганий стан.
О 12:12:40 розпочався пакетний постер на старій версії v2.0.14, і проблеми з рутом не було.
О 12:21:56 перша партія щойно відкритих пакетних плакатів була успішною, і з того часу вони працюють безперервно.
Здобуті уроки щодо подій помилок сортувальника Arbitrum
Цю помилку спричинила помилка в пакетному постері. Сам секвенсор не постраждав і не перервався, він продовжував обробляти транзакції протягом усього процесу. Повідомлення про те, що в секвенсорі закінчилися кошти, невірні. Механізм фінансування Arbitrum складається з двох гаманців, а саме: гаманця «sequencer» і гаманця «gas-refunder». Лише коли секвенсер зможе успішно випустити партію, вона буде повернена. Мережа Arbitrum не повернула кошти секвенсеру за це і відповідні проблеми не були спричинені тим, що в секвенсорі закінчилися кошти, тому жодні кошти користувачів не були під загрозою.
Arbitrum очистить параметри конфігурації, додані в проміжне рішення. Пізніше він планує переоцінити проблеми клієнта секвенсора та тайм-ауту сервера, щоб підвищити надійність мережі у випадку резервних транзакцій. Нова "версія 2.1.0-бета .2" бета-версія. Крім того, Arbitrum створить загальнодоступну сторінку стану мережі, щоб зменшити плутанину, якщо виникнуть проблеми з сервісом.
Посилання на цю статтю зроблено з офіційного сайту фонду Arbitrum
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Golden Observation | Огляд події помилки сортувальника Arbitrum
Автор: Голден Фінанс Джейсон
Jinjin Finance Blockchain, 10 червня Помилка в коді сортувальника Arbitrum цього тижня призвела до короткого переривання здатності мережі надсилати транзакції пакетами, і транзакції не могли бути підтверджені в основному ланцюзі. Відтоді вразливість усунуто, а функцію пакетної подачі транзакцій відновлено. 10 червня фонд Arbitrum опублікував звіт про аналіз помилки сортувальника Arbitrum. Далі розглянемо та з’ясуємо, чому ця помилка не призвела до втрати коштів користувачів.
Хронологія подій про помилку Arbitrum Sorter
О 06:04:53 7 червня 2023 року емітент пакету не зміг оновити своє подання стану L1 через тимчасову проблему з вузлом L1 сортувальника Arbitrum. Через проблему основної причини сортувальник Arbitrum продовжував намагатися запитати стан свого попереднього номера блоку перегляду L1. Це означає, що навіть після того, як тимчасова проблема вузла L1 вирішиться сама собою, пакетний видавець продовжуватиме запитувати стан старого номера блоку L1, а вузол L1 більше не матиме свого стану, оскільки він не є вузлом архіву.
О 09:38:28 7 червня 2023 року пакетний постер Arbitrum припинив публікацію транзакцій, оскільки досяг налаштованого максимального ліміту транзакцій у черзі (256), який дорівнює ліміту mempool. Якщо цей ліміт не досягнуто, масове опублікування продовжуватиметься, як зазвичай.
Об 11:09 ранку 7 червня 2023 року через неопубліковані пакети в смарт-контракті Sequencer Inbox було активовано сповіщення, щоб перевірити наявність нових пакетів, і попередження було надіслано на канал Slack.
Об 11:10 ранку відсутність останніх пакетних випусків викликала сповіщення на основі журналу та надіслало сповіщення про критичний рівень на канал Slack.
Об 11:13 ранку член команди спільноти ініціював PagerDuty з членом команди SRE, який негайно визнав інцидент і почав реагувати.
Вранці об 11:19:02 команда SRE перезапустила пакетний плакат, але через згаданий раніше максимальний ліміт транзакцій у черзі пакетному плакату не вдалося опублікувати транзакції. Команда SRE помітила цю проблему та почала перемикатися на стороннього постачальника L1 RPC, намагаючись пом’якшити проблему.
Об 11:24:16, через 5 хвилин після запуску пакетного плаката, він оновив перегляд стану L1 і опублікував першу партію транзакцій.
Об 11:25:09 конфігурацію пакетного плаката було змінено на використання стороннього постачальника L1 RPC і перезапущено, оскільки команда SRE вже почала вносити цю зміну та не помітила пакетування. Після перезапуску пакетні транзакції продовжують відбуватися.
Вранці об 11:30:21, через 5 хвилин після запуску пакетного плаката, перегляд стану L1 було оновлено, що спричинило розсинхронізацію стану L1, що також було основною причиною проблеми. Стан L1 було оновлено до останнього блоку з номером 17428199, але він використовував останній одноразовий номер 178078, що відповідає останньому блоку на той час, замість останнього блоку, який зберігається в його стані, в результаті чого всі транзакції в черзі в Redis були стерті, за винятком оскільки Redis вважає ці транзакції підтвердженими.
Об 11:30:26 плакат партії опублікував нову партію. Redis покладається на перегляд стану L1, щоб визначити, що публікувати, але на даний момент черга Redis порожня, як зазначено раніше, стан L1 неправильний, і пакет було опубліковано з випадковим числом у стані 178078, але для визначення пакет для публікації з використанням нерелевантного номера блоку 17428199, у результаті чого буде опубліковано старий пакет із серійним номером 229209, який фактично був опублікований об 11:24:16 раніше, а потім перезапуск плаката пакета. Оскільки старий пакет 229209 уже опубліковано, транзакцію L1, надіслану пакетом, було відкочено.
Об 11:36:35 ранку на адресі партійного плаката закінчився ефір, оскільки він не відшкодовував плату за газ, тому він припинив публікацію. Це навмисний механізм, щоб запобігти споживанню партійним плакатом усього газу, що зберігається в вартість партії відновлення.
Об 11:46 ранку член команди Nitro отримав дзвінок для вирішення проблеми програмного забезпечення з пакетним відновленням.
Близько 11:58 ранку Arbitrum почав отримувати повідомлення про те, що деякі користувачі виявили проблему з сортувальником (трансляція нещодавно відсортованих транзакцій на вузли RPC), тому що все більше і більше замовлених транзакцій відбувалося через проблеми з пакетним плакатом, а не через публікацію до ланцюжка, ця проблема в першу чергу стосується клієнтів каналу з поганим підключенням до Інтернету або недостатнім виділенням пам’яті, оскільки вони, швидше за все, відпадуть і виникнуть проблеми з повторним підключенням. Arbitrum рекомендує, щоб користувачі, які працюють з декількома вузлами RPC, запускали локальний ретранслятор, щоб зменшити необхідну зовнішню пропускну здатність.
О 12:03 Arbitrum зняв обмеження швидкості подачі Cloudflare, щоб полегшити проблему досягнення клієнтами ліміту швидкості під час спроби повторного підключення після відключення через Інтернет-з’єднання.
О 12:05 Arbitrum скасував усі обмеження на швидкість Cloudflare, щоб збільшити використання загальнодоступного RPC для тих, чиї вузли мали проблеми з підтримкою підключення до каналів.
О 12:12:09 несправний пакетний плакат було вимкнено, а сховище черги Redis очищено, щоб видалити поганий стан.
О 12:12:40 розпочався пакетний постер на старій версії v2.0.14, і проблеми з рутом не було.
О 12:21:56 перша партія щойно відкритих пакетних плакатів була успішною, і з того часу вони працюють безперервно.
Здобуті уроки щодо подій помилок сортувальника Arbitrum
Цю помилку спричинила помилка в пакетному постері. Сам секвенсор не постраждав і не перервався, він продовжував обробляти транзакції протягом усього процесу. Повідомлення про те, що в секвенсорі закінчилися кошти, невірні. Механізм фінансування Arbitrum складається з двох гаманців, а саме: гаманця «sequencer» і гаманця «gas-refunder». Лише коли секвенсер зможе успішно випустити партію, вона буде повернена. Мережа Arbitrum не повернула кошти секвенсеру за це і відповідні проблеми не були спричинені тим, що в секвенсорі закінчилися кошти, тому жодні кошти користувачів не були під загрозою.
Arbitrum очистить параметри конфігурації, додані в проміжне рішення. Пізніше він планує переоцінити проблеми клієнта секвенсора та тайм-ауту сервера, щоб підвищити надійність мережі у випадку резервних транзакцій. Нова "версія 2.1.0-бета .2" бета-версія. Крім того, Arbitrum створить загальнодоступну сторінку стану мережі, щоб зменшити плутанину, якщо виникнуть проблеми з сервісом.
Посилання на цю статтю зроблено з офіційного сайту фонду Arbitrum