Головна

0xduckmove288

May 30, 2025

Стаття

Якщо ви будуєте на Sui або возите з Move, ви, напевно, чули термін BCS, що плаває навколо. Це скорочення від машини форматування Binary Canonical Serialization, спочатку створеної для блокчейну Diem, а тепер є наріжним каменем екосистем на основі MOVE, таких як Sui, Aptos, Starcoin та 0L. Тож так, вам краще затишно з ним, якщо ви серйозно ставитеся до будівництва в цьому просторі. Що таке BCS? Бінарна канонічна серіалізація (BCS) - це формат, який використовується для серіалізації (кодування) та десеріалізації (декодування) структурованих даних у байти. Ви побачите, що він використовується, коли: Кодування транзакцій перед підписанням. Випромінювання або аналіз подій з блокчейну. Взаємодія з Move смарт-контрактами поза ланцюжком за допомогою JavaScript. Але BCS не включає інформацію про тип у байтах. Це означає, що ви повинні знати структуру заздалегідь під час декодування на відміну від форматів, таких як JSON або буфери протоколів, які більше самоописуються. Ключові особливості BCS Немає метаданих типу Серіалізований вихід не містить підказок щодо типів полів. Ви повинні знати, з чим маєте справу, коли декодуєте. Серіалізація, що залежить від замовлення Структури кодуються в точному порядку їх полів. Змініть порядок, і ваша десеріалізація переривається. Ось чому функції peel_* у Move повинні відповідати макету структури 1:1. Загальний тип У структурі типу: struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata, generic: T } Ви можете надійно десеріалізувати лише до мета-поля. Загальні типи псуються з обробкою BCS, тому завжди ставте їх останніми, якщо ви хочете, щоб ваші дані були безпечно розшифровані. Використання BCS в JavaScript Завдяки бібліотеці @mysten /bcs ви можете працювати з BCS в JS як професіонал. npm i @mysten/bcs і основний приклад: import { BCS, getSuiMoveConfig } from "@mysten/bcs"; const bcs = new BCS(getSuiMoveConfig()); const ser = bcs.ser(BCS.U16, 10); console.log(ser.toBytes()); // [0x0a, 0x00] const des = bcs.de(BCS.U16, ser.toBytes()); console.log(des); // 10 Ви також можете серіалізувати вектори та рядки: bcs.ser("vector", [1, 2, 3, 4]); // 04 01 02 03 04 bcs.ser(BCS.STRING, "test string"); // 0b7465737420737472696e67 Реєстрація користувальницьких типів Припустимо, у вас є такі структури переміщення: struct Metadata has drop, copy { name: std::ascii::String } struct BCSObject has drop, copy { id: ID, owner: address, meta: Metadata } Ви можете зареєструвати їх так в JS: bcs.registerStructType("Metadata", { name: BCS.STRING, }); bcs.registerStructType("BCSObject", { id: BCS.ADDRESS, owner: BCS.ADDRESS, meta: "Metadata", }); Приклад серіалізації та десеріалізації Серіалізація JavaScript: const bytes = bcs .ser("BCSObject", { id: "0x0000000000000000000000000000000000000005", owner: "0x000000000000000000000000000000000000000a", meta: { name: "aaa" } }) .toString("hex"); console.log("Hex:", bytes); Вихід може бути: 0x0000000000000000000000000000000000000005000000000000000000000000000000000000000a03616161 Тепер це можна передати в контракт Move або навіть перевірити вручну в Sui CLI. BCS може виглядати низькорівневим і важким на байт, але як тільки ви зрозумієте, як він кодує дані, ви відкриєте глибше розуміння того, як насправді діють смарт-контракти Move — і як безпечно з'єднати позаланцюгові системи on-chain ↔. І якщо ви налагоджуєте байти BCS на Sui Explorer (як наведений нижче): Кодування BCS Бінарна канонічна серіалізація, або BCS, - це формат серіалізації, розроблений в контексті блокчейну Diem, і зараз широко використовується в більшості блокчейнів на основі Move (Sui, Starcoin, Aptos, 0L). BCS використовується не тільки в Move VM, але також використовується для кодування транзакцій та подій, наприклад, серіалізація транзакцій перед підписанням або аналіз даних подій. Знання того, як працює BCS, має вирішальне значення, якщо ви хочете зрозуміти, як Move працює на більш глибокому рівні, і стати експертом Move. Давайте зануримося. Специфікація та властивості BCS Є деякі властивості кодування BCS високого рівня, про які слід пам'ятати, коли ми проходимо решту уроку: BCS - це формат серіалізації даних, де отримані вихідні байти не містять жодної інформації про тип; через це сторона, яка отримує закодовані байти, повинна знати, як десеріалізувати дані У BCS немає структур (оскільки немає типів); структура просто визначає порядок, в якому поля серіалізуються Типи обгортки ігноруються, тому outerType і UnnestedType матимуть однакове представлення BCS: структура OuterType { власник: InnerType } структура innerType { адреса: адреса } структура UnstedType { адреса: адреса } Типи, що містять поля загального типу, можна обробляти до першого поля загального типу. Тож корисною практикою є розміщення поля загального типу останніми, якщо це спеціальний тип, який буде сер/де'd. структура BCSobject має drop, copy { ідентифікатор: Ідентифікатор, власник: адреса, мета: Метадані, загальний: T } У цьому прикладі ми можемо десеріалізувати все аж до мета-поля. Примітивні типи, такі як непідписані int, кодуються у форматі Little Endian Вектор серіалізується як довжина ULEB128 (з максимальною довжиною до u32), за якою слідує вміст вектора. Повну специфікацію BCS можна знайти в сховищі BCS. Використання бібліотеки JavaScript @mysten /bcs Установка Бібліотека, яку вам потрібно буде встановити для цієї частини, є бібліотека @mysten /bcs. Встановити його можна, ввівши в кореневому каталозі проекту вузла: npm і @mysten /bcs Основний приклад Давайте спочатку скористаємося бібліотекою JavaScript для серіалізації та десеріалізації деяких простих типів даних: імпорт {БКС, GETSUIMoveConfig} з "@mysten /bcs «; //ініціалізуйте серіалізатор за допомогою конфігурацій Sui Move за замовчуванням const bcs = новий БКС (getSUIMoveConfig ()); //Визначте деякі типи тестових даних const ціле число = 10; масив const = [1, 2, 3, 4]; const string = «тестовий рядок» //використовувати bcs.ser () для серіалізації даних const ser_integer = bcs.ser (BCS.U16, ціле число); const ser_array = bcs.ser («вектор», масив); const ser_string = bcs.ser (BCS.STRING, рядок); //використовуйте bcs.de () для десеріалізації даних const de_integer = bcs.de (BCS.U16, сер_цілі.тобайт ()); const de_array = bcs.de («вектор», сер_масив.тобайтів ()); const de_string = bcs.de (BCS.STRING, SER_STRING.тобайт ()); Ми можемо ініціалізувати екземпляр серіалізатора за допомогою вбудованого налаштування за замовчуванням для Sui Move, використовуючи наведений вище синтаксис, new BCS (getSUIMoveConfig ()). Є вбудовані ENUM, які можна використовувати для типів Sui Move, таких як BCS.U16, BCS.STRING тощо. Для загальних типів його можна визначити за допомогою того самого синтаксису, що і в Sui Move, як вектор у наведеному вище прикладі. Давайте уважно розглянемо серіалізовані та десеріалізовані поля: int — це маленькі ендіанські шістнадцятимельні числа 0а00 10 перший елемент вектора вказує на загальну довжину, тоді це просто будь-які елементи у векторі 401020304 1,2,3,4 рядки - це просто вектори u8, при цьому перший елемент дорівнює довжині рядка 0б7465737420737472696е67 тестовий рядок Тип реєстрації Ми можемо зареєструвати власні типи, з якими ми будемо працювати, використовуючи наступний синтаксис: імпорт {БКС, GETSUIMoveConfig} з "@mysten /bcs «; const bcs = новий БКС (getSUIMoveConfig ()); //Зареєструвати тип метаданих bcs.registerStructType («Метадані», { ім'я: БЦ.СТРИНГ, }); //Те саме для основного об'єкта, який ми маємо намір прочитати BCS.RegisterStructType («BCSobject», { //BCS.ADDRESS використовується для типів ідентифікаторів, а також типів адрес ідентифікатор: BCS.АДРЕСА, власник: БЦ.АДРЕСА, meta: «Метадані», }); Використання bcs у смарт-контрактах Sui Продовжимо наш приклад зверху зі структурами. Визначення структури Почнемо з відповідних визначень структури в контракті Sui Move. { //.. Struct Метадані мають drop, copy { ім'я: std: :ascii: :Рядок } структура BCSobject має drop, copy { ідентифікатор: Ідентифікатор, власник: адреса, meta: Метадані } //.. } Десеріалізація Тепер давайте напишемо функцію для десеріалізації об'єкта в контракті Sui. загальнодоступний цікавий об'єктзбайтів (bcs_байтів: вектор): BCSObject { //Ініціалізує екземпляр байтів bcs нехай bcs = bcs: :новий (bcs_байт); //Використовуйте peel_*функції для видалення значень із серіалізованих байтів. //Порядок повинен бути таким же, як ми використовували в серіалізації! let (ідентифікатор, власник, мета) = ( bcs:: адресавилучення (& мут bcs), bcs:: адресавідклеювання (& мут bcs), bcs:: peel_vec_u8 (& мут bcs) ); //Упакуйте структуру BCSObject з результатами серіалізації BCSObject {id: об'єкт: :id_з_адреси (id), власник, мета: Метадані {ім'я: std: :ascii: :рядок (мета)}}} Методи peel_*, що варіюються в модулі Sui Frame bcs, використовуються для «очищення» кожного окремого поля з серіалізованих байтів BCS. Зверніть увагу, що порядок, яким ми очищаємо поля, повинен бути точно таким же, як порядок полів у визначенні struct. Тест: Чому результати не однакові з перших двох викликів peel_address на одному об'єкті bcs? Також зверніть увагу на те, як ми перетворюємо типи з адреси в id, а з вектора в std: :ascii: :string за допомогою допоміжних функцій. Тест: Що станеться, якби BSCobject мав тип UID замість типу ідентифікатора? Повний приклад Ser/De Знайдіть повні зразки кодів JavaScript та Sui Move у папці example_projects. Спочатку серіалізуємо тестовий об'єкт за допомогою програми JavaScript: //Будуємо тестовий об'єкт для серіалізації, зауважте, що ми можемо вказати формат виводу на hex нехай _байтів = bcs .ser («BCSObject», { ідентифікатор: «0x00000000000000000000000000000000000000000005», власник: «0x0000000000000000000000000000000000000000000а», мета: {ім'я: «ааа"} }) .toString («шестигранник»); Ми хочемо, щоб вихід запису BCS цього разу був у шістнадцятковому фо��маті, який можна вказати, як вище. Прикріпіть шестирядку результату серіалізації префіксом 0x та експортуйте до змінної середовища: експортувати об'єкт_HexString = 0x000000000000000000000000000000000000000000000000000500000000000000000000000000000000000000000000000А03616161 Тепер ми можемо або запустити пов'язані тести Move unit, щоб перевірити правильність: тест на самостійний рух Ви повинні побачити це в консолі: БУДІВНИЦТВО bcs_move Запуск тестів Move unit [ПРОПУСК] 0x0: :bcs_object: :тест_десеріалізація Результат тесту: ОК. Всього тестів: 1; пройдено: 1; не вдалося: 0 Або ми можемо опублікувати модуль (і експортувати PACKAGE_ID) і викликати метод emit_object за допомогою наведеного вище BCS серіалізованого шестирядка: власний виклик клієнта --функція emit_object --модуль bcs_object --package $PACKAGE_ID --аргс $OBJECT_HEXSTRING Потім ми можемо перевірити вкладку Події транзакції на Sui Explorer, щоб побачити, що ми випустили правильно десеріалізований BCSObject:

