Rédigé par : 0xTodd

À l'occasion du TGE officiel de Zircuit de $ZRC, parlons d'un mécanisme intéressant concernant le séquenceur dans ce projet.

Zircuit possède son propre L2, dont la caractéristique est qu'il a créé une solution appelée « Sécurité au niveau du séquenceur / SLS (Sequencer Level Security) ».

Nous savons tous que, actuellement, les entrées et sorties des transactions L2 se font via le séquenceur officiel du projet. Bien sûr, en raison de l'existence de ZK / preuve de défi, en général, nous ne nous inquiétons pas trop du mal que pourrait faire le séquenceur.

Dans l'ensemble, le séquenceur est un rôle de camp neutre, exécutant toujours chaque transaction avec intégrité.

Alors, bien que le séquenceur soit neutre, pouvons-nous faire des efforts pour le faire rejoindre le camp des bienveillants ?

Ainsi, Zircuit a activé ce mécanisme SLS, dont le but est d'isoler les « transactions malveillantes ».

Normalement, comment une transaction L2 est-elle ajoutée à la chaîne ? C'est simple en quatre étapes :

1. L'utilisateur initie la transaction et la diffuse

2. Transaction dans le pool de mémoire (mempool) en attente

3. Le séquenceur, en tant que camp neutre, l'aide à l'emballer dans un bloc

4. Transaction ajoutée à la chaîne

Cependant, basé sur le mécanisme SLS, cette étape est devenue cinq étapes :

1. L'utilisateur initie la transaction et la diffuse

2. Transaction dans le pool de mémoire (mempool) en attente

3. Le séquenceur en tant que camp bienveillant utilise certains outils pour vérifier si la transaction est malveillante

4. S'il n'y a pas de malveillance, aide à l'emballer dans un bloc

5. Transaction ajoutée à la chaîne

Mais que se passe-t-il s'il y a des transactions suspectes ? À partir de l'étape quatre, cela change :

4. S'il est suspecté de malveillance, entre dans le pool d'isolement

5. La révision du pool d'isolement est correcte, le séquenceur continue de l'emballer

Ou bien :

4. S'il est suspecté de malveillance, entre dans le pool d'isolement

5. La révision du pool d'isolement révèle qu'il s'agit bien d'une transaction malveillante, alors elle est refusée pour être emballée sur la chaîne

Ce standard de vérification SLS pour détecter la malveillance pourrait utiliser certaines bibliothèques open source et laisser l'IA aider à juger.

L'avenir a l'espoir de réaliser certains effets, par exemple : des actifs volés qui pourraient ne jamais être transférés ou revenir sur L1. Cela reste très significatif pour l'environnement actuel difficile de la chaîne de la forêt sombre.

Bien sûr, puisque c'est un contrôle des transactions, il est inévitable qu'il y ait des erreurs. Cependant, je comprends qu'en améliorant l'algorithme du pool d'isolement, cela peut réduire autant que possible ce type de problème.

C'est une arme à double tranchant, la blockchain souligne la permission sans restriction, ce qui contredit légèrement le SLS. Du point de vue de l'utilisateur normal, un tel L2 est effectivement un peu plus sûr.

Cependant, dans l'ensemble, je pense que bien qu'il y ait un léger impact sur la permission sans restriction, le gain en sécurité, notamment pour protéger les utilisateurs inexpérimentés, en vaut la peine.

En fin de compte, voici : le document original sur le mécanisme SLS de Zircuit : https://arxiv.org/html/2405.01819v1