TL;DR della risposta di Matt sul perché Tempo è un L1: la specifica del prodotto desiderato per la catena dei pagamenti è più facile da costruire come un L1 piuttosto che come un L2. Lezione per i progetti infrastrutturali: i progetti del tuo ecosistema target dovrebbero naturalmente utilizzare la tua infrastruttura/piattaforma se ragionano a partire dai principi fondamentali su come costruire al meglio la specifica del prodotto desiderato. Le specifiche del prodotto delle app determinano l'infrastruttura necessaria (vedi QT).

La frammentazione delle catene è ottima per i protocolli di interoperabilità. Ora che Tether, Circle e Stripe stanno costruendo diversi L1 di pagamento, è sempre più improbabile che avremo un L1 di pagamento globalmente dominante. Di conseguenza, l'interoperabilità tra le catene di pagamento diventa necessaria. - Gli indirizzi interoperabili della forma "address@chain" (ad es. ERC7930) diventeranno lo standard (de facto) - L'interoperabilità nativa supportata dalle catene o dagli emittenti di asset e l'interoperabilità supportata esternamente, come i ponti basati su intent o solver, continueranno a migliorare. Una catena assomiglierà quindi più a una banca o a un server di posta piuttosto che a un giardino recintato verticalmente come le piattaforme social e di e-commerce web2.

Cosa succede se un grande hack (come l'hack di Bybit) colpisce un asset RWA invece di Eth? Quale parte dello stack dovrebbe essere coinvolta nel ripristino dei danni causati dall'hack, se ce ne sono? Credo che la verità alla domanda si trovi da qualche parte tra le posizioni di @malekanoms e @CampbellJAustin (vedi il dibattito informativo nel QT): - Un layer base può essere massimamente credibilmente neutro - Tuttavia, ogni sforzo di tokenizzazione sul layer base può essere soggetto a regolamenti in diverse giurisdizioni. Questo può essere fatto a livello di smart contract (anziché fare affidamento su catene consortili, come accenna @CampbellJAustin): Circle già applica blacklist. Ci sono anche proposte di "ERC20 reversibili" che potrebbero annullare transazioni su un layer base neutro senza il coinvolgimento di validatori. Un altro punto che è stato trascurato nel dibattito riguarda le catene private, il rischio controparte e il ruolo delle prove a conoscenza zero. Le catene private non hanno senso storicamente perché erano semplicemente database operati privatamente. Tuttavia, con ZK, una catena privata può eliminare i rischi controparte, poiché l'operatore deve attenersi a regole predefinite quando gestisce la catena. Inoltre, se un validium privato (ad esempio, ZKsync prividium) si regola frequentemente su un layer base neutro, c'è anche protezione contro l'equivocazione da parte dell'operatore della catena privata. Lo spazio di design tra un layer base neutro e un'infrastruttura che riflette i sistemi legali del mondo reale è vasto. Dobbiamo discutere su come costruire sistemi migliori, piuttosto che concentrarci esclusivamente su ciò che esiste oggi.