Джерело: Celestia; Переклад: Денг Тонг, Золота Фінанси

Lemongrass оновлюється в вересні та розгортається ​​у тестовій версії основної мережі, що є першим оновленням Celestia, заснованим на консенсусі. Наступне оновлення Ginger, а саме Celestia-App V3, є другим.

Ginger подвоює ефективність, а доступність даних Celestia миттєво збільшується вдвічі! У версії v3 це досягається шляхом зменшення часу блокування з 12 секунд до 6 секунд, що поліпшує користувацький досвід швидшим часом остаточного підтвердження транзакційного одночасного інтервалу.

Ginger також поклав основу для управління спільнотою, збільшивши розмір блоку до максимальних 8 МБ кожні 6 секунд, що відповідає 1,33 МБ/с.

Ginger активується на висоті 2348907 Arabica (прогнозовано на 5 листопада 2024 року). Планується, що вона увійде на тестову мережу Mocha в листопаді і на Основну мережу Beta в грудні.

Celestia незабаром зазнає змін

Оновлення пряника містить CIP, визначений у CIP-25 (типовий CIP).

У CIP в Ginger включає:

• CIP-21: Введення типу blob для перевірених підписувачів
• CIP-24: Змінні версії програми розподілу газу
• CIP-26: версіювання часу очікування
• CIP-27: обмеження блоків для кількості PFB та не-PFB
• CIP-28: обмеження розміру угод

Крім вищезазначеного CIP, celestia-app v3 також містить важливу неконсенсус зміну: за замовчуванням потрібен BBR.

За замовчуванням є чорний ящик.

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

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

Це відкрило великі можливості для покращення пропускної здатності та продуктивності у майбутньому, наприклад, покращення, показані на тестовій мережі Mammoth Mini. celestia-app v3 вимагає включення BBR за замовчуванням.

Введення типу блобу з перевіреними підписниками

CIP-21 вводить «творчий блоб», в якому Адреса підписника безпосередньо включається в Метадані блоба. Валідатор Celestia тепер перевіряє, чи співпадає цей підписник з Адреса, що оплачується блобом, що дозволяє уникнути агрегації для окремої перевірки та обробки транзакцій PayForBlobs. Це спрощує процес перевірки агрегації, дозволяючи безпосередньо перевірити поле підписника блоба для забезпечення його автентичності.

Змінні програми розкладання газу

CIP-24 робить змінні програми газового планування GasPerBlobByte та TxSizeCostPerByte недоступними для змін через управління у блокчейні, забезпечуючи стабільність та передбачуваність Вартість транзакції через мережеве оновлення. Ця зміна спрощує обчислення газу в автономному режимі без необхідності запитувати мережу перед кожною угодою.

Налаштування часу перевищення версії

CIP-26 встановлює час блоку та відповідні параметри таймауту залежно від версії додатка, та скорочує час блоку з 12 секунд у v3 до 6 секунд. Ці зміни спрямовані на підвищення пропускної здатності мережі та скорочення часу остаточного підтвердження транзакцій. Також параметр ttl-num-blocks пулу пам'яті збільшується з 5 до 12, щоб забезпечити послідовну поведінку транзакцій за допомогою швидшого часу блоку.

Обмеження кількості блоків для PFB та не-PFB

CIP-27 обмежує кількість повідомлень PayForBlob (PFB) та не PFB для кожного блоку. Ця пропозиція реалізує обмеження в 600 повідомлень PFB та 200 повідомлень не PFB для кожного блоку. Ці обмеження є м'якими обмеженнями на етапі PrepareProposal, що означає, що вони не суворо виконуються на рівні Консенсус. Основна ідея цієї зміни полягає в тому, щоб запобігти занадто довгому часу обробки блоків шляхом обмеження кількості перевірених транзакцій у кожному блоку. Ці обмеження визначені на основі Бенчмарк з метою досягнення часу обробки кожного блоку приблизно 0.25 секунди за рекомендованої конфігурації перевірки.

Обмеження обсягу угод

CIP-28 на Celestia обмежує розмір окремої транзакції до 2MiB (2,097,152 байтів). Це обмеження накладатиметься на всі етапи обробки транзакцій (CheckTx, PrepareProposal та ProcessProposal), тому це зміна, яка порушує Консенсус. Її основний принцип полягає в тому, щоб уникнути проблем з обробкою великих транзакцій, навіть якщо це 8 MiB або більше Блоків. Це також відкриває шлях для зменшення години блоку та збільшення розміру блоку для збільшення потенційної пропускної здатності в майбутньому.