ВСТУП

Поточна надпис Ethereum в суті є старим вином в новій пляшці від Ordinals, новим парадигмом без реального значення. ETHS все ще має ризики безпеки, і хоча воно більш децентралізоване, ніж Rollup, його процес виведення все ще ґрунтується на сторонньому нотаріусі/менеджері, і є ризик крадіжки. Очевидно, наразі ETHS в основному є фінансовим хайпом, не тим, що воно може принести інновації, які Ethereum Layer 2 не може принести.

Нещодавній популярності BTC екологічних написів заохочила розробників інших ланцюгів будувати подібні системи. Спосіб реалізації систем написів на різних ланцюгах та функції, які вони можуть досягти, трохи відрізняються, але вони мають кілька спільних рис:

1. Всі написи використовують текстову інформацію, додану до переказу, щоб виразити операцію, яку ви хочете виконати, наприклад, написання «передача 1 монети XXX» у повідомленні. Зверніть увагу, що ця інформація є звичайним текстом і не включає операції, такі як виконання смарт-контракту на ланцюжку.

2. Розробники розроблять серію специфікацій та стандартів для стандартизації всієї текстової інформації.

3. Розробник надає набір індексаторів для обчислення внутрішнього стану системи написів після збору текстової інформації всіх написів на ланцюжку. Індексатор - це компонент з відкритим вихідним кодом поза ланцюжком, який може запустити будь-хто.

Надпис BTC Ordinals встановила механізм випуску NFT та токенів на BTC, а також спонукала до широкомасштабного обговорення BTC L2. У цьому розумінні ми можемо вважати, що Ordinals є дещо передовим і дослідницьким. Однак Ordinals була обмежена власною архітектурою BTC з точки зору технологій та виробничого досвіду, а також була критикована спільнотою BTC OG з причин, таких як забруднення пилом та споживання даних.

Отже, чи має сенс повторно надрукувати напис на Ethereum? Все-таки сам Ethereum має складні смарт-контракти, а ERC20 та NFT також є частиною самого Ethereum; який вплив будуть мати ці проекти написів на екосистему Ethereum, і чи вони спричинять суперечки і турботу на BTC?

Технічна реалізація етичної

Спочатку давайте поглянемо, як Етернічний реалізований. Це відомий проект напису на Ethereum, який в основному використовує Calldata для роботи.

Calldata - це початкові вхідні дані, які передаються в транзакції Ethereum. Зазвичай вони використовуються для передачі параметрів, необхідних для взаємодії зі смарт-контрактом, але також можуть бути використані для відправлення текстових повідомлень (коментарі, написи, примітки про переказ тощо) на адресу EOA. На малюнку входові дані - це calldata.

Якщо ви хочете використовувати Етнографію для напису «Привіт, світ» в транзакції, вам потрібно побудувати транзакцію з наступними даними виклику:

Після того, як поза ланцюжком монітор Indexer відстежує цю транзакцію, він оновить базу даних та повідомить користувача, що було створено нову напис, а зміст напису - Привіт, світ. У напис можна також розмістити більш складний вміст, такий як base64, який представляє інформацію про зображення.

Етнічність тепер пройшла 6 ESIPs (подібні до EIP пропозиції), щоб визначити використання написів в різних сценаріях. Однак це лише відносно базові специфікації написів, такі як формат транзакцій напису, ініційованих з EOA, події випуску контракту тощо.

Оскільки Etnicity - це проект на Ethereum, також можливо реалізувати певний рівень логіки за допомогою смарт-контрактів Ethereum. Важливо зауважити, що безпосереднє взаємодія зі смарт-контрактами не є рекомендованим підходом за Етичною.

Хоча офіційні майданчики NFT та подібні до них також реалізовані безпосередньо за допомогою смарт-контрактів. За офіційною документацією, Ethical хоче надати користувачам «децентралізовану та доступну обчислювальну послугу»: відокремлення обчислень від ланцюжка значно зменшить витрати на використання Ethereum.

