Comment j'aurais pu construire tempo en tant que L2 Séparer tempo en plusieurs composants : - un L2 OP stack zk validium. Cela évite le problème de la tarification de la surcharge de blob en gardant les données de transaction hors chaîne. - un SDK de couche d'application tempo pour incarner toutes les personnalisations de paiement qu'ils souhaitent, telles que des mémos intégrés et le paiement des frais en n'importe quel stablecoin. C'est le point d'entrée de Stripe dans la pile. - SDK d'enshrinement tempo, qui est l'ensemble des contrats standard/"TempoERC" qu'ils s'attendent à voir sur n'importe quelle "chaîne tempo". - utiliser plusieurs L2 automatiquement en arrière-plan dans le SDK tempo. En particulier, le scaling fractal L3 réglé sur le L2 validium tempo et les L2 ultra-scalés comme Mega et Rise. - utiliser des préconfirmations L2 liées pour une finalité rapide qui est absolument suffisante ; ne les laissez pas vous dire que la "finalité" alt L1 est meilleure, ce n'est pas le cas car littéralement rien ne les empêche de réécrire l'histoire de l'alt L1. Les préconfirmations liées sont extrêmement prometteuses et sous-explorées (Arb a été pionnier) : Par exemple, vous soumettez une transaction de paiement à l'un des L2 pris en charge par tempo, et en 200 ms, ils vous donnent une garantie prouvable bornée de finalité ou ils vous paient 10 millions de dollars. Ces types de liens de préconf peuvent fonctionner sur des chaînes tierces prises en charge par Tempo où Tempo ne gère pas le séquenceur, comme Mega ou Rise. Les préconf peuvent également offrir des garanties structurées en couches de finalité, telles que "inclus dans les N prochains blocs L2, ainsi que dans les M prochains blocs L1, à moins que le gaz L1 n'augmente au-dessus de Z gwei, auquel cas la finalité L1 est garantie dans les 100*M prochains blocs". Tout cela avec des paiements entièrement automatiques si la garantie n'est pas respectée. Des voies rapides pour les paiements peuvent prendre la forme de L3 fractal dédiés spécifiquement pour certains clients ou points de prix, ou une voie rapide dans le L2 core tempo qui offre des garanties de finalité beaucoup plus fortes/rapides. Tempo est un projet passionnant dirigé par deux organisations (Stripe et Paradigm) qui sont exactement le genre d'acteurs techniques sérieux et connectés qui sont prêts à réaliser le type d'architecture de pointe discuté ci-dessus. Il est ironique que Patrick ait dit que les utilisateurs/clients de paiement ne devraient pas se soucier de la chaîne qu'ils utilisent et qu'ils aient décidé de lancer leur propre One True Chain alors que d'excellentes architectures multi L2/L3 sont facilement disponibles-- non seulement en utilisant les propres L2/L3 de tempo, mais aussi d'excellents L2 ultra-scalés tiers. C'est tout simplement un meilleur modèle-- réduit le risque en découplant les innovations de paiement du choix initial de la chaîne. C'est un meilleur modèle, même avant de tenir compte de l'animosité et du coefficient de traînée que Paradigm a attisé en lançant un alt L1 avec une justification fallacieuse. Quel concurrent de Stripe finira par essayer quelque chose comme ce qui précède en premier ? Ce n'est qu'une question de temps.