TL;DR odpowiedzi Matta na pytanie, dlaczego Tempo jest L1: pożądana specyfikacja produktu dla łańcucha płatności jest łatwiejsza do zbudowania jako L1 zamiast L2. Lekcja dla projektów infrastrukturalnych: projekty w twoim docelowym ekosystemie powinny naturalnie korzystać z twojej infrastruktury/platformy, jeśli rozważają od podstaw, jak najlepiej zbudować swoją pożądaną specyfikację produktu. Specyfikacje produktów aplikacji określają wymaganą infrastrukturę (patrz QT).

Fragmentacja łańcuchów jest świetna dla protokołów interoperacyjności. Teraz, gdy Tether, Circle i Stripe budują różne płatnicze L1, coraz mniej prawdopodobne jest, że będziemy mieli jeden globalnie dominujący L1 płatniczy. W rezultacie interoperacyjność między łańcuchami płatniczymi staje się koniecznością. - Interoperacyjne adresy w formie "adres@łańcuch" (np. ERC7930) staną się (de facto) standardem - Natywna interoperacyjność wspierana przez łańcuchy lub emitentów aktywów oraz zewnętrznie wspierana interoperacyjność, jak mosty oparte na intencjach lub solverach, będą nadal się poprawiać. Łańcuch będzie bardziej przypominał bank lub serwer pocztowy niż pionowo zintegrowany zamknięty ekosystem, jak platformy społecznościowe i e-commerce web2.

Co się stanie, jeśli dojdzie do poważnego włamania (jak włamanie do Bybit) w przypadku aktywów RWA zamiast Eth? Która część stosu powinna być zaangażowana w naprawę szkód spowodowanych włamaniem, jeśli w ogóle? Uważam, że prawda na to pytanie leży gdzieś pomiędzy stanowiskami @malekanoms i @CampbellJAustin (zobacz informacyjną debatę w QT): - Warstwa bazowa może być maksymalnie wiarygodnie neutralna - Jednak każdy wysiłek tokenizacji na warstwie bazowej może podlegać regulacjom w różnych jurysdykcjach. Można to zrobić na poziomie smart kontraktów (zamiast polegać na łańcuchach konsorcjalnych, jak sugeruje @CampbellJAustin): Circle już egzekwuje czarne listy. Istnieją nawet propozycje "odwracalnych ERC20", które mogłyby cofnąć transakcje na neutralnej warstwie bazowej bez udziału jakichkolwiek walidatorów. Kolejny punkt, który został pominięty w debacie, dotyczy prywatnych łańcuchów, ryzyka kontrahenta i roli dowodów zerowej wiedzy. Prywatne łańcuchy nie mają sensu historycznie, ponieważ były po prostu prywatnie zarządzanymi bazami danych. Jednak dzięki ZK, prywatny łańcuch może wyeliminować ryzyko kontrahenta, ponieważ operator musi przestrzegać z góry określonych zasad podczas działania łańcucha. Co więcej, jeśli prywatny validium (np. ZKsync prividium) często rozlicza się z neutralną warstwą bazową, istnieje również ochrona przed sprzecznością ze strony operatora prywatnego łańcucha. Przestrzeń projektowa między neutralną warstwą bazową a infrastrukturą odzwierciedlającą rzeczywiste systemy prawne jest ogromna. Musimy omówić, jak zbudować lepsze systemy, zamiast koncentrować się wyłącznie na tym, co istnieje dzisiaj.