Одна вещь заставила меня перестать скроллить. Дело было не в самой ошибке. Дело было в строке, где говорится, что окно гонки существует только между чтением из базы данных и записью в базу данных. Сначала это выглядело как крошечная деталь реализации, но потом я начал думать о том, что это говорит о модели исполнения Babylon.
Я перестал искать атакующего и начал смотреть на поток. Я вернулся и сравнил путь валидации и некоторое время отслеживал, где именно изменения состояния становятся окончательными. Затем я взял кофе и снова перечитал последовательность. Чем дольше я смотрел, тем меньше это казалось проблемой безопасности само по себе. Это больше походило на выбор дизайна — насколько протокол готов терпеть риск по таймингу.
Постепенно стало очевидно: защита построена не вокруг того, чтобы сделать гонку невозможной. Она построена вокруг того, чтобы сделать возможность крайне малой. Это две разные идеи. Первая убирает условие. Вторая снижает вероятность. Эту разницу легко упустить, потому что снаружи обе могут выглядеть безопасно.
Вот чего никто не добавляет в презентацию. Babylon полагается на то, что валидаторы и сервисы обрабатывают состояние в предсказуемом порядке, одновременно принимая, что существует небольшая щель выполнения. Фактически протокол говорит, что операционная стоимость устранения каждой возможной гонки больше, чем оставшийся риск оставить одну узкую временную возможность.
Возможно, это правильная сделка ради производительности. Возможно, оставшееся воздействие настолько мало, что добавление большей синхронизации создаст проблемы где-то еще.
То, что я до сих пор не могу решить, — где Babylon проводит границу между допустимым предположением о тайминге и гарантией протокола, которая вообще не должна зависеть от тайминга.
@BabylonLabs_io
#baby $BABY
Я перестал искать атакующего и начал смотреть на поток. Я вернулся и сравнил путь валидации и некоторое время отслеживал, где именно изменения состояния становятся окончательными. Затем я взял кофе и снова перечитал последовательность. Чем дольше я смотрел, тем меньше это казалось проблемой безопасности само по себе. Это больше походило на выбор дизайна — насколько протокол готов терпеть риск по таймингу.
Постепенно стало очевидно: защита построена не вокруг того, чтобы сделать гонку невозможной. Она построена вокруг того, чтобы сделать возможность крайне малой. Это две разные идеи. Первая убирает условие. Вторая снижает вероятность. Эту разницу легко упустить, потому что снаружи обе могут выглядеть безопасно.
Вот чего никто не добавляет в презентацию. Babylon полагается на то, что валидаторы и сервисы обрабатывают состояние в предсказуемом порядке, одновременно принимая, что существует небольшая щель выполнения. Фактически протокол говорит, что операционная стоимость устранения каждой возможной гонки больше, чем оставшийся риск оставить одну узкую временную возможность.
Возможно, это правильная сделка ради производительности. Возможно, оставшееся воздействие настолько мало, что добавление большей синхронизации создаст проблемы где-то еще.
То, что я до сих пор не могу решить, — где Babylon проводит границу между допустимым предположением о тайминге и гарантией протокола, которая вообще не должна зависеть от тайминга.
@BabylonLabs_io
#baby $BABY