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

Чаще всего этот термин используется для описания многопользовательских сервисов, когда несколько приложений работают на одной инфраструктуре.

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

Поэтому вы придумали решение: вы разобьете каждый сервер на несколько "виртуальных" серверов. Каждый виртуальный сервер будет иметь свой собственный набор ресурсов, и каждый разработчик сможет арендовать виртуальный сервер для запуска своего приложения. Таким образом, вы сможете эффективно использовать физические серверы и предлагать свои услуги более широкому кругу клиентов с различными потребностями в ресурсах.

Все работает, если делиться справедливо...

Но есть одна загвоздка: что, если приложение одного разработчика начнет отнимать ресурсы и использовать их больше, чем "положено"? Внезапно у других виртуальных серверов на той же коробке станет меньше ресурсов, которые они смогут разделить между собой, и их производительность снизится.

...но если кто-то перераспределяет ресурсы, все остальные оказываются в проигрыше.

Очень важно, что это падение производительности происходит исключительно из-за других пользователей, которые были "случайно" размещены на том же физическом сервере, что и вы, вашим облачным провайдером. Вы не имеете права голоса в этом вопросе.

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

Но есть одна категория случаев, когда проблема шумных соседей жива и здорова: приложения для блокчейна.

Существует несколько способов представить себе блокчейн. С одной стороны, блокчейн - это распределенная сеть из множества серверов, которые работают вместе для ведения общей книги транзакций.

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

Именно так: блокчейн - это идеальная " multi-tenant" инфраструктура.

На одном блокчейне могут работать сотни тысяч приложений (смарт-контрактов), конкурирующих за ограниченные ресурсы. А поскольку эти ресурсы распределяются на рынке, усиление конкуренции напрямую ведет к росту затрат.

Обычно считается, что "быстрота" и "дешевизна" транзакций - это неотъемлемое свойство блокчейна. Но это неверно: эти свойства также определяются использованием цепи - и могут быстро меняться при изменении использования.

Это означает, что если, скажем, мемкоин взлетит в самый неподходящий момент, вы (и ваши пользователи!) можете внезапно обнаружить, что платите за бензин значительно больше.

Этот пример характерен не только для Ethereum! Все популярные цепочки рано или поздно сталкиваются с этой проблемой - это свидетельствует о том, насколько успешно цепочка создает спрос на пространство для блоков. Это проблема монолитных блокчейнов в целом. Шумные соседи всегда могут испортить вам день, что приведет к ухудшению UX и высоким затратам.

Единственным долгосрочным решением проблемы шумных соседей является отказ от "многопользовательской" архитектуры. Введите выделенные роллапы: новую технологию, которая обещает раз и навсегда решить проблему шумных соседей для приложений блокчейна.

С помощью выделенных роллапов проекты получают решение для масштабирования второго уровня, которое функционирует как отдельный блокчейн. Цепочка второго уровня размещает данные транзакций на базовом первом уровне, но при этом разгружает вычисления и хранение данных вне цепочки. Это означает значительное снижение конкуренции за ресурсы между приложениями. Это все равно что перейти с виртуального хостинга на выделенный сервер.

Еще лучше: выделенные роллапы можно настроить под конкретные нужды каждого приложения. Хотите минимизировать транзакционные издержки? Вы можете выбрать менее дорогую цепочку. Нужны тонны вычислительной мощности? Запустите роллап на более мощном сервере и увеличьте лимит газа. А может быть, вам нужно опуститься ниже EVM и добавить новые примитивы нижнего уровня, например операции с кривыми BLS, хэш-функции, удобные для ZK, или более эффективные утилиты для управления памятью.

Caldera - это самый простой способ для проектов запускать настраиваемые выделенные роллапы. Стремясь расширить возможности разработчиков, Caldera предоставляет необходимую инфраструктуру для создания специализированного блокчейна для любой экосистемы или приложения.

Такие разработчики, как zkHoldem, Syndr и Curio, уже используют Caldera для запуска быстрых, безопасных блокчейнов и приложений без ущерба для производительности и функциональности.

Если вы являетесь разработчиком, свяжитесь с нами! Мы с удовольствием обсудим, почему выделенный блокчейн может иметь смысл для вашего приложения.

Оригинал статьи на английском: English

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

