🚨Тепер доступний RGB 0.12 RC1 За 2 роки відстеження протоколу RGB це був, мабуть, найцікавіший момент Всього 14 годин тому на github RGB-WG Максим нарешті анонсував версію RC1, яка буде найстабільнішою версією RGB, а також запропонував всім RGB-розробникам якнайшвидше перейти на останню версію, і настає наступна глава екосистеми BTC Давайте зануримося в 👇 🧵 ———————— 🔶 Спрощення протоколу Цього разу зміни в основному стосуються рівня консенсусу, оскільки нова архітектура вперше представила zk-AluVM, компактну, високопродуктивну віртуальну машину Turing-complete zk, призначену для перевірки клієнта Якщо ви мало знаєте про RGB, ви можете подумати, що це найрідніша система смарт-контрактів BTC, звичайно, не тільки BTC, але й усі публічні ланцюжки в режимі UTXO можуть використовувати протокол RGB для завершення смарт-контрактів поза ланцюгом Повернемося до оновлення, в архітектурі також є деякі оптимізації рефакторингу стану контракту + перевірка консенсусу, які тут детально показувати не будемо За даними Github, цього разу v0.12 - 4-кратне зменшення обсягу коду консенсусу і 2-кратне скорочення в стандартній бібліотеці; - зменшити кількість типів даних на 30% в узагальнених параметрах в API 🔶 Держава єдина Мабуть, для звичайних людей найбільш відчутною зміною є уніфікація контрактної держави, яка раніше мала три типи контрактних станів (FT/NFT/інші) і тепер всі вони уніфіковані, і може знадобитися новий шаблон токена (попередній шаблон v0.11 має бути невірним) 🔶 Покращення платежів Тут є кілька основних поліпшень, і я виберу ключові з них 1. Контракти з кількома активами Тепер є можливість включати в контракт кілька сумісних токенів, які можуть бути викликані незалежно або спільно Наприклад, я можу визначити 100 монет + 500 NFT + деякі інші вкладення в контракті (найпростіші) 2. Скрипти оплати Наприклад, CoinJoin/PayJoin з мультипідписом, пакетна обробка транзакцій, робота блискавичного каналу тощо, підтримка принципу «один до багатьох» або «багато-до-одного» 🔶 Оптимізація продуктивності Стара версія даних про партії повинна бути повністю завантажена в пам'ять, версія 0.12 змінена на потокову аутентифікацію, пам'ять займає всього кілька сотень байт, і вона підходить для мобільних/апаратних гаманців Більше писати не буду, і це буде відрізнятися від загального використання | pepper 花椒解盘㊂正EV OKX Feed

🚨Тепер доступний RGB 0.12 RC1 За 2 роки відстеження протоколу RGB це був, мабуть, найцікавіший момент Всього 14 годин тому на github RGB-WG Максим нарешті анонсував версію RC1, яка буде найстабільнішою версією RGB, а також запропонував всім RGB-розробникам якнайшвидше перейти на останню версію, і настає наступна глава екосистеми BTC Давайте зануримося в 👇 🧵 ———————— 🔶 Спрощення протоколу Цього разу зміни в основному стосуються рівня консенсусу, оскільки нова архітектура вперше представила zk-AluVM, компактну, високопродуктивну віртуальну машину Turing-complete zk, призначену для перевірки клієнта Якщо ви мало знаєте про RGB, ви можете подумати, що це найрідніша система смарт-контрактів BTC, звичайно, не тільки BTC, але й усі публічні ланцюжки в режимі UTXO можуть використовувати протокол RGB для завершення смарт-контрактів поза ланцюгом Повернемося до оновлення, в архітектурі також є деякі оптимізації рефакторингу стану контракту + перевірка консенсусу, які тут детально показувати не будемо За даними Github, цього разу v0.12 - 4-кратне зменшення обсягу > коду консенсусу і 2-кратне скорочення в стандартній бібліотеці; - > зменшити кількість типів даних на 30% в узагальнених параметрах в API 🔶 Держава єдина Мабуть, для звичайних людей найбільш відчутною зміною є уніфікація контрактної держави, яка раніше мала три типи контрактних станів (FT/NFT/інші) і тепер всі вони уніфіковані, і може знадобитися новий шаблон токена (попередній шаблон v0.11 має бути невірним) 🔶 Покращення платежів Тут є кілька основних поліпшень, і я виберу ключові з них 1. Контракти з кількома активами Тепер є можливість включати в контракт кілька сумісних токенів, які можуть бути викликані незалежно або спільно Наприклад, я можу визначити 100 монет + 500 NFT + деякі інші вкладення в контракті (найпростіші) 2. Скрипти оплати Наприклад, CoinJoin/PayJoin з мультипідписом, пакетна обробка транзакцій, робота блискавичного каналу тощо, підтримка принципу «один до багатьох» або «багато-до-одного» 🔶 Оптимізація продуктивності Стара версія даних про партії повинна бути повністю завантажена в пам'ять, версія 0.12 змінена на потокову аутентифікацію, пам'ять займає всього кілька сотень байт, і вона підходить для мобільних/апаратних гаманців Більше писати не буду, і це буде відрізнятися від загального використання

19,43 тис.

Вміст на цій сторінці надається третіми сторонами. Якщо не вказано інше, OKX не є автором цитованих статей і не претендує на авторські права на матеріали. Вміст надається виключно з інформаційною метою і не відображає поглядів OKX. Він не є схваленням жодних дій і не має розглядатися як інвестиційна порада або заохочення купувати чи продавати цифрові активи. Короткий виклад вмісту чи інша інформація, створена генеративним ШІ, можуть бути неточними або суперечливими. Прочитайте статтю за посиланням, щоб дізнатися більше. OKX не несе відповідальності за вміст, розміщений на сторонніх сайтах. Утримування цифрових активів, зокрема стейблкоїнів і NFT, пов’язане з високим ризиком, а вартість таких активів може сильно коливатися. Перш ніж торгувати цифровими активами або утримувати їх, ретельно оцініть свій фінансовий стан.