nous venons de terminer l'examen du projet, voici donc un court fil sur @Lighter_xyz 🧵

la première grande différence entre Lighter et la récente vague de chaînes perpétuelles est l'utilisation de preuves zk. Le pont détenant plus de 1 milliard de dollars n'autorise que les retraits qui ont été prouvés par un programme fixe. À cause de cela, les validateurs ne peuvent pas simplement signer un retrait invalide pour voler des fonds.

la mauvaise nouvelle est que le programme prouvé par les zk proofs n'est pas disponible en source, donc il n'est actuellement pas possible de vérifier si la chaîne implémente correctement sa logique commerciale. L'équipe nous a communiqué qu'elle travaille à le rendre public dans 1 ou 2 semaines.

en supposant que le programme est bon, les preuves zk à elles seules ne suffisent pas à prévenir la perte de fonds. par exemple, le séquenceur centralisé pourrait censurer vos demandes de retrait, ou vos demandes d'annulation d'une commande. heureusement, @Lighter_xyz met en œuvre des transactions forcées via L1.

si un utilisateur ne peut pas faire inclure sa transaction en l'envoyant au séquenceur, il peut la forcer à travers L1, héritant d'une pleine résistance à la censure. le séquenceur a maintenant deux options : soit il inclut la tx et tout le monde est content, soit le projet est contraint de fermer.

oui, vous avez bien lu : le séquenceur a maintenant un fort incitatif à inclure toutes les demandes, sinon le système peut être mis en "mode désert", c'est-à-dire arrêté. Les transactions forcées que le séquenceur ne peut pas ignorer incluent : les retraits, les dépôts, la création et l'annulation de commandes.

mais comment les utilisateurs peuvent-ils sortir si le système est arrêté ? c'est là qu'intervient l'échappatoire : puisque lighter est un rollup et garantit la disponibilité des données avec des blobs, les utilisateurs peuvent reconstruire l'état le plus récent et prouver leurs soldes pour sortir. tous les ordres ouverts sont réglés en utilisant le dernier prix.

le projet est actuellement évolutif avec un délai de 21 jours, mais ce délai peut être réduit à zéro par un "conseil de sécurité" formé par un multisig 3/5. Cela empêche déjà le système d'être considéré comme étant au stade 1. L'équipe a communiqué des plans pour améliorer cette configuration.

une autre préoccupation découle des prix des indices. les oracles externes utilisés par le projet ne sont actuellement pas correctement authentifiés et le séquenceur est entièrement digne de confiance pour les rapporter correctement. c'est une vulnérabilité critique que l'équipe a exprimé son intention de résoudre.

Enfin, il est assez clair d'après les contrats que l'équipe s'est fortement inspirée de l'ancien @zksync lite, ce qui est bon ! zksync lite, avec dYdX v3, ont toujours été reconnus comme des rollups spécifiques aux applications avec de très bons modèles de sécurité.