Na konci víkendu jsem přemýšlel o breakout aplikacích tohoto cyklu, co mají společného a jak to souvisí s tím, co děláme v SOCKET. Konkrétně mnoho úspěšných aplikací změnilo hru tím, že se odpoutalo od přijímaného statu quo a zavedlo nové architektury, které nabízejí nové primitiva nebo lepší uživatelské zážitky. @hyperliquid -> změnil design mempoolu tak, aby upřednostňoval zrušení objednávek v rámci bloku - zásadní pro úspěch knihy objednávek v řetězci, získání MM pro zajištění likvidity a zabránění záplavě neúspěšných TX @cowswap -> zavedla off-chain aukce, aby umožnila dávkování uživatelských TX, našla COW a umožnila soutěž řešitele @ethena -> provádí bazický obchod na CEX na rozdíl od předchůdců, kteří byli omezeni na mnohem menší perp DEX - při zachování kolaterálu v řetězci To je přesně budoucnost, kterou si představujeme. Protokol řetězové abstrakce SOCKET umožňuje tvůrcům vytvářet aplikace, které těží z podobných úrovní přizpůsobení prostřednictvím konceptu AppGateway. AppGateways jsou abstrakcí na úrovni aplikace, která stojí nad všemi řetězci - mezi uživateli a kontrakty v řetězci. S AppGateway mohou tvůrci aplikací definovat jakoukoli logiku před spuštěním transakcí předtím, než se dostanou do řetězce. Transakce uživatele narazí na bránu, AppGateways spustí její logiku a poté se v řetězci provede proud transakcí. Kterýkoli ze 3 předchozích příkladů mohl být postaven na SOCKET. Ale kde to opravdu září, je, pokud chce tvůrce aplikací napsat aplikaci, která běží logicky na několika řetězcích. Se SOCKETem mohou psát své aplikace v normální solidnosti, jako by běžela na jednom řetězci. Smlouvy na jednom řetězci se mohou bez problémů skládat se smlouvami na jiných řetězcích nebo dokonce s off-chain systémy. Důležité je, že nemusí psát ultra složitý kód špaget, aby se vypořádali se zprávami napříč řetězci. Žádat tvůrce aplikací v oblasti kryptoměn, aby rozuměl zasílání zpráv napříč řetězci, je jako žádat vývojáře web2, aby se zabýval protokolem TCP/IP a staral se o přenos a směrování datových paketů vysílaných jeho aplikací. Na to kašlu. V dnešním stavu před SOCKET musí stavitel, který chce např. číst cenu aktiva na 3 různých řetězcích, aby mohl provést obchod tam, kde je nejlevnější, napsat smlouvu, která pošle zprávy do všech řetězců, načte ceny, vrátí zprávy do původního řetězce a vypořádá se s ověřením zpráv, náklady a latencí. Pomocí aktuální sady nástrojů není možné vytvořit bezproblémové uživatelské prostředí. Z pohledu tvůrce aplikací se můžete na soket dívat jako na to, že se stará o veškerou orchestraci nezbytnou napříč řetězci k vypořádání toho, co bylo definováno v AppGateway armádou off-chain aktérů, kteří provádějí akce vašich uživatelů s modulárním zabezpečením v chainu. V současné době máme ve výrobě: @BungeeExchange našem tržišti likvidity s objemem 1 miliardy > USD za měsíc je první aplikací postavenou na SOCKET. BungeeGateway je místo, kde jsou záměry a transakce uživatelů zpracovávány a porovnávány s řešiteli a fillery. @useenclave buduje vrstvu "Universal Balance" jako službu, která umožní peněženkám abstrahovat roztříštěné zůstatky v řetězci a nahradit je zastupitelným zůstatkem, který mohou uživatelé okamžitě utratit v jakémkoli řetězci. Zde EnclaveGateway páruje uživatelské objednávky s Paymasters. @rathfinance mění výnos DeFi na nativní funkci peněženek. Prostředky uživatelů jsou automaticky směrovány k nejlepším příležitostem napříč řetězci bez dalších kroků. projekty jako @derivexyz @aevoxyz @KintoXYZ @reya_xyz atd. používají SOCKET pro řetězově abstrahovaná uložení do své aplikace. Ale teprve začínáme škrábat po povrchu toho, co je možné vytvořit pomocí tohoto nového způsobu vytváření aplikací. Je to doslova Den 0 pro Chain Abstraction. Pokud dnes budujete něco ambiciózního v kryptoměnách - ozvěte se nám.