Чаще всего этот термин используется для описания многопользовательских сервисов, когда несколько приложений работают на одной инфраструктуре.

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

Поэтому вы придумали решение: вы разобьете каждый сервер на несколько "виртуальных" серверов. Каждый виртуальный сервер будет иметь свой собственный набор ресурсов, и каждый разработчик сможет арендовать виртуальный сервер для запуска своего приложения. Таким образом, вы сможете эффективно использовать физические серверы и предлагать свои услуги более широкому кругу клиентов с различными потребностями в ресурсах.

Все работает, если делиться справедливо...

Но есть одна загвоздка: что, если приложение одного разработчика начнет отнимать ресурсы и использовать их больше, чем "положено"? Внезапно у других виртуальных серверов на той же коробке станет меньше ресурсов, которые они смогут разделить между собой, и их производительность снизится.

...но если кто-то перераспределяет ресурсы, все остальные оказываются в проигрыше.

Очень важно, что это падение производительности происходит исключительно из-за других пользователей, которые были "случайно" размещены на том же физическом сервере, что и вы, вашим облачным провайдером. Вы не имеете права голоса в этом вопросе.

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

Но есть одна категория случаев, когда проблема шумных соседей жива и здорова: приложения для блокчейна.

Существует несколько способов представить себе блокчейн. С одной стороны, блокчейн - это распределенная сеть из множества серверов, которые работают вместе для ведения общей книги транзакций.

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

Именно так: блокчейн - это идеальная " multi-tenant" инфраструктура.

На одном блокчейне могут работать сотни тысяч приложений (смарт-контрактов), конкурирующих за ограниченные ресурсы. А поскольку эти ресурсы распределяются на рынке, усиление конкуренции напрямую ведет к росту затрат.

Обычно считается, что "быстрота" и "дешевизна" транзакций - это неотъемлемое свойство блокчейна. Но это неверно: эти свойства также определяются использованием цепи - и могут быстро меняться при изменении использования.

Это означает, что если, скажем, мемкоин взлетит в самый неподходящий момент, вы (и ваши пользователи!) можете внезапно обнаружить, что платите за бензин значительно больше.

Этот пример характерен не только для Ethereum! Все популярные цепочки рано или поздно сталкиваются с этой проблемой - это свидетельствует о том, насколько успешно цепочка создает спрос на пространство для блоков. Это проблема монолитных блокчейнов в целом. Шумные соседи всегда могут испортить вам день, что приведет к ухудшению UX и высоким затратам.

Единственным долгосрочным решением проблемы шумных соседей является отказ от "многопользовательской" архитектуры. Введите выделенные роллапы: новую технологию, которая обещает раз и навсегда решить проблему шумных соседей для приложений блокчейна.

С помощью выделенных роллапов проекты получают решение для масштабирования второго уровня, которое функционирует как отдельный блокчейн. Цепочка второго уровня размещает данные транзакций на базовом первом уровне, но при этом разгружает вычисления и хранение данных вне цепочки. Это означает значительное снижение конкуренции за ресурсы между приложениями. Это все равно что перейти с виртуального хостинга на выделенный сервер.

Еще лучше: выделенные роллапы можно настроить под конкретные нужды каждого приложения. Хотите минимизировать транзакционные издержки? Вы можете выбрать менее дорогую цепочку. Нужны тонны вычислительной мощности? Запустите роллап на более мощном сервере и увеличьте лимит газа. А может быть, вам нужно опуститься ниже EVM и добавить новые примитивы нижнего уровня, например операции с кривыми BLS, хэш-функции, удобные для ZK, или более эффективные утилиты для управления памятью.

Caldera - это самый простой способ для проектов запускать настраиваемые выделенные роллапы. Стремясь расширить возможности разработчиков, Caldera предоставляет необходимую инфраструктуру для создания специализированного блокчейна для любой экосистемы или приложения.

Такие разработчики, как zkHoldem, Syndr и Curio, уже используют Caldera для запуска быстрых, безопасных блокчейнов и приложений без ущерба для производительности и функциональности.

Если вы являетесь разработчиком, свяжитесь с нами! Мы с удовольствием обсудим, почему выделенный блокчейн может иметь смысл для вашего приложения.

Оригинал статьи на английском: English