Vens.sui134

May 29, 2025

Стаття

У травні 2025 року світ DeFi був похитнутий одним із найзначніших порушень безпеки в новітній історії. Протокол Cetus, провідна децентралізована біржа (DEX) та протокол ліквідності на блокчейні Sui, став жертвою складного злому, який призвів до втрат, що перевищує 200 мільйонів доларів. Цей інцидент не тільки викликав шокові хвилі через спільноту DeFi, але й викликав серйозні занепокоєння щодо безпеки смарт-контрактів та надійності протоколів, побудованих на нових блокчейнах, таких як Sui. Протокол Cetus зарекомендував себе як провідний DEX у мережі Sui, пропонуючи користувачам платформу для обміну токенами та забезпечення ліквідності. Як ключовий компонент інфраструктури в екосистемі Sui, Cetus відіграв вирішальну роль у полегшенні децентралізованої торгівлі та сприянні загальній ліквідності мережі. Його популярність зробила його привабливою мішенню для зловмисників, які прагнуть використовувати вразливості у своїй кодовій базі. Розгортається хак Cetus Порушення сталося 22 травня 2025 року, коли зловмисники виявили та використали критичний недолік логіки смарт-контрактів Cetus. Зокрема, вразливість випливає з тонкої помилки арифметичного переповнення, яка дозволила хакеру маніпулювати внутрішніми механізмами обліку протоколу. Розгортаючи підроблені токени та маніпулюючи кривими цін у пулах ліквідності, зловмисник зміг вичерпати величезну кількість коштів, не запускаючи системи негайного виявлення. Приблизно о 3:52 ранку за тихоокеанським часом (11:52 UTC) блокчейн-монітори почали виявляти нерегулярні транзакції в кількох пулах ліквідності на Cetus. Протягом кількох годин масштаб збитку став зрозумілим - активи на суму понад 260 мільйонів доларів були вилучені з протоколу. Вкрадені кошти були швидко обмінені та переведені до інших блокчейнів, що ускладнило зусилля з відновленн��. Вплив на ринок та екосистему Sui Наслідки злому були швидкими та серйозними. Торгівля на Cetus була негайно припинена, оскільки розробники намагалися оцінити ситуацію та пом'якшити подальші втрати. Тим часом вартість нативних токенів, пов'язаних з платформою, різко впала, причому деякі зазнали падіння до 80% за лічені години. Інвестори та користувачі зіткнулися з величезними втратами, а довіра до екосистеми Суй похитнулася. Одна особливо тривожна подія сталася, коли мережа Sui спробувала суперечливого контрзаходу: голосування за заморожування гаманця зловмисника, що містить 160 мільйонів доларів викрадених коштів. Хоча цей крок продемонстрував активний підхід до відновлення активів, він також викликав дискусії про принципи децентралізації та про те, чи підривають такі дії довіру до незмінності транзакцій блокчейну. З часом $SUI втратив 5%, а $ CETUS +- 40%, цей стрибок був і неймовірним, і жахливим. Технічні деталі експлуатації протоколу Cetus Згідно з аналізом, наданим фірмою з кібербезпеки Halborn, першопричина експлойту полягала в тому, як Cetus підтвердив певні арифметичні операції під час обміну токенами. Недолік у обробці великої кількості призвів до стану переповнення, яким зловмисник спритно маніпулював, щоб створити штучний дисбаланс у пулах ліквідності. Потім ці дисбаланси були використані для вилучення реальних активів із системи без належної компенсації постачальникам ліквідності. Цей тип вразливості є особливо підступним, оскільки він не завжди проявляється в нормальних умовах роботи; натомість для запуску потрібні конкретні крайові випадки, що включають дуже великі значення або незвичайні послідовності транзакцій. Такі помилки, як відомо, важко виявити під час стандартних аудитів та етапів тестування, що робить їх основними кандидатами для експлуатації противниками з хорошими ресурсами. Зусилля з реагування та відновлення Фонду Cetus та Sui (він же Mysten Labs) Під час нападу близько 160 мільйонів доларів, як повідомляється, були заморожені і будуть повернуті в пули Cetus. Ось чому весь фонд Суй ініціював голосування за розморожування цих токенів. Після нападу команда Cetus опублікувала публічні заяви, визнаючи порушення та окреслили кроки до вирішення. Вони тісно співпрацювали з блокчейн-аналітичними фірмами, такими як Elliptic і Chainalysis, щоб відстежувати рух вкрадених коштів та визначити потенційні шляхи відновлення. Крім того, виникли дискусії щодо впровадження аварійних оновлень для виправлення існуючих вразливостей та підвищення майбутньої стійкості до подібних атак. Члени громади висловили неоднозначну реакцію на ці події. Хоча багато хто високо оцінив прозорість, яку показало керівництво Cetus після злому, інші критикували відсутність готовності до таких сценаріїв та ставили під сумнів, чи були введені достатні гарантії до запуску.