Давайте детально дослідимо вартість виклику смарт-контракту, яку можна розділити на три частини:

·Основні витрати на транзакції: Будь-яка транзакція Ethereum потребує оплати, наразі 21000 газу.

·Вартість передачі даних (calldata): Calldata зазвичай використовується для надсилання даних та параметрів для взаємодії з розумними контрактами. Після налаштування EIP-2028 calldata зазвичай споживає 16 газу на байт (4 газу, якщо дані складають 0 байтів).

·Вартість виконання контракту: Якщо транзакція викликає функцію в розумному контракті, то в залежності від складності виконання функції також потрібно оплатити витрати на обчислення. Наприклад, якщо це пов'язано з оновленням статусу (наприклад, оновлення інформації про баланс у контракті ERC-20), виклик SSTORE може використовувати від 5000 до 20 000 газу.

Давайте розглянемо дуже просту транзакцію переказу USDT. Вартість транзакції складала 63 197 газу, а calldata така:

Давайте проаналізуємо ці дані виклику та витрати газу на це:

·Дані виклику Ethereum мають шістнадцятковий формат, тобто кожні дві цифри - це один байт (16^2 = 2^8). 0x в початку вказує, що дані у шістнадцятковому форматі.

·Після початку 0x a9059cbb - це селектор функції та займає 4 ненульових байти.

·Наступні 32 байти - це адреси, з 12 нулів спереду (оскільки адреси Ethereum складають 20 байтів, зліва додаються від 0 до 32 байтів), а 20 байтів ненульових даних адреси.

Останні 32 байти представляють собою суму, з великою кількістю нулів зліва, дані, відмінні від нуля, в кінці і 4 байти, відмінні від нуля.

·Таким чином, 28 ненульових байтів і 40 нульових байтів

Отже, callDataGas = 28 * 16 + 40 * 4 = 608 газу.

Загальна кількість газу становить 63197. Після віднімання витрат на calldata та фіксованих витрат, витрати на розрахунок розумного контракту для виконання цієї транзакції становлять 41589 газу. Витрати на розрахунок контракту становлять більшість цієї транзакції, і це лише проста транзакція. У складних транзакціях витрати на розрахунок контракту ще більше зростуть.

Переміщення процесу обчислення поза ланцюжок дійсно значно знизить витрати на використання: якщо ви не хочете викликати розумні контракти безпосередньо на ланцюжку, ви можете перейти за узгодженою адресою EOA

0x0000000000000000000000000000000face7 Надіслати дані транзакції

У calldata транзакції вкажіть, який контракт ви спочатку хотіли викликати, та відповідні вхідні параметри. Оскільки вищезазначена адреса є обліковим записом EOA та в ньому немає коду контракту, описана вище операція не спричинить виконання обчислювальних завдань на ланцюжку; вона лише розміщує повідомлення.

Поза ланцюжком, після того як Індексатор прослуховує це повідомлення, він проаналізує його, щоб дізнатися, який контракт на ланцюжку ETH спочатку хотів викликати автор цього повідомлення, після чого Індексатор обчислить результати виклику контракту поза ланцюжком.

Ну, якщо автономний індексатор хоче обчислити написи та смарт-контракти, він повинен мати набір правил STF (функція переходу стану) та час виконання. Складна частина може бути названа віртуальною машиною VM. Ethnic запустив власну VM—Ethnic VM—в ESIP-4, який пізніше був перейменований на Facet VM.

Facet — трохи схожий на копроцесор

Facet визначає себе як дешеву, просту у використанні, безпечну та децентралізовану платформу обчислень. Прослуховуйте дані Ethical на Ethereum, витягуйте їх на віртуальну машину для обчислень та нарешті повертайте результати користувачеві. У Facet є кілька ключових компонентів:

·Facet VM, набір VM, написаних на Ruby, відповідає за моніторинг транзакцій ETHS, розбір calldata та виконання операцій.

·Rubidity, мова програмування розумного контракту в Facet, схожа на Ruby, а також зберігає багато використань та концепцій solidity, що дозволяє розробникам швидко почати.

