Демонстрація сховища конфіденційності Midnight потребує зовнішніх підписувачів для випуску токенів Ethereum

By: cryptoslate.com|22.10.2026 14:00:42
0
Поширити
copy
Оцінити в GoogleОцінити в Google

Виведення з експериментального сховища Ethereum SIG Network вимагає підписувальної мережі, хоча основні активи залишаються на Ethereum. Цей приклад ілюструє залежність від виведення в плані конфіденційності Midnight's Nightmode: користувачі знищують захищений запит перед підписанням зовнішнього переказу, а відновлення невдалого переказу також потребує підтвердженої відповіді.

Обліковий запис Чарльза Хоскінсона @IOHK_Charles привітав Tron у Midnight 21 жовтня. Дорожня карта SIG націлена на Tron у грудні 2026 року, тоді як інтеграція Ethereum, що зазначена, перебуває в тестовій мережі stagenet.

Як сховище Ethereum утримує активи

SIG описує свою послугу як надання контракту Midnight звичайного облікового запису Ethereum. Поріг підписувачів генерує підпис Ethereum, коли контракт його запитує. SIG стверджує, що підписувачі є незалежними, і жоден підписувач не може діяти самостійно.

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

Це розрізнення також пояснює знищення. Початок виведення знищує захищений запит, що викупається, а не знищує основний ERC20. Успішний зовнішній платіж завершує викуп. Якщо платіж отримує один з задокументованих результатів невдачі, застосування може відновити запит.

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

Схема startWithdraw знищує цю монету та ставить запит у чергу. Пізніше очищення черги призначає номер послідовності транзакції облікового запису сховища, відомий як його nonce. Крок надсилання потім реєструє запит на точний переказ ERC20 та повідомляє службу підписування MPC, або багатостороннього обчислення.

Далі йде послідовність окремих відповідальностей:

КрокЩо має статисяНаслідок виведення
Авторизувати та поставити в чергуВласник витрачає захищений запит; Midnight реєструє запит.Запит знищується перед зовнішнім виплатою.
ПідписатиСлужба MPC повертає підпис для переказу сховища.Авторизація власника сама по собі не може підписати з облікового запису сховища.
Транслювати та виконатиКлієнт подає підписану транзакцію; Ethereum обробляє її.Повернута підпис все ще потребує зовнішньої транзакції для виконання.
ПідтвердитиСлужба MPC повідомляє про результат транзакції.Врегулювання Midnight залежить від автентифікованого результату.
ЗавершитиСховище перевіряє запис врегулювання та закриває запит.Результат визначає, чи залишається захищене знищення в силі, чи запит повторно випускається.

Служба підписування не транслює транзакцію. dApp або релейер збирає її з перевіреним підписом і надсилає на ланцюг EVM.

Невдалий переказ і безшумна служба - це різні речі

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

Сховище перевіряє підтвердження проти налаштованого ключа відповіді MPC перед дозволом на врегулювання.

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

Успішний переказ, що повертає true, залишає спалення на місці та закриває запит. На шляху невдачі відновлення є вимогою сховища на Midnight, а не новим платежем рідного активу до призначення.

Документований маршрут повернення вимагає перевіреного, очищеного підтвердження. Невідповідь на запит на підпис або відсутня відповідь на результат не відповідає цій умові.

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

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

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

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

Виробничий тест є повним шляхом виходу

Підтримка Mainnet залишається пов'язаною з ledger v9 у дорожній карті SIG. Оновлення репозиторію від 21 жовтня готує пакет сховища 0.5.0 на SIG Midnight 0.25.0. У цій версії коду опублікований реєстр адрес містить адресу сховища stagenet та порожній запис mainnet, який файл визначає як ще не розгорнутий або опублікований.

Окремий демонстраційний стек SIG використовує Midnight stagenet та Ethereum Sepolia, обидва публічні тестові мережі, з "фейковим" відповідником MPC. Це демонструє потік застосування. Це не встановлює, що виробничий кворум незалежних підписувачів працює в цій демонстрації.

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

Обсяг аудиту потребує такої ж точності. Остаточний звіт Hacken, датований 21 лютого 2025 року, охоплює контракти підпису ланцюга Ethereum Solidity. Його обсяг не встановлює покриття новішого Compact vault або повної системи Nightmode.

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

Ціна --

--
--
--

Цей контент надано лише для загальних інформаційних цілей і не є фінансовою, інвестиційною, юридичною чи податковою консультацією. Події, нагороди, онлайн-акцій або пов’язану інформацію, згадана тут, не слід розглядати як рекомендацію, прохання чи запрошення до купівлі, продажу, торгівлі чи інших операцій з криптоактивами. Криптоактиви є дуже волатильними та можуть призвести до збитків. Доступність послуг, продуктів WEEX та пов’язаних із ними подій може відрізнятися залежно від регіону. Ви несете відповідальність за забезпечення відповідності вашої участі чинному місцевому законодавству та нормативним актам.

Вам також може сподобатися

Нещодавні лістинги монет на WEEX

iconiconiconiconiconiconiconicon
Підтримка клієнтів:@weikecs
Співпраця:@weikecs
Кількісна торгівля та маркетмейкінг:[email protected]
VIP-програма:[email protected]