HaGiang144

May 25, 2025

Стаття

Тому що прозорість не повинна означати відмову від своїх секретів. На більшості публічних блокчейнів сьогодні кожна транзакція та ідентичність користувача є загальнодоступними. Хоча прозорість є однією з найбільших сильних сторін блокчейну, вона коштує конфіденційності, особливо коли мова йде про аутентифікацію. zKAT скорочення від автентифікаторів з нульовим знанням — це новий криптографічний примітив, який приносить автентифікацію, що зберігає конфіденційність, у світ блокчейнів. За допомогою ZKat користувачі можуть довести, що вони уповноважені здійснювати транзакцію, не розкриваючи правил або політики, що стоять за цією авторизацією. ##Проблема традиційних підходів Попередні спроби конфіденційності при аутентифікації, такі як використанняпорогових підпису, могли приховати лише обмежену інформацію. Наприклад, вони можуть приховати, які користувачі підписали транзакцію, але не багато іншого. Вони також боролися з більш складними політиками автентифікації**(наприклад, комбінації ролей, ідентифікацій або правил). ZKat змінює гру: Підтримкадовільно складноїполітики Дозволяє гнучкі структури, яккомбінації підписів із кількома схемами Зберіганнявсієї політики прихованоювід громадськості ##Як працює ZKat Для створення zKat автори розробиликомпілятор, який перетворює широко використовувану системуGroth16Zk-SNARK у новий тип доказуНеінтерактивного нульового знання (NIZK) - той, який підтримуєеквівалентні ключі верифікації. Що це означає? Це означає, що верифікаторне може розповіти, яка політика використовується, але доказ все ще переконує їх у тому, що вона дійсна. Це абсолютно нова криптографічна властивість, представлена в статті, і це основа того, як ZKat забезпечуєконфіденційність політики. Але автори не зупинилися на ZKat. Вони пішли на крок далі зZKAT, версією, яка підтримуєнепомітні оновлення. Коротше кажучи: Видавець політики може оновити політику автентифікації не розкриваючи нічого новего Це надзвичайно потужно в реальних блокчейн-системах, де політика може знадобитися еволюціонувати - подумайте про DAO, що оновлюють правила голосування, або установи, що обертають ключі. Вони також досліджують використаннярекурсивних zk-доказів, щоб зробити ZKat+ масштабованим та придатним для інтеграції з блокчейном. Дослідники реалізували zKAT в прототип для автентифікації на основі порогових показників. Їх оцінка показує: Продуктивність нарівні з традиційними пороговими підписами ZKat підтримуєнабагато складнішу політику Все це, змінімальними витратами