·Глухий контракт, глухий контракт, тип контракту, який працює на Facet. Ім'я повне гумору. Деякі люди також правильно називають його глухим контрактом. Само слово "глухий" - це гра слів; глухий може описувати мовчазний процес роботи цього типу контракту. Але з іншого боку, за офіційною приказкою "Такі глухі, що вони розумні", це означає бути дурним, з вираженою схильністю до сперечань з розумними контрактами, тому немає проблем із називанням їх глупими контрактами.

Сам дурний контракт фактично не буде розгортатися на Ethereum; його код буде опублікований на ланцюжку ETH у вигляді виклику даних. Ось приклад Facet виклику дурного контракту:

Транзакція на виготовлення до адреси чорної діри EOA

0x000000000000000000000000000face7 подає calldata на зображенні нижче, заявляючи, що ви хочете лише токен і кількість монет. Це фактично те ж саме, що і Ordinals або BRC-20:

Давайте ще раз подивимося на візуальне порівняння між Rubidity та Solidity, як показано нижче.

Хоча офіційне заявлення говорить, що Rubidity має концепцію та структуру, схожу на Solidity, щоб розробники могли швидко почати роботу. Але ми знаємо, що це фактично має негативний вплив на розробників. Також, наразі Facet VM підтримує лише дурні контракти на офіційному білому списку, що свідчить про те, що уряд не дуже впевнений у цій мові та VM. Чи важче офіційно використовувати EVM в інженерії, ніж розробляти нову VM та нову мову, я не знаю. Але одне річ впевнена: нова мова, новий контракт, нова екосистема та новий спосіб використання Ethereum - це дійсно досить схеми.

Атака Фасета на смарт-контракти

Документація Facet зробила наступні сильні коментарі щодо Ethereum та смарт-контрактів: «Смарт-контракти вважаються функцією, яка робить Ethereum особливим, і все ж теза Facet полягає в тому, що смарт-контракти - це найбільший недолік дизайну Ethereum».

Вони вважають, що смарт-контракт Ethereum є найбільшим недоліком дизайну, тому що сам контракт вимагає лише заданого введення (calldata), а його вихід визначений, тому його не варто обчислювати в ланцюжку, витрачаючи гроші даремно без причини. У поєднанні з «децентралізованим і доступним обчислювальним сервісом» Ethical стає зрозуміло, що Ethnic і Facet дійсно хочуть створити враження ринку: «Ми створюємо нову парадигму розширення та метод використання Ethereum», але насправді деякі власні технічні рішення ETS не дуже надійні.

З продуктової точки зору, Facet може непрямо викликати смарт-контракти під ланцюгом, а також має власну систему дурних контрактів під ланцюгом. Звісно, уряд здійснює свій гасло.

Проте з економічної точки зору, у світі немає безкоштовного обіду; звісно, зберігання та обчислення потребують грошей. Так як Indexer вирішує цю частину витрат? На це немає офіційного пояснення, тому давайте уявимо:

· Користувачі оплачують. Наприклад, комісія за обробку, яку стягує ринок NFT від покупців, але ми не можемо дивитися на просту модель оплати проекту як на довгостроковий метод оплати, схожий на мережу L2.

·Станьте багатими через власний екологічний хайп. Це, звісно, можливо, але це лише тимчасове рішення, щоб тримати проект крутим протягом певного часу. Якщо Етнічність має стати новим парадигмою Ethereum, Індексатор повинен мати довгостроковий, мережевий економічний механізм для гарантування роботи.

Якщо загальнодоступні товари не є прибутковими, які організації будуть пожертвувати? Я думаю, що принаймні Фонд Ethereum не буде особливо активним, оскільки сам Ethereum має дуже хороше рішення - Rollup.

Першопричина фасетів і дурних контрактів

Якщо нам потрібна лише проста форма напису Ethereum, то одного проекту Ethnic вистачить. Тому чому його пропозиція ESIP-4 знову породжує Facet?

