Canal d'état, solution de mise à l'échelle Layer2 pour Ethereum
TechFlow SélectionTechFlow Sélection
Canal d'état, solution de mise à l'échelle Layer2 pour Ethereum
La zone de canal est divisée en canal de paiement et canal d'état, où le canal d'état dérive du canal de paiement.
Dédié à des analyses Web3 approfondiesRédaction : Zhang Lehui
I. Qu'est-ce qu'un canal et pourquoi en a-t-on besoin ?
1.1 Pourquoi a-t-on besoin de canaux ?
À mesure que le nombre d'utilisateurs et de transactions augmente sur la blockchain, cela entraîne des embouteillages, une lenteur des transactions et des frais élevés. Il devient donc nécessaire d'améliorer l'évolutivité de la blockchain. Les canaux constituent alors l'une des solutions envisageables.
1.2 Qu'est-ce qu'un canal ?
-
Premièrement : un canal est une solution destinée à résoudre les problèmes de mise à l'échelle de la blockchain. Il s'agit d'un réseau ou d'un protocole pair-à-pair (p2p) permettant aux deux parties impliquées d'effectuer plusieurs transactions, puis de soumettre uniquement le résultat final du traitement et du calcul à la chaîne principale pour y être validé par signature et réglé. On distingue les canaux de paiement et les canaux d'état, ce dernier étant dérivé du premier.
-
Deuxièmement : les canaux réduisent les interactions directes avec la chaîne principale en traitant les opérations hors chaîne, allégeant ainsi la charge du réseau principal tout en diminuant les coûts pour les utilisateurs.
-
Troisièmement : chaque canal est géré par un contrat intelligent multisignature (multisig) déployé sur la chaîne principale. Pour ouvrir un canal, les deux parties doivent déployer un contrat sur la chaîne, puis y déposer une certaine quantité d'actifs.
-
Quatrièmement : lors de la création du canal, les deux parties établissent un état initial indiquant leurs soldes respectifs (par exemple, Alice : 5 ETH, Bob : 5 ETH). Chaque partie signe cet état initial et conserve localement une copie signée. Cet état initial peut être stocké dans une base de données locale ou un espace de stockage sécurisé.
-
Cinquièmement : lors de la fermeture du canal, les deux parties doivent confirmer l'état final et générer une signature correspondante. Cet état final est ensuite soumis à la blockchain, où il fait l'objet d'une vérification de signature et d'un règlement, marquant officiellement la clôture du canal.
II. Principe de fonctionnement et processus des canaux d'état
2.1 Création et déploiement d'un contrat multisig, ouverture du canal
2.1.1 Déploiement du contrat multisig
Une chaîne L1 doit déployer un contrat multisig afin de gérer le canal. Ce contrat exige que les deux parties versent une certaine somme d'argent, qui sera verrouillée jusqu'à la fermeture du canal, au terme de laquelle le règlement sera effectué et les fonds libérés.
2.1.2 Versement des fonds
Après (ou avant) le déploiement du contrat, les deux parties doivent chacune déposer une certaine quantité de fonds, qui seront alors bloqués dans ce contrat multisig.
2.2 Transactions hors chaîne
2.2.1 Génération de l'état initial
Lorsque le canal est établi, les deux parties créent un état initial enregistrant leurs soldes initiaux (par exemple, Alice : 5 ETH, Bob : 5 ETH). Elles signent toutes deux cet état initial et conservent chacune une copie signée. Cet état initial peut être stocké localement par chacune des parties, dans une base de données ou un système de stockage sécurisé.
image.png
2.2.2 Effectuer une transaction
Alice paie 1 ETH à Bob. Après cette transaction, le nouvel état des soldes devient : Alice : 4 ETH, Bob : 6 ETH. Les deux parties signent et confirment ce nouvel état de solde.
image.png
2.2.3 Plusieurs transactions successives
Les deux parties peuvent continuer à effectuer plusieurs transactions. Après chaque transaction, elles mettent à jour l'état des soldes et le signent pour confirmation. Par exemple, après que Bob a payé 2 ETH à Alice, le nouvel état des soldes devient : Alice : 6 ETH, Bob : 4 ETH. Ces données de transaction restent stockées localement chez Alice et Bob, sans être immédiatement soumises à la blockchain.
image.png
2.3 Fermeture du canal
2.3.1 Préparation de la fermeture du canal
2.3.1.1 Confirmation de l'état final
Alice et Bob doivent confirmer l'état de transaction le plus récent et s'assurer qu'ils sont tous deux d'accord sur cet état, qui reflète la dernière répartition des soldes (par exemple, Alice : 6 ETH, Bob : 4 ETH).
2.3.1.2 Génération de la signature de l'état final
Les deux parties signent l'état final, produisant ainsi une information contenant la répartition finale des soldes ainsi que les signatures des deux parties.
image.png
2.3.2 Soumission de l'état final à la blockchain
L'une ou l'autre des parties (Alice ou Bob) peut soumettre l'état final à la blockchain. Le contenu soumis inclut la répartition finale des soldes ainsi que les signatures des deux parties.
2.3.3 Vérification et règlement
2.3.3.1 Vérification des signatures
La blockchain vérifie les signatures soumises afin de s'assurer que l'état final présenté a bien été accepté par les deux parties. La logique de vérification consiste généralement à contrôler la validité des signatures et à confirmer leur correspondance avec l'état final.
2.3.3.2 Règlement des soldes
Une fois la vérification réussie, le contrat intelligent libère les fonds depuis l'adresse multisig vers les deux parties conformément à la répartition des soldes définie dans l'état final. Par exemple, Alice reçoit 6 ETH et Bob reçoit 4 ETH.
2.3.3.3 Marquage de la fermeture du canal
Le contrat intelligent marque l'état du canal comme « fermé », empêchant toute nouvelle soumission d'état ultérieure.
III. Pourquoi concevoir les canaux sous forme de contrat multisig ?
La conception du contrat de canal sous forme de contrat multisig vise principalement à garantir la sécurité des fonds des deux parties, en exigeant leur accord mutuel pour tout transfert de fonds. Cette conception apporte une couche supplémentaire de sécurité, empêchant toute action unilatérale sur les fonds sans l'accord de l'autre partie. Voici les principales raisons justifiant cette conception :
3.1 Garantir la sécurité des fonds
Dans un contrat multisig, tout transfert de fonds nécessite l'autorisation via plusieurs signatures (généralement celles des deux parties). Cela garantit qu'aucune partie ne peut transférer les fonds unilatéralement, renforçant ainsi la sécurité financière.
3.2 Prévenir la fraude
Un contrat multisig permet efficacement d'empêcher toute tentative de fraude de la part d'une des parties. En effet, tout mouvement de fonds requiert la confirmation par signature des deux parties, garantissant que chaque transaction est mutuellement acceptée.
3.3 Mettre en œuvre un mécanisme de confirmation par signature pour les transactions hors chaîne
Le contrat multisig permet d'effectuer plusieurs transactions hors chaîne, en mettant à jour et confirmant l'état après chaque transaction via une signature. L'état final, une fois approuvé par les deux parties, est soumis à la chaîne pour règlement. Ce mécanisme repose sur la confirmation par signature des deux parties, assurant transparence et reconnaissance mutuelle de chaque étape.
3.4 Assurer la correction de la fermeture du canal
Lors de la fermeture du canal, le contrat multisig impose que la soumission et le règlement de l'état final soient effectués avec l'accord des deux parties. Cela évite qu'une partie ne ferme le canal unilatéralement pour obtenir une répartition inéquitable des soldes.
IV. Comparaison des avantages et inconvénients des canaux d'état
4.1 Avantages
Premièrement : faible coût des transactions, amélioration de l'efficacité. Deuxièmement : les données ne sont pas publiées sur la chaîne, offrant une forte confidentialité. Troisièmement : existence d'une période de contestation, assurant un haut niveau de sécurité.
4.2 Inconvénients
Premièrement : présence d'une période de contestation, ralentissant le retrait des fonds. Deuxièmement : absence de support des contrats intelligents hors chaîne. Troisièmement : nécessité pour les deux parties de rester en ligne simultanément. Les participants doivent maintenir une connexion active afin de recevoir et traiter rapidement les mises à jour d'état et participer à la résolution de litiges ; si l'une des parties tente de fermer malicieusement le canal ou de soumettre un état erroné, l'autre partie, étant en ligne, peut intervenir rapidement via le mécanisme de résolution de litige sur chaîne. Quatrièmement : nombre limité de participants. Un canal implique généralement uniquement deux parties, ne permettant pas une participation massive. Cinquièmement : non adapté aux grands réseaux, évolutivité limitée.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@UpchainDAO
