Технологія Ontology Wasm знижує вартість перенесення смарт контрактів dApp зі складною бізнес-логікою на блокчейн, що значно збагачує dApp екосистему.
В даний час одночасно підтримує розробку як мовою Rust, і мовою C++. Мова Rust краще підтримує Wasm, а байт-код, що згенерував, простіше, що може ще більше знизити вартість контрактних викликів. Отже, як використовувати Rust для розробки контракту у мережі Ontology?
Розробка WASM - контракту за допомогою Rust
Створення контракту
- Це хороший інструмент створення проектів та управління пакетами при розробці програм на Rust, який допомагає розробникам краще організовувати взаємодію коду та сторонніх бібліотек. Щоб створити новий Ontology Wasm-контракт, просто виконайте наступну команду:
Структура проекту, яку вона генерує:
Файл Cargo.toml використовується для налаштування базової інформації проекту та інформації залежної бібліотеки. Секція [lib] у файлі мусить бути встановленої значення crate-type = [“cdylib”]. Файл lib.rs використовується для написання коду логіки контракту. На додаток, Вам необхідно додати параметри залежностей до розділу [dependencies] файлу конфігурації Cargo.toml:
За допомогою цієї залежності розробники можуть викликати інтерфейси, які взаємодіють із блокчейном Ontology, та інструменти такі, як параметр серіалізації.
Функція введення договору
Кожна програма має функцію введення, наприклад main- функція, яку ми зазвичай бачимо, але контракт не має main- функції. Коли розробляється Wasm-контракт з допомогою Rust, то функція invoke за умовчанням використовується як функція введення використання контракту. Ім'я функції Rust буде неясним при компіляції вихідного коду Rust в байт-код, який може виконувати віртуальна машина. Щоб попередити компілятор від генерування надлишкового коду та скоротити розмір контракту, функція invoke додає інструкцію #[no_mangle].
Як функція invoke отримує параметри для транзакції?
Бібліотека ontio_std надає функцію runtime::input(), щоб отримати параметри для виконання транзакції. Розробники можуть використовувати ZeroCopySource для десеріалізації отриманого масиву байтів. У якому перший лічений масив байтів - це ім'я invoke-методу, далі параметри методу.
Як повертається результат виконання контракту?
Функція runtime::ret, яка надається бібліотекою ontio_std, повертає результат виконання методу.
Закінчена invoke-функція виглядає так:
Серіалізація та десеріалізація даних контракту
У процесі розробки контрактів розробники завжди наштовхуються на проблеми серіалізації та десеріалізації, а саме з тим, як зберегти struct-тип даних у базу даних і як масив байтів, зчитаний з бази даних, десеріалізувати, щоб отримати struct-тип даних.
Бібліотека ontio_std надає інтерфейси декодера та кодера для серіалізації та десеріалізації даних. Поля структури struct також реалізують інтерфейси декодера та кодера, так що структура може бути серіалізована та десеріалізована. Примірники класу Sink необхідні, коли серіалізуються різні типи даних. Примірник класу Sink має set-тип поле buf, яке зберігає байт тип дані, проте серіалізовані дані зберігаються в buf.
Для даних з фіксованою довжиною (наприклад: byte, u16, u32, u64 і т.д.) дані безпосередньо перетворюються на масив байтів і потім зберігаються в buf; для даних нефіксованої довжини спочатку потрібно серіалізувати довжину, а потім Ddata (наприклад, цілі числа без знака невідомого розміру, включаючи u16, u32 або u64 і т. д.).
Десеріалізація є прямою протилежністю. До кожного методу серіалізації є відповідний метод десеріалізації. Десеріалізація потребує використання екземплярів класу Source. Цей екземпляр класу має два поля buf та pos. Buf використовується для зберігання даних, які будуть десеріалізовані, а pos використовується для зберігання поточної позиції зчитування. Коли зчитується конкретний тип даних, якщо ви знаєте їх довжину, ви можете зчитувати їх безпосередньо, для даних невідомої довжини - спочатку рахуйте довжину, а потім рахуйте вміст.
Доступ та оновлення даних у ланцюжку
Ontology-wasm-cdt-rust — інкапсулював операційний метод роботи з даними в ланцюзі, який зручний для розробників, щоб реалізовувати такі операції, як додавання, видалення, зміна і запитування даних у ланцюзі наступним чином:
- database::get(key) - використовується, щоб запитати дані з ланцюга, а key запитує реалізацію інтерфейсу AsRef;
- database::put(key, value) — використовується для збереження даних у мережі. Key вимагає виконання інтерфейсу AsRef, а value запитує реалізацію інтерфейсу Encoder;
- database::delete(key) - використовується, щоб видалити дані з ланцюжка, а key запитує реалізацію інтерфейсу AsRef.
Тестування контракту
Коли реалізуються методи контракту, нам потрібен доступ до даних у ланцюгу і нам потрібна відповідна віртуальна машина, щоб виконати байткод контракту, тому зазвичай необхідно розгорнути контракт у ланцюгу для тестування. Але такий метод тестування є проблематичним. Щоб зробити легше для розробників тестування контрактів, ontio_std бібліотека надає mock-модуль для тестування. Цей модуль забезпечує симуляцію даних у ланцюгу, роблячи легше розробників юнит- тестування методів у контракті. Конкретні приклади можна знайти .
Налагодження контракту
console::debug(msg) виводить налагоджувальну інформацію під час налагодження контракту. Інформація msg буде внесена в лог-файл ноди. Обов'язковою умовою є встановлення рівня лог-файла в режим налагодження, коли запущена локальна тест-нода Ontology.
runtime::notify(msg) виводить відповідну налагоджувальну інформацію під час налагодження контракту. Цей метод зберігатиме внесену інформацію в ланцюг і може бути запрошений з ланцюга за допомогою методу getSmartCodeEvent.
Статтю було переведено редакцією Hashrate&Shares спеціально для OntologyRussia.
Ви розробник? Приєднуйтесь до нашої технічної спільноти на . Крім того, загляньте в на нашому сайті, там ви можете знайти інструменти розробника, документацію та багато іншого.
Онтологія
- /
- Telegram /
- /
Джерело: habr.com