Найновіші
Будьте в курсі останніх дописів.
Пости
2358
Деконструювання архітектури Суй: двійні двигуни нарвала та бульшарка
Твердження про продуктивність блокчейну Sui - майже миттєва остаточність та масивна горизонтальна масштабованість - не є магічними. Вони є результатом ретельно розробленої архітектури, яка принципово відходить від монолітних конструкцій блокчейну. В основі цієї інновації лежить складна система, яка розумно відокремлює подання транзакцій від консенсусу, використовуючи два ключові компоненти: Narwhal і Bullshark. Щоб по-справжньому зрозуміти, що робить Sui таким потужним, ми повинні деконструювати його архітектуру та побачити, як ці частини поєднуються, щоб вирішити основні проблеми продуктивності блокчейну. Архітектурна мета: уникнути вузького місця консенсусус Традиційні блокчейни змушують кожну транзакцію, якою б простою вона не була, через глобальний механізм консенсусу (наприклад, Proof-of-Work або стандартний Proof-of-Stake). Цей процес за своєю суттю повільний і інтенсивний для спілкування, оскільки кожен вузол у мережі повинен узгодити точний загальний порядок всіх транзакцій. Це основне вузьке місце, яке обмежує швидкість і збільшує витрати. Архітектори Суй зрозуміли, що більшість транзакцій не потребують такого важкого підходу. Проста однорангова передача активів не залежить від будь-якої іншої паралельної транзакції. Отже, основною архітектурною метою Суї було виділити консенсус і використовувати його лише тоді, коли це вкрай необхідно. Це призвело до двосторонньої системи обробки, побудованої на новаторському механізмі mempool та консенсусу. Великий розрив: прості та складні транзакції Першим і найважливішим кроком життєвого циклу транзакцій Суй є сортування. Коли користувач подає транзакцію, мережа негайно аналізує об'єкти, з якими він має намір взаємодіяти. Цей аналіз сортує транзакцію в один із двох шляхів. • Прості транзакції (об'єкти, що належать): Цей шлях призначений для транзакцій, які включають лише «об'єкти, що належать» - активи, контрольовані однією адресою. Приклади включають надсилання токенів SUI, передачу NFT або використання витратного елемента в грі, якою ви володієте. Ці операції причинно незалежні від інших. Вони не вимагають впорядкування щодо дій інших користувачів. Для цього Суй використовує легкий процес, який називається візантійською послідовною трансляцією або «швидким шляхом». Угода направляється валідаторам, які самостійно перевіряють її дійсність і підписують її. Після того, як відправник збирає кворум підписів (сертифікат), транзакція є остаточною. Весь цей процес обходить формальний консенсус і досягає остаточності менш ніж за секунду. • Складні транзакції (спільні об'єкти): Цей шлях зарезервований для транзакцій, які включають «спільні об'єкти» — об'єкти, які декілька користувачів можуть читати та записувати одночасно. Подумайте про пул ліквідності децентралізованої біржі, спільний лічильник у грі для кількох гравців або державний аукціонний контракт. У цих випадках порядок операцій має вирішальне значення. Якщо два користувачі намагаються вийти з одного пулу одночасно, мережа повинна домовитися про те, хто був першим. Для цих транзакцій Sui використовує свій повний двигун консенсусу: Narwhal і Bullshark. Двигун консенсусу: глибоке занурення в нарвала та бичаку Коли транзакція вимагає замовлення, вона надсилається до нового механізму консенсусу Суй. Цей механізм унікальний, оскільки він відокремлює відповідальність за забезпечення доступності даних (mempool) від відповідальності узгодження конкретного порядку цих даних (протокол консенсусу). Нарвал: високопродуктивний мемпул • Що це таке: Narwhal - це протокол мемпулу мережі. Його завдання полягає в тому, щоб надійно транслювати транзакції всім валідаторам і упакувати їх у впорядковані партії, але поки не узгоджуючи послідовність перехресних валідаторів цих пакетів. • Як це працює: Кожен валідатор запускає свого власного «працівника» Narwhal, який отримує транзакції. Цей працівник групує їх у групу, створює «колекцію» та транслює цю колекцію до «праймеріз» Narwhal всіх інших валідаторів. Праймеріз збирає ці партії від усіх валідаторів та гарантує, що вони доступні в мережі. Нарвал заснований на структурі спрямованого ациклічного графа (DAG). Кожна партія посилається на попередні партії, створюючи графік причинності. • Проблема, яку вона вирішує: Традиційні мемпули часто хаотичні та неефективні, що призводить до мережевого спаму та поганої продуктивності. Narwhal — це неймовірно високопродуктивний двигун, спеціально розроблений для того, щоб протистояти атакам від відмови в обслуговуванні (DoS) та гарантувати, що всі валідатори мають доступ до одного набору очікуваних транзакцій, не перевантажуючись. Він діє як високоефективний, стійкий шар сортування та розподілу. Bullshark: Ефективний консенсус на основі DAG • Що це таке: Bullshark - це протокол консенсусу за замовчуванням, який працює поверх структурованого графіка пакетів транзакцій, наданих Narwhal. (Можна також використовувати більш ранню версію під назвою Туск). • Як це працює: Поки Narwhal будує DAG, Bullshark «перетинає» його, щоб визначити остаточний загальний порядок для партій транзакцій. Це досягається із значно меншими витратами на зв'язок, ніж традиційні протоколи BFT. Замість кількох раундів голосування по кожному окремому блоку, Bullshark використовує причинно-наслідкові зв'язки, вже встановлені в DAG нарвалів. Лідер пропонує замовлення, а валідатори просто голосують за його підтвердження. Якщо лідер повільний або несправний, протокол може швидко перейти до наступного лідера з мінімальною затримкою, що робить його дуже надійним. • Проблема, яку вона вирішує: Стандартні консенсусні протоколи, такі як Tendermint, вимагають інтенсивного, синхронного зв'язку між усіма вузлами, щоб узгодити кожен блок, що обмежує швидкість. Працюючи над DAG, наданим Narwhal, Bullshark може замовляти транзакції з набагато меншими кроками зв'язку, що дозволяє отримати швидший консенсус і більшу пропускну здатність для складних транзакцій, які цього потребують. Поєднуючи все разом: подорож транзакції • Подання: Користувач підписує та подає транзакцію. • Стріаж: валідатори перевіряють об'єкти транзакції. • Шлях A (швидкий шлях): Якщо він включає лише об'єкти, що належать, транзакція транслюється, підписується кворумом валідаторів та завершується. Кінець подорожі. • Шлях B (консенсусний шлях): якщо він включає спільний об'єкт, транзакція надсилається до мепулу Narwhal. • Mempool/DAG: працівники Narwhal партіюють транзакцію та транслюють її, створюючи DAG пакетів, доступних для всіх валідаторів. • Консенсус: Протокол Bullshark працює на цьому DAG, узгоджуючи остаточний, загальний порядок партій. • Виконання: Після замовлення транзакція виконується усіма валідаторами, і її наслідки завершуються. Кінець подорожі. Висновок: Архітектура, побудована для продуктивності Архітектура Суй - це майстер-клас з інженерної ефективності. Відмовившись ставитися до всіх транзакцій як рівних, він створює систему, яка може обробляти переважну більшість простих дій користувача з безпрецедентною швидкістю. Для більш складних взаємодій, які потребують координації, він розгортає найсучасніший двигун на основі DAG, який відокремлює доступність даних від замовлення, щоб максимізувати пропускну здатність. Ця конструкція з двома двигунами, оснащена швидким шляхом для простих транзакцій та комбінацією Narwhal/Bullshark для складних, є тим, що дозволяє Sui звільнитися від традиційної форми блокчейну та забезпечити продуктивність, необхідну для справді масштабованого та зручного веб-сторінку3.
- Architecture
0+15
Помилка Sui Move - Неможливо обробити транзакцію Не знайдено дійсних газових монет для транзакції
Коли я роблю це: //Розділіть платіж з основної монети конст [PaymentCoin] = TX.спліткойни ( tx.object (первинний Coin.CoinObjectID), [tx.pure.u64 (Обов'язкова сума платежу)] ); //Використовуйте оригінальну монету для оплати газу tx.setGasPayment ([{ Об'єктID: первинний Coin.CoinObjectID, версія: первинна коін.версія, дайджест: первинний коїн.дайджест }]); ТК.сетгасБюджет (10_000_000); Він скаржиться на об'єкти, що змінюються, не можуть з'являтися більше одного в одній транзакції. Коли я знімаю платіж за газ, він скаржиться «Не вдається обробити транзакцію Для транзакції не знайдено дійсних газових монет». Моя функція контракту приймає .01 sui в обмін на NFT
- Sui
- Transaction Processing
- Move
02
Концептуальне покрокове керівництво: ваша перша взаємодія з об'єктом Sui
Давайте візуалізуємо, як це працює без написання жодного рядка коду. •Створення (карбування) :Уявіть, що ви граєте в гру і заробляєте «Легендарний меч». Розумний контракт гри виконує функцію, яка створює новий об'єкт Sword. Цей об'єкт має такі атрибути, як пошкодження: 100, рідкість: «Легендарний», і найголовніше, йому присвоєно унікальний ідентифікатор, а поле власника встановлено на адресу вашого гаманця. •Передач: Ви вирішуєте продати меч своєму другові Девіду. Ви підписуєте транзакцію, яка говорить: «Візьміть об'єкт з ідентифікатором 0x123... (меч) і передати його право власності на адресу Давида». Оскільки тільки ви володієте мечем, це проста транзакція. Він надсилається валідаторам, які швидко підтверджують ваше право власності, підписують зміни та завершують її за мілісекунди, не потребуючи повного консенсусу в мережі. •Модифікація: Об'єкт Sword може мати функцію під назвою upgrade (). Ви можете викликати цю функцію, яка може споживати об'єкт «Заточувальний камінь», який ви також маєте, щоб змінити атрибут пошкодження об'єкта Меча з 100 на 110. Знову ж таки, оскільки ви володієте обома об'єктами, це проста транзакція, яка виконується на швидкому шляху. Висновок: Будівництво для майбутнього Суй - це не поступове вдосконалення; це зміна парадигми. Переходячи від перевантаженої односмугової дороги до багатосмугової супермагістралі, він відкриває продуктивність, необхідну для того, щоб web3 став основним. Його об'єктно-центрична модель у поєднанні з безпекою мови Move та зручним газовим механізмом створює середовище, де розробники можуть створювати складні високочастотні програми, такі як он-ланцюгові ігри, соціальні мережі та системи DeFi в режимі реального часу, які раніше просто не були можливими. Для користувачів це перетворюється на швидший, дешевший та безпечніший досвід, нарешті подолавши розрив між обіцянкою web3 та безперебійною юзабіліті веб-2.
- Sui
0
Глибоке занурення в блокчейн Sui: більше, ніж просто ще один рівень 1
У всесвіті блокчейнів рівня 1, що швидко розширюється, легко загубитися в шумі маркетингових обіцянок та технічного жаргону. Новачки і навіть досвідчені криптоентузіасти часто запитують: «Чим це відрізняється?» Коли справа доходить до блокчейну Sui, відповідь - це не незначна зміна або невелике вдосконалення; це фундаментальне переосмислення того, як блокчейн повинен бути розроблений для обслуговування наступного покоління децентралізованих додатків. Ця стаття розкриє основну філософію Суї, дослідить проблеми, які вона має на меті вирішити, та проілюструє, чому її унікальна об'єктно-центрична модель являє собою значний стрибок вперед. **Проблема: звільнення від ланцюгів послідовної обробки ** Протягом багатьох років у світі блокчейнів домінувала модель «на основі облікових записів», популяризована Ethereum. У цій моделі вся мережа по суті являє собою один гігантський спільний комп'ютер. Кожна транзакція, будь то простий переказ токенів між двома людьми або складна взаємодія з протоколом DeFi, повинна оброблятися в певному порядку. Це відоме як послідовна обробка. Уявіть собі банк з одним касиром. Не має значення, чи хочете ви просто внести чек, чи подаєте заявку на складний бізнес кредит; кожен повинен стояти в одній єдиній лінії і обслуговуватися один за одним. Це саме вузьке місце, яке мучить традиційні блокчейни. Це призводить до декількох критичних проблем: • Низька пропускна здатність: Мережа може обробляти лише стільки транзакцій, скільки може обробити «один касир» за певний час. • Висока затримка: Ваша проста транзакція може застрягти за величезною, обчислювально інтенсивною транзакцією, що призведе до тривалого очікування. • Нестабільні збори за газ: Коли лінія стає занадто довгою (високий попит на мережу), користувачі змушені робити ставки один проти одного, сплачуючи непомірні збори, щоб привернути увагу касира. Це робить багато додатків, особливо в іграх та соціальних мережах, економічно нежиттєздатними. Рішення Суй: Об'єктно-центрична революція Розробники Sui, багато з яких походили з вдосконаленого блокчейн-проекту Meta Diem, визнали, що цей однофайловий рядок непотрібний. Вони поставили просте, але глибоке запитання: «Чому дві абсолютно не пов'язані угоди повинні чекати один одного?» Якщо Аліса надсилає Бобу квиток на концерт NFT, а Чарлі окремо створює меч у відеогрі, ці дві події не впливають одна на одну. Вони не торкаються одних і тих самих даних. То чому їх слід примушувати в послідовний порядок? Це розуміння призвело до об'єктно-центричної моделі Суя. Замість єдиної спільної книги (моделі облікового запису), Суй розглядає світ як сукупність програмованих об'єктів. Об'єктом може бути що завгодно: монета, NFT, ігровий персонаж, позиція DeFi або профіль у соціальних мережах. Кожен об'єкт має глобально унікальний ідентифікатор і контролюється власником. Новаторським наслідком цієї моделі є паралельне виконання транзакцій. Повертаючись до нашої банківської аналогії, Суй схожий на банк з тисячами касирів. Якщо ваша транзакція включає лише об'єкти, якими ви володієте (наприклад, переказ власних грошей), ви можете звернутися до будь-якого доступного касира, не чекаючи в основному рядку. Це «швидкий шлях». Тільки коли транзакція включає спільний об'єкт (наприклад, депозит у центральний інвестиційний пул, який використовує багато людей), їй потрібно пройти більш формальний процес замовлення. **Ключові диференціатори, які переосмислюють досвід користувача Цей архітектурний зсув забезпечує кілька унікальних функцій, які безпосередньо вирішують больові точки старих блокчейнів.** • Масивна масштабованість за допомогою паралелізму: обробляючи переважну більшість транзакцій паралельно, Sui може досягти теоретичної пропускної здатності, виміряної в сотнях тисяч транзакцій в секунду (TPS). Ця горизонтальна масштабованість означає, що в міру додавання до мережі більше валідаторів (комп'ютерів) її ємність збільшується, подібно до додавання більшої кількості серверів до програми web2. • Постійно низькі та передбачувані збори за газ: газова модель Sui розроблена для стабільності. Оскільки ємність мережі не є постійним вузьким місцем, газові війни значною мірою пом'якшуються. Крім того, Sui відокремлює вартість виконання від вартості зберігання даних. Користувачі сплачують одноразову плату за зберігання своїх об'єктів у мережі, створюючи «фонд зберігання», який компенсує майбутнім валідаторам витрати на зберігання цих даних. Це призводить до більш передбачуваних транзакційних витрат, що має вирішальне значення для розробників, які будують стійкий бізнес. • Покращена безпека за допомогою Sui Move: Sui використовує потужну версію мови програмування Move, яка була спеціально розроблена для безпечного поводження з цифровими активами. На відміну від інших мов смарт-контрактів, де активи представлені як записи в книзі, у Move такий актив, як Монета, є справжнім ресурсом. Система типів мови гарантує, що вона не може бути випадково дубльована або видалена, усуваючи цілі класи поширених помилок та експлойтів на рівні компілятора.
- Sui
0Мова переміщення: живлення смарт-контрактів Sui
Коли ви чуєте про будівництво на Суї, неодноразово з'являється одне слово:Рухати. Це не просто чергова мова смарт-контрактів - це модель програмування, яка насамперед безпека, розроблена для запобігання самих помилок та експлойтів, які мучили інші блокчейни. Якщо ви хочете створювати надійні, безпечні та високопродуктивні програми на Sui, розуміння Move є важливим. За своєю суттю, Move розглядає цифрові активи як об'єкти реального світу. Якщо у вас є чашка, ви не можете випадково «клонувати» її у дві чашки або забути, куди ви її поклали - право власності завжди явне. Це називаєтьсяресурсоорієнтоване програмування, і це одна з найбільших сильних сторін Move. Це гарантує, що токени, NFT та інші активи не можуть бути дубльовані або втрачені без того, щоб ваш код зробив його * дуже* навмисним. На Sui Move отримує оновлення. Об'єктна модель Sui розширює можливості Move, дозволяючи зберігати дані безпосередньо в об'єктах, передавати їх між транзакціями та безпечно мутувати їх, не торкаючись непов'язаного стану. Це означає, що ви можете розробляти програми, які масштабуються горизонтально, паралельно обробляючи дані різних користувачів, не стикаючись з глобальними вузькими місцями. Ще однією великою перевагою єсильне статичне друкування. Переміщення змушує вас точно визначити, що може, а що не може відбуватися з вашими даними, перш ніж код навіть запуститься. Якщо ваш контракт намагається надіслати токен на недійсну адресу або змінити незмінний об'єкт, він не буде компілювати. Хоча спочатку це може здатися суворим, це різко зменшує помилки виконання та ризики безпеки. Розробники, які починають користуватися Move, часто стикаються з кривою навчання, особливо якщо вони походять від Solidity або JavaScript. Перехід мислення від «змінних і балансів» до «об'єктів та власності» може зайняти час. Хорошою відправною точкою є вивчення офіційних прикладів Sui Move, повозитися з невеликими модулями та експериментувати з передачею об'єктів. Як тільки ви зрозумієте право власності та можливості, все інше починає клацати. На практиці філософія дизайну Move позбавляє вас від цілих категорій дорогих помилок. Замість того, щоб покладатися на зовнішній аудит, щоб вловити небезпечну логіку після розгортання, сама мова допомагає запобігти компіляції цих помилок. У поєднанні з високою пропускною здатністю Sui та виконанням на основі об'єктів, Move відкриває двері для більш складних, інтерактивних та безпечних децентралізованих додатків, ніж можуть підтримувати більшість ланцюгів. Спираючись на принципи Move - розглядаючи активи як унікальні ресурси, будуючи з сильним типом та користуючись перевагами паралельного виконання Sui, ви можете створювати контракти, які є одночасно потужними та надійними. У світі Web3 це серйозна конкурентна перевага.
- Move
0
Роль консенсусу в Суї
За своєю суттю блокчейн - це гігантська машина угод. Кожен вузол повинен домовитися про те, що сталося, в якому порядку і кому що належить. Це називаєтьсяконсенсус, і це основа довіри до децентралізованої мережі. Sui використовує новий підхід до цього, оптимізуючи швидкість, масштабованість та ефективність. У більшості блокчейнів усі транзакції - будь то прості чи складні - проходять один і той же важкий процес консенсусу. Це все одно, що змусити всіх чекати в одній лінії безпеки аеропорту, незалежно від того, чи перевозять вони один рюкзак або цілий вантажний контейнер. Sui змінює це за допомогоюдворежимної системи транзакцій. Ось як це працює: •Прості транзакції— Якщо транзакція торкається лише об'єктів, що належать одному користувачеві, вона не потребує повного консенсусу. Натомість Суй використовує більш швидкий механізм під назвоюВізантійське послідовне мовлення*. Це дозволяє транзакціям здійснюватися майже миттєво, не залучаючи всю мережу до їх замовлення. •Складні транзакції— Якщо транзакція включає * спільні об'єкти* (доступні для кількох користувачів), Sui використовуєNarwhal & Bullshark, свій розширений протокол консенсусу. Це гарантує, що всі погоджуються щодо точного порядку подій, щоб не було ризику подвійних витрат або конфліктних оновлень. Краса цього дизайну полягає в тому, що мережа не витрачає ресурси на замовлення транзакцій, які не потрібно замовляти. Пропускаючи консенсус у багатьох поширених випадках, Sui може обробляти набагато більше транзакцій паралельно, ніж традиційні ланцюги. Чому це має значення? •Нижча затримка- Гравці в грі можуть миттєво оновити своїх персонажів, не чекаючи всієї мережі. •Більш висока пропускна здатність— Додаток DeFi може обробляти тисячі незалежних переказів токенів одночасно. •Ефективність витрат- Користувачі платять менше за газ, оскільки мережа не забита непотрібними раундами консенсусу. Уявіть собі ігровий ринок, де сотні гравців купують і продають предмети одночасно. На більшості блокчейнів кожна торгівля стояла б у черзі одна за одною. На Sui, якщо угоди не торкаються одного спільного ресурсу, всі вони можуть бути підтверджені паралельно - наприклад, десятки станцій самообслуговування замість одного касира. Ця гібридна модель консенсусу є однією з найбільших нововведень Суї. Ось чому мережа може масштабуватися до мільйонів щоденних транзакцій без поту - все це зберігаючи безпеку та довіру недоторканими.
- Sui
- Transaction Processing
0Роль консенсусу в Суї
За своєю суттю блокчейн - це гігантська машина угод. Кожен вузол повинен домовитися про те, що сталося, в якому порядку і кому що належить. Це називаєтьсяконсенсус, і це основа довіри до децентралізованої мережі. Sui використовує новий підхід до цього, оптимізуючи швидкість, масштабованість та ефективність. У більшості блокчейнів усі транзакції - будь то прості чи складні - проходять один і той же важкий процес консенсусу. Це все одно, що змусити всіх чекати в одній лінії безпеки аеропорту, незалежно від того, чи перевозять вони один рюкзак або цілий вантажний контейнер. Sui змінює це за допомогоюдворежимної системи транзакцій. Ось як це працює: •Прості транзакції— Якщо транзакція торкається лише об'єктів, що належать одному користувачеві, вона не потребує повного консенсусу. Натомість Суй використовує більш швидкий механізм під назвоюВізантійське послідовне мовлення*. Це дозволяє транзакціям здійснюватися майже миттєво, не залучаючи всю мережу до їх замовлення. •Складні транзакції— Якщо транзакція включає * спільні об'єкти* (доступні для кількох користувачів), Sui використовуєNarwhal & Bullshark, свій розширений протокол консенсусу. Це гарантує, що всі погоджуються щодо точного порядку подій, щоб не було ризику подвійних витрат або конфліктних оновлень. Краса цього дизайну полягає в тому, що мережа не витрачає ресурси на замовлення транзакцій, які не потрібно замовляти. Пропускаючи консенсус у багатьох поширених випадках, Sui може обробляти набагато більше транзакцій паралельно, ніж традиційні ланцюги. Чому це має значення? •Нижча затримка- Гравці в грі можуть миттєво оновити своїх персонажів, не чекаючи всієї мережі. •Більш висока пропускна здатність— Додаток DeFi може обробляти тисячі незалежних переказів токенів одночасно. •Ефективність витрат- Користувачі платять менше за газ, оскільки мережа не забита непотрібними раундами консенсусу. Уявіть собі ігровий ринок, де сотні гравців купують і продають предмети одночасно. На більшості блокчейнів кожна торгівля стояла б у черзі одна за одною. На Sui, якщо угоди не торкаються одного спільного ресурсу, всі вони можуть бути підтверджені паралельно - наприклад, десятки станцій самообслуговування замість одного касира. Ця гібридна модель консенсусу є однією з найбільших нововведень Суї. Ось чому мережа може масштабуватися до мільйонів щоденних транзакцій без поту - все це зберігаючи безпеку та довіру недоторканими. Якщо ви готові, тепер я можу зробитиСтаттю 4 - Переміщення мови: Потужність смарт-контрактів Sui, щоб ми мали перші чотири повністю відшліфовані.
- Sui
- Architecture
- SDKs and Developer Tools
- Transaction Processing
- Security Protocols
0Розуміння об'єктно-орієнтованої моделі Суї
Більшість блокчейнів розглядають токени та стани смарт-контрактів як записи у гігантській спільній книзі, але Sui перевертає це на голову. Замість того, щоб працювати з величезною глобальною державою, Sui будується навколооб'єктів— автономних фрагментів даних, які знаходяться в мережі і можуть бути у власності, передаватися або модифіковані. Подумайте про об'єкти, як посилки в поштовому відділенні. Кожен має унікальний ідентифікатор, визначеного власника та конкретний вміст. Завдання блокчейну полягає в тому, щоб переконатися, що ці посилки не можуть бути вкрадені, дубльовані або змінені без згоди власника. У Sui об'єктом може бути будь-що: монета, NFT, ігровий персонаж, ділянка землі в метавсесвіті або навіть внутрішня структура даних смарт-контракту. У Суї є два основних типи об'єктів: •Власні об'єкти— належать до певної адреси. Тільки ця адреса (або її авторизовані смарт-контракти) може змінювати їх. •Спільні об'єкти— доступні для декількох користувачів. Вони вимагають більш суворого упорядкування транзакцій та консенсусу, оскільки кілька людей можуть взаємодіяти з ними одночасно. Справжня магія походить відРесурсоорієнтованого дизайну Move. У Sui об'єкти зберігаються як ресурси, а це означає, що їх неможливо скопіювати або випадково видалити. Якщо ви передаєте об'єкт, оригінал зникає — ні дублікатів, ні записів привидів. Це робить систему безпечною та передбачуваною. Коли ви надсилаєте транзакцію в Sui, ви в основному кажете: «Я хочу взяти цей об'єкт, зробити щось з ним і створити нову версію». Блокчейн перевіряє, що ви насправді володієте об'єктом і чи дозволена ваша дія, а потім відповідно оновлює стан. Для розробників такий підхід змінює гру. Це означає: • Ви можете розробляти програми, де кожен актив є першокласним громадянином, а не лише рядок бази даних. • Транзакції, пов'язані з непов'язаними об'єктами, можуть працювати паралельно, роблячи мережу набагато швидшою, ніж традиційні ланцюги. • Складні ігрові предмети, позиції DeFi або облікові дані особи можуть існувати як захищені об'єкти, що передаються. Ось короткий приклад: уявіть, що ви будуєте ринок для ігрових мечів. Кожен меч - це об'єкт з такою статистикою, як сила атаки, довговічність та рідкість. Коли гравець оновлює свій меч, він замінює старий об'єкт новим, який має оновлену статистику. Блокчейн гарантує, що лише законний власник може внести ці зміни - і ніхто інший не може дублювати меч. Розуміння цієї об'єктно-орієнтованої моделі є ключем до створення справді інтерактивних та масштабованих додатків на Sui. Це зміщує ваше мислення від «оновлення змінних у глобальному контракті» на «передачу активів, подібних до реального світу, безпечним та перевіреним способом».
- Sui
- Architecture
0
Дорожня карта Суй до 2025 року: технічні інновації для масового прийняття
Sui, запущений у 2023 році, готовий до масового прийняття зі своєю дорожньою картою до 2025 року. Маючи TVL на $2 млрд та 8 мільйонів гаманців, токен SUI Sui керує його екосистемою. Огляд Sui: 120 000+ TPS та низькі збори Sui забезпечують масовий маркет DApps. zkLogin та спонсорство газу сприяють впровадженню, а Mysticeti v2 підвищує продуктивність. Архітектура: Об'єктно-центрична модель та Mysticeti підтримують паралельну обробку, з горизонтальним масштабуванням, що забезпечує майбутню потужність. Складність може уповільнити прийняття розробником. SDK та інструменти розробника: SDK та тестові мережі Sui спрощують розробку, а Move забезпечує безпеку. Реєстр переміщення підвищить складність, сприяючи прийняттю. Обробка транзакцій: Паралельне виконання та підсекундність підтримують масові DApps. Mysticeti v2 зменшить затримку, покращуючи прийняття користувачів. Протоколи безпеки: Правила власності Move та BFT Mysticeti забезпечують довіру. Гаманці zkLogin та edDSA забезпечують безпечне прийняття для основних користувачів. NFT: Динамічні NFT забезпечують масштабовані програми з низькою платою стимулюючи залучення. SuiBridge розширить прийняття крос-ланцюгів, покращуючи ринки. Move: безпечний дизайн Move підтримує майбутні DApps з оптимізацією виконання SuivM. Реєстр Move сприятиме прийняттю розробників у 2025 році. Дорожня карта Sui до 2025 року використовує технічні інновації для масового прийняття, формуючи майбутнє Web3.
- Sui
- Architecture
- Transaction Processing
0Проектування газоефективних транзакцій Sui — практичний посібник
Суй вже відомий тим, що має дуже низькі збори за газ порівняно з великими іменами, такими як Ethereum або Solana, але «низький» не означає «безкоштовний». Якщо ви створюєте масштабний додаток - особливо той, який обробляє тисячі транзакцій на день - навіть крихітна неефективність кожної транзакції врешті-решт обійдеться вам. Багато розробників потрапляють у пастку думок: * «Якщо я просто вкладу всі свої дії в одну велику транзакцію, це буде ефективніше» .* У Sui це не завжди так. Щоразу, коли ви додаєте більшеоб'єктів введення(активи в ланцюзі, які ваша транзакція читає або змінює), складність зростає. Це може виштовхнути вашу транзакцію за межі бюджету газу або спричинити помилки «вичерпання газу», особливо під час запуску масових операцій. ####Крок 1: Профіль перед оптимізацієм Першим кроком до ефективності газу є розуміння вашого поточного використання. Sui дає вам простий спосіб зробити це за допомогою --gas-budgetпрапора CLI. Імітуючи ваші операції з різними бюджетами газу, ви можете побачити, скільки газу їм насправді потрібно. Це допоможе вам визначити, чи їсть одна «мегатранзакція» набагато більше газу, ніж повинна. Наприклад: sui client call --function my_function \ --module my_module \ --package \ --args \ --gas-budget 2000 Якщо ви бачите, що транзакція провалилася, якщо ви не встановите величезний бюджет газу, це ваш червоний прапор. ####Крок 2: Розбийте великі транзакції Замість того, щоб збивати все в один раз, розділіть його на менші логічні групи. Скажімо, ваш DApp карбує нові NFT, передає їх користувачам та оновлює деякі метадані — все в одній транзакції. Це три окремі операції, кожна з яких має власний об'єкт читання та запису. Кращий підхід: Транзакція 1 → Mint NFT Транзакція 2 → Передача NFT Транзакція 3 → Оновити метадані Розбиваючи їх, ви зменшуєте кількість вхідних об'єктів на кожному кроці, що знижує ймовірність досягнення межі газу або помилок версії об'єкта. ####Крок 3: Пакетні підписи в SDK Якщо ви використовуєте SDK JavaScript Sui, тут є прихована перлина: ви можете підписатидекілька дій в одній партії, а потім надіслати їх разом. Це економить газ, уникаючи повторної перевірки підпису, яка може накопичуватися в ситуаціях великого обсягу. Процес простий: Створіть кілька блоків транзакцій в пам'яті. Підпишіть їх усі відразу. Надішліть їх одним дзвінком RPC. Але є проблема — ви повинніоновити стан об'єктубезпосередньо перед виконанням пакету. Якщо номер версії об'єкта зміниться під час очікування транзакції, це не вдасться. ####Крок 4: Використовуйте незмінні дані для констант Ось тонка, але потужна оптимізація: незмінні дані (об'єкти, які ніколи не змінюються після створення)вільні для читанняв Sui. Якщо ви зберігаєте одні й ті ж значення знову і знову в об'єктах, що змінюються, як-от ціни за замовчуванням, параметри конфігурації або ідентифікатори посилань, ви змушуєте ваші транзакції виконувати непотрібну роботу. Замість цього: Зберігайте ці константи як незмінні об'єкти один раз. Посилайтеся на них у своїх транзакціях замість того, щоб копіювати їх кожен раз. Таким чином, ваші транзакції не витрачають газ на читання або запис одних і тих самих даних повторно. ####Крок 5: Тримайте уявлення про газоефективність Оптимізація газу - це не лише економія кількох центів; це про те, щоб зробити ваш DAppбільш надійним. Коли ваші транзакції є ощадливими, вони рідше виходять з ладу, виконуються швидше і їх легше налагодити. З часом ці заощадження збільшуються - як з точки зору грошей, так і в більш плавному користуванні. Ключові висновки: Профіль транзакцій перед оптимізацією. Розбийте великі транзакції на менші. Пакетні підписи для збереження при повторних перевірках. Зберігайте константи як незмінні, щоб уникнути зайвих витрат на газ. Завжди оновлюйте стан об'єкта перед відправкою транзакції. Освоюйте ці звички рано, і пізніше ви уникнете болісних проблем із масштабуванням. Низькі гонорари Суї - це подарунок, але тільки якщо ви ставитеся до них з повагою.
- Sui
- SDKs and Developer Tools
- Transaction Processing
0
