GavinWood пропонує мінімізувати ланцюг реле

Relay Chain — це основна частина мережі Polkadot, яка містить основну логіку мережі. Необхідно, щоб ретрансляційний ланцюг прийняв ці основні логіки, перш ніж парачейн почне працювати і XCM може бути розроблений. Але з розвитком часу тепер цю основну логіку можна вважати перенесеною в системний парачейн! У результаті доктор Гевін Вуд і Джо Петровскі з Web3 Foundation ініціювали RFC-32, запропонувавши перенести логіку кількох підсистем із ретрансляційного ланцюга на «системний парачейн», які разом утворюють усю мережу Polkadot.

Отже, навіщо розкладати частину логіки релейного ланцюга на системні парачейни? Які функції розбиваються в першу чергу? Ознайомтеся з важливою інформацією, зібраною PolkaWorld нижче!

Чому ви хочете це зробити? **

Мережа Polkadot призначена для масштабування та надання можливості кільком незалежним державним машинам (тобто парачейнам) працювати за загальною гарантією безпеки та валідності. Щоб досягти цієї гарантії, Relay Chain має набір валідаторів, які в першу чергу відповідають за безпеку Relay Chain. Однак не всі валідатори мають справу безпосередньо з переходами станів для парачейнів. Кожен перехід стану парачейну обробляється підмножиною валідаторів, яка називається опорною групою. Це означає, що не всі валідатори мають справу безпосередньо з кожним переходом станів парачейна, лише підмножина з них відповідає за обробку переходів станів.

Але коли в ланцюжку ретрансляції відбуваються переходи станів, до виконання повинні бути залучені всі валідатори, щоб забезпечити узгодженість і безпеку мережі. Однак побічним ефектом цієї конструкції є вузьке місце продуктивності, оскільки кожна зміна стану вимагає перевірки в масштабах всієї мережі, що збільшує затримку та обмежує пропускну здатність.

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

Загалом, є кілька основних причин для міграції частини логіки ретрансляційного ланцюга до системного парачейну:

  1. Продуктивність і масштабованість: Переносячи певну логіку та обов'язки на системний парачейн, Relay Chain може зосередитися на своїх основних обов'язках, покращуючи продуктивність і масштабованість усієї мережі.
  2. Оптимізація ресурсів: коли частина логіки переноситься в системний парачейн, ретрансляційний ланцюг може звільнити більше ресурсів для інших завдань, таких як обробка міжланцюгових повідомлень або забезпечення безпеки для більшої кількості парачейнів.
  3. Модульність і гнучкість: модульна конструкція полегшує модифікацію, оновлення або додавання нових функцій, не втручаючись в основну роботу релейного ланцюга. Це забезпечує більшу гнучкість для майбутніх інновацій та розширення функцій.
  4. Безпека: Відокремлення частин логіки від ланцюга реле знижує ризик однієї точки відмови. В окремому системному парачейні, якщо парачейн зазнає атаки або зазнає невдачі, це навряд чи вплине на ланцюг ретрансляції або інші парачейни.
  5. Більше можливостей парачейну: Вивільняючи ресурси ретрансляційного ланцюга, мережа Polkadot може підтримувати більше парачейн-приєднання, ще більше розширюючи свою екосистему.
  6. Оптимізація конкретних функцій: У міру розвитку Polkadot деякі функції або логіка можуть вимагати спеціалізованої оптимізації або спеціалізованих методів обробки. Перенесення цих функцій у спеціалізовані системні парачейни забезпечує їх оптимальну обробку та оптимізацію.

**Які функції буде розбито на системні парачейни? **

Можливими варіантами міграції з магістрального ланцюга є такі модулі та підсистеми:

1.Ідентичність

  1. Залишки

  2. Стейкінг (стейкінг)

Страйк

Провайдер виборів

Список сумок

шекелів

Номінаційні пули

Швидке зняття зі стейкінгу

  1. Управління

Казначейство та щедроти

Голосування за обвинувальний вирок

Референдум

Примітка: Поточні модулі аукціону та краудлендінгу більше не використовуватимуться, а будуть замінені новою системою під назвою Coretime. Подробиці про системний ланцюжок Coretime та його інтерфейси описані в RFC-1 та RFC-5 відповідно. Polkadot Fellowship також розробляє парачейни Coretime. Щоб дізнатися більше про прогрес у Polkadot, перегляньте статтю Прогрес Polkadot за 3 квартал: запущено 5 нових парачейнів, USDC входить в екосистему, значно зростають стейки, сегреговані облікові записи та он-чейн події.

Як здійснити міграцію? **

Деякі підсистеми можуть бути відносно просто перенесені з ретрансляційного ланцюга в інші місця. На прикладі автентифікації можна просто заблокувати зміни стану в ланцюжку ретрансляції та встановити початковий стан для нового ланцюга, використовуючи стан, пов'язаний з автентифікацією. Цей початковий стан і пов'язана з ним логіка, або модулі, потім використовуються для запуску нового ланцюжка.

Однак є підсистеми, які не можуть мати простоїв під час процесу міграції, оскільки вони мають вирішальне значення для належного функціонування всієї мережі, наприклад, стейкінг та управління. Незважаючи на це, ці критичні підсистеми можуть співіснувати з іншими ланцюжками систем з аналогічними дозволами протягом деякого часу. Так само, як «Gov1» і «OpenGov» співіснували, коли був введений останній.

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • Прокоментувати
  • Поділіться
Прокоментувати
0/400
Немає коментарів
  • Закріпити