Оскільки систему напису не можна використовувати для складної логіки транзакцій. Ми можемо розглянути робочу логіку офіційного контракту на NFT Ethical, який використовує механізм відкладеного замовлення.

Якщо ви хочете внести напис NFT у контракт, вам потрібно лише записати calldata як ethscriptionID напису та викликати контракт ринку. Оскільки ця операція намірено вибирає недійсну форму виклику функції, це спричиняє виклик fallback () за замовчуванням.

Зрештою на ланцюжку Ethereum буде кинуто подію, яка називається PotentialEthScriptionOfferings. Після того як індексатор вузла відстежує цю подію поза ланцюжком, він локально передасть власність на NFT у контракт ринку.

Для економії газу ринок торгівлі ETHS не зберігає деякі параметри невиконаних замовлень продавця, такі як ціна, термін, тощо, в контракті ETH, а замість цього зберігає їх офлайн у вигляді повідомлень. Візуально їх мали б зберігати на сервері додатків. Після того, як покупець відслідкував це повідомлення, він може подати замовлення на покупку, видавши команду BuyWithSignature ().

Використання механізму відкладеного замовлення є нормою для NFT, оскільки самі NFT не є однорідними. Тому, якщо це токен згрупованої токенної написи, чи можна використовувати механізм AMM договору? Відповідь - ні. Статус написаних NFT або токенів не є на L1, що майже те саме, що Ординали та BRC-20. Це повністю протилежно до деякої громадської пропаганди. Усі повинні бути обережні. Напис не є активом на ланцюгу ETH в справжньому розумінні слова. Ми не можемо сказати, що calldata, що створив актив, знаходиться на L1, і ми можемо декларувати інструкції щодо операцій на L1, що називається внутрішнім активом на L1. В іншому випадку внутрішній актив на Rollup L2 також може бути названий активом L1, оскільки calldata Rollup знаходиться на L1. Очевидно, це абсурдно називати цей тип активу внутрішнім активом L1.

Ви, можливо, запитуєте, чи це просто смарт-контракт, який використовується для торгівлі? Чому кажуть, що написи на контракті не можуть бути прочитані та змінені? Насправді, цей контракт відповідає лише за збір грошей, їх передачу та проведення подій для індексаторів вузлів під ланцюгом, щоб вони могли слухати та спровоковувати відповідні операції. У очах EVM Ethereum стан чогось подібного до напису не може бути відновлений у базі даних «стану світу», яка спеціально зберігає стан Ethereum, і контракти не можуть посилатися на нього.

Незалежно від того, у якій формі є актив, токен, NFT або будь-що дивне, я можу надати дуже простий стандарт для ідентифікації активів рівня L1 та L2: чи можна відновити їх стан до "стану світу" Ethereum, чи може EVM L1 посилатися, викликати, запитувати та змінювати стан активу; якщо ні, то це не є активом рівня L1.

Таким чином, ви також можете побачити, що назва події депозиту - PotentialEthscriptionDeposit, тобто «можливе поповнення напису», а не остаточне поповнення, оскільки контракт не може визначити, чи існує цей напис, і неможливо перевірити його автентичність. Якщо ви замовляєте напис, якого не існує, або чийось іншого, контракт не відхилить вас; просто Indexer не включить ваші дії.

Отже, система напису може реалізувати лише цю просту псевдо-логіку договору; відкладені замовлення - одне з них. Сутність відкладеного замовлення полягає в тому, що обидві сторони угоди погоджуються з інформацією одна іншої згідно з правилом. Насправді це може бути виражено у звичайному тексті без смарт-контракту. Це схоже на принцип напису.

Ми можем уявити, як цей процес може бути завершений без використання смарт-контракту: продавець врізає повідомлення в звичайну транзакцію, переказує мені 1ETH, і хтось, хто зауважує 123, може отримати NFT з моїм написом номер 123. Це потребує лише підтримки Індексатора цієї логіки. Він слухає, що хтось переказав 1ETH продавцю та додав АВС, тоді його можна передати безпосередньо в базу даних Індексатора поза ланцюжком.

