July 27, 2022

Еще одно сравнение Sui и APTOS

от alvatar.eth | Álvaro Castro-Castilla

Дисклеймер. Гуру английского и тонкостей технических моментов отсылаю сразу в конец текста, читать оригинал.

Я провел несколько дней, устанавливая и тестируя обе цепи Sui и Aptos.
Несмотря на то, что в наши дни их обычно называют вместе, они имеют значительные конструктивные различия.

Язык Move.

Они оба используют свой собственный вариант языка Move, который облегчает параллельное выполнение. Это язык со вкусом Rust, со статически принудительными и строгими правилами владения ресурсами и формальной верификацией.

Это круто, и мне понравилось его изучать.

В версии Move от Sui были внесены некоторые изменения, наиболее заметным из которых является API владения (ownership API). Он более чистый и более четко раскрывает дизайн блокчейна, IMO. Но библиотеки кажутся немного менее развитыми, чем у Aptos.

Архитектура.

Sui использует мемпул на основе DAG (Narwhal) + алгоритм консенсуса Tusk. DAG затем используется на уровне исполнения для распараллеливания (круто!). В отличие от Avalanche (Snowman++), который пока не раскрывает всю мощь DAG для распараллеливания.

Версия Move в Sui делает очень явным, когда объект является принадлежащим/общим или изменяемым/неизменяемым. Это позволяет создать интуитивно понятную модель программирования. Более того, это позволяет Sui использовать надежную трансляцию (FastPay) для транзакций, не связанных с общим объектом, таких как платежи.

Aptos использует BlockSTM, который является развитием высокопроизводительного алгоритма HotStuff, и вводит параллелизацию путем динамического обнаружения зависимостей и планирования задач выполнения (черпая вдохновение в Software Transactional Memory).

Трудно сказать, какой из них окажется лучше на практике, но я ставлю на Sui. Aptos уже проделала очень хорошую работу по оптимизации своей текущей конструкции, в то время как у Sui, похоже, больше возможностей. Два пути византийского соглашения также дают преимущество Sui.

Масштабируемость.

Важно заметить, что обе цепочки не оптимизированы для случая домашнего валидатора (for the home validator case) и крупномасштабной децентрализации, а скорее относятся к лагерю "максимального использования пропускной способности сети" (т.е. как Solana). Рост вероятно, будет узким местом.

Sui решает эту проблему с помощью эффективного шардинга хранилища, фокусируясь на горизонтальном масштабировании ресурсов. С другой стороны, Aptos уделяет больше внимания поддержке разнородных валидаторов (heterogeneous validators)(ограниченный процессор и/или ограниченное хранилище). Мне нравится подход Суи к этому вопросу.

Опыт разработчиков.

Они оба находятся на схожей стадии развития, Aptos немного впереди. Настройка системы заняла у меня больше времени, чем собственно кодирование (я также использую NixOS). Изучение языка и среды требует некоторых проб и ошибок.

Развертывание в devnet также несколько громоздко в обоих случаях. К счастью, библиотеки модульных тестов вполне пригодны для использования.

Худшей частью определенно были непонятные ошибки компилятора и бессмысленные ответы devnet на ошибки. Это может быть настоящим поглотителем времени

В дальнейшем, или если бы я начал все сначала, я бы рекомендовал следующее:

- Во-первых, прочитайте документацию и некоторые примеры. Убедитесь, что вы можете их запустить.
- Затем перейдите непосредственно к исходному коду фреймворка в той ветке, которую вы используете (как для изучения, так и в качестве документации).

Оригинал https://twitter.com/cryptoalvatar/status/1551878559903490048

Канал про разное https://t.me/bey_baraban

Канал по FTM https://t.me/fantom_for_russia

Чат FTM https://t.me/Cryptonite_chat