Association des normes maximales d'Orlovsky, LNP / BP
Dans le journal, nous proposons un moyen de mettre à niveau la couche Bitcoin 1 (blockchain / timechain) sans Softfork requis. Les propriétés de mise à niveau des propriétés de validation côté client peuvent être progressives, possède une option de déploiement sans autorisation (c'est-à-dire sans support majoritaire ou coopération de mineurs) et aura l'évolutivité de la commande
Le mot Bitcoin a acquis plusieurs significations, nous les distinguons donc en utilisant des termes plus spécifiques. Nous utilisons Bitcoin comme terme générique générique désignant le système dans son ensemble, qui peut inclure plusieurs couches (y compris un certain avenir) et l'idée globale du système de trésorerie électronique entre pairs provenant de Satoshi Nakamoto. Dans le même temps, nous utilisons BTC pour désigner Bitcoin comme une rareté numérique, de l'argent et de la monnaie. Nous distinguons également le consensus de POW Bitcoin (la règle de sélection du producteur de bloc suivant), consensus de Nakamoto (qui comprend le consensus de POW amélioré avec des moyennes cryptoéconomiques de punition mineure), Bitcoin Blockchain (également nommé TimeChain ) comme une implémentation actuelle spécifique de la couche Bitcoin 1 et du TimeChain spécifique de Bitcoin Lose 1 et Bitcoin Protocol (BP) comme ensemble de normes, de technologies et d'outils pour travailler avec les transactions Bitcoin sur chaîne (dans n'importe quelle couche 1 possible).
L'implémentation originale de Bitcoin par Satoshi Nakamoto a apporté l'idée étrange que tout le monde a besoin pour vérifier les transactions pour le monde entier. Cette idée a reçu le nom de la blockchain , ou, parfois, TimeChain - qui est devenu un euphémisme pour un grand livre avec un accès public. L'introduction du grand livre a créé deux problèmes: l'absence d'évolutivité et la mauvaise vie privée; Le premier empêche l'effet d'adoption et de réseautage de se produire; L'autre contredit l'esprit cypherpunk d'origine de Bitcoin et représente un risque civilisationnel stratégique (voir inévitabilité du cypherpunk pour une civilisation appropriée et un manifeste de cypherox).
L'évolutivité et, en partie, les problèmes de confidentialité ont ensuite été résolus par l'introduction de systèmes de couche 2, comme le réseau Lightning et d'autres solutions proposées. Parmi ceux-ci, le moins fructueux a été l'idée de Sidechain, qui a hérité la plupart (sinon la totalité) des limitations de la technologie de la blockchain d'origine tout en résolvant seulement un problème de faible programmabilité, a créé un bac à sable pour les expériences et, en partie, certains aspects de la confidentialité. Lightning Network - une solution de couche 2 plus réussie qui est déjà déployée et opérationnelle - a ses propres problèmes d'évolutivité en raison de la nécessité de sur-collatéralisation des liquidités, des limites du débit du trafic de potins (tous deux conduisant à la centralisation du réseau) et une diminution de la sécurité / de la confiance Dans des conditions de couche de base élevées [..]. D'autres alternatives proposées, comme ARK, nécessitent plusieurs changements de couche de base (une ou deux trfitures souples), ce qui présente des défis pour le déploiement. Enfin, aucune des solutions de deuxième couche existantes ou proposées ne résout les problèmes de confidentialité de la couche de base Bitcoin, et d'autres solutions de couche 1 axées sur la confidentialité (comme Coinjoin) ne protègent toujours pas des autorités juridiques et introduisent des problèmes de fongsibilité supplémentaires de BTC.
Ainsi, on peut conclure que c'est l'approche de la blockchain basée sur le grand livre pour la construction de la couche 1 qui doit être pleinement repensée afin de résoudre les problèmes ci-dessus. Les premières idées de cet espace sont venues avec Peter Todd en 2016 et 2017 lorsqu'il a souligné que les propriétaires d'un État (par exemple BTC ou tout autre contrat avec état) doivent vérifier une partie de l'histoire transactionnelle - la partie qui est directement lié à leur propriété - et omettez le reste. Il a nommé sa validation d'approche côté client . Giacomo Zucco a conçu un protocole capable de créer des actifs avec cette approche, nommée RVB . Dans mes travaux précédents chez LNP / BP Standards Association, j'ai pu développer RVB davantage et le convertir en premier système générique à contrat intelligent validé par le client avec un état riche et un calcul de Turing complété, offrant des fonctionnalités suffisantes pour exécuter tout ce qui Peut être fait avec des contrats intelligents basés sur la blockchain - mais sans le grand livre public / blockchain de stockage de données utilisateur, en utilisant directement les propriétés de dépenses anti-doubles du protocole de consensus Bitcoin Pow. Ce système a été développé publiquement au cours de quatre ans et sorti en avril 2023.
Dans la proposition actuelle, nous démontrons que le bitcoin, s'il est fourni avec une couche validée de côté client (comme RVB), peut être mise à niveau vers un système sans les propriétés limitantes du grand livre public (blockchain) et, tout en préservant le protocole de consensus POW,, Il peut être basé sur une nouvelle couche non blockchain évolutive 1 (CodeDamed Prime ). Cette couche sera en mesure d'héberger un nombre théoriquement indéfini de transactions (au moins des milliards par minute) car le stockage de l'état, l'informatique et la validation seront déplacés vers la couche validée côté client ci-dessus. Une telle conception ne nécessite pas de réseau Lightning ou d'autres couches d'évolutivité et de paiement sur le dessus et les échelles dans le pire des cas en tant que
Le protocole dispose de trois options de déploiement (sans autorisation, activées par un mineur et SoftFork), les deux premiers ne nécessitant aucune fourche souple (ou dure). Les options sont indépendantes, mais peuvent également être déployées de manière conséquente.
La proposition offre plusieurs avantages au bitcoin en tant que liquidités numériques:
Certains inconvénients relatifs du système proposé sont:
Le système proposé (CodeDamed Prime ) se compose de quatre composants principaux:
Ces composants sont conjointement équivalents dans leur fonctionnalité à un grand livre de type blockchain; Cependant, dans notre conception, ils deviennent abstraits, offrant beaucoup plus d'évolutivité et d'intimité que tout autre système de blockchain.
À sa fondation Prime, un service d'horodatage, créant une séquence d'en-têtes, chacun s'engageant sur une racine d'arbre Merkle de données validées côté client externe:
diagramme de classe
Direction LR
`En-tête n` <| -` En-tête n + 1`
classe `En-tête n` {
prev_commitment
merkle_root
merkle_tree_height
horodatage
// champs de guerre
tlv_extensions
}
classe `En-tête n + 1` {
prev_commitment
merkle_root
merkle_tree_height
horodatage
// champs de guerre
tlv_extensions
}
Chaque en-tête est équipé d'une extension TLV en option, qui peut être utilisée pour les futures mises à niveau du protocole; Sa taille est indépendante du nombre de transactions contenues dans l'arbre Merkle des données validées côté client et est de l'ordre de 100 octets (selon les données TLV).
Prime ne fournit aucune protection contre les doubles dépenses; Il sera fourni par la partie validée côté client du système. Les seules parties du système d'horodatage qui sont validées (règles de consensus) sont:
Les en-têtes Prime sont les seules informations qui doivent être disponibles publiquement et mondialement; Cela peut être réalisé en utilisant un réseau P2P distribué.
Les arbres de Merkle ( PMT ) à l'épreuve sont une structure intermédiaire et éphémère reliant les données validées côté client aux en-têtes. Les PMT sont produits par des mineurs et mis à la disposition du public via le même moyen ou d'autres moyens que les en-têtes; Cependant, contrairement aux en-têtes, ils ne sont pas tenus de persister. Chaque utilisateur de réseau suit tous les nouveaux PMT, extrait une partie des informations liées à l'état qu'il possède, l'enregistre dans sa propre cachette de données validées côté client et rejette le reste du PMT.
En raison de la nature éphémère, de l'absence de validation et pas besoin de connaître le contenu PMT pour l'exploitation de l'en-tête suivant, la taille du PMT n'affecte pas l'évolutivité du système. Ainsi, le PMT peut être de (plusieurs) gigaoctets, s'engager dans des milliards et des milliards de transactions.
Les feuilles des arbres contiennent des témoins fermant les sections à usage unique: un mécanisme décrit en détail dans la section suivante. Les PMT sont construits conformément à la norme LNPBP-4 de la norme LNPBP-4 multi-protocole et utilisé aujourd'hui pour héberger les engagements dans les transactions Bitcoin (à la fois en chaîne et en protocoles hors chaîne comme Lightning). Cela signifie que chaque utilisation à usage unique a un placement prédéfini unique dans le PMT, de sorte qu'un seul chemin de merkle et un témoin à feuilles sont suffisants pour prouver la fermeture - ou l'absence de fermeture - d'un seul seul utilisation unique dans le en tête. Les utilisateurs gardent une trace d'un ensemble de leurs sceaux à usage unique qui n'ont pas encore été fermés (analogue de l'ensemble UTXO) et extraient des preuves relatives de chaque PMT nouvellement produit. Si leurs sceaux n'étaient pas fermés, ce sont les preuves d'une non-opération (puisque le témoin démontre un autre à usage unique fermé sur ce chemin).
Les preuves constituent une partie croissante en fonction du temps de l'histoire validée du côté client. Les exigences de mémoire pour un nœud se développent de manière dépendante du temps comme
où
Ceci est logarithmiquement meilleur que l'évolutivité de tout nœud de blockchain, où les exigences de mémoire augmentent à mesure
où
où
Le
où
Le protocole à usage unique empêche les attaques à deux dépenses sur le système.
Les sceaux à usage unique (ou SEAL ) sont une forme spéciale d'engagement cryptographique proposé par Peter Todd. La primitive peut être comparée à d'autres formes d'engagements cryptographiques qui incluent les fonctions de hachage et l'horodatage:
Plus d'informations sur la construction à usage unique sont données dans la norme LNPBP-8. Prime utilise une forme spécialement conçue de sceaux à usage unique qui est différent de celui utilisé dans les protocoles existants (comme RVB).
La définition d'un seul utilisation se compose de deux composantes:
unique_id : Identifiant généré par l'utilisateur à l'échelle mondiale, qui peut être généré de manière déterministe à partir du contrat_id, du hachage de fonctionnement du contrat et du numéro de sortie de l'opération du contrat;spending_conditions_cmt : engagement (hachage) des conditions dans lesquelles le sceau peut être fermé à l'avenir (similaire à scriptPubkey dans la sortie de transaction Bitcoin). Les scellés sont définis dans le système de contrat intelligent validé côté client (RVB ou RVB). Chaque joint peut avoir un état affecté (comme dans RVB), par exemple, le solde BTC ou toute autre donnée riche. Lorsqu'un utilisateur aime mettre à jour cet état - ou transférer sa propriété à un autre utilisateur, une transition d'état doit être préparée, définissant de nouveaux (s) à usage unique et du nouvel état. Ensuite, un témoin fermant que la SEAL à usage unique est construite, s'engageant sur les données de transition de l'État et fournissant un script source, correspondant à l'engagement des conditions de dépense et aux données satisfaisant à ce script / conditions. La proposition résume d'un système de script spécifique utilisé (il peut être de la simplicité, ALUVM comme dans RVB aujourd'hui, et en espérant non EVM :); Le moteur de script peut être spécifié à l'aide du champ version , de sorte que de nouveaux moteurs ou opcodes peuvent être introduits au fil du temps (voir la section de mise à niveau):
diagramme de classe
Direction LR
Définition <| - Témoin: unique_id
Définition de classe {
unique
dépense_conditions_cmt
}
Classe témoin {
version
unique
state_transition_cmt
dépenser_conditions_src
satisfaction_data
}
Le témoin est mis sous la forme explicite à l'intérieur d'une feuille de ptree et fourni aux mineurs, en construisant le ptree et les en-têtes. La feuille doit être placée de manière déterministe à l'intérieur de l'arbre Merkle concernant le sceau unique_id , par exemple dans la fente
Merkle Path to the Leaf Matching unique_id , ainsi que le contenu des feuilles (fournir des données de témoin) permet de vérifier que chaque utilisation unique a été fermée une fois et une seule fois dans l'histoire d'un contrat intelligent - et qu'il a été fermé en satisfaisant le script conditions. Veuillez noter que les preuves doivent être accumulées pour chaque unique_id SEAL UNE-SEAL à partir du moment de sa définition jusqu'à la clôture - une exigence pour prouver que le sceau n'était pas fermé entre les deux. Ces preuves, tant qu'elles démontrent unique_id uniques, peuvent omettre des conditions de dépenses sensibles à la confidentialité et des données de satisfaction, ne fournissant que leur hachage; Ainsi, les témoins historiques peuvent être de taille fixe. Comme mentionné précédemment, à des fins d'évolutivité, l'historique des preuves peut également être comprimé en utilisant des preuves de connaissances zéro.
Le système, lorsqu'il est déployé avec une option sans permission, nécessitera son propre protocole consensuel. La sécurité du protocole n'est pas critique, car elle est fixée à la sécurité Bitcoin POW avec un mécanisme dédié décrit ci-dessous. La seule exigence pour le consensus est d'être résistante à la censure, ce qui signifie un ensemble ouvert de mineurs / validateurs sans identité. Les deux seuls protocoles consensus connus pour satisfaire ces propriétés sont POW et Ouroboros Crypsinesinef of BFT consensus cryptoéconomiquement sécurisé par les récompenses de mineur.
Le service d'horodatage ne frappe aucune crypto-monnaie, et les mineurs sont récompensés par des frais du jour 1. Un contrat dédié pour les frais de mineur est fourni par RVB ou d'autres protocoles de contrat intelligent validé par le client, qui spécifie les moyens de paiement (BTC , stablecoin ou paiements tokenisés). Les mineurs doivent participer à un réseau P2P anonyme sans autorisation, où les utilisateurs des protocoles publient leurs témoins équipés de transactions payant des frais à "celui qui mine la prochaine en-tête". Les mineurs incluent ces transactions dans leur histoire validée côté client et, ce faisant, ont la possibilité d'utiliser les fonds gagnés à l'avenir.
Au moment du lancement du système, une sortie dédiée "tout le monde-dépense" avec une quantité supérieure de SAT est créée sur la blockchain Bitcoin. Les informations sur cet UTXO deviennent une partie de la Genèse et sert de définition d'une mine à usage unique . Un mineur résolvant le défi POW doit dépenser cette sortie et à l'intérieur de la transaction Bitcoin de dépenses fournit un engagement de tapret en tête de l'en-tête miné et un nouveau mineur à usage unique "n'importe qui-can" pour le prochain mineur. Cela ancre l'en-tête créé vers la blockchain Bitcoin d'une manière unique, de sorte que la seule séquence d'en-tête de temps valide est celle qui suit cette séquence de sections à usage unique.
Si une partie passe l'actuel mineur à usage unique sans créer un engagement - ou s'engager dans un en-tête sans POW suffisant, une telle fermeture est considérée comme invalide; Dans ce cas, toute partie est autorisée à créer une transaction Bitcoin spéciale fournissant des informations OP_RETURN publiquement identifiables ("annonce") sur un nouveau mineur à usage unique ( réinitialisation du protocole ); Seule la première annonce OP_RETURN qui est classée par une procédure appropriée est considérée comme valide en vertu des règles de consensus.
L'ancrage à usage unique POW représente un protocole de consensus complet qui peut être exécuté par le système sans aucun autre consensus supplémentaire (POW ou BFT). Alternativement, il peut être combiné avec un consensus secondaire avec une règle selon laquelle à moins que la sécurité du deuxième protocole de consensus ne soit inférieure à la sécurité de Bitcoin Pow, le Bitcoin Pow a la priorité - avec un commutateur automatique au consensus secondaire comme consensus principal lorsque cela la condition n'est pas remplie.
Nous ne répondons délibérément pas à la question de la structure du réseau P2P dans cette proposition, car plusieurs systèmes alternatifs peuvent coexister et rivaliser de manière axée sur le marché. Au lieu de cela, comme les propriétés du réseau sont importantes pour les objectifs du projet, nous définissons les exigences générales pour la sélection d'un réseau P2P:
Au moment actuel, nous ne voyons pas de réseau rencontrant les propriétés susmentionnées; Cependant, nous voyons plusieurs réseaux avec un potentiel de développement vers eux:
Nous prévoyons de travailler sur le projet Renostr, d'utiliser nos travaux précédents à partir du protocole Storm et d'utiliser le chiffrement de bout en bout de style BiP-324. D'autres projets peuvent construire des solutions alternatives et la meilleure option doit être sélectionnée par le marché.
Nous voyons trois étapes - ou des options - dans la façon dont la solution proposée peut être déployée dans Bitcoin. Chacune des étapes est facultative; Le système peut fonctionner sans un ou deux d'entre eux. De plus, chaque option a ses propres compromis, cependant, s'ils sont déployés comme étapes conséquentes, ces compromis sont progressivement résolus.
Le système peut être lancé indépendamment du Bitcoin TimeChain, avec le consensus ancré à la sécurité de Bitcoin POW via un mécanisme dédié basé sur des secousses à usage unique (que nous décrivons dans l'article). Cela ne nécessite aucune modification du côté mineur ou de tout bitcoin Soft / Hardfrks, mais avec cette configuration, le BTC peut être transféré vers le nouveau système sans confiance que d'une manière - et de la manière qui nécessitera une fédération.
Les mineurs de Bitcoin commencent à traiter les transactions Prime et mettent l'engagement à horodatage des en-têtes de service à la Bitcoin Blockchain Coinbase - comme ils le font dans un cas d'exploitation fusionnée. Cela supprime la nécessité d'un consensus principal dédié, mais est vulnérable aux attaques de puissance de hachage, obligeant la grande majorité des mineurs à rejoindre le protocole avant son déploiement.
La proposition ne nécessite pas de Softfork spécifique, cependant, avec les règles de consensus Bitcoin actuelles, il ne peut pas fournir un moyen sans confiance pour que BTC soit déplacé du nouveau système Prime à la blockchain Bitcoin. Bien que nous ne voyions pas cela comme une exigence (Prime présente trop d'avantages sur la blockchain de sorte que nous considérons la blockchain comme déjà à long terme), à court terme, cela peut présenter un défi pour l'adoption de la plate-forme.
Il existe de nombreuses propositions différentes à fourche douce qui peuvent permettre de telles fonctionnalités. Ils se répartissent dans deux catégories principales:
L'adoption de l'une de ces propositions permettra une pigeon sans confiance pour BTC sur la plate-forme principale. Nos propres préférences vont après des codes opératoires à savoir zéro-connaissance, car ils ont de nombreux autres avantages et ne fournissent pas de compromis inévitables dans les carrefours.
La mise à niveau d'un système validé côté client est très différente de la mise à niveau du réseau Blockchain ou P2P (comme Lightning). Cela est dû au fait que les blockchains sont des protocoles de consensus qui sont des machines d'état entièrement répliquées, tandis que la validation côté client utilise une réplication partielle. D'une part, il est plus simple de mettre à niveau le système dans des parties liées à l'état inconnu - mais d'autre part, en raison de l'absence de garanties non cryptoéconomiques sur un état accessible à l'échelle mondiale fournis par le réseau , il est beaucoup plus difficile de coordonner toute mise à niveau.
En d'autres termes, les mises à niveau de la validation côté client sont fondamentalement différentes des carriques et des trfrches durs de la blockchain et nécessitent l'introduction de nouveaux concepts et termes.
Si quelque chose n'était pas valide et est devenu valide après une mise à niveau (nous appelons ce changement rapide ), tous les utilisateurs existants ne seront pas affectés: ils possèdent et géraient déjà l'état qui est valide. Cependant, ils peuvent ne pas être en mesure d'interagir avec les utilisateurs exécutant des versions plus anciennes du logiciel - un problème résoluble si leurs pairs acceptent de mettre à niveau. La mise à niveau ne présente aucun risque pour ces pairs car ils n'utiliseront aucun des États qu'ils possèdent - et la mise à niveau ne touchera pas les données historiques.
D'un autre côté, la situation où quelque chose était valable - et est devenu invalide en vertu des nouvelles règles - est très différente: les utilisateurs peuvent perdre leur état existant pour toujours et doivent s'opposer à une mise à niveau autant que possible. Nous appelons de telles mises à niveau des repères , et nous les considérons comme acceptables uniquement si un bogue critique a été découvert: la mise à niveau sera "coordonnée" par le désir des utilisateurs sincères / non chétiers pour éviter les problèmes introduits par le bogue.
Si le système inspiré de RVB ou RVB est utilisé comme composant de contrat intelligent, les mises à niveau de cette partie auront une autre caractéristique distinctive. RVB isole chaque programme («contrat intelligent») dans un bac à sable; Et un contrat, une fois émis, ne peut pas passer à la nouvelle version du protocole. Le seul moyen de mise à niveau est de produire un nouveau contrat lorsqu'un émetteur (ou des parties auxquels il a été délégué par les émetteurs, y compris la communauté) fera un transfert d'État de l'ancien contrat à la nouvelle - et chacun du contrat Les propriétaires seront d'accord là-dessus.
Comme avantage secondaire, cette approche permet l'introduction progressive de nouvelles fonctionnalités, d'instructions, etc., pas réalisables dans le monde de la blockchain: les émetteurs des nouveaux contrats ne dépendent pas des versions de protocole précédents et peuvent proposer des solutions plus avancées sans aucun risque de mise à niveau ou ou plus Coordination communautaire.
L'auteur est reconnaissant à Giacomo Zucco, qui était la personne insistant avec l'idée de supprimer la dépendance du bitcoin à la blockchain contraignante et de voir la validation côté client comme une voie à suivre. De multiples discussions avec lui et Peter Todd au fil des ans avaient aidé à concevoir de nombreuses parties du système. Parmi d'autres, l'auteur souhaite mentionner Alex Kravets, Federico Tenga, Olga Ukolova qui étaient les interlocuteurs qui ont passé de nombreuses heures à discuter de questions liées à la validation du côté client, aux défauts de blockchain et à des conceptions sans blockchain.