Звичайно, цей приклад фактично може викликати деякі проблеми, такі як повторні транзакції, які можуть виникнути через те, що кілька людей купують NFT. Продавець отримав кілька переказів, але в кінці кінців NFT можуть бути передані тільки одній особі за допомогою Індексатора. Це також повинно бути однією з причин, чому уряд відкрито критикує смарт-контракти, але використовує контракти для реалізації ринку NFT, тому ви також повинні зрозуміти офіційне заявлення про те, що виклик смарт-контрактів без розрахунку через Facet є ненадійним.

Звичайно, відкладені замовлення теоретично можуть використовувати звичайний текст, а не вимагати контракт, але відносно складна логіка AMM вимагає смарт-контрактів, оскільки вона потребує не угоди між двома сторонами, але контрактного схвалення. Контракт, який виступає надійним рецензентом, повинен перевіряти базову інформацію, таку як баланс і ліквідність, та виконувати обчислення. Контракт повинен мати можливість отримати будь-які дані про активи, які йому потрібні.

AMM, з іншого боку, є лише відносно простою формою DeFi, і будь-яка інша складна логіка не може бути реалізована лише на Ethnic. Тому був запущений Facet - головний пріоритет Facet - це міждоменність! Фактично це L2, але в ньому немає блокової структури, тому ми не називаємо його міжланцюжковим, а міждоменним. Коли всі L1 активи переходять у Facet міждоменно, не виникає проблеми, що їх не можна назвати міждоменними. Усі позаланцюжкові активи можуть бути використані зіпсованими контрактами під ланцюгом, тим самим підтримуючи складну логіку контракту.

Порівняння з Rollup

Через довгу дискусію ви повинні бути здатні побачити, що рішення Ethical дещо схоже на Rollup. Але це лише «схоже»; строго кажучи, воно реалізує лише підмножину основних функцій Rollup. Відсутня функціональність, з іншого боку, призвела до фатальних пошкоджень його наративу або поставила користувачів перед серйозним ризиком.

Rollup - це складна система, і ми не будемо розгортати це тут. Вона має щось спільне з Етанолом:

• Вони всі надсилають дані calldata для транзакцій L2 на Ethereum.

• Усі обчислення обробляються поза ланцюжком.

Спільні риси дуже очевидні, і нам потрібно продемонструвати відмінності детально.

Згортання масового надходження calldata

У більшості випадків користувачі в Rollup не надсилають транзакції безпосередньо до L1, а замість цього надсилають їх до поза ланцюжкового послідовника. Послідовник сортує всі транзакції, упаковує та стискає їх і відправляє calldata до L1 партіями. Подавши calldata від кількох користувачів у одній транзакції, основна вартість 21 000 газу може бути розведена.

У етнічності немає такого механізму; всі користувачі надсилають дані виклику безпосередньо на L1.

Використовуючи приклад з USDT вище (608 газу для calldata), давайте припустимо, що 100 користувачів ініціювали 100 транзакцій, і приблизно розрахуємо відмінність вартості між ними з дуже малою строгості:

· Кожен користувач напису заплатить 21608 газу (608 + 21000). Решта обчислення не оплачується, оскільки обчислення знаходиться поза ланцюжком.

Користувачі Rollup платять 818 газу ((608*100+21000) /100) на людину. Математична частина така ж, як вище.

Звичайно, кожен користувач Rollup також повинен платити комісію за обчислення та зберігання L2 послідовнику, але воно набагато дешевше, ніж L1, тому в даному випадку це можна не враховувати. Крім того, rollup потребує деяких додаткових спеціальних полів для збільшення обсягу, але в той ж час воно має кращу компресію даних, тому ми не будемо розгортати це тут.

За цією орієнтовною оцінкою можна побачити, що Етанол не має вигоди вартості над Шаром 2. Також в пропаганді проекту я бачив речі типу "4000 написів можуть бути передані пакетами, близько 0.11 ETH, і в середньому лише 0.05U за переказ", щоб довести, що використання Етанолу є дешевим. Насправді це не уточнює принципи та деталі взаємодії ETHS.

