Темні басейни швидко стають наступним фронтиром сектору децентралізованої фінансової (DeFi) системи Ethereum. Дизайн темних басейнів зменшує проблеми, такі як невизначеність ціни та погана конфіденційність у торгівлі на ланцюжку - проблеми, які зробили зовнішніх інвесторів обережними до DeFi, незважаючи на очевидні переваги, такі як доступ до ліквідності 24/7 та нові механізми генерації доходів.

У цій статті ми надаємо огляд темних басейнів та досліджуємо їх роль у традиційній фінансовій сфері та DeFi. Ми подробиць пояснюємо механіку криптовалютних темних басейнів та обговорюємо потенційні перешкоди для більш широкого прийняття ончейн темних басейнів.

Вступ: Темні басейни в традиційній фінансовій сфері

Незважаючи на звучання зловісне і незаконне, темні басейни фактично є довготривалою складовою (високорегульованої) традиційної фінансової системи. Нижче наведено визначення темного басейну з Investopedia:

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

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

Книга замовлень на біржі з централізованою лімітованою книгою замовлень (CLOB) є публічною.джерело)

Припустимо, Аліса розміщує маркет-ордер на продаж 500 акцій Tesla на біржі. Це невелике замовлення, яке майже не вплине на ціну акцій Tesla, що пропонуються на біржі. Однак розміщення Алісою ордера на продаж 10 мільйонів акцій Tesla – це зовсім інша справа.

У цьому сценарії велике замовлення на продаж, яке видно в книзі замовлень, сигналізує про потенційне зниження попиту на акції Tesla. Софістиковані торгові фірми, особливо ті, які використовують алгоритми торгівлі високої частоти (HFT), ймовірно, підхоплять цей сигнал. Вони можуть діяти швидко, продавши свої утримання до того, як замовлення Еліс буде виконано, передбачаючи зниження ціни на акції Tesla. Внаслідок цього ринкова вартість акцій Tesla може зменшитися, що призведе до гіршої ціни виконання для Аліси. Якщо Аліса не використовує передові торгові техніки, її угода може завершитися збитками, оскільки зниження ціни відбувається до того, як її замовлення буде виконано.

Проблема ускладнюється наявністю фірми HFTякі використовують власні алгоритми, здатні реагувати в реальному часі на активність на біржі з централізованою книгою лімітних заявок (CLOB). Ось кілька гіпотетичних сценаріїв:

Фронтраннинг

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

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

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

Згасання котирування

Продовжимо на прикладі Еліс, але на цей раз зосередимося на поведінці маркет-мейкерів - сутностей, які надають котирування на купівлю та продаж на біржі. Припустимо, що велике замовлення на продаж Аліси стало видимим в публічному замовленні на біржі. Маркет-мейкер спочатку мав пропозицію на купівлю акцій Tesla по $200 за кожну. Побачивши значне замовлення на продаж Аліси, маркет-мейкер може підозрювати, що збільшення пропозиції призведе до падіння ціни акцій Tesla.

Щоб уникнути покупку акцій за 200 доларів, які потім втратили б свою вартість, ринковий мейкер швидко скасовує або змінює своє замовлення на покупку. Ця дія, відома як відсутність котирування, фактично забирає ліквідність з ринку. Коли продаж Аліси, нарешті, виконується, залишається менше покупців, і вона змушена згодитись на нижчу ціну - наприклад, 195 доларів замість 200.

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

Чому темні басейни?

Темні басейни з'явилися в традиційній фінансовій сфері як відповідь на вищезазначені проблеми. На відміну від «освітлених» бірж, у темних басейнах укладаються угоди поза публічними біржами, такими як Нью-Йоркська фондова біржа (NYSE) та Nasdaq. Замовлення, надіслані покупцями та продавцями, співставляються безпосередньо, і тільки оператор має інформацію про замовлення.

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

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

Припустимо, що Еліс вирішила продати 10 мільярдів акцій Tesla в темному басейні, встановивши ціну продажу $1 за акцію. Темний басейн ідентифікує та збігає замовлення Еліс з відповідним замовленням Боба на купівлю 10 мільярдів акцій Tesla за тією самою оцінкою. Коли угода виконується, громадськість залишається незнаючою деталей транзакції до моменту врегулювання. Тільки після цього ринок дізнається, що змінилося 10 мільярдів акцій, але без знання ідентичності покупця або продавця, тим самим захищаючи торгові наміри та стратегії обох сторін.

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

