[Pavé !] Ajout pour la RFC5 : Des noeuds qui ne stockent pas les UTXOs

v11
rfc
scaling

#101

CAP ou PA…C…AP?

Au regard du problème enoncé par le très frustrant, non moins célèbre théorème d’impossibilité Consistency Availability Partitionning(sharding).

Que pourrions nous dire de cet algorithme?

La blockchain / le reseau nous offre l’availability du log
La PoW supprime le partitionning lors de la resolution de forks pour permettre la consistence
L’idée suggeré est de reintroduire du sharding tout en gardant la PoW. il y a qelque chose d’étrange que je n’arrives pas bien a saisir.

y a-t’il une couche qui m’echappe ?
sagit-il d’un sharding purement applicatif?
Dans ce cas, comment garantis-tu la consistence des UTXO à la validation d’un block?
La ‘nature’ particulière de l’UTXO? propriete a usage unique est-elle suffisante pour garantir tout ca ?
Cela ne reviens t’il pas a stocker ses propres UTXO.

Quitte a changer l’algo pourquoi ne pas stocker les balances des comptes a chaque mouvement, on se ferais sacrement moins chier… A merde, il y a une réponse a ca :confused:

Ceci dis j’aime beaucoup l’idée de choisir la ou je stock mes g1
l’idée de sharding m’effraie un peu mais avec des demonstrations qui sait… peut etre que le vieux CAP deviendra vraiment has been


#102

J’avoue ne pas comprendre tes interrogations. Parlons-nous du même sharding ?

Que veux-tu dire par “consistence des UTXO” ?

De quelle nature tu parle ? La seule utilisation de “compte à propriétaire unique” n’est pas envisagée, qu’est-ce qui te fais penser le contraire ? Stocker ses propres UTXO, c’est à dire ?

Les UTXOs ont une condition de dépense programmable ce qui permet de faire des “compte à propriétaire unique” comme plus. Le “plus” implique que l’on ne peux pas stocker les balances des “comptes”, vu que c’est comptes n’existent pas réelement et n’ont pas de sens avec des “scripts” plus complexes.


#103

Euh… je parles de titre de proprieté à usage unique… comme un chèques quoi, un UTXO c’est un chèque pour faire simple, je le depense et boom il disparait. un tiers l’a écrit, signé et me la donné. voila ma definition de l’UTXO (posssiblement inexacte mais c’est celle que j’enplois ici) je ne parles pas de comptes !

et donc sa nature serait “un truc un peut comme un chèque” sauf que nature c’est mieux.

= Partition

C’est la tout le sujet du pavé non ? comment implementer un autre algo tout en gardant la blockchain cohèrente sachant que le théoreme PAC est assez clair :

Consistence+Partition+Availability = PAS possible

Donc j’aimerais une description clair du “trade off” réalisé par cette algo. Si on partitionne quelque chose ca serait bien de savoir ce qui est sacrifié au profit de la partition realisé.

Pour moi l’idée est sympa mais pas possible à moins de remettre en cause une impossibilité mathématique Mais c’est possible aussi que j’ai mal compris…

En quoi cet algo, partitionnant l’état de la blockchain reste-il cohérent (PAC’s Consistency ) ? la question est tout à fait clair, je ne comprends pas ce que tu ne comprends pas.

Si un noeud cherche a valider un block, il doit s’assurer que l’UTXO n’a pas déjà été utilisé, il doit faire tout un paquet de tests de coherence qui nécessite la connaissance de toute la chain


#104

Je comprends mieux. En effet une UTXO se comporte comme un titre à usage unique, avec un condition d’utilisation programmable.

Si je me souviens bien (ce sujet date un peu maintenant), la solution proposée est de stocker les UTXO dans un arbre de Merkle, et de demander à l’éméteur d’une transaction de fournir les UTXO accompagnés de leurs preuves dans l’arbres. Avec ceci, il devient possible pour les noeuds de ne plus stocker l’ensemble des UTXOs. L’état reste consistant, car les noeuds continuent de vérifier les transactions présentes dans les blocs pour les oublier ensuite. De ce que je comprends du théorème PAC, la proposition introduit justement le partitionnement en permettant à chaqu’un de ne stocker que ce qu’il souhaite. Du coup, la propriété “availability” n’est pas respectée, mais n’est pas souhaitée. Si un noeud veut vouloir utiliser une UTXO, il faut qu’il la stocke et qu’il maintienne une preuve à jour (ou qu’il la demande à un autre noeud avec un protocole adéquat).

Est-ce que ça réponds à ta question ? :slight_smile: J’avoue ne pas connaitre se théorème ni avoir connaissance dans les théories mathématiques abordées, mais ça serait un plaisir d’apprendre de nouvelles choses.


#105

C’est une réponse qui me convient, en gros le chèque peut bruler, etre perdu ce qui me semble un effet tout a fait naturel. la ou ca deviendrait un probleme c’est lors de la reévaluation du DU, si des billets brulent alors la masse monetaire n’est pas exactement ce qu’elle semble etre. il faudrait donc au moins tout les 6 mois que le protocole compte les “UTXO en circulation”

Je n’ai pas la rigueur mathematique pour l’expliquer et je ne veux pas t’induire en erreur, je ne suis meme pas sur que ce soit un theoreme au sens propre. mais c’est un phénomène largement documenté commun à TOUS les systèmes distribué (du systeme big data massivement partitionné au torrent en passant par les blockchain)


#106

Ce n’est pas un problème, la masse monétaire est comptée indépendamment de ce qu’en font les humains. La réévaluation du DU est toujours parfaitement exacte.


#107

La MM est comptabilisé en fonction de l’emission de monnaie et non de la masse réelement en circulation !? je suis surpris! Mais je n’y vois pas de problème majeur sachant la forme exponentielle de la g1.


#108

Tente de définir “réellement en circulation”, et tu verras qu’il est plus simple de compter directement la masse émise.


#109

Oui.

Je n’aurais pas précisé autre chose !