Off-chain pre-confirmation

Завдяки позачерговому послідовнику запити користувачів Rollup можуть бути попередньо підтверджені протягом 1 с. Це набагато краще для UX, ніж система напису протягом 12 с або більше на L1. Звичайно, прихильники напису також можуть стверджувати, що до кінцевих результатів таких транзакцій недостовірні до тих пір, поки calldata не буде надіслано на ланцюг ETH.

Цензуростійкий та децентралізований

Користувачі на Rollup ймовірно будуть цензурити оффчейн послідовники, тоді як Етер не може цензурувати користувачів. Однак добре спроектований Rollup матиме примусову функцію агрегування, щоб протистояти перегляду послідовника, і в кінцевому підсумку послідовник не має жодної влади переглядати користувачів взагалі.

Отже, коли користувачі використовують Rollup, вони також можуть обійти послідовник напряму на L1. Rollup дає користувачам різні варіанти. Ви можете використовувати швидший послідовник або використовувати L1 напряму. Однак Етер може використовувати лише L1, і для користувачів немає можливості вибору вільно.

Також Етніч критикував послідовника Rollup за централізацію. Але сам індексатор також є високо централізованою компонентою. Етнік пояснив, що оскільки кожен може запустити та перевірити індексатор, він не є централізованим, але насправді величезна більшість людей не запускає вузлі самостійно. Тому ETHS показує свій децентралізований бік лише в порівнянні з Rollup у крайніх випадках. В кінцевому підсумку, послідовник Rollup може відмовити або зламати, але ETHS може продовжувати працювати, поки члени спільноти запускають кілька індексаторів.

Модель прибутку

Жоден проект не може використовувати любов для вироблення електроенергії. Проекти довгострокового розвитку повинні уважно розглядати питання моделей прибутку. Чи є це централізована сутність або комбінація децентралізованих сутностей, вони повинні бути прибутковими для захисту мережевої безпеки протягом тривалого часу.

Секвенсор Rollup має чітку модель прибутку: збільшення плати за газ, видобуток MEV тощо. Секвенсор має владу, щоб забезпечити нормальну роботу мережі. Оскільки користувачі надсилають calldata безпосередньо на L1, Індексатор не багато бере плату.

Зручність для розробників

Більшість мов розробки контрактів Rollup, інструментальних ланцюгів тощо можуть безпосередньо використовувати Ethereum, і розробники можуть безперешкодно мігрувати на Rollup. Нічого з цього не існує в Етніч; вам потрібно оволодіти новим Rubidity, будувати нові скани, ознайомитися з новими ВМ тощо. Звісно, коли дивитися в зворотному напрямку, цей опір також є можливістю для дослідження, яке може бути зумовлене розвитком нової екосистеми.

Виведення та вирішення статусу

Це фатальна проблема Facet. Ми знаємо, що Rollup не лише подає calldata (вхідні дані) на L1 пакетами, але також регулярно подає вирішення стану (вихідні дані) після N операцій на L1. ZKR та OPR мають різні методи доказу для визначення того, чи є зв'язок між вхідними та вихідними даними правильним. Незалежно від методу доказу, кінцеве рішення - це контракт L1. Вихідні та вхідні дані на Rollup можна відстежувати та не можна підробити.

Так для чого потрібне урегулювання статусу? Використовується для виведення коштів, тобто виведення коштів з рівня L2 на рівень L1. Коли статус на L1 опублікований, ми можемо використовувати доказ Меркла та інші засоби, щоб довести, що моє прохання про виведення на L2 включене в той кореневий статус на основі кореневого статусу. Як тільки контракт буде правильно перевірений, активи можуть бути виведені на L1.

У Facet немає механізму вирішення статусу, тому неможливо досягти можливості виконання виведення з L2 на L1 без дозволу та децентралізації. Як вже зазначалося вище, йому також потрібен рівень L2 для виконання більш складної логіки контракту. Так само, як його AMM Swap FacetSwap.