0xduckmove288

May 19, 2025

Стаття

(p/s: Не одне з тих «оновлень web3», які дають вам 3 рядки пуху і називають це альфа 😮‍💨) Читати статтю повністю: https://x.com/InternSui81687/status/1897309368644985108 Ви коли-небудь переміщуєте активи між ланцюгами і відчуваєте, що ви Індіана Джонс ухиляється від пасток? Так. Це тому, що взаємодія зараз = ризиковані мости + центральні точки відмови. Іка каже: «Ні, ми з цим закінчили». Вони створюють систему, яка не надійна, швидка автофокусування і нікому не дає ключі. Побудований на Sui, він використовує порогове шифрування та 2PC-MPC У відео тут Девід Леш (співзасновник Ika) прямо говорить про те, що думають усі: сумісність порушена AF. І замість того, щоб писати ще один блог «нам потрібно рішення», як це роблять більшість команд, вони витратили два роки залучивши експертів з безпеки, ботаніків AI та науковців, щоб насправді створити його. Що вони придумали? Система, що використовує 2PC MPC та порогове шифрування — химерні слова, які в основному означають: ваші ключі залишаються вашими, ваші активи не перегортаються, як різдвяний подарунок 2017 року, і все рухається швидко. Мовляв, Іка не просто захищає ваші речі. Він розриває транзакції з затримкою менше секунди і все ще залишається децентралізованим. Тим часом мости тут займають 8 хвилин, а ваша душа просто підтверджує обмін. Вони побудували це на Суї. І якщо ви спали на Суї досі, ця дрімота закінчилася. Об'єктно-центрична модель Суї, блискуча фінальність та консенсус Mysticeti (так, це річ, ні, це не вигадано) ідеально підходять для того, що намагається зробити Іка. Девід навіть сказав, що досвід розробників Суй зробив це очевидним вибором — що є рідкісною похвалою в криптовалюті, де кожен інструмент розробників відчувається як стародавній сувій. Але те, що мене справді вразило, - це їхнє ставлення до UX. Найкраща криптовалюта? Той, який нудний. Не в поганому сенсі, але «це просто працює». Іка шукає майбутнє, де ти навіть не знаєш, що робиш крос-ланцюгові речі. Ні спливаючих вікон, ні мостів, ні підроблених токенів. Просто відкрийте свій гаманець, позичайте BTC на власному рівні, зробіть обмін між ланцюгами та зберігайте вібін. Це те, про що ми просили і якось забули вимагати. І не думайте, що це лише для Degen Bros. Ika дозволяє DAO, інді-командам та компаніям впроваджувати власні рішення щодо зберігання - подумайте про «стартовий пакет Fireblocks», але на стероїдах і насправді доступний. Вам більше не потрібна настройка в розмірі 500 тисяч доларів, щоб створити безпечну інфраструктуру. Просто Суй, Іка і трохи мужності. О, і давайте не будемо спати на біткойн. BTC роками сидить осторонь, як той чувак, який відмовляється приєднатися до гри. Але Іка робить його доступним для гри. DeFi без обгортання, без переміщення — просто заблокуйте його як рідну заставу та йдіть. Установам це сподобається, тому що це робить їх відповідними та ефективними. Ніяких податкових FUD, ніяких пасток зберігання. Просто капітал тече чисто. Тож якщо хтось запитає вас: «Що далі для криптовалюти?» не надсилайте їм тему твіту з написом «Суперсумісність - це майбутнє»

RogueRig134

May 13, 2025

Стаття

@ikadotxyz, надшвидка паралельна мережа MPC на блокчейні Sui, викликає серйозний кайф за свій потенціал революції в безпеці та сумісності Web3. Останні публікації на X підкреслюють бичачі настрої, оскільки, як повідомляється, IKA торгується між 4.90 і $10 на передмаркетних платформах, таких як Whales, незважаючи на пропозицію токенів 1 мільярда. Це свідчить про можливу ринкову капіталізацію в мільярди, якщо імпульс збережеться, що підживлюється стратегічними інвестиціями в 21 мільйон доларів від Фонду Sui та рекордною мистецькою кампанією SUI NFT 1,4 млн. Затримка на менше секунди та здатність Ika масштабуватися на сотнях вузлів підписантів роблять її зміною для DeFi, децентралізованого зберігання та крос-ланцюгових додатків. Очікується, що майбутній запуск токена IKA на Sui розблокує нову утиліту, що призведе до подальшого впровадження. Користувачі X схвильовані роллю IKA в програмі лояльності @GiveRep, і деякі називають це однією з найбільших можливостей для airdrop на Sui. Тим не менш, передринкові ціни можуть бути мінливими та спекулятивними, тому діапазон 4.90—10 доларів не гарантовано збережеться після запуску. Завжди вивчайте основи проекту - перевірте офіційні канали Іки, щоб отримати більш глибокі уявлення, і зважуйте ризики, перш ніж приступити до цього. Екосистема Sui нагрівається, але ніщо не є впевненою ставкою в криптовалюті

