Ми всередині називаємо цей проект міграції "Atlas" — мета дуже проста: перенести традиційну платіжну систему з п’ятиетапного процесу "приймання→розподіл→повернення→Розрахунок→звірка" в Linea, при цьому потрібно зменшити витрати на персонал і експлуатацію.
Спочатку поговоримо про перевірку семантики. Ми просто взяли список перевірок та тестові випадки, які раніше використовувалися на L1, і по черзі порівняли їх з потоком подій та граничними випадками. На щастя, сумісність zkEVM дуже допомогла, заощадивши витрати на повторне навчання. Ми підключили CI/CD до тестової мережі та створили панель моніторингу "подання—доказ—упаковка—повернення", щоб ризиковий менеджмент і фінансовий відділ могли в реальному часі бачити дані.
Далі потрібно перевести бізнес-логіку на мову станів: переведення, заморожування, підтвердження, вивільнення, відкат — кожен етап відповідає стану в контракті. Раніше для обробки винятків, за які відповідав оператор, тепер це перетворилося на скасовані гілки контракту. Масове переказування коштів подається паралельно за номером партії та контрольної суми, а ненормальні ситуації обробляються через попередньо задані обхідні канали.
Градієнтний розподіл трафіку поділяється на три етапи: 5%→20%→50%, для кожного етапу підготовлені скрипти для відкату. У разі заторів на мосту, система автоматично переходить в однонаправлений режим тільки для читання, а після підтвердження транзакцій, повторно записує повторні транзакції.
Під час аналізу витрат ми використовуємо "кожні тисячу операцій" як єдину одиницю вимірювання, щоб порівняти середнє значення підтвердження, затримку в хвості, процент невдач, витрати на повторні спроби та трудозатрати між L1 і Linea. Висновок досить чіткий: витрати на газ знижуються до незначного рівня, невдачі майже не призводять до додаткових витрат; фінансова звірка безпосередньо змінюється з T+1 на T+0; обсяг запитів служби підтримки різко знижується.
Останнє — це організаційні зміни: розподіл прав, відстрочка вступу в дію, подвійний підпис, тренування з реагування на інциденти — все це включено в щотижневі засідання. Зовнішня риторика також змінилася, тепер не кажуть "платіжний канал", а "блокчейн бухгалтерська система".
Цього разу основний здобуток міграції полягає не в "знайденні дешевої ланцюга", а в побудові системи, яку можна підтримувати. Відтепер менеджери продуктів можуть бути впевнені, що можуть вбудовувати більш детальну бізнес-логіку в сценарії контрактів.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
6 лайків
Нагородити
6
2
Репост
Поділіться
Прокоментувати
0/400
SilentObserver
· 7год тому
Ей, ця пастка atlas має щось цікаве.
Сумісність zkEVM дійсно спрощує справи, не потрібно все скасовувати і починати з нуля - це найкраще.
T+1 одразу зменшується до T+0, ці дані справді заспокоять багатьох.
Але зниження до 5% від Grayscale на початку все ж виглядає трохи обережно?
Головне - це те, що "у блокчейні облікова система", якщо змінити формулювання, чи може ефект бути таким великим?
Справжніми переможцями є ті, хто більше не повинен вручну звіряти рахунки, працівники, га-га.
Переглянути оригіналвідповісти на0
PumpingCroissant
· 7год тому
Гарно, що сумісність zkEVM дійсно приносить користь у виробництві OP
---
Отже, зрештою, ви просто різко зменшили витрати на експлуатацію, так? Це і є основна суть
---
Мене цікавить T+0 для звірки, як саме це працює
---
Чи буде проблема, коли Грейд 50?
---
Що може захистити ця система з подвійним підписом?
---
Фраза "бухгалтерська система у блокчейні" звучить досить вражаюче
---
Цей обхідний канал заздалегідь налаштований чи написаний тимчасово?
---
Обсяг заявок різко впав, це дійсно без проблем чи ніхто не запитує?
---
Основне не те, що це дешева ланка, а те, що це повторно використовувана інфраструктура, вірно?
---
Тепер будь-хто може спробувати перенести платіж на L2
---
Які конкретно проблеми вирішує zkEVM?
Ми всередині називаємо цей проект міграції "Atlas" — мета дуже проста: перенести традиційну платіжну систему з п’ятиетапного процесу "приймання→розподіл→повернення→Розрахунок→звірка" в Linea, при цьому потрібно зменшити витрати на персонал і експлуатацію.
Спочатку поговоримо про перевірку семантики. Ми просто взяли список перевірок та тестові випадки, які раніше використовувалися на L1, і по черзі порівняли їх з потоком подій та граничними випадками. На щастя, сумісність zkEVM дуже допомогла, заощадивши витрати на повторне навчання. Ми підключили CI/CD до тестової мережі та створили панель моніторингу "подання—доказ—упаковка—повернення", щоб ризиковий менеджмент і фінансовий відділ могли в реальному часі бачити дані.
Далі потрібно перевести бізнес-логіку на мову станів: переведення, заморожування, підтвердження, вивільнення, відкат — кожен етап відповідає стану в контракті. Раніше для обробки винятків, за які відповідав оператор, тепер це перетворилося на скасовані гілки контракту. Масове переказування коштів подається паралельно за номером партії та контрольної суми, а ненормальні ситуації обробляються через попередньо задані обхідні канали.
Градієнтний розподіл трафіку поділяється на три етапи: 5%→20%→50%, для кожного етапу підготовлені скрипти для відкату. У разі заторів на мосту, система автоматично переходить в однонаправлений режим тільки для читання, а після підтвердження транзакцій, повторно записує повторні транзакції.
Під час аналізу витрат ми використовуємо "кожні тисячу операцій" як єдину одиницю вимірювання, щоб порівняти середнє значення підтвердження, затримку в хвості, процент невдач, витрати на повторні спроби та трудозатрати між L1 і Linea. Висновок досить чіткий: витрати на газ знижуються до незначного рівня, невдачі майже не призводять до додаткових витрат; фінансова звірка безпосередньо змінюється з T+1 на T+0; обсяг запитів служби підтримки різко знижується.
Останнє — це організаційні зміни: розподіл прав, відстрочка вступу в дію, подвійний підпис, тренування з реагування на інциденти — все це включено в щотижневі засідання. Зовнішня риторика також змінилася, тепер не кажуть "платіжний канал", а "блокчейн бухгалтерська система".
Цього разу основний здобуток міграції полягає не в "знайденні дешевої ланцюга", а в побудові системи, яку можна підтримувати. Відтепер менеджери продуктів можуть бути впевнені, що можуть вбудовувати більш детальну бізнес-логіку в сценарії контрактів.