Переслати оригінальний заголовок «Обмеження масштабування блокчейнів та теоретично найшвидші ВМ»

TL;DR

Ми спостерігаємо зсув у бік одного потужного сервера; Solana, Megaeth та великий набір одного послідовника, всі ведуть до одного: одного високопропускного сервера з великою пам'яттю (з них нел2 завжди буде практично найшвидшим).

Нещодавно розмовляв з іншим засновником, якого я дуже поважаю, і він сказав, що я маю написати нашу розмову.

Все почалося з простого запитання; «Чи розпаралелює Сонік якимось чином виконання транзакцій?». Відповідь – ні. І це спочатку може здатися дивним вибором, оскільки протягом останніх 2 років, якщо ви читали про технологію віртуальних машин, ви б побачили паралелі практично скрізь. То чому б і ні?

Щоб відповісти на це питання, нам спочатку потрібно подивитися, як звукова інженерія оцінює, над чим ми повинні працювати, у нас була маса теорій, які на папері звучать практично, які ми хотіли реалізувати, але обмежені фізичні ресурси команди, тож як нам вибрати, яка з них є найбільш ефективною? Тому замість того, щоб працювати над БУДЬ-ЯКОЮ з цих ідей, команда вирішила витратити рік на створення Aida, Aida є неймовірно потужним інструментом, який дозволяє нам відтворювати цілі блокчейни (будь-які) за лічені хвилини, а не місяці з корисними показниками продуктивності. Це означало, що ми можемо створити прототип, протестувати в Aida і дуже швидко дізнатися, які теорії справедливі, а які ні.

Aida також дозволяє нам використовувати досить потужні профілі, які призводять до виведення, таких як;

Таким чином, маючи вищевказане на місці, ми могли дуже швидко й точно перевірити наші припущення щодо пропускної здатності, тому ми вирішили порівняти виключно у пам'яті VM проти диска, паралельне виконання, RDMS проти KV проти плоского файлу, підмножини, нові моделі консенсусу та багато іншого

Єдиним найбільшим покращенням була БД, збільшення на 800%, наступні суперсети, за якими слідував консенсус, і дуже низьким у цьому списку, зі скромним покращенням на 30%, було паралельне виконання. Це здається нелогічним, оскільки ментальна модель чогось на кшталт паралельного виконання здається інтуїтивно кращою, ніж результати. Отже, як ми проводили паралелі? Можливо, ми помилилися, тестом було "ясновидіння" абсолютна ідеальна форма впорядкування, движок, який знає оптимальне сортування та розпаралелювання перед виконанням (те, що на практиці вже неможливо, тому навіть 30% вище, ніж повинно бути).

VM та блокчейни - дуже складні компоненти, і часто ми вимірюємо неправильні показники (або зовсім не вимірюємо).

Тоді він запитав мене: "Звідки ж швидкість Solana, якщо не вища, ніж у Sonic?". Відповідь: "Sonic швидше, ніж Solana, але Sonic не швидший, ніж найшвидша, на яку може бути здатна Solana.".

Ми спостерігаємо зсув у бік єдиних потужних серверів; Solana, Megaeth і широкий спектр одиночних секвенсорів схиляються до одного: один сервер з високою пропускною здатністю, високим обсягом пам'яті (з них не L2 завжди буде практично найшвидшим). Це рішення, якщо його правильно оптимізувати, завжди буде швидшим, ніж кілька учасників. Таким чином, максимальна оптимізована пропускна здатність чогось на кшталт Solana або Megaeth буде вищою, ніж у їхнього наступного найшвидшого конкурента, який має консенсус щодо 2+ серверів.

Отже, наступне питання, ймовірно, полягає в тому, чому Сонік не робить обраних офіціантів одним лідером? І відповідь тут, це не те, для чого ми оптимізуємося. Один із наших північних стартів, про який я писав ще у 2018 році, полягав у тому, що, коли ми бачимо появу міжкомунікаційних програм, у певний момент потрібен консенсус. Уявіть собі жваве перехрестя без знаків зупинки або світлофора і сотні автомобілів. Найбільш оптимізований метод полягає в тому, щоб автомобілі «зареєструвалися» на перехресті, а потім домовилися про порядок сортування і найбільш оптимізований метод, при якому кожен автомобіль повинен рухатися, щоб максимізувати пропускну здатність. Ви не можете використовувати тут систему, засновану на лідері, і ви не можете припустити, що партія не є зловмисною, у цьому випадку консенсус Sonic оптимізований до такої міри, що він вже може перевірятися на raspberry pi сьогодні без втрати будь-якої пропускної здатності, тому всі автомобілі можуть домовитися про порядок на основі консенсусу Sonic. Sonic оптимізований для mesh-мереж.

В будь-якому випадку, випадкові монологи, сподіваюсь, вони якось допомогли.

Відмова від відповідальності:

1. Ця стаття передрукована з [Andre Cronje]. Усі авторські права належать оригінальному авторові [Андре Кроньє]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Ворота Навчитисякоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.
3. Команда вивчення Воріт робить переклади статей на інші мови. Копіювання, поширення або плагіат перекладених статей заборонені, якщо не зазначено інше.