Rogue129

May 13, 2025

Стаття

Щоб налаштувати вузол Sui, вам потрібно встановити бінарні файли Sui, клонувати сховище Sui та налаштувати вузол. Ви можете збирати з вихідного коду або використовувати Docker. Після запуску вузла можна стежити за його станом і прогресом синхронізації. Детальні кроки: Встановіть бінарні файли Sui: Дотримуйтесь інструкцій у документації Sui, щоб встановити бінарні файли Sui. Якщо ви використовуєте Docker, дотримуйтесь інструкцій у повному вузлі Docker Readme. Якщо ви створюєте з джерела, вам потрібно буде клонувати репозиторій Sui та компілювати його. Налаштуйте вузол: Повний вузол: Ви можете налаштувати вузол Sui Full за допомогою Docker або шляхом побудови з джерела, відповідно до документації Sui. Вузол валідатора: дотримуйтесь інструкцій у конфігурації вузла Sui Validator, щоб налаштувати вершину валідатора. Це включає встановлення та налаштування Sui, управління ключами та конфігурацію сховища. Повна конфігурація вузла: Вимкніть будь-який запущений повний вузол. Видаліть базу даних і файл genesis.blob. Отримати джерело з останнього випуску. Скиньте свою гілку. Завантажте останню блоб генезису. Оновіть файл конфігурації fullnode.yaml, якщо потрібно. Перезапустіть вузол Sui Full. Запустіть вузол: Запустіть вузол Sui, використовуючи відповідну команду для вашого методу конфігурації (наприклад, команди sui-node або Docker). Контролюйте вузол: Слідкуйте за станом вашого вузла, прогресом синхронізації та журналами, щоб переконатися, що він працює належним чином. Використовуйте такі інструменти, як ведення журналу, трасування та метрики для моніторингу вузла. Порт метрик за замовчуванням - 9184, але ви можете змінити його у файлі fullnode.yaml. Додаткові кроки: Реєстрація комітету: Якщо ви керуєте вузлом валідатора, вам потрібно зареєструватися в комітеті. Рідкий стейкінг: Якщо ви запускаєте вузол, ви також можете брати участь у ліквідному стейкінгу. Синхронізуйте форк: якщо ви робите внесок у проект Sui, вам потрібно буде синхронізувати форк з основним сховищем. Виконавши ці дії, ви можете успішно налаштувати та запустити вузол Sui.

HaGiang144

May 12, 2025

Стаття

