Écrit par Robin Linux Traducteur: Denlink Community Translation Group
Résumé
BitVM est un paradigme informatique utilisé pour exprimer les contrats Turing-complets Bitcoin. Cela ne nécessite aucune modification des règles de consensus du réseau Bitcoin. Contrairement à effectuer des calculs sur Bitcoin, ils sont simplement vérifiés, similaires aux rollups optimistes. L’expéditeur déclare qu’une fonction donnée évalue certaines entrées à une sortie particulière. Si l’affirmation est fausse, le vérificateur peut apporter une preuve concise de fraude et pénaliser les vérificateurs. En utilisant ce mécanisme, toute fonction calculable peut être vérifiée sur Bitcoin.
Promettre un grand programme sur une adresse Taproot nécessite beaucoup de calcul et de communication hors chaîne, mais son empreinte sur la chaîne est petite. Tant que les deux parties travaillent ensemble, elles peuvent effectuer des calculs hors chaîne arbitrairement complexes et sans laisser de traces sur la chaîne. L’application en chaîne n’est requise qu’en cas de litige.
1 Introduction
De par sa conception, la fonctionnalité de contrat intelligent de Bitcoin est limitée aux opérations de base telles que les signatures, les verrous temporels et les verrous de hachage. BitVM crée un nouvel espace de conception pour des contrats Bitcoin plus expressifs et l’informatique hors chaîne. Les applications potentielles incluent des jeux tels que les échecs, le Go ou le poker, ainsi que la vérification de la preuve de validité dans les contrats Bitcoin. En outre, il peut être possible de relier Bitcoin à des chaînes externes, de créer des marchés de prédiction ou de simuler de nouveaux opcodes.
Le principal inconvénient du modèle présenté ici est qu’il ne fonctionne qu’avec deux configurations, le prover et le verifier. Une autre limitation est que pour les vérificateurs et les vérificateurs, beaucoup de calcul et de communication hors chaîne sont nécessaires pour exécuter le programme. Cependant, ces questions semblent prometteuses pour être abordées avec d’autres recherches. Dans ce travail, nous nous concentrons uniquement sur les composants clés d’une BitVM à deux parties.
2 Schéma
Avec les Rollups optimistes 1[2] [3] et la proposition MATT (Merkelize All The Things) 2 De même, nos systèmes sont basés sur des protocoles à l’épreuve de la fraude et de stimulation-réponse. Cependant, BitVM ne nécessite aucune modification des règles de consensus de Bitcoin. Les primitives sous-jacentes sont relativement simples. Il est principalement basé sur des verrous de hachage, des verrous temporels et de grands arbres pivotants.
Le développeur soumet le programme petit à petit à la chaîne, mais valider tout sur la chaîne consommerait des ressources informatiques excessives, de sorte que le vérificateur effectue une série de défis élaborés pour falsifier succinctement les fausses affirmations du prouveur. Ensemble, le précurseur et le vérificateur signent une série de défis – répondre aux transactions afin de résoudre les litiges plus tard.
Le modèle vise simplement à illustrer que cette approche permet un calcul universel sur Bitcoin. Pour les applications pratiques, nous devrions envisager des modèles plus efficaces.
Le protocole est simple: tout d’abord, le prouveur et le vérificateur compilent le programme dans un circuit binaire géant. Le développeur soumet le circuit à une adresse Taproot avec un script feuille pour chaque porte logique à cette adresse. En outre, ils présignent une série de transactions pour soutenir les jeux de défi-réponse entre les vérificateurs et les vérificateurs. Maintenant qu’ils ont échangé toutes les données requises, ils peuvent transférer leur dépôt en chaîne à l’adresse Taproot générée.
Cela active le contrat et ils peuvent commencer à échanger des données hors chaîne pour déclencher des changements d’état dans le circuit. Si l’auteur fait de fausses déclarations, le vérificateur peut prendre son dépôt. Cela garantit que les attaquants perdront toujours leurs dépôts.
Engagement de valeur 3 bits
L’engagement bit-value est l’élément le plus fondamental de ce système. Il permet au développeur de définir la valeur d’un bit particulier sur « 0 » ou « 1 ». En particulier, il permet au prover de définir la valeur d’une variable entre différents scripts et UTXO. Ceci est essentiel car il met à l’échelle le runtime d’exécution en divisant le temps d’exécution de la machine virtuelle de Bitcoin en plusieurs transactions.
La promesse contient deux valeurs de hachage, hash0 et hash1. Par la suite, l’émetteur définit la valeur du bit sur « 0 » en révélant preimage0 (la préimage de hash0) ou sur « 1 » en révélant preimage1 (la préimage de hash1). Si, à un moment donné, ils révèlent à la fois preimage0 et preimage1, le validateur peut les utiliser comme preuve de fraude et prendre le dépôt du prouveur. C’est ce qu’on appelle une déclaration contradictoire. Être capable de punir des déclarations contradictoires est ce qui rend un engagement contraignant – c’est un « engagement incitatif ».
La combinaison de promesses de valeurs binaires avec des verrous temporels permet aux validateurs de forcer le décideur à décider de la valeur d’un bit particulier dans un délai donné.
Figure 1 : Mise en œuvre d’un engagement bit-valueFigure 1 : Mise en œuvre d’un engagement de 1 bit. Pour déverrouiller ce script, le prover doit révéler l’une des préimages de hash0 ou hash1. Dans cet exemple d’exécution, le prover révèle hash1 et définit la valeur du bit sur « 1 ». Nous pouvons reproduire cette promesse pour appliquer une valeur spécifique dans différents scripts.
POUR SIMPLIFIER, À PARTIR DE LÀ, SUPPOSONS QU’IL EXISTE UN OPCODE APPELÉ OP BITCOMMITMENT, QUI EST UN RACCOURCI POUR LE SCRIPT CI-DESSUS. L’opcode consomme deux hachages et une préimage hachée. En fonction du hachage qui correspond à la préimage, il place une valeur binaire sur la pile.
4 Promesses de porte logique
Toute fonction calculable peut être représentée comme un circuit booléen. La porte NAND est une porte logique universelle, de sorte que n’importe quelle fonction booléenne peut en être composée. Pour garder notre modèle simple, nous montrons comment notre approche fonctionne avec des portes NAND simples. De plus, nous montrons comment combiner les portes arbitrairement. Tout cela prouve que BitVM peut représenter n’importe quel circuit.
La réalisation de la promesse de la porte NAND est simple. Il contient deux promesses de bits représentant deux entrées et un engagement de bits représentant les sorties. Le script calcule la valeur NAND des deux entrées pour s’assurer qu’elle correspond aux bits de sortie promis.
Figure 2 : Engagement aux portes pour les opérations NAND Figure 2 : Engagement aux portes pour les opérations NAND. L’exécution de ce script doit révéler les valeurs des promesses de bits A, B et C telles que A NAND B = C est vrai.
(Ici, pour plus de simplicité, supposons qu’un opcode nommé OP NAND existe.) EN FAIT, IL N’EXISTE PAS, MAIS IL PEUT ÊTRE FACILEMENT MIS EN ŒUVRE EN UTILISANT OP BOOLAND ET OP NOT. ）
5 Promesses de circuits binaires
Dans la section précédente, nous avons défini l’engagement de la porte NAND. Nous pouvons représenter n’importe quel circuit en combinant des promesses de portes. Chaque étape de l’exécution est engagée à Tapleaf. Ils sont tous fusionnés dans la même adresse Taproot afin que le praticien puisse exécuter n’importe quelle porte dans le circuit. L’exécution de la porte nécessite que le fabricant ouvre la promesse de porte correspondante et définisse des valeurs pour ses bits d’entrée et de sortie.
Taptree peut devenir massif et avoir un milliard de scripts Tapleaf, mais son empreinte sur la chaîne est petite.
Figure 3 : Exemple de circuit aléatoire Figure 3 : Exemple de circuit aléatoire avec 8 portes NAND différentes et 4 entrées A, B, C et D. En utilisant des milliards de portes, pratiquement n’importe quelle fonction peut être définie.
Figure 4Figure 4 : Pour chaque porte, l’adresse Taproot du prouveur contient un script feuille avec la promesse de porte correspondante. Cela permet au fabricant de régler les valeurs d’entrée du circuit à tout moment (ici A, B, C et D).
6 Défis et réponses
Il ne suffit pas de s’engager dans un circuit. Afin de réfuter des allégations erronées, le vérificateur doit être en mesure de contester la déclaration du prouveur. Cela peut être réalisé en pré-signant une série de transactions lors de la configuration. Ces transactions répondent à → défis →→ répondent à →... façon liée. Si l’une des parties cesse de participer, après une période d’expiration, l’autre partie gagne le défi et peut accepter les dépôts des deux parties. Tant que les deux parties travaillent ensemble, elles peuvent travailler ensemble pour résoudre n’importe quel contrat par une signature 2-de-2. Les mécanismes suivants ne sont requis qu’en cas de fraude.
Figure 5 : Une série de transactions présignéesFigure 5 : Une série de transactions présignées pour effectuer plusieurs séries de défis et de réponses. Cette séquence est générée lors de l’installation.
Vicky choisit un défi en ouvrant un verrou de hachage dans sa feuille Tap. Cela débloquera un Tap spécifique pour Paul et le forcera à l’exécuter. Le script force Paul à révéler la promesse de porte du défi Vicky. En répétant ce processus pour plusieurs séries de requêtes, vous pouvez rapidement réfuter toute affirmation incohérente.
Si le développeur cesse de coopérer hors chaîne avec le validateur, le validateur a besoin d’un moyen de forcer le chargeur à agir sur la chaîne. Le validateur y parvient en déverrouillant le verrou de hachage : chaque Tapleaf NAND dans l’UTXO du prouveur ne peut être dépensé que si le développeur connaît la préimage détenue par le certificateur. Ainsi, le prouveur peut prouver qu’un Tapleaf donné fonctionne correctement en révélant ses entrées et sorties, mais seulement si le vérificateur le « déverrouille » en révélant la préimage du hachage qui protège ce Tapleaf. En appliquant une recherche binaire, les validateurs peuvent rapidement identifier l’erreur du prouveur après seulement quelques séries de défis et de réponses.
Figure 6 : Après chaque réponse, Vicky peut pénaliser un comportement ambigu. Si Paul expose deux valeurs contradictoires à une variable, Vicky gagne immédiatement le défi et est autorisée à prendre son dépôt. Vicky prouve l’ambiguïté de Paul en révélant l’une des deux protoimages promises par ses morceaux.
7 Entrée et sortie
Le promoteur, peut définir l’entrée en révélant la promesse de bits correspondante. Idéalement, ils révèlent des engagements hors chaîne pour minimiser l’occupation sur la chaîne. Dans un cas non coopératif, les validateurs peuvent forcer les vérificateurs à révéler leurs entrées sur la chaîne.
De grandes quantités de données peuvent être traitées en échangeant le cryptage à l’avance. De cette façon, le proxénète peut révéler la clé de déchiffrement ultérieurement.
La contribution multipartite est également possible. Les portes peuvent avoir des engagements des deux côtés.
8 Limitations et perspectives
Il est inefficace de représenter des fonctions dans des circuits NAND simples. En utilisant des opcodes plus avancés, les programmes peuvent être représentés plus efficacement. Par exemple, Bitcoin Script prend en charge l’ajout de nombres 32 bits, nous n’avons donc pas besoin de circuits binaires. Nous pouvons également avoir des promesses de bits plus grandes, par exemple, 32 bits dans un seul hachage. De plus, la taille du script peut atteindre environ 4 Mo. Ainsi, nous pouvons implémenter beaucoup plus d’une instruction NAND dans chaque script feuille.
Le modèle présenté ici est limité à deux parties. Cependant, il peut être possible d’avoir des canaux bidirectionnels et de les relier entre eux pour former un réseau similaire au Lightning Network. L’exploration des deux paramètres peut donner lieu à des possibilités de généralisation intéressantes. Par exemple, nous pouvons explorer une topologie en étoile de 1 à n pour un réseau. Une autre question de recherche est de savoir si nous pouvons appliquer notre modèle à une configuration n-to-n et créer des usines de canaux plus complexes. De plus, nous pouvons combiner nos systèmes avec différents protocoles hors chaîne tels que le Lightning Network ou les Rollups.
D’autres orientations de recherche incluent la mémoire inter-applications, comment faire des déclarations sur des données arbitraires gravées sur la chaîne, ou les circuits programmables hors chaîne, c’est-à-dire les machines virtuelles hors chaîne. Des techniques d’échantillonnage plus sophistiquées, similaires aux STARK, peuvent également être appliquées pour examiner les circuits en un seul tour.
La prochaine grande étape est l’achèvement d’une conception et d’une implémentation concrètes de BitVM, ainsi que de Tree ++, un langage de haut niveau pour l’écriture et le débogage de contrats Bitcoin.
9 Conclusion
Bitcoin est Turing-complet dans un sens, car le codage des preuves de fraude dans les grands Taptrees vérifie l’exécution de tout programme. Une limitation majeure de ce modèle est qu’il ne fonctionne que dans le cas des deux parties. On espère que la généralisation pourra être faite dans les travaux ultérieurs.
Remerciements
Un merci spécial à Super Testnet et Sam Parker, qui ont toujours cru que Bitcoin ne serait pas Turing-complet.
Références
[1] Recherche Ethereum. Rollups optimistes. 2022.
[2] Salvatore Ingala. Merkleize toutes les choses. , 2022.
Ressources
[1] Équipe de traduction :
[2] Cumuls optimistes 1 :
[3] MATT 提案(Merkelize All The Things)2:
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
BitVM: Calculez n’importe quoi sur Bitcoin
Écrit par Robin Linux Traducteur: Denlink Community Translation Group
Résumé
BitVM est un paradigme informatique utilisé pour exprimer les contrats Turing-complets Bitcoin. Cela ne nécessite aucune modification des règles de consensus du réseau Bitcoin. Contrairement à effectuer des calculs sur Bitcoin, ils sont simplement vérifiés, similaires aux rollups optimistes. L’expéditeur déclare qu’une fonction donnée évalue certaines entrées à une sortie particulière. Si l’affirmation est fausse, le vérificateur peut apporter une preuve concise de fraude et pénaliser les vérificateurs. En utilisant ce mécanisme, toute fonction calculable peut être vérifiée sur Bitcoin.
Promettre un grand programme sur une adresse Taproot nécessite beaucoup de calcul et de communication hors chaîne, mais son empreinte sur la chaîne est petite. Tant que les deux parties travaillent ensemble, elles peuvent effectuer des calculs hors chaîne arbitrairement complexes et sans laisser de traces sur la chaîne. L’application en chaîne n’est requise qu’en cas de litige.
1 Introduction
De par sa conception, la fonctionnalité de contrat intelligent de Bitcoin est limitée aux opérations de base telles que les signatures, les verrous temporels et les verrous de hachage. BitVM crée un nouvel espace de conception pour des contrats Bitcoin plus expressifs et l’informatique hors chaîne. Les applications potentielles incluent des jeux tels que les échecs, le Go ou le poker, ainsi que la vérification de la preuve de validité dans les contrats Bitcoin. En outre, il peut être possible de relier Bitcoin à des chaînes externes, de créer des marchés de prédiction ou de simuler de nouveaux opcodes.
Le principal inconvénient du modèle présenté ici est qu’il ne fonctionne qu’avec deux configurations, le prover et le verifier. Une autre limitation est que pour les vérificateurs et les vérificateurs, beaucoup de calcul et de communication hors chaîne sont nécessaires pour exécuter le programme. Cependant, ces questions semblent prometteuses pour être abordées avec d’autres recherches. Dans ce travail, nous nous concentrons uniquement sur les composants clés d’une BitVM à deux parties.
2 Schéma
Avec les Rollups optimistes 1[2] [3] et la proposition MATT (Merkelize All The Things) 2 De même, nos systèmes sont basés sur des protocoles à l’épreuve de la fraude et de stimulation-réponse. Cependant, BitVM ne nécessite aucune modification des règles de consensus de Bitcoin. Les primitives sous-jacentes sont relativement simples. Il est principalement basé sur des verrous de hachage, des verrous temporels et de grands arbres pivotants.
Le développeur soumet le programme petit à petit à la chaîne, mais valider tout sur la chaîne consommerait des ressources informatiques excessives, de sorte que le vérificateur effectue une série de défis élaborés pour falsifier succinctement les fausses affirmations du prouveur. Ensemble, le précurseur et le vérificateur signent une série de défis – répondre aux transactions afin de résoudre les litiges plus tard.
Le modèle vise simplement à illustrer que cette approche permet un calcul universel sur Bitcoin. Pour les applications pratiques, nous devrions envisager des modèles plus efficaces.
Le protocole est simple: tout d’abord, le prouveur et le vérificateur compilent le programme dans un circuit binaire géant. Le développeur soumet le circuit à une adresse Taproot avec un script feuille pour chaque porte logique à cette adresse. En outre, ils présignent une série de transactions pour soutenir les jeux de défi-réponse entre les vérificateurs et les vérificateurs. Maintenant qu’ils ont échangé toutes les données requises, ils peuvent transférer leur dépôt en chaîne à l’adresse Taproot générée.
Cela active le contrat et ils peuvent commencer à échanger des données hors chaîne pour déclencher des changements d’état dans le circuit. Si l’auteur fait de fausses déclarations, le vérificateur peut prendre son dépôt. Cela garantit que les attaquants perdront toujours leurs dépôts.
Engagement de valeur 3 bits
L’engagement bit-value est l’élément le plus fondamental de ce système. Il permet au développeur de définir la valeur d’un bit particulier sur « 0 » ou « 1 ». En particulier, il permet au prover de définir la valeur d’une variable entre différents scripts et UTXO. Ceci est essentiel car il met à l’échelle le runtime d’exécution en divisant le temps d’exécution de la machine virtuelle de Bitcoin en plusieurs transactions.
La promesse contient deux valeurs de hachage, hash0 et hash1. Par la suite, l’émetteur définit la valeur du bit sur « 0 » en révélant preimage0 (la préimage de hash0) ou sur « 1 » en révélant preimage1 (la préimage de hash1). Si, à un moment donné, ils révèlent à la fois preimage0 et preimage1, le validateur peut les utiliser comme preuve de fraude et prendre le dépôt du prouveur. C’est ce qu’on appelle une déclaration contradictoire. Être capable de punir des déclarations contradictoires est ce qui rend un engagement contraignant – c’est un « engagement incitatif ».
La combinaison de promesses de valeurs binaires avec des verrous temporels permet aux validateurs de forcer le décideur à décider de la valeur d’un bit particulier dans un délai donné.
Figure 1 : Mise en œuvre d’un engagement bit-valueFigure 1 : Mise en œuvre d’un engagement de 1 bit. Pour déverrouiller ce script, le prover doit révéler l’une des préimages de hash0 ou hash1. Dans cet exemple d’exécution, le prover révèle hash1 et définit la valeur du bit sur « 1 ». Nous pouvons reproduire cette promesse pour appliquer une valeur spécifique dans différents scripts.
POUR SIMPLIFIER, À PARTIR DE LÀ, SUPPOSONS QU’IL EXISTE UN OPCODE APPELÉ OP BITCOMMITMENT, QUI EST UN RACCOURCI POUR LE SCRIPT CI-DESSUS. L’opcode consomme deux hachages et une préimage hachée. En fonction du hachage qui correspond à la préimage, il place une valeur binaire sur la pile.
4 Promesses de porte logique
Toute fonction calculable peut être représentée comme un circuit booléen. La porte NAND est une porte logique universelle, de sorte que n’importe quelle fonction booléenne peut en être composée. Pour garder notre modèle simple, nous montrons comment notre approche fonctionne avec des portes NAND simples. De plus, nous montrons comment combiner les portes arbitrairement. Tout cela prouve que BitVM peut représenter n’importe quel circuit.
La réalisation de la promesse de la porte NAND est simple. Il contient deux promesses de bits représentant deux entrées et un engagement de bits représentant les sorties. Le script calcule la valeur NAND des deux entrées pour s’assurer qu’elle correspond aux bits de sortie promis.
Figure 2 : Engagement aux portes pour les opérations NAND Figure 2 : Engagement aux portes pour les opérations NAND. L’exécution de ce script doit révéler les valeurs des promesses de bits A, B et C telles que A NAND B = C est vrai.
(Ici, pour plus de simplicité, supposons qu’un opcode nommé OP NAND existe.) EN FAIT, IL N’EXISTE PAS, MAIS IL PEUT ÊTRE FACILEMENT MIS EN ŒUVRE EN UTILISANT OP BOOLAND ET OP NOT. ）
5 Promesses de circuits binaires
Dans la section précédente, nous avons défini l’engagement de la porte NAND. Nous pouvons représenter n’importe quel circuit en combinant des promesses de portes. Chaque étape de l’exécution est engagée à Tapleaf. Ils sont tous fusionnés dans la même adresse Taproot afin que le praticien puisse exécuter n’importe quelle porte dans le circuit. L’exécution de la porte nécessite que le fabricant ouvre la promesse de porte correspondante et définisse des valeurs pour ses bits d’entrée et de sortie.
Taptree peut devenir massif et avoir un milliard de scripts Tapleaf, mais son empreinte sur la chaîne est petite.
Figure 3 : Exemple de circuit aléatoire Figure 3 : Exemple de circuit aléatoire avec 8 portes NAND différentes et 4 entrées A, B, C et D. En utilisant des milliards de portes, pratiquement n’importe quelle fonction peut être définie.
6 Défis et réponses
Il ne suffit pas de s’engager dans un circuit. Afin de réfuter des allégations erronées, le vérificateur doit être en mesure de contester la déclaration du prouveur. Cela peut être réalisé en pré-signant une série de transactions lors de la configuration. Ces transactions répondent à → défis →→ répondent à →... façon liée. Si l’une des parties cesse de participer, après une période d’expiration, l’autre partie gagne le défi et peut accepter les dépôts des deux parties. Tant que les deux parties travaillent ensemble, elles peuvent travailler ensemble pour résoudre n’importe quel contrat par une signature 2-de-2. Les mécanismes suivants ne sont requis qu’en cas de fraude.
Vicky choisit un défi en ouvrant un verrou de hachage dans sa feuille Tap. Cela débloquera un Tap spécifique pour Paul et le forcera à l’exécuter. Le script force Paul à révéler la promesse de porte du défi Vicky. En répétant ce processus pour plusieurs séries de requêtes, vous pouvez rapidement réfuter toute affirmation incohérente.
Si le développeur cesse de coopérer hors chaîne avec le validateur, le validateur a besoin d’un moyen de forcer le chargeur à agir sur la chaîne. Le validateur y parvient en déverrouillant le verrou de hachage : chaque Tapleaf NAND dans l’UTXO du prouveur ne peut être dépensé que si le développeur connaît la préimage détenue par le certificateur. Ainsi, le prouveur peut prouver qu’un Tapleaf donné fonctionne correctement en révélant ses entrées et sorties, mais seulement si le vérificateur le « déverrouille » en révélant la préimage du hachage qui protège ce Tapleaf. En appliquant une recherche binaire, les validateurs peuvent rapidement identifier l’erreur du prouveur après seulement quelques séries de défis et de réponses.
7 Entrée et sortie
Le promoteur, peut définir l’entrée en révélant la promesse de bits correspondante. Idéalement, ils révèlent des engagements hors chaîne pour minimiser l’occupation sur la chaîne. Dans un cas non coopératif, les validateurs peuvent forcer les vérificateurs à révéler leurs entrées sur la chaîne.
De grandes quantités de données peuvent être traitées en échangeant le cryptage à l’avance. De cette façon, le proxénète peut révéler la clé de déchiffrement ultérieurement.
La contribution multipartite est également possible. Les portes peuvent avoir des engagements des deux côtés.
8 Limitations et perspectives
Il est inefficace de représenter des fonctions dans des circuits NAND simples. En utilisant des opcodes plus avancés, les programmes peuvent être représentés plus efficacement. Par exemple, Bitcoin Script prend en charge l’ajout de nombres 32 bits, nous n’avons donc pas besoin de circuits binaires. Nous pouvons également avoir des promesses de bits plus grandes, par exemple, 32 bits dans un seul hachage. De plus, la taille du script peut atteindre environ 4 Mo. Ainsi, nous pouvons implémenter beaucoup plus d’une instruction NAND dans chaque script feuille.
Le modèle présenté ici est limité à deux parties. Cependant, il peut être possible d’avoir des canaux bidirectionnels et de les relier entre eux pour former un réseau similaire au Lightning Network. L’exploration des deux paramètres peut donner lieu à des possibilités de généralisation intéressantes. Par exemple, nous pouvons explorer une topologie en étoile de 1 à n pour un réseau. Une autre question de recherche est de savoir si nous pouvons appliquer notre modèle à une configuration n-to-n et créer des usines de canaux plus complexes. De plus, nous pouvons combiner nos systèmes avec différents protocoles hors chaîne tels que le Lightning Network ou les Rollups.
D’autres orientations de recherche incluent la mémoire inter-applications, comment faire des déclarations sur des données arbitraires gravées sur la chaîne, ou les circuits programmables hors chaîne, c’est-à-dire les machines virtuelles hors chaîne. Des techniques d’échantillonnage plus sophistiquées, similaires aux STARK, peuvent également être appliquées pour examiner les circuits en un seul tour.
La prochaine grande étape est l’achèvement d’une conception et d’une implémentation concrètes de BitVM, ainsi que de Tree ++, un langage de haut niveau pour l’écriture et le débogage de contrats Bitcoin.
9 Conclusion
Bitcoin est Turing-complet dans un sens, car le codage des preuves de fraude dans les grands Taptrees vérifie l’exécution de tout programme. Une limitation majeure de ce modèle est qu’il ne fonctionne que dans le cas des deux parties. On espère que la généralisation pourra être faite dans les travaux ultérieurs.
Remerciements
Un merci spécial à Super Testnet et Sam Parker, qui ont toujours cru que Bitcoin ne serait pas Turing-complet.
Références
[1] Recherche Ethereum. Rollups optimistes. 2022.
[2] Salvatore Ingala. Merkleize toutes les choses. , 2022.
Ressources
[1] Équipe de traduction :
[2] Cumuls optimistes 1 :
[3] MATT 提案(Merkelize All The Things)2: