На вихідних я розмірковував про додатки для проривів цього циклу, про те, що у них спільного і як це пов'язано з тим, що ми робимо в SOCKET. А саме, багато успішних додатків змінили правила гри, відійшовши від прийнятого статус-кво, і представили нові архітектури, щоб запропонувати нові примітиви або кращий користувацький досвід. @hyperliquid > змінено дизайн мемпулу, щоб надавати пріоритет скасуванню замовлень у блоці - це має вирішальне значення для успіху книги ордерів у мережі, щоб забезпечити ліквідність і уникнути потоку невдалих TX. @cowswap > запроваджено аукціон поза мережею, щоб дозволити пакетування користувацьких tx, знаходити COW та забезпечувати конкуренцію розв'язувачів. @ethena -> виконує базисну торгівлю на CEX, на відміну від попередників, які були обмежені набагато меншими perp DEX, зберігаючи при цьому заставу в ланцюжку Саме таке майбутнє ми собі уявляємо. Протокол ланцюгової абстракції SOCKET дозволяє розробникам створювати додатки, які отримують вигоду від аналогічних рівнів кастомізації за допомогою своєї концепції AppGateway. AppGateways - це абстракція на рівні додатка, яка знаходиться над усіма ланцюжками - між користувачами та ончейн-контрактами. За допомогою AppGateway розробники додатків можуть визначити будь-яку логіку перед виконанням транзакцій, перш ніж вони потраплять у ланцюжок. Транзакція користувача потрапляє на шлюз, AppGateways запускає свою логіку, а потім потік транзакцій виконується в ланцюжку. Будь-який з 3 більш ранніх прикладів може бути побудований на SOCKET. Але де це дійсно яскраво, так це якщо розробник додатків хоче написати додаток, який працює на декількох ланцюжках. За допомогою SOCKET вони можуть писати свій додаток у звичайній монолітності, ніби він працює на одному ланцюжку. Контракти на одному ланцюгу можуть легко поєднуватися з контрактами в інших ланцюгах або навіть з офчейн-системами. Важливо, що їм не потрібно писати надскладний спагетті-код, щоб впоратися з крос-чейн обміном повідомленнями. Попросити розробника додатків у криптовалюті зрозуміти крос-чейн обмін повідомленнями — це все одно, що попросити розробника web2 розібратися з TCP/IP, щоб впоратися з транспортуванням і маршрутизацією пакетів даних, що випромінюються їхнім додатком. До біса це. У сьогоднішньому статус-кво перед SOCKET розробник, який хоче, наприклад, прочитати ціну активу в 3 різних ланцюгах, щоб виконати угоду, де вона найдешевша, повинен написати контракт, який надсилає повідомлення всім ланцюгам, отримувати ціни, повертати повідомлення в початковий ланцюг і займатися перевіркою повідомлень, вартістю та затримкою. Неможливо побудувати бездоганний користувацький досвід за допомогою поточного набору інструментів. З точки зору конструктора додатків, ви можете розглядати SOCKET як такий, що піклується про всю оркестровку, необхідну в ланцюгах, щоб вирішити те, що було визначено в AppGateway армією офчейн-акторів для виконання дій ваших користувачів із модульною безпекою в ланцюжку. У виробництві на даний момент ми маємо: @BungeeExchange наш маркетплейс ліквідності, який має обсяг >1 мільярд доларів на місяць, є першим додатком, побудованим на SOCKET. BungeeGateway - це місце, де наміри та транзакції користувача обробляються та зіставляються з розв'язувачами та наповнювачами. @useenclave створює рівень «Універсальний баланс» як послугу, щоб дозволити гаманцям абстрагуватися від фрагментованих балансів ланцюгів і замінювати їх взаємозамінним балансом, який користувачі можуть миттєво витратити на будь-який ланцюг. Тут EnclaveGateway зіставляє замовлення користувачів з Paymasters. @rathfinance перетворює прибутковість DeFi на нативну функцію для гаманців. Кошти користувачів автоматично спрямовуються на найкращі можливості між ланцюгами без зайвих кроків. Такі проекти, як @derivexyz @aevoxyz @KintoXYZ @reya_xyz і т.д., використовують SOCKET для депозитів у своєму додатку. Але ми лише починаємо розуміти, що можна створити за допомогою цього нового способу створення додатків. Це буквально 0-й день для ланцюгової абстракції. Якщо ви створюєте щось амбітне в криптовалюті сьогодні - звертайтеся до нас.