У дослідженні світу Web3, поза загальним прагненням до швидших швидкостей транзакцій та менших комісій, все більше виникають глибші структурні проблеми. Як можна економно зберігати величезні обсяги даних? Як можна надійно захистити конфіденційну інформацію в децентралізованому середовищі? Чи можна ефективно виконувати складні обчислення поза ланцюгом, зберігаючи їх результати перевіреними та довіреними в ланцюжку? Багато проектів намагаються вирішити ці проблеми, поєднуючи різні сторонні сервіси. Однак цей шлях часто приносить із собою складність інтеграції, потенційне тертя щодо довіри та фрагментований досвід користувача. Зіткнувшись із цими проблемами на рівні інфраструктури, блокчейн Sui та його основна команда розробників Mysten Labs запропонували більш інтегроване рішення. Замість того, щоб покладатися на клаптик зовнішніх інструментів, вони розробили блокчейн з унікальною архітектурою, включаючи його об'єктно-центричну модель та мову програмування Move, одночасно створюючи тр�� щільно пов'язані компоненти нативної інфраструктури: Walrus, Seal та Nautilus. Ця стаття має на меті розпакувати концепції дизайну, що стоять за цими трьома компонентами, дослідити, як вони працюють, як вони співвідносяться один з одним та які реальні зміни вони можуть внести в додатки Web3. Унікальна архітектура Суй Щоб зрозуміти, як ці три інструменти працюють на Sui, ми повинні спочатку подивитися на деякі ключові характеристики самої платформи Sui. Однією з основних інновацій Sui є його об'єктно-орієнтована модель, фундаментальний зсув від традиційної архітектури на основі облікових записів. Sui розглядає токени, NFT і навіть складні структури даних як окремі «об'єкти». Уявіть, що ви керуєте кожним активом як окремим вікном замість того, щоб записувати все в єдину книгу. Ця конструкція дозволяє паралельно обробляти непов'язані дії, як-от обробку двох не пов'язаних між собою NFT, покращуючи пропускну здатність. Ця деталізація об'єктів створює природну синергію з Walrus and Seal: Walrus розглядає збережені дані як об'єкти, тоді як Seal може прикріплювати правила дозволу безпосередньо до окремих об'єктів. Крім того, Sui використовує мову програмування Move, розроблену спеціально для управління цифровими активами. Move підкреслює безпеку та має на меті зменшити багато поширених уразливостей смарт-контрактів на мовному рівні. Цей міцний фундамент робить його добре придатним для побудови надійних компонентів інфраструктури. Вирівнюючи дизайн ланцюга та розвиток інфраструктури під одним дахом (Mysten Labs), Sui прагне забезпечити більш безперебійний, синергетичний досвід розробників. Морж: економічне, програмоване децентралізоване зберігання Зберігання великих файлів (зображень, відео, моделей штучного інтелекту, які разом називаються блобами) безпосередньо в ланцюжку, як відомо, дорого. Кожне з існуючих децентралізованих рішень для зберігання має компроміси, але Walrus шукає нового балансу між економічною ефективністю та інтерактивністю смарт-контрактів, безпосередньо вирішуючи бар'єри витрат масштабних ланцюгових даних. В основі Walrus лежить кодування Erasure, розумна техніка, яка «осколює» файл і додає «підказки відновлення», щоб файл можна було реконструювати, навіть якщо частини втрачені. Морж називає ці зайві фрагменти «Червоною штучкою». Подумайте про це так: якщо у вас є два числа, скажімо, 3 і 5, і ви зберігаєте обидва, а також їх суму (8), втрата 3 не є катастрофічною - ви можете відновити її, використовуючи 8 - 5 = 3. Аналогічну роль відіграють додаткові фрагменти відновлення, математично прив'язані до оригіналів. Після фрагментації та кодування Морж розподіляє ці осколки по багатьох вузлах. Навіть якщо деякі фрагменти відсутні, система може реконструювати вихідний файл до тих пір, поки буде отримано порогову кількість фрагментів, що заощаджує значний простір порівняно з повною реплікацією файлу. Такий підхід різко знижує витрати на зберігання даних і може наблизити ціни на децентралізовані сховища до цін на централізовані хмарні постачальники. Ще цікавіше, Walrus використовує об'єктну модель Суї: кожен збережений файл стає програмованим об'єктом на ланцюзі. Розробники можуть використовувати Move для написання смарт-контрактів, які керують цими об'єктами зберігання, встановлюючи правила доступу, автоматичне оновлення метаданих тощо. Сховище більше не просто пасивне, воно стає власним програмованим ресурсом. Існує також рівень утиліти токенів: взаємодія з даними Walrus на Sui вимагає токенів SUI для запису метаданих (таких як імена файлів, розміри, місця зберігання) та потенційно блокування токенів для плати за зберігання. Якщо прийняття моржів зросте, попит на SUI може зрости, посилюючи пропозицію. Печатка: Децентралізований сховище та охоронець доступу Багато додатків Web3 мають справу з конфіденційними даними: ідентифікатори користувачів, фінансові дані, вміст платних стін. Як у децентралізованому контексті безпечно зберігати секрети та контролювати доступ до них? Seal - це рішення з децентралізованого управління секретами (DSM), призначене для відповіді на це питання. Однією з його основних технологій є порогове шифрування. Уявіть собі сховище, для відкриття якого потрібно два ключі, кожен з яких тримає інша людина. Аналогічно, порогове шифрування розділяє ключі дешифрування на кілька частин і розподіляє їх на незалежні сервери ключів. Тільки тоді, коли попередньо визначена кількість з них співпрацює (поріг), дані можна розшифрувати - жоден сервер не може зробити це самостійно, що поширює довіру та підвищує стійкість до помилок. Інша розумна особливість Seal полягає в тому, що логіка контролю доступу пишеться як Move смарт-контракти в ланцюжку. Розробники можуть визначити чіткі правила: наприклад, доступ до певних даних можуть лише користувачі, які мають певний NFT або які заплатили плату. Така прозорість і перевірка відрізняє Seal від традиційних систем централізованого доступу. Коли користувач або додаток хоче розшифрувати секрет, він надсилає запит на ключові сервери. Ці сервери перевіряють правила ланцюга. Тільки при дотриманні умов вони випускають свої ключові фрагменти. Фактична розшифровка відбувається на клієнтському пристрої, тому ключові сервери ніколи не торкаються вихідних даних. Seal може захистити дані, що зберігаються в будь-якому місці - у Walrus, інших децентралізованих мережах або навіть централізованих хмарах. Це робить його ідеальним для безпечних повідомлень, приватних даних користувачів, платного вмісту, конфіденційного голосування тощо. Nautilus: Зробити позаланцюгові обчислення перевіреними в ланцюжку Блокчейни не чудово справляються зі складними або ресурсомісткими завданнями. Робити це в мережі повільно, дорого і ставить під загрозу конфіденційність. Такі рішення, як Layer 2s або оракули, допомагають, але Nautilus досліджує інший шлях: забезпечує надійні позаланцюгові обчислення. Nautilus використовує апаратне рішення під назвою Довірені середовища виконання (TEE). Подумайте про TEE як про безпечну, ізольовану зону всередині процесора. Код і дані всередині цієї зони захищені від решти системи, включаючи саму операційну систему. Основний робочий процес виглядає наступним чином: Розробник розгортає обчислювальне завдання (наприклад, фінансові моделі, висновок штучного інтелекту, ігрову логіку) до TEE, яким вони керують. Коли завдання закінчується, TEE виробляє криптографічний сертифікат - своєрідну «квитанцію», захищену від підробки, яка підтверджує: завдання виконано в TEE код не був підроблений процес завершений успішно. Ця атестація та результат подаються до смарт-контракту Move на Sui. Договір перевіряє атестацію (наприклад, дійсність підпису та хеш коду). Тільки якщо перевірка проходить, договір приймає результат і приступає до ланцюгових дій. Nautilus поєднує високопродуктивні позаланцюгові обчислення з можливістю перевірки та довірою в мережі, не розкриваючи конфіденційних деталей. Наутілус в дії: Випадок синьої крилки Конкретним прикладом є Bluefin, децентралізована торгова платформа для безстрокових активів. Більшість високопродуктивних торгових платформ стикаються з дилемою: ведення книг ордерів повністю в ланцюжку забезпечує прозорість, але повільне та дороге; переміщення їх за межі ланцюга покращує швидкість, але створює проблеми довіри. Bluefin використовує Nautilus для подолання цього розриву: • Збіг замовлень проходить всередині TEE, забезпечуючи безпечну, ізольовану обробку. • Nautilus надає криптографічний доказ того, що відповідна логіка працювала правильно. • Докази та результати подаються в ланцюжку, де смарт-контракти перевіряють їх перед виконанням розрахунків. Цей підхід дозволяє Bluefin пропонувати швидке узгодження поза ланцюгом із гарантіями довіри в мережі, що робить його життєздатним для DeFi з високим рівнем продуктивності, як-от торгівлі деривативами. Звичайно, це зміщує певну довіру від чистого консенсусу блокчейну до апаратного забезпечення та впровадження TEE.