• Боб не знає нічого про Еліс та знає лише, що отримав 10 мільярдів акцій Tesla за 10 мільярдів доларів, а хтось отримав 10 мільярдів доларів за ці акції. Боб не може зникнути з цієї цитати, оскільки стакан замовлень захований - Боб мусить планувати купувати акції насправді, щоб знати, що у когось є 10 мільярдів акцій на продаж (ця інформація відома, коли замовлення збігається).
• Передвиконання угоди Еліс складне, оскільки центральний оператор приховує деталі незавершених ордерів на купівлю і продаж та ринкової ліквідності. Єдиний спосіб, яким угода Еліс стає публічною інформацією, це коли адміністратор темної пулі ділиться інформацією з зовнішніми сторонами (це незаконно, проте).

Сьогодні вже працює десятки пулів, і оцінки свідчать, що 40 відсотків електронних угод здійснюються через темні басейни. Рост популярності темних басейнів співпав ззростаюча регуляція, особливо з урахуванням привілейованого доступу операторів пулів до інформації про очікуючі замовлення (Кредит Суїсс та Барклайз були оштрафовані в 2016 році на загальну суму $150 млн за витік інформації про угоди у темних басейнах до зовнішніх сторін).

Темні пулі в DeFi

(джерело)

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

• Архівні вузли можуть запитувати блокчейн для отримання інформації про історичні транзакції, що взаємодіють з пулом AMM, та перехрещувати їх з онлайн-діяльністю, пов'язаною з певною адресою. Це робить надзвичайно простим для кожного копіювати торгові стратегії, застосовані альфа-трейдерами.
• Mempool, який зберігає інформацію про очікуючі транзакції, є публічним і доступним для будь-кого, хто підключений до повного вузла. Це робить користувачів DEX вразливими до проблеми зникнення котирувань, коли люди скасовують ордери на купівлю/продаж у відповідь на велику угоду, здатну змінити ринок, і призводить до виконання за гіршою ціною для трейдерів.
• Стан після DEX може бути обчислено простим спостерігачем у мемпулі, що відкриває двері до зловживання MEV (максимально добувної вартості) вилучення з боку валідаторів та ботів MEV. Ці учасники можуть спостерігати вплив угоди на пул DEX і вирішувати, чи фронтранити або засендвічити транзакцію, якщо симуляція змін стану виявляє потенційні прибутки. (Те, що користувачі надсилають транзакції «відкрито» для включення в блок, ускладнює проблему.)
• Якщо виробник блоків намагається цензурувати транзакцію користувача, торгівля на DEX може не відбутися. Оскільки інформація про рахунки є публічно доступною, валідатори можуть створювати профілі для конкретних адрес і обирати дискримінацію проти таких контрагентів при обробці транзакцій.
• Валідатори можуть побачити інформацію про транзакцію та вирішити виключити її з наступного блоку. Користувачі не можуть унеможливити валідаторам затемнити деталі транзакції або уникнути розкриття наміру купівлі/продажу токенів.

(Джерело)

Ці проблеми призвели до втрати популярності традиційних DEXів серед великих китів та інституційних трейдерів, які чутливі до ціни та якості виконання. DeFi є найбільшою жертвою, так як DEXи не змогли замінити біржі TradFi, незважаючи на кілька переваг, таких як безкордонні транзакції та довірче, прозоре виконання для користувачів. Нові альтернативи, такі як CowSwap і UniswapXЗдається, що вирішено проблему, але знову появляється потреба вірити центральному оператору, подібно до того, як працюють традиційні темні басейни. Хоча темні басейни в TradFi є приватними в тому сенсі, що інформація про рахунок прихована від інших, ці дані залишаються доступними банку або оператору, що робить їх вразливими до зловживань або протікань, якщо адміністратори є менш ніж здатними або безсовісними.

Перенесення темних басейнів на ланцюг є не лише можливим, але й є оптимальним підходом до створення децентралізованих торговельних платформ, які надають якісне виконання без надмірної залежності від центральних операторів. Хоча вроджена прозорість блокчейнів - де кожен може перевірити обчислювальну точність, запустивши вузол, - може здатися протиріччям функціональності темного басейну, цей виклик можна подолати. Рішення полягає в технології підвищення конфіденційності (PET), криптографічному підході, який дозволяє приховування інформації при збереженні цілісності оновлень в журналі. Це дозволяє нам використовувати можливість перевірки блокчейну, вводячи необхідні для роботи темного басейну функції конфіденційності.

