На перший погляд, «Intent-centric» звертає увагу лише на результат і не піклується про процес.Насправді процес прихований у «чорній скриньці» вищими технологіями. Сьогодні я візьму як приклад distributed Intent Architecture. Я вам її важко розберу. Контент WorkFlow в цьому чорному ящику буде дуже сухим. Рекомендується спочатку поставити лайк, а потім читати.
Ймовірно, це представлятиме «розумну» архітектуру наступного покоління блокчейнів.
На початку розвитку Інтернету також існували чорні ящики.Наприклад, мало людей розуміли принципи зв’язку протоколів Інтернет-технологій, таких як HTTP, TCP/IP, CDN та IPV6, але всі плавали в програмах верхнього рівня. В епоху web3 також необхідно пройти через процес приховування внутрішнього протоколу, що саме робить Intent-centric. Тільки так можна справді знизити поріг використання web3, і додатки web3 можуть залітати в домівки звичайних людей.
**То як же розібрати цей «чорний ящик»? **
По-перше, якщо чорна скринька надається централізованою платформою, це не входить до сфери цієї статті, тому що централізований сервер теоретично може попередньо встановити різні складні фонові параметри та інструкції, такі як популярна програма соціальної платформи Bot і Friend .tech – це програма, яка базується на хостингу. Але це дуже непарадигмально. Я хочу ознайомити вас з тим, як організувати та керувати децентралізованим ринком намірів у майбутньому.
**Основним моментом є те, як перетворити складні абстрактні вимоги користувачів на інструкції, які можна візуалізувати програмою, а також автоматизувати виконання з низькою відмовостійкістю. **
**Приклад:**Сяо Ван розмістив замовлення на UniswapX. Намір вимагав замовлення з лімітом ціни, безкоштовну плату за газ, анти-MEV, маршрут із найменшим прослизанням, zk-SNARKization для захисту конфіденційності тощо. Після надсилання запиту Група виробників (професійних установ, маркетмейкерів) у «чорній скриньці» почала розробляти стратегію для виконання наказу Сяо Вана. Нарешті, після раунду аукціону, компанія А виграла право на виконання, і нарешті ute завершила Платформа сплачує плату за обробку, сплачену Сяо Ван Компанії А, і в той же час надає певну винагороду платформі.
Отримавши намір Сяо Вана, чорна скринька класифікує його. Наприклад, лімітне замовлення = умовна транзакція, і контракт автоматично запускається, якщо умова виконується; anti-MEV = офлайновий маршрутизатор розширення, який використовує канал рівня 2; конфіденційність захист = ядро. Дані потребують виконання каналу перевірки ZK-SNARK; ці наміри можуть бути призначені рівням 1 і рівням 2, або різні модульні технології можуть бути ввімкнені для обробки одночасно, і, нарешті, зібрані клієнту користувача для завершення остаточного вихідний результат.
**Базова децентралізована архітектура намірів включає користувач Користувач——розв’язувач Розв’язувач—виконавець утор—результат. **
Він може бути модульно вкладений в існуючу структуру смарт-контракту EVM, для чого потрібно запрограмувати намір для плавного виклику смарт-контрактами чи проксі-контрактами, або методами автономного розширення та різними протоколами DeFi у ланцюжку.
Для незалежної роботи в новій публічній архітектурі ланцюга, на додаток до Solver і Excutor, він також повинен мати відповідні ролі, такі як Proposer і Validator, щоб реалізувати децентралізовану роботу ланцюга.
Солвер — це розв’язувач, який відповідає за програмування абстрактних намірів. Наприклад: користувач А має три наміри під час надсилання транзакції: прозорий намір + намір безпеки + намір конфіденційності. Прості транзакції безпосередньо обробляються на рівні 1, тоді як складні транзакції надходять на розв’язувач рівня 2. Розв’язувач пропускає два наміри через технологію підтвердження з нульовим знанням, надану ZK Proof, і алгоритм випадкового шифрування, який надає ciphertext. Нарешті, оброблені txs буде надіслано до Mempool, очікуючи на упаковку та завантаження в ланцюжок;
utor — це виконавець, який відповідає за зміну txs, надісланого Solver, до кінцевого стану виконання + завершення перевірки. Це можна розуміти як майнер, який нарешті успішно реалізував намір користувача та відповідає за перевірку що не буде помилок під час виконання наміру для завершення остаточної поведінки бухгалтерського обліку в ланцюжку; у більш загальному розумінні Solver еквівалентний Searcher в Ethereum, відповідальному за збір і сортування транзакцій, а utor еквівалентний builder в Ethereum , відповідальний за остаточне пакування та генерацію блоків.
Звичайно, він також має ролі Node, Relay і Validator, які нічим не відрізняються від існуючих публічних ланцюжків, тому я не буду пояснювати занадто багато. Бездозвільні організації та установи можуть брати участь як у Solver, так і utor у формі аукціону для забезпечення прозорості та децентралізації системи.
Приблизний робочий процес (як показано нижче):
Користувач надсилає дані про наміри - Gossip Node отримує та передає дані:
①Прості транзакції переходять безпосередньо до L1 --> Generate Recepit через Proposer, Validator, utor тощо рівня 1.
②Складні транзакції буде призначено L2—>Solver відповідає за модульну інтеграцію zk, зашифрованого тексту та інших даних технічного програмування—>Proposer упорядковує та сортує дані для упаковки—>Validator перевіряє дійсність даних—>utor завершує запис блоку Рахунок --> Повернутися до квитанції користувача.
Клієнт користувача збере Recepit і завершить перевірку.
Після прочитання ви відчуваєте, що це абсолютно новий набір архітектури блокчейну Архітектура? Ну це так. Нова високомодульна структура публічного ланцюга, яка об’єднує різні існуючі технології.
Від сценарію в епоху Bitcoin до програмованого в епоху Ethereum, до програмованого ++ в епоху намірів. «Розумна» архітектура блокчейну наступного покоління ідеально повноцінно використовує різноманітні передові технології для виконання транзакцій (включно зі штучним інтелектом), а користувачі також можуть передавати складніші вимоги через рівень намірів, а весь процес виконання є високоавтоматизованим. і модульний. Лише тоді, коли блокчейн стане простішим у використанні та «розумним», можна нарешті реалізувати масове впровадження.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Аналіз жорсткого ядра: «розумна» архітектура блокчейна наступного покоління
Автор: HAOTIAN-CRYPTOINSIGHT, Джерело: Substack Haotian-CryptoInsight
На перший погляд, «Intent-centric» звертає увагу лише на результат і не піклується про процес.Насправді процес прихований у «чорній скриньці» вищими технологіями. Сьогодні я візьму як приклад distributed Intent Architecture. Я вам її важко розберу. Контент WorkFlow в цьому чорному ящику буде дуже сухим. Рекомендується спочатку поставити лайк, а потім читати.
Ймовірно, це представлятиме «розумну» архітектуру наступного покоління блокчейнів.
На початку розвитку Інтернету також існували чорні ящики.Наприклад, мало людей розуміли принципи зв’язку протоколів Інтернет-технологій, таких як HTTP, TCP/IP, CDN та IPV6, але всі плавали в програмах верхнього рівня. В епоху web3 також необхідно пройти через процес приховування внутрішнього протоколу, що саме робить Intent-centric. Тільки так можна справді знизити поріг використання web3, і додатки web3 можуть залітати в домівки звичайних людей.
**То як же розібрати цей «чорний ящик»? **
По-перше, якщо чорна скринька надається централізованою платформою, це не входить до сфери цієї статті, тому що централізований сервер теоретично може попередньо встановити різні складні фонові параметри та інструкції, такі як популярна програма соціальної платформи Bot і Friend .tech – це програма, яка базується на хостингу. Але це дуже непарадигмально. Я хочу ознайомити вас з тим, як організувати та керувати децентралізованим ринком намірів у майбутньому.
**Основним моментом є те, як перетворити складні абстрактні вимоги користувачів на інструкції, які можна візуалізувати програмою, а також автоматизувати виконання з низькою відмовостійкістю. **
**Приклад:**Сяо Ван розмістив замовлення на UniswapX. Намір вимагав замовлення з лімітом ціни, безкоштовну плату за газ, анти-MEV, маршрут із найменшим прослизанням, zk-SNARKization для захисту конфіденційності тощо. Після надсилання запиту Група виробників (професійних установ, маркетмейкерів) у «чорній скриньці» почала розробляти стратегію для виконання наказу Сяо Вана. Нарешті, після раунду аукціону, компанія А виграла право на виконання, і нарешті ute завершила Платформа сплачує плату за обробку, сплачену Сяо Ван Компанії А, і в той же час надає певну винагороду платформі.
Отримавши намір Сяо Вана, чорна скринька класифікує його. Наприклад, лімітне замовлення = умовна транзакція, і контракт автоматично запускається, якщо умова виконується; anti-MEV = офлайновий маршрутизатор розширення, який використовує канал рівня 2; конфіденційність захист = ядро. Дані потребують виконання каналу перевірки ZK-SNARK; ці наміри можуть бути призначені рівням 1 і рівням 2, або різні модульні технології можуть бути ввімкнені для обробки одночасно, і, нарешті, зібрані клієнту користувача для завершення остаточного вихідний результат.
**Базова децентралізована архітектура намірів включає користувач Користувач——розв’язувач Розв’язувач—виконавець утор—результат. **
Солвер — це розв’язувач, який відповідає за програмування абстрактних намірів. Наприклад: користувач А має три наміри під час надсилання транзакції: прозорий намір + намір безпеки + намір конфіденційності. Прості транзакції безпосередньо обробляються на рівні 1, тоді як складні транзакції надходять на розв’язувач рівня 2. Розв’язувач пропускає два наміри через технологію підтвердження з нульовим знанням, надану ZK Proof, і алгоритм випадкового шифрування, який надає ciphertext. Нарешті, оброблені txs буде надіслано до Mempool, очікуючи на упаковку та завантаження в ланцюжок;
utor — це виконавець, який відповідає за зміну txs, надісланого Solver, до кінцевого стану виконання + завершення перевірки. Це можна розуміти як майнер, який нарешті успішно реалізував намір користувача та відповідає за перевірку що не буде помилок під час виконання наміру для завершення остаточної поведінки бухгалтерського обліку в ланцюжку; у більш загальному розумінні Solver еквівалентний Searcher в Ethereum, відповідальному за збір і сортування транзакцій, а utor еквівалентний builder в Ethereum , відповідальний за остаточне пакування та генерацію блоків.
Звичайно, він також має ролі Node, Relay і Validator, які нічим не відрізняються від існуючих публічних ланцюжків, тому я не буду пояснювати занадто багато. Бездозвільні організації та установи можуть брати участь як у Solver, так і utor у формі аукціону для забезпечення прозорості та децентралізації системи.
Приблизний робочий процес (як показано нижче):
Користувач надсилає дані про наміри - Gossip Node отримує та передає дані:
①Прості транзакції переходять безпосередньо до L1 --> Generate Recepit через Proposer, Validator, utor тощо рівня 1.
②Складні транзакції буде призначено L2—>Solver відповідає за модульну інтеграцію zk, зашифрованого тексту та інших даних технічного програмування—>Proposer упорядковує та сортує дані для упаковки—>Validator перевіряє дійсність даних—>utor завершує запис блоку Рахунок --> Повернутися до квитанції користувача.
Клієнт користувача збере Recepit і завершить перевірку.
Після прочитання ви відчуваєте, що це абсолютно новий набір архітектури блокчейну Архітектура? Ну це так. Нова високомодульна структура публічного ланцюга, яка об’єднує різні існуючі технології.
Від сценарію в епоху Bitcoin до програмованого в епоху Ethereum, до програмованого ++ в епоху намірів. «Розумна» архітектура блокчейну наступного покоління ідеально повноцінно використовує різноманітні передові технології для виконання транзакцій (включно зі штучним інтелектом), а користувачі також можуть передавати складніші вимоги через рівень намірів, а весь процес виконання є високоавтоматизованим. і модульний. Лише тоді, коли блокчейн стане простішим у використанні та «розумним», можна нарешті реалізувати масове впровадження.