Вчора творець Ordinals Кейсі Родармор опублікував блог, в якому представляє новий протокол замінних маркерів (FT) Runes.
Стосовно того, чи потрібен біткойн FT, Кейсі Родармор заявив у своєму твіті, що FT має дві сторони. З одного боку, 99,99% FT — це «лайно» та шахрайство, що послаблює чистоту біткойна; з іншого боку, вони приносять багато комісійних доходів, розробникам і користувачам в екосистему біткойнів. «Люди люблять токени, і вони схожі на кіберпанк-казино, тому дохід від комісій, ймовірно, буде значним і триватиме, доки занепокоєння щодо бюджетів (кібер)безпеки не будуть повністю розвіяні».
Він додав, що вже з’явилися такі протоколи FT, як BRC-20, RGB і Taproot. Порівняно з простими протоколами в ланцюжку, такі протоколи, як RGB і Taproot, є складними і можуть створювати проблеми для роботи користувача. BRC-20 є дуже простим і може забезпечити хорошу взаємодію з користувачем порівняно з RGB/Taproot, який потребує інфраструктури зберігання та пошуку даних поза ланцюгом; але проблема з токенами BRC 20 полягає в тому, що вони генерують «сміттєвий UTXO» та займають простір для монет.
Rodarmor сказав, що Runes — це протокол на основі UTXO, який більш природним чином підходить для біткойнів і сприяє мінімізації колекцій UTXO, уникаючи створення «сміттєвих UTXO».
Цей вміст взято з допису в блозі Кейсі Родармор і був зібраний Odaily Planet Daily
Я не впевнений, чи є гарною ідеєю створення нового протоколу Fungible Token (FT) для Bitcoin. 99,9% FT – це шахрайство та меми. Однак, здається, вони не зникнуть найближчим часом, як і казино, здається, не зникнуть найближчим часом.
Створення хорошого протоколу FT для біткойнів може принести значний дохід від комісії за транзакції, увагу розробників і користувачів до біткойна. Крім того, якщо протокол має менший слід у ланцюзі та стимулює відповідальне управління UTXO, він може зменшити шкоду порівняно з існуючими протоколами. Наприклад, популярний зараз BRC-20 призвів до генерації великої кількості сміття UTXO.
Якщо ми порівняємо існуючі протоколи FT, то виявимо, що вони мають кілька важливих відмінностей:
Складність: наскільки складним є протокол? Чи легко це реалізувати? Чи легко усиновити?
Взаємодія з користувачем: чи є деталі реалізації, які негативно впливають на взаємодію з користувачем? Зокрема, протоколи, які покладаються на дані поза ланцюгом, мають менший слід у ланцюзі, але створюють значну складність і вимагають від користувачів запуску власних серверів або виявлення існуючих серверів і взаємодії з ними.
Модель стану: протоколи на основі UTXO більш природно вписуються в біткойн і сприяють мінімізації набору UTXO, уникаючи створення «сміттєвих» UTXO.
Власні токени: протоколи з власними токенами, необхідними для роботи протоколу, є громіздкими, їх можна вилучити та, природно, менш широко поширені.
Виходячи з наведених вище параметрів, результати порівняння існуючих протоколів FT в екосистемі Bitcoin є такими:
BRC-20: не базується на UTXO, і досить складний, оскільки вимагає використання порядкової теорії в деяких операціях;
RGB: дуже складний, покладається на дані поза мережею, розроблявся протягом тривалого часу та не був прийнятий;
Контрагент: має рідні токени, необхідні для певних операцій, а не на основі UTXO;
Omni Layer: має рідні токени, необхідні для певних операцій, а не на основі UTXO;
Taproot Assets: дещо складний і покладається на дані поза мережею.
Для біткойна, як би виглядав простий протокол FT на основі UTXO з хорошим користуванням? Далі я хотів би познайомити вас з дуже крутим рішенням під назвою «Руни».
(1 огляд
Баланс рун зберігається в UTXO; UTXO може містити будь-яку кількість рун.
Транзакція містить повідомлення протоколу, якщо вона містить вихідні дані, pubkey сценарію якого містить OP_RETURN, за яким іде надсилання даних R у верхньому регістрі ASCII. Повідомлення протоколу — це всі дані, які надсилаються після першого.
Руни, введені в транзакції з недійсними повідомленнями протоколу, будуть знищені, що дозволить майбутнім оновленням змінити спосіб розподілу або створення рун, уникаючи старіших клієнтів від неправильного розподілу балансу рун.
Цілі числа кодуються як префікс int, де початкова цифра int визначає його довжину в байтах.
(2) Трансфер
Перший імпульс даних у повідомленні протоколу декодується в послідовність цілих чисел.
Ці цілі числа інтерпретуються як послідовність кортежів (ID, OUTPUT, AMOUNT). Якщо кількість декодованих цілих чисел не кратна 3, повідомлення протоколу недійсне.
Ідентифікатор — це числовий ідентифікатор циклу, який буде призначено
OUTPUT — це індекс виходу, який буде призначено
AMOUNT — це кількість прогонів, які мають бути виділені
ID кодується як дельта. Це дозволяє призначати ту саму руну кілька разів, щоб уникнути дублювання повного ідентифікатора руни. Наприклад, кортеж: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Виконайте такі завдання:
ID 100, вихід 1, 20 рун
ID 100, вихід 2, 10 рун
id 120, вихід 1, 5 рун
AMOUNT 0 - це скорочення від "усі руни, що залишилися".
Після обробки всіх призначень кортежу, будь-які непризначені руни призначаються до першого виходу не OP_RETURN (якщо є). Зайві завдання будуть проігноровані.
Руни можна спалити, призначивши їх виводу OP_RETURN, що містить повідомлення протоколу.
(3)Проблема
Якщо повідомлення протоколу має друге надсилання даних, це транзакція проблеми. Другий імпульс даних декодується у два цілі числа, SYMBOL і DECIMALS. Якщо залишити додаткові цілі числа, повідомлення протоколу є недійсним.
Транзакція випуску може створити будь-яку кількість рун випуску, використовуючи ідентифікатор 0 у кортежі призначення, максимум до 2^128 - 1.
SYMBOL — це зрозумілий для людини 26-бітний базовий символ кодування, подібний до символу, що використовується в порядкових іменах sat. Єдині допустимі символи від A до Z.
DECIMALS — це кількість цифр після коми, яку слід використовувати під час відображення виданих рун.
Якщо СИМВОЛ не було призначено, він призначається опублікованій руні, і опублікована руна отримує наступний доступний цифровий ідентифікатор руни (починаючи з 1).
Якщо SYMBOL уже виділено, або це BITCOIN, BTC або XBT, нова руна не буде створена. Виділення транзакцій звільнення з використанням ідентифікатора руни 0 ігноруватиметься, але інші розподіли все одно оброблятимуться.
(4) ПРИМІТКА
Під час відображення балансів UTXO рідний баланс біткойнів UTXO може відображатися з ідентифікатором руни 0 і символами BITCOIN, BTC або XBT.
Щоб зберегти протокол простим, (Runes) не використовує механізм, щоб уникнути присідання символу. Фактично, ефективний і простий спосіб уникнути зв’язування символів полягає в тому, щоб дозволити виділення лише символів понад певної довжини, яка з часом зменшується, а потім досягає нуля та дозволяє використовувати всі символи. Це дозволить уникнути розподілу коротких, ідеальних символів на початку протоколу та заохотити тих, хто запізнюється, конкурувати за ідеальні символи - якщо така конкуренція має сенс.
Написано в кінці
Чи справді це рішення працює на ринку? Я поняття не маю.
Він настільки простий, наскільки це можливо, не покладається на дані поза ланцюгом, не має власних токенів і ідеально вписується в рідну модель UTXO Bitcoin. Така схема могла б залучити користувачів з інших схем із гіршим впливом на ланцюг і звернути увагу розробників і користувачів на біткойн, спонукаючи їх прийняти сам біткойн.
Світ FT, з іншого боку, є абсолютно непоправною прірвою обману та жадібності, тому її можна змити.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Замінити BRC-20, щоб активувати екосистему BTC? Засновник Ordinals пропонує новий протокол Руни
Оригінал | Кейсі Родармор
Складено | Odaily Planet Daily
Вчора творець Ordinals Кейсі Родармор опублікував блог, в якому представляє новий протокол замінних маркерів (FT) Runes.
Стосовно того, чи потрібен біткойн FT, Кейсі Родармор заявив у своєму твіті, що FT має дві сторони. З одного боку, 99,99% FT — це «лайно» та шахрайство, що послаблює чистоту біткойна; з іншого боку, вони приносять багато комісійних доходів, розробникам і користувачам в екосистему біткойнів. «Люди люблять токени, і вони схожі на кіберпанк-казино, тому дохід від комісій, ймовірно, буде значним і триватиме, доки занепокоєння щодо бюджетів (кібер)безпеки не будуть повністю розвіяні».
Він додав, що вже з’явилися такі протоколи FT, як BRC-20, RGB і Taproot. Порівняно з простими протоколами в ланцюжку, такі протоколи, як RGB і Taproot, є складними і можуть створювати проблеми для роботи користувача. BRC-20 є дуже простим і може забезпечити хорошу взаємодію з користувачем порівняно з RGB/Taproot, який потребує інфраструктури зберігання та пошуку даних поза ланцюгом; але проблема з токенами BRC 20 полягає в тому, що вони генерують «сміттєвий UTXO» та займають простір для монет.
Rodarmor сказав, що Runes — це протокол на основі UTXO, який більш природним чином підходить для біткойнів і сприяє мінімізації колекцій UTXO, уникаючи створення «сміттєвих UTXO».
Цей вміст взято з допису в блозі Кейсі Родармор і був зібраний Odaily Planet Daily
Я не впевнений, чи є гарною ідеєю створення нового протоколу Fungible Token (FT) для Bitcoin. 99,9% FT – це шахрайство та меми. Однак, здається, вони не зникнуть найближчим часом, як і казино, здається, не зникнуть найближчим часом.
Створення хорошого протоколу FT для біткойнів може принести значний дохід від комісії за транзакції, увагу розробників і користувачів до біткойна. Крім того, якщо протокол має менший слід у ланцюзі та стимулює відповідальне управління UTXO, він може зменшити шкоду порівняно з існуючими протоколами. Наприклад, популярний зараз BRC-20 призвів до генерації великої кількості сміття UTXO.
Якщо ми порівняємо існуючі протоколи FT, то виявимо, що вони мають кілька важливих відмінностей:
Виходячи з наведених вище параметрів, результати порівняння існуючих протоколів FT в екосистемі Bitcoin є такими:
Для біткойна, як би виглядав простий протокол FT на основі UTXO з хорошим користуванням? Далі я хотів би познайомити вас з дуже крутим рішенням під назвою «Руни».
(1 огляд
Баланс рун зберігається в UTXO; UTXO може містити будь-яку кількість рун.
Транзакція містить повідомлення протоколу, якщо вона містить вихідні дані, pubkey сценарію якого містить OP_RETURN, за яким іде надсилання даних R у верхньому регістрі ASCII. Повідомлення протоколу — це всі дані, які надсилаються після першого.
Руни, введені в транзакції з недійсними повідомленнями протоколу, будуть знищені, що дозволить майбутнім оновленням змінити спосіб розподілу або створення рун, уникаючи старіших клієнтів від неправильного розподілу балансу рун.
Цілі числа кодуються як префікс int, де початкова цифра int визначає його довжину в байтах.
(2) Трансфер
Перший імпульс даних у повідомленні протоколу декодується в послідовність цілих чисел.
Ці цілі числа інтерпретуються як послідовність кортежів (ID, OUTPUT, AMOUNT). Якщо кількість декодованих цілих чисел не кратна 3, повідомлення протоколу недійсне.
ID кодується як дельта. Це дозволяє призначати ту саму руну кілька разів, щоб уникнути дублювання повного ідентифікатора руни. Наприклад, кортеж: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Виконайте такі завдання:
AMOUNT 0 - це скорочення від "усі руни, що залишилися".
Після обробки всіх призначень кортежу, будь-які непризначені руни призначаються до першого виходу не OP_RETURN (якщо є). Зайві завдання будуть проігноровані.
Руни можна спалити, призначивши їх виводу OP_RETURN, що містить повідомлення протоколу.
(3)Проблема
Якщо повідомлення протоколу має друге надсилання даних, це транзакція проблеми. Другий імпульс даних декодується у два цілі числа, SYMBOL і DECIMALS. Якщо залишити додаткові цілі числа, повідомлення протоколу є недійсним.
Транзакція випуску може створити будь-яку кількість рун випуску, використовуючи ідентифікатор 0 у кортежі призначення, максимум до 2^128 - 1.
SYMBOL — це зрозумілий для людини 26-бітний базовий символ кодування, подібний до символу, що використовується в порядкових іменах sat. Єдині допустимі символи від A до Z.
DECIMALS — це кількість цифр після коми, яку слід використовувати під час відображення виданих рун.
Якщо СИМВОЛ не було призначено, він призначається опублікованій руні, і опублікована руна отримує наступний доступний цифровий ідентифікатор руни (починаючи з 1).
Якщо SYMBOL уже виділено, або це BITCOIN, BTC або XBT, нова руна не буде створена. Виділення транзакцій звільнення з використанням ідентифікатора руни 0 ігноруватиметься, але інші розподіли все одно оброблятимуться.
(4) ПРИМІТКА
Під час відображення балансів UTXO рідний баланс біткойнів UTXO може відображатися з ідентифікатором руни 0 і символами BITCOIN, BTC або XBT.
Щоб зберегти протокол простим, (Runes) не використовує механізм, щоб уникнути присідання символу. Фактично, ефективний і простий спосіб уникнути зв’язування символів полягає в тому, щоб дозволити виділення лише символів понад певної довжини, яка з часом зменшується, а потім досягає нуля та дозволяє використовувати всі символи. Це дозволить уникнути розподілу коротких, ідеальних символів на початку протоколу та заохотити тих, хто запізнюється, конкурувати за ідеальні символи - якщо така конкуренція має сенс.
Написано в кінці
Чи справді це рішення працює на ринку? Я поняття не маю.
Він настільки простий, наскільки це можливо, не покладається на дані поза ланцюгом, не має власних токенів і ідеально вписується в рідну модель UTXO Bitcoin. Така схема могла б залучити користувачів з інших схем із гіршим впливом на ланцюг і звернути увагу розробників і користувачів на біткойн, спонукаючи їх прийняти сам біткойн.
Світ FT, з іншого боку, є абсолютно непоправною прірвою обману та жадібності, тому її можна змити.