Будівництво децентралізованих темних басейнів може здатися неможливим, оскільки блокчейни призначені для транспарентності та можливості запитів. Фактично саме це робить блокчейни кращими, ніж звичайні бази даних: кожен може запустити вузол та перевірити, що зміни в базі даних обчислені правильно. Але ми можемо обійти це обмеження, використовуючи криптографію - зокрема, технологію, яка підвищує приватність (PET) - яка дозволяє приховувати інформацію, переконуючись, що оновлення до реєстру відповідають правилам.

Як працюють темні басейни?

Не існує єдиного способу побудувати onchain dark pool. Однак усі криптовалютні dark pools мають спільну характеристику: вони використовують різні криптографічні механізми для приховування інформації про onchain-торгівлю та підвищення якості виконання для користувачів.

Мультипартійний обчислення (MPC), докази з нульовим знанням, порогове шифрування, повністю гомоморфне шифрування (FHE) та надійні середовища виконання (TEEs) - це деякі примітиви, доступні для механізмів розробників, що працюють над крипто-орієнтованими темними пулами. Метою у кожному випадку є підтримка гарантій конфіденційності торгівлі без збільшення довірчих припущень або зроблення системи вразливою до маніпуляцій.

Відступник, TristeroіRailgunце приклади onchain dark pools у екосистемі Ethereum. Ми коротко розглянемо кожен з цих протоколів, щоб надати загальне уявлення про те, як onchain dark pools працюють на практиці. Ця стаття буде приділяти увагу Renegade, досліджуючи його дизайн та підхід протоколу до захисту інформації про угоди, укладені учасниками ринку.

Renegade: Прискорення приватного DeFi за допомогою передової криптографії

Renegade - децентралізована, приватність-зберігаюча темна пул, розроблена для вирішення критичних недоліків існуючого децентралізованого торгівельного ландшафту фінансів (DeFi). Використовуючи передові криптографічні техніки, такі як докази нульового знання (ZKP) і множинна обчислювальна операція (MPC), Renegade дозволяє користувачам розміщувати, збігати і вирішувати замовлення безпечно, не розкриваючи свої баланси, торгові наміри або стратегії третім сторонам. На відміну від традиційних DEX, які викривають дані замовлень загальній перевірці, Renegade шифрує всю інформацію про гаманці та замовлення, забезпечуючи приватні торгові операції та стійкість до маніпуляцій.

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

Вирішення проблем поточних систем DeFi

Дизайн сьогоднішніх децентралізованих бірж (DEXes) — чи то на основі автоматизованих маркет-мейкерів (AMMs), чи то на основі централізованих книг лімітованих ордерів (CLOBs) — вводить критичні недоліки, які впливають на всіх учасників, від звичайних користувачів до інституційних трейдерів. Ці проблеми виникають через те, що транзакції та ордери транслюються у відкритому вигляді на прозорих блокчейнах. Хоча прозорість є основою для бездовірної перевірки, вона також піддає трейдерів шкідливим практикам, таким як фронтранінг, зникнення котирування та профілювання адрес.

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

Максимально добувна вартість (MEV)

Середній загальний прибуток MEV (даних за 30 днів) відповідно до EigenPhi

Коли замовлення та транзакції стають видимими у мемпулі, вони стають вразливими до маніпулювання виробниками блоків (у рівні 1) або послідовниками (у рівні 2). Ці актори можуть переупорядкувати, попередити або відстежити транзакції для отримання прибутку. Наприклад, спостерігання великого купівельного або продажного замовлення дозволяє зловживаючим акторам виконати свої транзакції з вищими комісіями за газ (попереднє виконання) або експлуатувати можливості, що виникають відразу після виконання (запуск). Ця форма MEV впливає на всі дизайни DEX, незалежно від того, чи використовують вони архітектуру AMM чи CLOB.

Прозорість угод

Прозорість базових замовлень на блокчейн розкриває трейдерів як передопераційні, так і післяопераційні ризики:

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

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

Профілювання на основі адрес

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

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

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

