Dans un nouveau post sur le forum, nous proposons de mettre à jour les exigences de la Phase 1 en introduisant un nouveau "test de retrait du Conseil de sécurité" qui tente de répondre à la question : Les utilisateurs peuvent-ils sortir, en présence d'opérateurs malveillants, même si le Conseil de sécurité disparaît ?

L'exigence actuelle de la Phase 1 permet l'utilisation active de la minorité du Conseil de sécurité pour fournir une résistance à la censure, des garanties de disponibilité ou des garanties de sécurité, sans avoir besoin de mettre en œuvre des mécanismes véritablement sans autorisation.

Bien qu'à l'époque nous ayons décidé de ne pas aborder cette potentielle faille, nous avons remarqué un intérêt croissant de la part des projets à utiliser de telles stratégies pour atteindre la Phase 1 et un intérêt décroissant pour le renforcement des systèmes de preuve ou la mise en œuvre de transactions forcées.

Nous discutons de trois projets de Stage 1 qui ne passent actuellement pas le test de désengagement : @Starknet, @KintoXYZ (maintenant fermé) et @Scroll_ZKP. Bien que nous fournissions un bref résumé ici, nous invitons les gens à lire les détails dans le post.

Aujourd'hui, Starknet satisfait l'exigence actuelle de la Phase 1 en utilisant la minorité du Conseil de Sécurité comme un prouveur autorisé. Si des utilisateurs sont censurés, ils sont censés contacter les membres du Conseil de Sécurité, qui sont ensuite censés faire fonctionner l'infrastructure du prouveur en temps voulu.

Aucun mécanisme exact n'a jamais été défini sur la manière de contacter le Conseil de sécurité en matière de censure. De même, si le Conseil de sécurité n'est pas en mesure d'exécuter le prouveur à temps, ou disparaît simplement, les fonds peuvent être compromis.

Une manière plus robuste de satisfaire le principe de la Phase 1 serait de mettre en œuvre des transactions forcées et un mécanisme de secours de vivacité pour le prouveur. Starknet manque actuellement de ces deux mécanismes.

.@KintoXYZ a utilisé les membres du Conseil de sécurité comme seuls challengers autorisés dans le protocole. Si le Conseil de sécurité "s'éloigne", ou n'est pas en mesure de fournir le service en temps voulu, les fonds peuvent être compromis. Une solution plus robuste serait d'ouvrir des défis sans autorisation.

Enfin, bien que @Scroll_ZKP implémente déjà des transactions forcées et un retour de l'activité pour le prouveur autorisé, seul le Conseil de Sécurité peut récupérer d'une pause malveillante. Une pause qui expire automatiquement serait suffisante pour satisfaire le test.

Notamment, beaucoup des principales chaînes satisfont déjà aux tests de retrait du Conseil de sécurité et n'auraient besoin d'aucun changement pour maintenir la désignation de la Phase 1 : @arbitrum, @Optimism, @inkonchain et @unichain. Toutes mettent déjà en œuvre des txs forcés et une preuve sans autorisation.

@Scroll_ZKP Il est à noter que de nombreuses chaînes de premier plan satisfont déjà aux tests de retrait du Conseil de sécurité et n'auraient besoin d'aucun changement pour maintenir la désignation de Stage 1 : @arbitrum, @Optimism, @base, @inkonchain et @unichain. Toutes mettent déjà en œuvre des txs forcés et une preuve sans autorisation.