#dusk недавно проводил разбор архитектуры шлюза для движения средств и обнаружил крайне незаметное слепое пятно в синхронизации реестра. Многие ошибочно полагают, что узлу достаточно увидеть подтверждение в блокчейне, чтобы сразу зачислить средства на счёт в базе данных, но при этом упускают ключевую задачу — сопоставление владельца и устранение дубликатов. При обработке поле комментария используется для идентификации пользователя, а хеш транзакции служит защитой от повторного выполнения. Если сопоставлять только метки, из-за совпадений или ошибок в написании средства могут попасть не на тот счёт; если же проверять лишь уникальность хеша, программа окажется в безвыходной ситуации, не зная, кому зачислить деньги.@Dusk

На этой неделе во время тестирования узла $DUSK я намеренно прервал работу сервиса, чтобы проверить восстановление после критического сбоя. Если код сначала продвинет контрольную точку блока, а затем аварийно завершится, не успев зачислить средства, то после перезапуска пропустит эту операцию, что приведёт к расхождению в учёте. Если поменять порядок и сначала зачислить средства, а потом сохранить прогресс обработки, то после перезапуска неизбежно произойдёт повторное зачисление. Как видите, атомарная связь между сканированием и зачислением — вопрос жизни и смерти.$BTC

Если копнуть глубже, за внешне одинаковым поступлением средств могут стоять совершенно разные логические сущности. Потоки Moonlight с открытой историей и конвертации Phoenix, пересекающие границы приватности, с точки зрения шлюза выглядят как увеличение баланса, но правила прослушивания событий на нижнем уровне у них совершенно разные. Грубая обработка всего одним пакетом неизбежно приведёт к катастрофе при сверке. Чтобы понять, насколько надёжна сеть, не стоит смотреть только на скорость создания блоков — важно, может ли она предоставить доказательства восстановления на основе доказательств с нулевым разглашением.$ETH

Думаю, у такого скрупулёзного механизма сверки действительно есть две стороны. Он увеличивает сроки технической интеграции и повышает стоимость экспериментов, доставляя немало хлопот разработчикам, привыкшим просто обращаться к API. Но для институционального хранения активов бесперебойная работа системы в спокойное время может быть обманчивой. Если после отключения питания в серверной удаётся без малейших расхождений проверить каждую операцию в обратном порядке по цепочке доказательств дерева Меркла, вот это и есть настоящее конкурентное преимущество.

С какими инцидентами, вызванными проблемами на нижнем уровне, вы больше всего боитесь столкнуться при повседневной работе узлов или запуске скриптов взаимодействия?