HaGiang144

May 01, 2025

Стаття

Що таке кіоск Суй? Kiosk — це вбудований модуль смарт-контрактів на блокчейні Sui, призначений для стандартизації та спрощення способу зберігання, управління та торгівлі NFT. Він діє як програмована вітрина NFT — ідеально підходить для розробників, які хочуть уникнути переосмислення колеса для кожного проекту, пов'язаного з NFT. Незалежно від того, чи створюєте ви ринок, біржу ігрових активів чи галерею цифрових предметів колекціонування, Kiosk пропонує вам безпечні, настроювані будівельні блоки. 🛠️ Основні характеристики кіоску 📦 Зберігання та дисплей NFT: Користувачі можуть депонувати NFT у смарт-контракти Kiosk, щоб зберігати, демонструвати або торгувати ними 🔐 Безпечний перехід власності: Усі потоки купівлі/продажу стандартизовані та перевірені - до побачення тіньові свопи 👋 🎛️ Точні дозволи: Кіоск дозволяє розробникам точно визначати, хто може що робити з кожним NFT. 📈 Розширюваність розробника: аукціони підключення, пакетні списки, пакети тощо. 🤔 Навіщо будувати з кіоском? Уявіть, що ви запускаєте додаток NFT. Ймовірно, вам знадобиться спосіб, щоб користувачі могли безпечно зберігати активи. Спосіб перерахування та покупки активів. Кіоск обробляє все це за вас. Замість того, щоб писати всі ці потоки з нуля (і ризикувати помилками 🐛 або експлойтами), ви використовуєте перевірений у бою API Kiosk. 🧪 Приклад програми: побудова з кіоском Давайте перейдемо до реального прикладу. Ви створите базовий модуль NFT, а потім скористайтеся модулем Kiosk, щоб депонувати його, перелічити його та дозволити іншим придбати його. Покрокова розбивка коду module 0xNFT::simple_nft { use sui::object::{UID}; use sui::tx_context::TxContext; struct SimpleNFT has key { id: UID, name: String, description: String, url: String, } public entry fun mint( name: String, description: String, url: String, ctx: &mut TxContext ): SimpleNFT { SimpleNFT { id: UID::new(ctx), name, description, url, } } } Команди (Sui CLI) Compile your package sui move build Deploy to network sui client publish --gas-budget 10000 Mint NFT sui client call --function mint --module simple_nft \ --args "My NFT" "Desc" "https://example.com/img.png" --gas-budget 1000 Initialize Kiosk sui client call --function init_kiosk --module kiosk_example --gas-budget 1000 Deposit NFT to Kiosk sui client call --function deposit_nft --module kiosk_example \ --args --gas-budget 1000 List for sale sui client call --function list_nft_for_sale --module kiosk_example \ --args 100 --gas-budget 1000 Purchase NFT sui client call --function purchase_nft --module kiosk_example \ --args --gas-budget 1000 Кіоск є одним з найпотужніших примітивів в екосистемі Sui для розробників NFT. Він абстрагує повторювану логіку та вводить безпеку та модульність у ваш стек додатків. За допомогою лише кількох рядків коду ви створюєте повні потоки ринку NFT, які готові до виробництва та перевірені в бою.

MiniBob406

Apr 30, 2025

Стаття

