Як зрозуміти нову статтю Віталіка про масштабування Ethereum?

Як зрозуміти нову статтю Віталіка Бутеріна про думки про масштабування Ethereum? Дехто каже, що Віталік вигукує замовлення на написи Blob, що обурює. Отже, як працюють пакети BLOB? Чому не можна ефективно використовувати простір BLOB-об’єктів після оновлення Cancun?Чи є вибірка доступності даних DAS для підготовки до шардингу?

На мій погляд, Cancun готовий до використання після апгрейду, а Віталік переживає за розвиток Rollup. Далі дозвольте мені розповісти про моє розуміння:

1. Як багато разів пояснювалося раніше, Blob — це тимчасовий пакет даних, який може бути безпосередньо отриманий на рівні консенсусу шляхом відв’єднання від даних виклику EVM, і пряма перевага полягає в тому, що EVM не може отримати доступ до даних Blob під час виконання транзакцій, тому він не може генерувати високі обчислювальні витрати на рівні виконання.

В даний час, балансуючи між рядом факторів, розмір 1 BLOB-об’єкта становить 128 Кб, транзакція пакета в основну мережу містить максимум два блоби, в ідеалі, кінцевою метою блоку основної мережі є передача 16 МБ приблизно 128 пакетів BLOB.

Таким чином, команда проекту Rollup повинна максимально збалансувати кількість блоків BLOB, ємність транзакцій TPS і вартість зберігання вузлів основної мережі Blob, а також прагнути використовувати простір BLOB-об’єктів з найкращими витратами.

Візьмемо для прикладу Optimism, в даний час відбувається близько 500 000 транзакцій на день, в середньому одна транзакція в основну мережу кожні дві хвилини, несучи по одному пакету BLOB за раз. Навіщо брати один, адже TPS стільки, що ним не можна користуватися, звичайно, можна перевозити і два, тоді ємність кожної краплі не буде повною, але це додає додаткових витрат на зберігання, що не обов’язково.

Що робити, коли обсяг транзакцій Rollup off-chain збільшується, наприклад, обробляється 50 млн транзакцій на день?1. Стисніть і стиснути обсяг транзакцій кожного пакета, щоб зробити велику кількість транзакцій у просторі BLOB, наскільки це можливо, 2. Збільште кількість ляпок і 3. Скоротіть частоту пакетних транзакцій.

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

Таким чином, протягом певного періоду часу після оновлення Cancun Rollups не «об’ємні» з точки зору кількості та частоти використаних ляблів, а також використання пробілів-блобів.

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

Тому що теоретично, якщо є сторона проекту рівня 2, яка здійснює високочастотні транзакції з високою пропускною здатністю в основну мережу Batch і заповнює блок Blob кожен раз, якщо вона готова нести високі витрати на підробку пакета транзакцій, це вплине на нормальне використання Blob іншими layer2, але в поточній ситуації це теоретично можливо так само, як хтось, хто купує обчислювальні потужності, щоб здійснити атаку хардфорка на BTC на 51%, але на практиці це не має мотиву отримання прибутку.

Метою впровадження Blob є зменшення навантаження на EVM та покращення можливостей експлуатації та обслуговування вузлів, що, безсумнівно, є індивідуальним рішенням для Rollup. Очевидно, що на даний момент він використовується неефективно, і плата за газ за використання рівня 2 ще довго буде стабільною в «низькому» діапазоні. Це дасть ринку layer2 довгострокове золоте вікно розвитку для «збільшення військ і накопичення зерна».

3. Отже, що, якщо одного разу ринок layer2 певною мірою процвітатиме, і кількість транзакцій від Batch до Mainnet стане величезною щодня, а пакетів BLOB-об’єктів наразі недостатньо? Ethereum вже дав рішення: за допомогою вибірки доступності даних (DAS):

Наприклад, кожен вузол зберігає 1/8 усіх даних BLOB, а 8 вузлів утворюють команду для задоволення можливостей DA, що еквівалентно збільшенню поточної ємності сховища BLOB-об’єктів у 8 разів. Власне, це і буде зроблено на наступному етапі шардингу.

Але в даний час Віталік повторював це багато разів, що сповнено чарівності, і, здається, попереджає більшість учасників проекту layer2: не завжди скаржтеся на високу ємність Ethereum DA, з вашою поточною потужністю TPS, ви не розвинули здатність пакетів даних Blob до крайності, поспішайте і збільшуйте вогневу міць, щоб займатися екологією, розширювати користувачів і обсяг транзакцій, і не завжди думайте про втечу DA і займайтеся ланцюговою роботою в один клік.

Пізніше Віталік додав, що лише Arbitrum досяг Stage 1 серед основних роллапів, і хоча DeGate, Fuel тощо досягли Stage 2, вони ще не знайомі широкій спільноті. Етап 2 є кінцевою метою безпеки зведення, дуже мало ролапів досягли стадії 1, і більшість ролапів знаходяться на стадії 0, що свідчить про те, що розвиток індустрії ролапів дійсно турбує Віталіка.

4. Насправді, з точки зору масштабування вузьких місць, у рішення Rollup layer2 все ще є багато можливостей для підвищення продуктивності.

1. Простір Blob використовується ефективніше за рахунок стиснення даних, OP-Rollup наразі має спеціальний компонент Compressor для цього, а сам ZK-Rollup стискає SNARK/STARK поза мережею, щоб довести, що надсилання до основної мережі є «стисненням»;

2. Зменшіть залежність layer2 від основної мережі, наскільки це можливо, і використовуйте технологію optimistic proof лише для забезпечення безпеки L2 за особливих обставин, наприклад, більшість даних Плазми знаходиться в ланцюжку, але у сценаріях депозиту та зняття коштів це відбувається в основній мережі, тому основна мережа може обіцяти свою безпеку.

Це означає, що рівень2 повинен вважати лише важливі операції, такі як депозити та зняття коштів, тісно пов’язаними з основною мережею, що не тільки зменшує навантаження на основну мережу, але й підвищує продуктивність самого L2. Можливість «паралельної обробки» Sequencer, згадана в попередньому обговоренні паралельного EVM, який перевіряє, класифікує та попередньо обробляє велику кількість транзакцій поза мережею, а також гібридний ролап, реалізований Metis, який використовує OP-Rollup для звичайних транзакцій і ZK Route для спеціальних запитів на виведення коштів, мають схожі міркування.

Вище.

Загалом, стаття Віталіка про майбутній план масштабування Ethereum дуже повчальна. Зокрема, він незадоволений статусом розробки layer2, оптимістично налаштований щодо простору продуктивності Blob і перспектив майбутньої технології шардингу, і навіть вказує на деякі напрямки, які варто оптимізувати для layer2.

По суті, єдина невизначеність залишається за самим рівнем 2, як прискорити розробку?