Перенаправить оригинальное название «Ограничения масштабирования блокчейнов и какие VM-системы теоретически самые быстрые»

ТЛ; ДОКТОР

Мы наблюдаем сдвиг в сторону отдельных мощных серверов; Solana, Megaeth и широкий спектр одиночных секвенсоров — все они опираются на одну вещь: один сервер с высокой пропускной способностью и большим объемом памяти (из них сервер без L2 всегда будет практически самым быстрым).

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

Все началось с простого вопроса: «Параллелит ли Sonic выполнение транзакций каким-либо образом?». Ответ - нет. И на первый взгляд это может показаться странным выбором, поскольку за последние 2 года, если вы следите за технологиями VM, вы, скорее всего, видели параллелизацию практически повсюду. Так почему же мы этого не делаем?

Чтобы ответить на этот вопрос, нам сначала нужно посмотреть, как Sonic engineering оценивает то, над чем мы должны работать, у нас была масса теорий, которые на бумаге звучат практично, которые мы хотели реализовать, но физические ресурсы команды были ограничены, так как же мы выбираем, какая из них наиболее эффективна? Таким образом, вместо того, чтобы работать над ЛЮБОЙ из этих идей, команда решила потратить год на создание Aida, Aida - это невероятно мощный инструмент, который позволяет нам воспроизводить целые блокчейны (любые) за считанные минуты, а не месяцы с полезными показателями производительности. Это означает, что мы можем создавать прототипы, тестировать в «Аиде» и очень быстро узнавать, какие теории работают, а какие нет.

Aida также позволяет нам выполнять довольно мощное профилирование, что приводит к таким результатам, как;

Таким образом, имея все вышесказанное, мы могли очень быстро и точно проверить наши предположения о пропускной способности, поэтому мы решили сравнить виртуальные машины и диски исключительно в памяти, параллельное выполнение, RDMS, KV и неструктурированные файлы, супермножества, новые модели консенсуса и многое другое

Самым большим улучшением была DB, увеличение на 800%, следующие супермножества, за которыми следовал консенсус, и очень низкое в этом списке, со скромным улучшением в 30%, было параллельное выполнение. Это кажется нелогичным, поскольку мысленная модель для чего-то вроде параллельного выполнения интуитивно кажется лучше, чем результаты. Так как же мы проводили параллели? Может быть, мы ошиблись, тест был "Ясновидение" - абсолютно идеальная форма упорядочения, движок, который знает оптимальную сортировку и распараллеливание перед выполнением (то, что на практике уже невозможно, поэтому даже 30% выше, чем должно быть).

VM и блокчейны - очень сложные компоненты, и часто мы измеряем неправильные метрики (или вообще не измеряем).

Затем он спросил меня: «Откуда берется скорость Solana? Или она на практике не выше, чем у Sonic?». Ответ: «Соник быстрее Соланы, но Соник не быстрее, чем может быть самая быстрая Солана».

Мы наблюдаем сдвиг в сторону отдельных мощных серверов; Solana, Megaeth и широкий спектр одиночных секвенсоров — все они опираются на одну вещь: один сервер с высокой пропускной способностью и большим объемом памяти (из них сервер без L2 всегда будет практически самым быстрым). Это решение, если его правильно оптимизировать, всегда будет быстрее, чем несколько участников. Таким образом, максимальная оптимизированная пропускная способность чего-то вроде Solana или Megaeth будет выше, чем у их следующего по скорости конкурента, который делает консенсус с 2+ серверами.

Тогда следующий вопрос, вероятно, заключается в том, почему Sonic не делает серверы, избираемые одним лидером? И ответ здесь: это не то, для чего мы оптимизируем. Одно из наших северных начинаний, о котором я писал еще в 2018 году, заключалось в том, что по мере того, как мы наблюдаем появление взаимодействующих программ, в какой-то момент требуется консенсус. Представьте себе оживленный перекресток без знаков остановки или светофоров и сотни автомобилей. Наиболее оптимизированный метод заключается в том, чтобы автомобили «зарегистрировались» на перекрестке, а затем договорились о порядке сортировки и наиболее оптимизированном методе, в котором каждый автомобиль должен двигаться, чтобы максимизировать пропускную способность. Вы не можете использовать здесь систему, основанную на лидере, и вы не можете предполагать, что партия не является злонамеренной, в этом случае консенсус Sonic оптимизирован до такой степени, что он уже сегодня может проверяться на Raspberry Pi без потери пропускной способности, поэтому все автомобили могут договориться о порядке на основе консенсуса Sonic. Sonic оптимизирован для ячеистых сетей.

В любом случае, бессвязные болтовня, надеюсь, это как-то помогло.

Отказ от ответственности:

1. Эта статья предоставлена взаймы от [gateАндре Кронье]. Все авторские права принадлежат автору оригинала [Андре Кронье]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. Команда gate Learn занимается переводом статьи на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.