TL;DR van Matt's reactie over waarom Tempo een L1 is: de gewenste productspecificatie voor de betalingsketen is gemakkelijker te bouwen als een L1 in plaats van als een L2. Les voor infrastructuurprojecten: je doel-ecosysteemprojecten zouden natuurlijk gebruik moeten maken van je infrastructuur/platform als ze redeneren vanuit de eerste principes over hoe ze het beste hun gewenste productspecificatie kunnen bouwen. De productspecificaties van apps bepalen de vereiste infrastructuur (zie QT).

Fragmentatie van ketens is geweldig voor interoperabiliteitsprotocollen. Nu Tether, Circle en Stripe allemaal verschillende betalings L1's bouwen, is het steeds onwaarschijnlijker dat we één wereldwijd dominante betalings L1 zullen hebben. Als gevolg hiervan wordt interoperabiliteit tussen betalingsketens noodzakelijk. - Interoperabele adressen van de vorm "address@chain" (bijv. ERC7930) zullen de (de facto) standaard worden. - Native interop ondersteund door ketens of activa-uitgevers en extern ondersteunde interop, zoals intent- of solver-gebaseerde bruggen, zullen blijven verbeteren. Een keten zal dan meer lijken op een bank of mailserver dan op een verticaal geïntegreerde afgesloten tuin zoals web2 sociale en e-commerce platforms.

Wat gebeurt er als een grote hack (zoals de Bybit-hack) plaatsvindt bij een RWA-activum in plaats van Eth? Welk deel van de stack zou betrokken moeten zijn bij het ongedaan maken van de schade van de hack, indien van toepassing? Ik geloof dat de waarheid van de vraag ergens ligt tussen de posities van @malekanoms en @CampbellJAustin (zie het informatieve debat in de QT): - Een basislaag kan maximaal geloofwaardig neutraal zijn. - Echter, elke tokenisatie-inspanning op de basislaag kan onderworpen zijn aan regelgeving in verschillende rechtsgebieden. Dit kan gedaan worden op de smart contract-laag (in plaats van te vertrouwen op consortiumketens, zoals @CampbellJAustin suggereert): Circle handhaaft al zwarte lijsten. Er zijn zelfs "omkeerbare ERC20" voorstellen die transacties op een neutrale basislaag kunnen terugdraaien zonder betrokkenheid van validators. Een ander punt dat in het debat werd gemist, betreft private ketens, tegenpartijrisico en de rol van zero-knowledge proofs. Private ketens maken historisch gezien geen zin omdat ze gewoon privé beheerde databases waren. Echter, met ZK kan een private keten tegenpartijrisico's elimineren, aangezien de operator zich moet houden aan vooraf gedefinieerde regels bij het bedienen van de keten. Bovendien, als een private validium (bijv. ZKsync prividium) frequent afrekent naar een neutrale basislaag, is er ook bescherming tegen tegenstrijdigheid van de operator van de private keten. De ontwerpruimte tussen een neutrale basislaag en infrastructuur die de juridische systemen van de echte wereld weerspiegelt, is enorm. We moeten bespreken hoe we betere systemen kunnen construeren, in plaats van ons uitsluitend te concentreren op wat er vandaag de dag bestaat.