Ми бачимо, що FacetSwap (декілька dex, побудованих на Facet з дурними контрактами) має чітко дві дії: депозит та виведення. Зазвичай для Swap немає депозитів або виведень, оскільки Facet вимагає переходу між доменами перед тим, як ви зможете його використовувати.

У Facet, депозит потребує блокування коштів L1 на контракті мосту L1 та випуску відповідної події ethscriptions_protocol_createEthscription для того, щоб індексатор міг проіндексувати. Це відповідає іншим методам поповнення L2.

З іншого боку, зняття коштів має серйозні проблеми з безпекою. Оскільки на Facet немає механізму розрахунку статусу, контракти не можуть бути використані для автоматичного визначення того, чи дійсне виведення коштів з L2 на L1. Отже, який метод використовував Фасет? Адміністратор відпустив механізм свідка, подібний до раніше вкраденого мосту Axie.

Давайте глянемо прямо на міст Facet. Адреса:

0xd729345aa12c5af2121d96f87b673987f354496b.

HashedMessage - це повідомлення, підписане відправником та містить частину вмісту виведення. Відправник - це адреса за замовчуванням адміністратора. Оскільки немає вирішення статусу, не можна здійснити перевірку, наприклад, чи є у обліковому записі стільки монет на L2. Тому всі кошти в контракті можуть бути зняті з підписом відправника, чи то це буде недобросовісна поведінка сторони проекту, чи хакерська атака для отримання приватного ключа.

У Rollup не потрібно свідків для виведення активів; на бічних ланцюгах, якщо свідки хочуть зробити щось децентралізоване, вони можуть обрати частину власної системи згоди як агентів та використовувати заставу для певної міри стримування злочину.

В етнічному та фасетному – нічого. Це просто, неприховано, адреса адміністратора. Це, ймовірно, занадто грубо для L2-проекту, який часто кричить «смарт-контракти — це недоліки дизайну», «Rollup централізований» і «ми обчислювальна платформа наступного покоління». Очевидно, що у нього все ще є багато недоліків, але ми можемо продовжувати спостерігати, хоча ці недоліки нелегко виправити, і вони, ймовірно, існують і в Bitcoin Layer 2.

підсумований

Наразі в Етернеті є деяка "фальшива пропаганда". Ось декілька ключових моментів:

·Активи на Етнічному та Фасет не є активами, що випущені на L1.

·Для надання складних можливостей контрактування Facet перетворився на сутність L2, але він має великі фінансові ризики безпеки.

·Офіційно заявлено, що збираються видалити обчислення контрактів на рівні L1, але навіть не використовують власний топ-додаток.

·Етанол схожий з Rollup з дуже поганим базовим функціоналом. Ані Rollup не є дешевим і швидким, ані Rollup не є безпечним. Те, що він може досягти, може зробити Rollup, і він не може забезпечити ті дуже важливі функції, які може здійснити Rollup.

·Якщо він хоче вирішити вищезазначені проблеми, йому потрібно розробити механізм встановлення статусу, а також послідовник та блок L2, тоді це врешті-решт стане Rollup.

Етнічність скористалася написом BTC та поклала на концепцію, щоб надихнути старе вино в нових пляшках, але вона не відкрила нову парадигму. Наразі ETHS все ще в основному ґрунтується на фінансових спекуляціях, не те що цей продукт сам по собі може принести те, чого не має Ethereum Layer 2. Довгострокова цінність цього виду речей, очевидно, ще не відкрита, але у своїй поточній формі ETHS взяла на себе 'непереносиме бремене життя', і його гасло далеко відповідає його практичному ефекту.

Застереження:

1. Ця стаття була розміщена з [ theblockbeats]. Усі авторські права належать оригінальному автору [Туман, гік Веб3]. Якщо є зауваження до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно поглядами автора і не становлять жодних інвестиційних порад.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонено.