Relay Chain — это основная часть сети Polkadot, которая содержит основную логику сети. Необходимо, чтобы релейная цепочка предприняла эту базовую логику, прежде чем парачейн сможет начать работать и XCM может быть разработан. Но с развитием времени, теперь эту основную логику можно считать мигрировавшей в системный парачейн! В результате доктор Гэвин Вуд и Джо Петровски из Web3 Foundation инициировали RFC-32, предложив перенести логику нескольких подсистем из цепочки ретрансляторов в «системный парачейн», которые вместе образуют всю сеть Polkadot.
Итак, зачем же декомпозировать часть логики релейной цепочки на системные парачейны? Какие функции разбиваются в первую очередь? Ознакомьтесь с важной информацией, собранной PolkaWorld, ниже!
Почему вы хотите это сделать? **
Сеть Polkadot предназначена для масштабирования и позволяет нескольким независимым конечным автоматам (т.е. парачейнам) работать под общей гарантией безопасности и действительности. Для достижения этой гарантии в Relay Chain есть набор валидаторов, которые в первую очередь отвечают за безопасность Relay Chain. Однако не все валидаторы занимаются непосредственно переходами состояний для парачейнов. Каждый переход состояния парачейна обрабатывается подмножеством валидаторов, называемых резервной группой. Это означает, что не все валидаторы имеют дело непосредственно с каждым переходом состояния парачейна, только часть из них отвечает за обработку переходов между состояниями.
Но когда в цепочке ретрансляции происходят переходы между состояниями, все валидаторы должны быть вовлечены в выполнение, чтобы обеспечить согласованность и безопасность сети. Однако побочным эффектом такой схемы является узкое место производительности, так как каждое изменение состояния требует проверки в масштабах всей сети, что увеличивает задержку и ограничивает пропускную способность.
Но если переход состояния релейной цепи можно будет сделать на парачейне, то это высвободит некоторые ресурсы. Это означает, что часть ресурсов валидатора, которая в противном случае использовалась бы для переходов между состояниями релейной цепочки, может быть перепрофилирована, что обеспечит сети больше времени ядра, т.е. больше места в блоке.
В целом, существует несколько основных причин для переноса части логики релейной цепочки в системный парачейн:
**Какие функции будут разбиты на системные парачейны? **
Возможны следующие модули и подсистемы для миграции из транкинговой цепочки:
1.Идентификация
Балансы
Стейкинг (стейкинг)
Забастовка
Организатор выборов
Список сумок
НИС
Номинационные пулы
Быстрый вывод из стейкинга
Сокровищница и контракты
Голосование по обвинительному приговору
Референдум
Примечание: Текущие модули аукциона и краудлендинга больше не будут использоваться, а будут заменены новой системой под названием Coretime. Подробная информация о системной цепочке Coretime и ее интерфейсах описана в RFC-1 и RFC-5 соответственно. Polkadot Fellowship также разрабатывает парачейны Coretime. Чтобы узнать больше о прогрессе Polkadot, см. Прогресс Polkadot Q3: запущено 5 новых парачейнов, USDC входит в экосистему, стейкинг, сегрегированные аккаунты и ончейн-события значительно растут.
Как выполнить миграцию? **
Некоторые подсистемы могут быть перенесены из цепочки ретрансляторов в другие места относительно просто. Используя аутентификацию в качестве примера, вы можете просто заблокировать изменения состояния в цепочке реле и установить начальное состояние для новой цепочки, используя состояние, связанное с проверкой подлинности. Это начальное состояние и связанная с ним логика, или модули, затем используются для запуска новой цепочки.
Однако есть подсистемы, которые не могут быть простоями в процессе миграции, потому что они критически важны для правильного функционирования всей сети, такие как стейкинг и управление. Тем не менее, эти критически важные подсистемы могут сосуществовать с другими цепочками систем с аналогичными разрешениями в течение некоторого времени. Точно так же, как “Gov1” и “OpenGov” сосуществовали, когда последний был представлен.