У постійно розвиваючому ландшафті технології блокчейн мови програмування смарт-контрактів стали основою децентралізованих додатків (dApps). Серед них Move став новаторським нововведенням, пропонуючи унікальні функції, які відрізняють його від традиційних мов, таких як Solidity або Vyper. Розроблений з урахуванням безпеки та масштабованості, Move був створений для усунення багатьох вразливостей та неефективності, властивих попереднім екосистемам блокчейну. У цій статті розглядаються витоки, особливості та вплив мови програмування Move, досліджуючи її шлях від початку до того, щоб стати одним із найперспективніших інструментів для побудови надійних децентралізованих систем. Витоки руху: рішення проблем блокчейну Мова програмування Move була вперше представлена компанією Meta (раніше Facebook) як частина свого амбітного проекту Diem (спочатку називався Libra). Diem мав на меті створити глобальну цифрову валюту та фінансову інфраструктуру, що працює на технології блокчейн. Однак команда швидко зрозуміла, що існуючих мов смарт-контрактів недостатні для їхнього бачення. У традиційних мовах часто не вистачало механізмів запобігання поширеним уразливостям, таким як атаки повторного входу, переповнення цілих чисел та несанкціоноване дублювання ресурсів. Ці проблеми вже завдали значної шкоди іншим екосистемам, особливо сумнозвісному злому DAO на Ethereum. Щоб подолати ці виклики, інженерна команда Meta розробила Move, нову мову, спеціально розроблену для ресурсоорієнтованого програмування. На відміну від звичайних мов програмування, Move розглядає цифрові активи як першокласні ресурси, гарантуючи, що їх не можна дублювати, ненавмисно видаляти або використовувати неправильно. Цей підхід був натхненний лінійною логікою, математичною основою, яка застосовує суворі правила власності на ресурси. Вбудовуючи ці принципи в ядро мови, Move ввів зміну парадигми в тому, як розробники взаємодіють з цифровими активами на блокчейні. Хоча проект Diem в кінцевому підсумку був відкладений через регуляторний контроль, Move знайшов нове життя в незалежних блокчейн-проектах, таких як Aptos і Sui. Ці платформи прийняли Move як свою основну мову смарт-контрактів, визнаючи його потенціал революціонізувати спосіб побудови та захисту децентралізованих додатків. Ключові особливості руху: чому він виділяється 1. Ресурсоорієнтоване програмування Однією з визначальних характеристик Move є його зосередженість на ресурсоорієнтованому програмуванні. У Move цифрові активи, такі як токени, NFT або навіть власні об'єкти, розглядаються як ресурси, які дотримуються суворих правил власності. Після створення ресурс не може бути скопійований або знищений, якщо його модуль прямо не дозволяє. Це гарантує, що критичні операції, пов'язані з активами, такі як перекази або оновлення стану, виконуються безпечно та надійно. Наприклад, розглянемо просту функцію передачі токенів, написану в Move: приклади модулів: :token { використовувати sui: :об'єкт:: {Сам, UID}; використовувати sui: :перенесення; Struct Token має ключ, магазин { ідентифікатор: UID, значення: u64, } публічна весела монета (ctx: & mut txContext, значення: u64): Токен { Токен { ідентифікатор: об'єкт: :новий (ctx), цінність, } } загальнодоступний веселий transfer_token (токен: токен, одержувач: адреса) { переказ: :публічний_переказ (токен, од��ржувач); } } Тут структура являє Token собою ресурс, який можна передати лише за допомогою функції public_transfer. Будь-яка спроба дублювати або маніпулювати маркером поза цією функцією призведе до помилки компіляції. Цей дизайн усуває цілі класи помилок та експлойтів, які зазвичай зустрічаються в інших мовах. 2. Модульність та інкапсуляція Move сприяє модульному дизайну, дозволяючи розробникам інкапсулювати функціональність в автономні модулі. Кожен модуль визначає свої типи, функції та елементи керування доступом, забезпечуючи чіткий поділ між різними компонентами смарт-контракту. Наприклад, розробник може створити окремі модулі для створення токенів, торгових пар та логіки управління. Ця модульність покращує читаність коду, ремонтопридатність та повторне використання. 3. Підтримка офіційної перевірки Ще однією особливістю Move є підтримка формальної перевірки, процесу, який використовується для математичного доведення правильності програми. Формальна перевірка допомагає виявити тонкі помилки та крайні випадки, які не можуть бути виявлені традиційними методами тестування. Хоча не всі проекти на основі MOVE вимагають формальної перевірки, структура мови полегшує застосування цієї техніки, коли це необхідно. 4. Об'єктно-орієнтоване проектування (вдосконалення, специфічні для SUI) На блокчейні Sui Move був додатково вдосконалений за допомогою об'єктно-орієнтованої моделі. Кожен ресурс у Sui Move має глобально унікальний ідентифікатор (UID), що дозволяє пряме посилання та взаємодію з об'єктами. Ця конструкція спрощує складні робочі процеси, такі як управління NFT або відстеження специфічних для користувача даних, зберігаючи високу продуктивність та масштабованість. Реальні програми Move З моменту прийняття Aptos та Sui Move використовувався для створення широкого спектру децентралізованих додатків. Деякі помітні приклади включають: 1. Протоколи децентралізованих фінансів (DeFi) Сильний акцент Move на безпеці робить його ідеальним для додатків DeFi, де на кону поставлені активи вартістю мільярди доларів. Такі проекти, як Cetus - децентралізована біржа (DEX), побудована на SUI - використовують ресурсоорієнтоване програмування Move для впровадження передових торгових функцій, мінімізуючи ризики, пов'язані з маніпуляцією активами. 2. Незамінні токени (NFT) Маркетплейси NFT мають велику користь від здатності Move визначати та керувати унікальними цифровими активами. Розробники можуть створювати складні стандарти NFT з детальним контролем над власністю, роялті та метаданими. Крім того, об'єктно-орієнтовані вдосконалення Sui дозволяють безперебійно інтегрувати динамічні NFT, які можуть розвиватися на основі заздалегідь визначених умов. 3. Ігрові та метавсесвітні платформи Ігри на блокчейн вимагають ефективного поводження з ігровими активами, взаємодії з гравцями та оновлень у режимі реального часу. Модульна архітектура Move та виконання з низькою затримкою роблять його добре придатним для створення захоплюючих ігрових вражень. Такі платформи, як Blockus, ігрова екосистема Web3, використовують Move для живлення своїх децентралізованих ігор та економіки. Порівняння переходу з іншими мовами смарт-контрактів Хоча Move має деякі подібності з іншими мовами смарт-контрактів, його унікальні функції надають йому конкурентну перевагу: Солідність: як основна мова Ethereum, Solidity широко прийнята, але страждає від застарілих проблем, таких як вразливість до атак повторного вступу. Move вирішує ці слабкі місця за допомогою своєї ресурсоорієнтованої моделі та більш суворої безпеки типу. Rust (використовується в Solana): Rust пропонує чудову продуктивність та безпеку пам'яті, але не має вбудованої підтримки Move для управління ресурсами та офіційної перевірки. Крім того, крута крива навчання Rust може стримувати новачків порівняно з більш інтуїтивно зрозумілим синтаксисом Move. Чіткість (використовується в стеках): Clarity підкреслює прозорість та передбачуваність, але діє в обмеженому обсязі, пов'язаному з екосистемою Bitcoin. Move, з іншого боку, підтримує більш широкі випадки використання в декількох блокчейнях. Майбутнє руху: прийняття та еволюція Оскільки технологія блокчейну продовжує дозрівати, попит на безпечні та масштабовані мови смарт-контрактів буде тільки зростати. Move готовий зіграти ключову роль у формуванні наступного покоління децентралізованих додатків завдяки своєму інноваційному дизайну та зростаючій підтримці спільноти. Такі проекти, як Aptos і Sui, активно інвестують у освіту розробників, інструменти та інфраструктуру, щоб прискорити впровадження Move. Такі ініціативи, як платформа Move eLearning, надають вичерпні навчальні посібники та ресурси для початківців розробників, знижуючи бар'єр для входу. Крім того, співпраця з академічними установами та лідерами галузі сприяє дослідженню передових тем, таких як офіційна перевірка та міжланцюгова взаємодія. Зважаючи на майбутнє, ми можемо очікувати, що Move розшириться за межі поточних випадків використання, забезпечуючи все, від рішень корпоративного рівня для ланцюгів поставок до децентралізованих соціальних мереж. Його адаптивність та надійність гарантують, що він залишається актуальним у все більш різноманітній та взаємопов'язаній екосистемі блокчейну.