Для вирішення цих проблем Renegade замінює прозорість контрольованою приватністю за допомогою комбінованого використання доказів з нульовим відомості (ZKP) та багатостороннього обчислення (MPC). ZKP забезпечують, що угоди є дійсними, баланси достатні, а правила протоколу дотримуються, не розкриваючи зміст гаманця або деталі транзакцій. У той же час, MPC забезпечує безпечне зіставлення замовлень, де кілька сторін співпрацюють, щоб знайти відповідність угод без розкриття будь-яких вхідних даних або розкриття конфіденційної інформації.

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

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

Як працює Renegade внутрішньо?

Renegade переосмысляет децентрализованную торговлю, интегрируя передовые криптографические техники, которые переопределяют границы прозрачности, конфиденциальности и справедливости в DeFi. Обращаясь к ограничениям обычных децентрализованных бирж, Renegade представляет инновационный подход, который сочетает технологии с сохранением конфиденциальности с бездоверительной, цепочной торговлей.

Цей розділ надає ближчий погляд на унікальні архітектурні компоненти, які працюють в Renegade. Ми розглянемо:

• Дерево зобов'язань та дизайн гаманця: Як гаманці користувачів залишаються повністю поза ланцюжком та приватними, захищеними криптографічними зобов'язаннями, та керуються складною ієрархією ключів.
• Релейери та супер релейери: Роль релейерів у забезпеченні безпечного відповідності та виконання угод, поряд з їх інтеграцією з делегованими дозволами гаманця.
• MPC механізм співставлення: революційний двосторонній механізм багатостороннього обчислення Renegade, який забезпечує приватне, безпечне співставлення угод.
• Спільні SNARKs: Як атомні розрахунки досягаються завдяки безперервному поєднанню доказів нульового знання з багатопартійним обчисленням.
• Продуктивність та масштабованість: Обговорення компромісів, пов'язаних з вибором дизайну Renegade та тим, як його архітектура збалансовує приватність, децентралізацію та ефективність.

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

Гаманці Renegade та дерево зобов'язань

