З усіма, які стверджують, що вони отримують все менші та менші часи блоків на L2, я подумав, що настав час описати, що відбувається. Зокрема, давайте перевіримо, що таке блоки L2, в чому вони відрізняються від блоків L1 та чому нам дійсно не варто так багато турбуватися про часи блоків L2, навіть якщо вони є цікавим інженерним показником.
Згадуючи часи, коли термін "блокчейн" ще щось значив (близько 2009 року), концепція блоків була введена, оскільки нам потрібно було одиницю для групи транзакцій, поданих на згоду.
Наприклад, на Bitcoin кожен виробник блоку намагається знайти розташування транзакцій, яке задовольняє вимоги PoW, а потім транслює цей блок у мережу. Інші вузли перевірять, що цей блок дійсно відповідає вимогам PoW. На Ethereum, який зараз є PoS та заснований на рахунках, виробники блоків обчислюють хеш стану блокчейну після виконання кожного блоку (зобов'язання стану), а валідатори повторно обчислюють це значення для простої перевірки блоку. Загальний процес завжди однаковий:
На ланці лінії-1 блоки мають значення: ви перевіряєте цілісність ланцюжка на рівні блоків, ви керуєте відгалуженнями на рівні блоків тощо.
TL;DR: блоки є важливою складовою консенсусу.
L2s існують через повільність консенсусу та децентралізацію, яка потребує підтримки повільних комп'ютерів та мереж. Підхід L2 перенаправляє обробку транзакцій на найшвидший доступний комп'ютер, а потім публікує підтверджуваний звіт про виконання на L1 для консенсусу. Просто кажучи, більшість сучасних L2 - це централізовані системи, що грають в роль блокчейнів. І це абсолютно нормально.
Ось де часи блоку стають розмитими. L2s продовжують будувати блоки головним чином для сумісності програмного забезпечення L1, але це в основному штучно. При публікації резюме на L1 L2s зазвичай пакують кілька блоків разом, щоб знизити витрати. Хоча час від часу потрібні зобов'язання стану для доказів шахрайства/правомірності, вони не потрібні для кожного блоку. Тому блоки L2 фактично є некорисними.
Коли хтось стверджує, що у нього є швидкі блоки L2, вони просто налаштували значення конфігурації системи, щоб зменшити час блоку. Хоча їм все ще потрібно обробляти значну кількість транзакцій на блок, це й є все.
Як користувач, ви турбуєтеся лише про одне: час циклу. Іншими словами, як довго знадобиться моїй транзакції, щоб досягти L2 послідовника, виконатися і результат став видимим на вузлі RPC, яким я користуюся? Сконцентруємося на останній частині: як довго знадобиться, щоб повідомити виконання транзакції до RPC?
Повільні блокчейни зазвичай чекають на кінець блоку перед його надсиланням пірнам. Solana розпочала ідею того, що ви можете передавати блоки натомість: просто надсилайте транзакції іншим перевіряючим, як тільки ви їх обробите. Solana розбиває їх на записи (групи макс. 64 транзакцій), які самі розбиваються на шреди для передачі в мережі. У нас єглибока статтяз цієї теми, якщо ви цікавитесь. Вони транслюються неперервно з вузла-лідера до інших, що означає, що ви отримуєте інформацію про виконання ваших транзакцій, перш ніж блок навіть закінчиться.
L2s тепер вирішили використовувати цей механізм: Base, з Flashblocks, переходить від часу блоку 2 секунди до менших 200 мс підблоків. MegaETH має концепцію “міні-блоків”, які генеруються кожні 15 мс на їх тестовій мережі (більшість часу). Eclipse використовує систему входу/обрізання Solana. Таким чином, користувачам потрібно менше чекати на виконання своїх транзакцій. Це досить добре для UX!
Проте будьмо ясні: справжня функція тут - «зменшені інтервали комунікації по мережі». Це не має нічого спільного з тим, що деякі блоки є вроджено кращими за інші. Ми просто розділяємо блоки на менші частини і передаємо їх паралельно з виконанням. Чи ви називаєте ці частини блоками, міні-блоками чи клаптиками, не має значення. Кінцева мета - це швидша комунікація, а не кращі блоки.
Bagikan
З усіма, які стверджують, що вони отримують все менші та менші часи блоків на L2, я подумав, що настав час описати, що відбувається. Зокрема, давайте перевіримо, що таке блоки L2, в чому вони відрізняються від блоків L1 та чому нам дійсно не варто так багато турбуватися про часи блоків L2, навіть якщо вони є цікавим інженерним показником.
Згадуючи часи, коли термін "блокчейн" ще щось значив (близько 2009 року), концепція блоків була введена, оскільки нам потрібно було одиницю для групи транзакцій, поданих на згоду.
Наприклад, на Bitcoin кожен виробник блоку намагається знайти розташування транзакцій, яке задовольняє вимоги PoW, а потім транслює цей блок у мережу. Інші вузли перевірять, що цей блок дійсно відповідає вимогам PoW. На Ethereum, який зараз є PoS та заснований на рахунках, виробники блоків обчислюють хеш стану блокчейну після виконання кожного блоку (зобов'язання стану), а валідатори повторно обчислюють це значення для простої перевірки блоку. Загальний процес завжди однаковий:
На ланці лінії-1 блоки мають значення: ви перевіряєте цілісність ланцюжка на рівні блоків, ви керуєте відгалуженнями на рівні блоків тощо.
TL;DR: блоки є важливою складовою консенсусу.
L2s існують через повільність консенсусу та децентралізацію, яка потребує підтримки повільних комп'ютерів та мереж. Підхід L2 перенаправляє обробку транзакцій на найшвидший доступний комп'ютер, а потім публікує підтверджуваний звіт про виконання на L1 для консенсусу. Просто кажучи, більшість сучасних L2 - це централізовані системи, що грають в роль блокчейнів. І це абсолютно нормально.
Ось де часи блоку стають розмитими. L2s продовжують будувати блоки головним чином для сумісності програмного забезпечення L1, але це в основному штучно. При публікації резюме на L1 L2s зазвичай пакують кілька блоків разом, щоб знизити витрати. Хоча час від часу потрібні зобов'язання стану для доказів шахрайства/правомірності, вони не потрібні для кожного блоку. Тому блоки L2 фактично є некорисними.
Коли хтось стверджує, що у нього є швидкі блоки L2, вони просто налаштували значення конфігурації системи, щоб зменшити час блоку. Хоча їм все ще потрібно обробляти значну кількість транзакцій на блок, це й є все.
Як користувач, ви турбуєтеся лише про одне: час циклу. Іншими словами, як довго знадобиться моїй транзакції, щоб досягти L2 послідовника, виконатися і результат став видимим на вузлі RPC, яким я користуюся? Сконцентруємося на останній частині: як довго знадобиться, щоб повідомити виконання транзакції до RPC?
Повільні блокчейни зазвичай чекають на кінець блоку перед його надсиланням пірнам. Solana розпочала ідею того, що ви можете передавати блоки натомість: просто надсилайте транзакції іншим перевіряючим, як тільки ви їх обробите. Solana розбиває їх на записи (групи макс. 64 транзакцій), які самі розбиваються на шреди для передачі в мережі. У нас єглибока статтяз цієї теми, якщо ви цікавитесь. Вони транслюються неперервно з вузла-лідера до інших, що означає, що ви отримуєте інформацію про виконання ваших транзакцій, перш ніж блок навіть закінчиться.
L2s тепер вирішили використовувати цей механізм: Base, з Flashblocks, переходить від часу блоку 2 секунди до менших 200 мс підблоків. MegaETH має концепцію “міні-блоків”, які генеруються кожні 15 мс на їх тестовій мережі (більшість часу). Eclipse використовує систему входу/обрізання Solana. Таким чином, користувачам потрібно менше чекати на виконання своїх транзакцій. Це досить добре для UX!
Проте будьмо ясні: справжня функція тут - «зменшені інтервали комунікації по мережі». Це не має нічого спільного з тим, що деякі блоки є вроджено кращими за інші. Ми просто розділяємо блоки на менші частини і передаємо їх паралельно з виконанням. Чи ви називаєте ці частини блоками, міні-блоками чи клаптиками, не має значення. Кінцева мета - це швидша комунікація, а не кращі блоки.