Issues de secours - Censorship.wtf

Hypothesis (0:35)

L'hypothèse : la décentralisation complète et immédiate peut ne pas être réalisable ou souhaitable pour toutes les entreprises dès maintenant.

C'est ok si certaines entreprises souhaitent adopter une approche plus progressive de la décentralisation.

Il peut y avoir d'autres voies que la décentralisation complète qui permettent malgré tout d’offrir initialement certaines propriétés d'auto-hébergement (les utilisateurs ont le contrôle de leurs propres fonds) et de lutte contre la censure.

Les "issues de secours" sont proposés comme une alternative : ils pourraient permettre aux entreprises de prétendre légalement offrir une certain auto-hébergement à leurs clients.

Étude de cas (2:10)

La priorité pour une entreprise hors crypto est la rentabilité, pas nécessairement la décentralisation complète dès le départ.

L'auto-hébergement pourrait être une proposition de valeur ajoutée pour les clients, surtout après les défaillances retentissantes d'exchanges centralisés comme FTX.

L'entreprise veut rassurer les clients que leurs fonds sont retirables à la demande, contrairement à FTX. Pour l'entreprise, la "non-censure" signifierait que les utilisateurs peuvent retirer des fonds de manière autonome et permissionless.

Les issues de secours doivent être définis précisément et de manière minimale, comme permettre uniquement des retraits et des échanges non censurables.

Les deux transactions clés qui doivent être non censurables pour un auto-hébergement de base sont :

1. Retrait complet des fonds
2. Exécution forcée d'échange

Cela apporte une certaine auto-conservation et non-censure tout en permettant à l'entreprise de se concentrer sur la rentabilité lors d'une phase transitoire avant la décentralisation complète.

Morale de l'histoire (4:25)

Pour les entreprises, la rentabilité est la priorité. L'auto-hébergement est une fonctionnalité supplémentaire. Légalement, les entreprises peuvent prétendre être "non-custodial" si elles peuvent prouver que les utilisateurs peuvent retirer des fonds à la demande.

Les entreprises ne veulent peut-être offrir qu'une certain degré d'auto-hébergement, même sans décentralisation complète. C'est positif et doit être encouragé.

La décentralisation est très difficile, comme en témoignent les défis auxquels font face les Layer 2. Nous devons donc permettre une certaine flexibilité.

Le rôle des issues de secours est de créer des outils et des bridges pour rendre l'auto-hébergement facile pour les entrepreneurs construisant des services.

L'exemple de la fintech de trading (6:15)

L'entreprise de trading veut un auto-hébergement immédiat pour les utilisateurs, mais pas encore de décentralisation complète. Si une entreprise centralisée implémente bien les issues de secours, elle peut augmenter les profits et la satisfaction des utilisateurs

C'est aussi une victoire pour l'industrie crypto qui aide à apporter sécurité et autonomie à plus d'utilisateurs.

Nous devons réfléchir à la façon de rendre l'auto-hébergement facile pour les entrepreneurs construisant des services utilisés par des millions de personnes.

L'exemple de Appchain (8:05)

La décentralisation est idéale pour les transactions blockchain, car elle les rend résistantes à la censure et donne aux utilisateurs le contrôle de leurs propres fonds.

Une "appchain" est une blockchain dédiée à une application spécifique, plutôt qu'être une blockchain à usage général. Les appchains sont comme des solutions de "Layer 3" adaptées à des cas d'utilisation particuliers.

De nombreuses appchains existantes sont axées sur les échanges, les NFT, les DEX, etc. Il existe déjà des exemples comme Dydx, Immutable X, Loopring, etc.

Ces échanges et plateformes NFT basés sur des appchains ont déjà implémentés des issues de secours aujourd'hui. Elles leur permettent un contrôle centralisé des fonds lorsque nécessaire, tout en maintenant un haut degré de décentralisation et de contrôle de l'utilisateur pour les transactions normales.

Le cas dYdX (10:20)

dYdX a déjà utilisé les issues de secours avec succès. Plus de 150 utilisateurs ont déjà forcé des transactions et retiré des fonds de dYdX, y compris des montants de plusieurs millions de dollars.

Cela montre que les issues de secours fonctionne comme prévu : pour permettre aux gens de récupérer leur argent s'ils le souhaitent.

Architectures des issues de secours :

1. Contrat de file d'attente L1
2. Notification de la chaîne d'application L2
3. L'utilisateur appelle l'outil d'évasion
4. Le Séquenceur traite la demande
5. L'application approuve/rejette
6. L'utilisateur obtient le retrait L1 en cas d'approbation

Si l'application ne répond pas dans les 7 à 14 jours, elle est sanctionnée en étant gelée. Les utilisateurs peuvent ensuite retirer des fonds via le calculateur de solde.

Cela protège contre la censure ou la défaillance de l'application tout en permettant une décentralisation transitoire

Risques (16:40)

Le principal problème est le risque de déni de service (DoS), car les utilisateurs peuvent être spammés avec des transactions forcées : un attaquant pourrait envoyer de nombreuses transactions forcées pour submerger l'application et déclencher la sanction

Dans Starknet, les transactions forcées sont coûteuses (par exemple 1 million de gaz) pour décourager le spam

Aucune attaque de spam majeure ne s'est produite jusqu'à présent, donc le coût élevé semble fonctionner comme élément dissuasif. Cependant, d'autres mesures anti-spam pourraient encore devoir être envisagées.

Un autre problème est la possibilité de mettre à jour les contrats : si les contrats peuvent être facilement mis à jour, l'application pourrait contourner les sanctions

Dans StarkEx, la mise à jour des contrats pour contourner les gels semble plus difficile. Mais cela doit être pris en compte lors de la mise en œuvre des issues de secours dans les Starknet Appchains

Prochaines étapes (18:55)

Les issues de secours seront mises en œuvre pour les Starknet Appchains. Ils seront probablement utilisés pour des applications DeFi comme les exchanges, les jeux, etc.

La question de savoir si les issues de secours doivent être déployés pour le Layer 2 Starknet public. Cela poserait de grands défis techniques, car les issues de secours doivent être minimales pour la sécurité.

Les issues de secours rendent l'auto-hébergement facile à revendiquer légalement pour les entreprises. Sans ces bridges, les entreprises ne se soucieraient peut-être pas de la décentralisation ou de l'auto-hébergement

Même transitoires, les issues de secours aident à apporter des éléments clés de la décentralisation aux applications grand public. Cela peut aider à prévenir des défaillances centralisées majeures comme FTX à l'avenir.