Renegade вводить модель управління станами, яка надає перевагу конфіденційності та перевіряється. В основі системи знаходиться дерево підписів, глобальне дерево Меркла, до якого можна додавати тільки дані. Дерево зберігає криптографічні представлення (зобов'язання) гаманців користувачів. Ця конструкція гарантує повну конфіденційність вмісту гаманців, забезпечуючи децентралізовані системи, які не вимагають довіри.

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

Аналогія: Гаманці як міні-ролапи

Щоб краще зрозуміти архітектуру Renegade, ми можемо провести паралель з розкладами Ethereum. У розкладі транзакції виконуються поза ланцюгом, де зміни стану відбуваються приватно, і лише кореневий стан, криптографічне представлення кумулятивного стану розкладу, періодично надсилається на Ethereum. Паралельно з цим коренем стану надається доказ знань нульової відомості (ZKP), щоб підтвердити, що перехід стану відповідає правилам протоколу розкладу, не розголошуючи жодних деталей транзакції.

Гаманці Renegade працюють дивовижно схожим чином:

• Виконання поза ланцюжком: Всі операції гаманця, такі як розміщення замовлення, оновлення балансу та виконання угод, відбуваються поза ланцюжком. Ці оновлення відображаються в приватному стані гаманця, недоступному для зовнішніх спостерігачів, включаючи Ethereum.
• Зобов'язання на ланцюжку: Після оновлення стану гаманця, його нове зобов'язання додається до дерева зобов'язань. Це зобов'язання служить криптографічним резюме нових балансів гаманця, замовлень та будь-яких змін, зроблених під час процесу оновлення. Оновлення супроводжується ZKP, що забезпечує валідність переходу від старого стану гаманця до нового.

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

Схема відправки-розкриття для оновлення гаманця

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

1. Розкрийте старий гаманець: Користувач надсилає доказ Меркла, показуючи, що їх попередня зобов'язаність гаманця існує як листок у Дереві зобов'язань. Цей процес розкриття не розкриває жодних подробиць щодо вмісту гаманця, що зберігає передторговельні гарантії конфіденційності Renegade. Система вивчає лише те, що зобов'язання гаманця є дійсним та включеним до дерева.
2. Обчислення нульовиків: Щоб запобігти повторному використанню старих станів гаманця, Renegade потребує обчислення двох нульовиків для кожного гаманця: нульовика витрачення гаманця та нульовика відповідності гаманця. Ці нульовики походять від зобов'язаності старого гаманця та приватного випадкового значення, що забезпечує унікальність.

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

1. Зобов'язатися до нового гаманця: Користувач генерує новий стан гаманця, який відображає бажані оновлення, такі як розміщення замовлення, коригування балансу або вирішення угоди, і обчислює його криптографічне зобов'язання. Подається ZKP для підтвердження наступного:
   • Старе зобов'язання гаманця існує у Дереві зобов'язань.
   • Нульовізатори обчислюються правильно й унікально.
   • Перехід від старого стану гаманця до нового відповідає правилам протоколу (наприклад, відсутність несанкціонованого збільшення балансу).
   • Користувач має секретні ключі, необхідні для авторизації оновлення.

Якщо доказ перевірено та нульіфікатори підтверджені як невикористані, смарт-контракт позначає нульіфікатори старого гаманця як "витрачені" та вставляє нове зобов'язання в Дерево зобов'язань.

(Джерело: Документація Renegade)

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

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

Ієрархія ключів та система релеїв

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

Як працює ієрархія ключів

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

• Коренева пара ключів: Коренева пара ключів - це пара ключів ECDSA (крива secp256k1), ідентична стандартному приватному ключу Ethereum. Це найбільш авторитетний ключ і надає повну власність над гаманцем. Усі операції, які змінюють стан гаманця - такі як внесення, виведення, розміщення замовлень або скасування - потребують підпису від кореневого секретного ключа. Для забезпечення максимальної безпеки кореневий ключ зберігається виключно на клієнтському боці і ніколи не надається жодній зовнішній стороні, включаючи релейери.
• Скаляр збігів: Скаляр збігів - це секретне скалярне значення, визначене на кривій bn254, і використовується як механізм, за допомогою якого релейєри мають дозвіл надсилати збіги для вирішення до розумного контракту або базового рівня. На відміну від традиційних асиметричних ключів, скаляр збігів є одним секретним значенням, яке релейєри використовують для генерації доказів нульового знання (ZKPs), щоб довести своє знання про передобраз скалярного значення під хешем Poseidon. Це гарантує, що релейєри можуть вирішувати лише збіги, на які є явний дозвіл у конфігурації гаманця. Крім того, скаляр збігів у парі з попередньо визначеними комісіями в гаманці дозволяє користувачам вказувати точні витрати, які релейєри можуть стягувати за свої послуги.
• Симетричний API-ключ: Симетричний API-ключ є інструментом, який використовується поза протоколом для аутентифікації взаємодії між користувачем та релеєм. Він дозволяє релеїв передавати оновлення в реальному часі, такі як зміни гаманця або статуси замовлень, користувачеві, не компрометуючи безпеку гаманця або його криптографічну цілісність. Хоча він не прямо пов'язаний з операціями гаманця, цей ключ полегшує безперебійну комунікацію та покращує загальний досвід торгівлі.
• Сліпий насіння та ділитися насінням: Сліпий насіння та ділитися насінням є важливими компонентами, які дозволяють ретрансляторам розшифрувати та обробляти інформацію гаманця безпечно. Ці насіння виконують функцію ключів перегляду, надаючи ретрансляторам змогу отримати доступ до приватного стану гаманця. Однак як насіння, вони динамічно хешуються у значення, які змінюються з кожною транзакцією. Це забезпечує, що значення сліпого та ділити незалежні від поточної операції, запобігаючи будь-якому повторному використанню чи ненавмисному доступу.

Blinder seed відповідає за індексацію гаманця on-chain шляхом створення криптографічного хеш-ланцюжка, який зв'язує стани гаманця. Це забезпечує, що присутність гаманця в дереві зобов'язань залишається доведеною, не викриваючи його вмісту.

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

Як працюють релейєри в renegade

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

Відносини між релеєрами та ієрархією ключів ґрунтуються на чіткій моделі делегування. Користувачі діляться лише необхідними секретами, такими як збіговий скаляр, насіння затемнення та насіння діления, з релеєрами. Ці секрети дають релеєру можливість перегляду та обробки даних гаманця безпечно. Збіговий скаляр дозволяє релеєрам авторизувати та вирішувати збіги, доводячи знання преімеджа хешу Poseidon через докази з нульовим розголошенням (ZKPs). Насіння затемнення та насіння діления, забезпечують доступ релеєрів до даних гаманця без їх викриття перед зовнішніми спостерігачами та без несанкціонованого контролю. Це поділ влади забезпечує можливість релеєрам виконувати делеговані завдання, не компрометуючи загального контролю або безпеки користувача.

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

Relayers також надають значну зручність процесу торгівлі, оброблюючи обчислювальну складність збігу замовлень з двигуном збігів MPC та забезпечуючи дійсність цих збігів за допомогою спільних SNARKs. Цей механізм дозволяє ретрансляторам знезавди завантажити багато технічного бремені від користувачів, забезпечуючи при цьому строгі передопераційні та післяопераційні гарантії конфіденційності Renegade. Безпечно керуючи цими операціями, ретранслятори не тільки захищають чутливі дані гаманця під час збігу замовлень та розрахунків, але й полегшують багато проблем, пов'язаних з користувацьким досвідом, які зазвичай виникають у системах збереження конфіденційності. Їх здатність надавати оновлення в реальному часі за допомогою симетричного ключа API додатково покращує користувацький досвід, забезпечуючи, що користувачі залишаються в курсі своїх угод та стану гаманця без порушення безпеки.

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

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

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

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

Система релейерів, інтегрована зі Системою Ключової Ієрархії, додатково підвищує користувацький досвід та ефективність функціонування Renegade. Релейери спрощують процес торгівлі, керуючи обчислювально інтенсивними задачами збігу замовлень та розрахунків, використовуючи двигун відповідності MPC та доведення SNARK для забезпечення приватності та правильності. У той же час, їхня здатність надавати оновлення у реальному часі за допомогою симетричного API-ключа зводить до мінімуму відстань між надійними гарантіями конфіденційності та плавним користувацьким досвідом.

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

Як виконуються замовлення в Renegade

У Renegade процес зведення замовлень об'єднує дії користувачів, сприяння посередників та передові протоколи криптографії, щоб створити безперервний та конфіденційний досвід торгівлі. У цьому розділі розглядається шлях одного замовлення - від його створення користувачем до остаточного врегулювання - пояснюються роль посередників, механіка двохчастинного (MPC) зведення та гарантії безпеки, надані спільними SNARKs. Досліджуючи ці етапи, ми розкриємо, як Renegade забезпечує, що угоди залишаються приватними, атомними та повністю перевірними, не жертвуючи зручністю або недовірою.

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

Користувач створює замовлення

Шлях зіставлення замовлень у Renegade починається з того, що користувач взаємодіє з інтерфейсом, щоб створити замовлення. Це передбачає визначення ключових параметрів, таких як торгова пара (наприклад, WETH/USDC) і кількість, якою вони хочуть торгувати. На відміну від традиційних систем, Renegade не підтримує лімітні ордери, оскільки Renegade не є центральною книгою лімітних ордерів (CLOB) і має на меті уникнути непотрібних складнощів, натомість кожен ордер прив'язаний до середньої точки, тобто угода виконується в середній точці переважаючого спреду на великих біржах, таких як Binance, Coinbase, OKX і Kraken. Після того, як ціна визначена на основі даних з кількох майданчиків, користувачі підтверджують деталі свого замовлення, а програмне забезпечення гаманця плавно оновлює стан, щоб відобразити новий порядок, дотримуючись архітектури Renegade, що зберігає конфіденційність.

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

ПЗ гаманця потім надсилає оновлене зобов'язання до дерева зобов'язань як частину схеми коміт-розкриття Ренегата, разом з доказом нульового знання (ZKP), який підтверджує всю транзицію. Цей доказ забезпечує, що оновлення гаманця відповідає протокольним правилам, включаючи достатні баланси та правильні переходи стану, не розкриваючи жодних чутливих деталей про замовлення або вміст гаманця. Після перевірки транзиції старий гаманець позначається як витрачений, а нове зобов'язання безпечно додається до Дерева Зобов'язань.

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

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

Relayer обробляє замовлення

Як тільки користувач розміщує замовлення, релей стає невід'ємною частиною процесу, забезпечуючи безпечні та приватні взаємодії між гаманцем користувача та ширшою системою Renegade. Завдяки делегованим секретам - скаляру відповідності, насінню затемнення та насінню ділення - релей розшифровує гаманець користувача, щоб отримати доступ до деталей новоствореного замовлення. Ця делегація робить релей критичним посередником, який безперешкодно мости приватний гаманець користувача та більший торговий екосистема, забезпечуючи ефективне співставлення замовлень та повне відповідність з гарантіями конфіденційності та безпеки протоколу.

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

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

• Криптографічні зобов'язання до деталей замовлення (наприклад, пара токенів, сума, ціна).
• Zero-знання предикат, який криптографічно доводить, що замовлення є дійсним згідно правил протоколу, не розкриваючи чутливих деталей, таких як баланси гаманця або конкретики замовлення.
• Для перевірки сумісності потрібні додаткові метадані, такі як комісії та вимоги до розрахунків.

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

(Джерело: документація Renegade)

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

Відповідність замовлень

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

(Джерело: документація Renegade)

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

Якщо двигун MPC визначає, що замовлення сумісні, він генерує кортеж матчу, криптографічне представлення матчу. Цей кортеж включає важливі деталі, такі як токени, які будуть обмінюватися, залучені суми та напрямок торгівлі для кожного учасника.

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

(Джерело: документація Renegade)

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

Для підтвердження кортежу відповідності релеї спільно будують спільне доказ SNARK, який криптографічно підтверджує, що відповідність є дійсною згідно з правилами протоколу. Цей доказ забезпечує, що:

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

Співпрацюючі докази SNARK відіграють важливу роль у забезпеченні цілісності процесу зведення. Шляхом посилання зашифрованих вихідних даних двигуна МПК на зобов'язання, що зберігаються в Дереві зобов'язань, вони надають механізм перевірки без довіри, який гарантує відповідність зведення правилам протоколу Renegade. Тільки після перевірки доказу до зашифрованих значень у кортежі зведення, таких як суми, які будуть обмінюватися, стають доступними. Цей фазовий підхід забезпечує конфіденційність торгівлі обох сторін протягом процесу зведення та перевірки.

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

Завершення угоди

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

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

Після підтвердження зашифрованих торгових записів та доказів, розумний контракт Renegade оновлює дерево зобов'язань та позначає замовлення як «обтяжені» - забороняючи подальші дії до розрахунку. Ці зашифровані записи зберігаються в дереві зобов'язань для посилання на розрахунок. Ця фаза демонструє приватно-безпечну архітектуру Renegade: зашифровані деталі торгівлі, поєднані з криптографічними доказами, забезпечують безвідмовну, приватну торгівлю, забезпечуючи перевірку протягом усього процесу розрахунку.

Продуктивність та масштабованість

У цьому розділі розглядаються дві фундаментальні виклики, які виникають внаслідок інноваційних дизайнерських виборів Renegade:

• Обчислювальні витрати MPC та SNARKs: Компроміси в часі затримки та вимогах до ресурсів, які вводяться цими передовими криптографічними техніками.
• Масштабованість мережі посередника: Як інфраструктура взаємодії ренегата керує великими обсягами торгів та адаптується до різних потреб користувачів.

Давайте детальніше розглянемо кожен з них.

Обчислювальні витрати ГДК і СНАРК

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

Аналогічно, генерація спільних SNARK-доказів є витратним завданням. Хоча SNARK-и призначені для ефективної перевірки on-chain, їх створення включає велику кількість криптографічних операцій, особливо при доведенні складних заяв, таких як валідність замовлення та перехід стану гаманця. Ці обчислювальні витрати додаються до часу та ресурсів, необхідних для завершення угоди, що робить її менш підходящою для сценаріїв, що вимагають високочастотного або миттєвого торгівлі.

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

Масштабованість мережі ретрансляторів

Конструкція Renegade мінімізує довіру до ретрансляторів, покладаючись на них лише для жвавості, необхідної для узгодження угод. Крім цього, ретранслятори не мають повноважень щодо зберігання чи прийняття рішень, оскільки всі дії криптографічно перевіряються за допомогою доказів із нульовим розголошенням (ZKP). Ця безнадійна конструкція означає, що посилення ретрансляторів обчислювальним шляхом, наприклад, за рахунок збільшення їх обчислювальної потужності для обробки більшої кількості угод, не створює значних ризиків. У той же час, мережева архітектура Renegade повністю інклюзивна, що дозволяє різноманітним ретрансляторам, різним за розміром і обчислювальними можливостями, співіснувати в межах однієї екосистеми, не викликаючи жодних системних проблем.

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

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

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

(Джерело: Документація Ренегату)

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

Висновок

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

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

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

Відмова від відповідальності:

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