"Звільняйте місце, Sui. Звільняйте місце, Aptos." — ось як починається твіт про запуск. Ніхто не запитав, що це насправді означає на рівні реалізації. Sui використовує об’єктно-орієнтований Move. Кожен актив — це унікальний об’єкт у ланцюжку. Це дозволяє паралельне виконання без конфліктів стану, оскільки незалежні об’єкти не блокують один одного. Це архітектурна причина, чому Sui може обробляти транзакції, як 15 мільйонів ігрових взаємодій XOCIETY у ланцюжку, без вузьких місць. Aptos використовує обліково-орієнтований Move з Block-STM, оптимістичним паралелізмом, виявленням конфліктів та відкатом. Більш знайомий розробникам Ethereum, складніший для чистого паралелізму, але з потужнішими інструментами формальної верифікації через Move Prover. Реалізація Move в @Nasun_io є обліково-орієнтованою. Це свідомий вибір для ланцюжка, який одночасно запускає DEX, шар штучного інтелекту для управління та економіку ігрових активів. Обліково-орієнтована модель надає Baram більш узгоджену модель стану для аудиту. Це робить логіку маршрутизації замовлень Pado ближчою до того, що вже відомо розробникам Ethereum. Але це також означає, що Nasun не отримує паралелізму на рівні об’єктів Sui без додаткових зусиль. Тихе спостереження: «паралельне виконання Layer-1» згадується в описі власного продукту Nasun. На обліково-орієнтованому ланцюжку паралельне виконання вимагає оптимістичного паралелізму на зразок Block-STM або еквіваленту. Що саме працює під капотом, і як він обробляє конфлікти між обмінами Pado та розрахунками активів Gen Sol, що відбуваються одночасно? Ось технічне питання, на яке формулювання «Звільняйте місце Sui» навіть не намагалося відповісти.