Репост из: Monster News
Друзья, не секрет, что сейчас я занимаюсь восстановлением работоспособности Minter Hub.
За это время пришлось очень глубоко закопаться в исходники: уже сделано около сотни фиксов и различных правок. Но знаете, в чем оказалась одна из главных проблем старой архитектуры и почему со временем она просто перестала нормально работать?
В коде были жестко зашиты параметры среднего времени блока для каждой сети:
🔸 BNB Chain - 5 секунд
🔸 Ethereum - 15 секунд
На основе этих значений Minter Hub рассчитывал номер блока, до которого сформированная транзакция должна оставаться валидной для смартконтракта. Если до этого блока она не исполнялась, ее срок действия заканчивался.
И все работало - пока сами блокчейны не изменились.
Ethereum сократил среднее время блока примерно до 12 секунд, а BNB Chain сегодня способен выпускать блоки менее чем за секунду.
И тут начиналась настоящая фантастика.
Представьте: мост рассчитывает, что транзакция будет действительна, условно, до блока 100 000. Но сеть производит блоки значительно быстрее, чем заложено в старой логике. В результате мост пытается отправить эту транзакцию, когда сеть находится уже, например, на блоке 100 050.
Смарт-контракт закономерно отвечает: транзакция уже просрочена.
Сейчас как раз пилю исправление этой логики. Причем задача не сводится к тому, чтобы просто заменить 15 секунд на 12, а 5 секунд на новое значение. Через какое-то время параметры сети снова могут измениться - и мы получим ту же проблему.
Нужно уйти от жестко заданного времени и при этом сделать это так, чтобы не затронуть консенсус и совместимость существующей системы.
Это хороший пример того, о чем часто забывают при создании мостов.
Можно написать работающий мост и даже идеально протестировать его на момент запуска. Но мост соединяет несколько независимых блокчейнов, каждый из которых продолжает развиваться и может менять свои параметры.
Поэтому код моста тоже не может быть написан один раз и навсегда.
Он требует постоянной поддержки, обслуживания и адаптации к изменениям сетей, которые соединяет.
За это время пришлось очень глубоко закопаться в исходники: уже сделано около сотни фиксов и различных правок. Но знаете, в чем оказалась одна из главных проблем старой архитектуры и почему со временем она просто перестала нормально работать?
В коде были жестко зашиты параметры среднего времени блока для каждой сети:
🔸 BNB Chain - 5 секунд
🔸 Ethereum - 15 секунд
На основе этих значений Minter Hub рассчитывал номер блока, до которого сформированная транзакция должна оставаться валидной для смартконтракта. Если до этого блока она не исполнялась, ее срок действия заканчивался.
И все работало - пока сами блокчейны не изменились.
Ethereum сократил среднее время блока примерно до 12 секунд, а BNB Chain сегодня способен выпускать блоки менее чем за секунду.
И тут начиналась настоящая фантастика.
Представьте: мост рассчитывает, что транзакция будет действительна, условно, до блока 100 000. Но сеть производит блоки значительно быстрее, чем заложено в старой логике. В результате мост пытается отправить эту транзакцию, когда сеть находится уже, например, на блоке 100 050.
Смарт-контракт закономерно отвечает: транзакция уже просрочена.
Сейчас как раз пилю исправление этой логики. Причем задача не сводится к тому, чтобы просто заменить 15 секунд на 12, а 5 секунд на новое значение. Через какое-то время параметры сети снова могут измениться - и мы получим ту же проблему.
Нужно уйти от жестко заданного времени и при этом сделать это так, чтобы не затронуть консенсус и совместимость существующей системы.
Это хороший пример того, о чем часто забывают при создании мостов.
Можно написать работающий мост и даже идеально протестировать его на момент запуска. Но мост соединяет несколько независимых блокчейнов, каждый из которых продолжает развиваться и может менять свои параметры.
Поэтому код моста тоже не может быть написан один раз и навсегда.
Он требует постоянной поддержки, обслуживания и адаптации к изменениям сетей, которые соединяет.