Machine à état et réponses prouvées des noeuds aux clients ?

R&D
121

Ok :slight_smile: compte = ?

122

Compte = Addresse = Hash du script de verouillage des sorties

123

Par contre pour l’historique, ça se passe comment ?

edit : oups, c’était une question pour @nanocryk

124

Tu calcule hash(index + addresse) pour index allant de 0 à n, tu obtient les hashs utilisés en inputs de transactions. Au bout d’une certaine periode ils sont supprimées de l’arbre de Merkles car trop anciens, mais des noeuds peuvent choisir de les garder et de proposer ces archives (ça sera même le comportement par défaut, un noeud pouvant activer une option lui permettant de supprimer du disque les documents qui sortent de l’arbre).

125

Mais du coup :
Compte = previous_hash(previous_index, hash)

Comment fait le client pour connaître previous index et hash ?

126

Non inso, Source = (index + compte), et index est incrémenté de 1 à chaque fois.

127

Bref le compte ne bouge jamais, seul son solde varie et son “hash courant” à cibler par une transaction pour débiter dessus.

1 Like
128

La source = hash(index, compte) :slight_smile:

129

Oui voilà, la source change à chaque fois qu’on pompe sur le compte.

1 Like
130

Oui, elle change pour les prochaines transactions (essayons de ne pas perdre inso :wink: )

Bloc 18 :

  • Avant : Compte 1 -> (15 G1, 0)
  • Transaction : hash(Compte 1, 0) 5 G1 -> Autre compte
  • Après : Compte 1 -> (10 G1, 1)

Bloc 19 :

  • Avant : Compte 1 -> (10 G1, 1)
  • Transaction : hash(Compte 1, 1) 5 G1 -> Autre compte
  • Après : Compte 1 -> (5 G1, 2)
1 Like
131

Mais comment est ce que le noeud sait à quel compte correspond le hash utilisé en source de la transaction ?

1 Like
132

Au moment de la validation, il a le même index, et peut donc reconnaitre le hash. Sinon il ne sait pas quelle est la source.

C’est justement le côté “anonymisation” que je remarquais. S’il n’est vraiment pas souhaitable, on peut toujours stocker en clair dans la transaction (compte, index) et il n’y aura plus ce brouillage de piste. Ou alors le laisser en option (mais autant que tout le monde l’utilise sinon ceux qui l’utilisent seraient “suspects”).

Par contre, j’ai trouvé un très gros problème à ce système : des relative time locks. Ils ne fonctionnent plus du tout. Une première solution que je vois c’est que la transaction possède un champ qui défini si elle sera groupée. Si elle est groupée, elle se “fond” dans la somme précédente et la date d’insertion devient la dernière date de mise à jour du compte, les anciennes étant perdues. Si par contre elle ne doit pas être groupée, chaqu’un de ses outputs restent indépendants et garderont leur date d’inscription tant qu’ils ne sont pas consommés. (ce qui est absolument nécéssaire pour gérer des time locks relatifs, a moins que vous voyez une autre manière de gérer ça)

Il faudrait que je mette dans la RFC la liste des documents et informations qui sont stockées dans l’arbre de Merkle, car la ça commence à faire beaucoup d’informations à suivre.

Edit : on pourrait référencer une transaction via hash(tx_id, output_index). Quand une transaction est inclue dans un bloc, si elle doit être groupée alors on ajoute la somme au compte correspondant, sinon on la garde telle quelle. Je vais le définir dans la RFC, sachant que je vais remanier un peu la structure du document de cette façon :

  • Introduction et explication de la structure générale
  • Définition des différentes briques du système (encodages, documents, script system)
  • Définition détaillée de la structure et du protocole de consensus en utilisant les briques au dessus

De cette manière le lecteur peut comprendre pourquoi on aborde telle ou telle “brique” et comment elle s’insère dans la structure de manière générale.

1 Like
133

Ok, et pour l’output ?

134
  • Si l’output supporte les “merge” : le compte correspond au script hash
    • Si le compte est déjà dans la blockchain, on lui rajoute la somme de l’output
    • Sinon on créé ce nouveau compte (script_hash, counter=1) avec la valeur de l’input
  • Si l’output ne supporte pas les “merge” (besoin de ne pas mélanger les outputs, par exemple pour garder les dates et utiliser la date d’insertion de la transac avec FetchSourceBlockTime et FetchDeltaBlockTime) :
    • Le compte correspond à (hash(id de transaction, index de l'output), index=0)
    • Aucune autre transaction ne peux être réalisé vers ce compte (pas de merge)

Pour uniformiser tout ça, on possède dans la blockchain la liste des
account-> (amount, counter, script, date)

  • Si counter = 0, pas de merge, et le compte correspond à hash(tx_id, output_index), et la date est la date d’insertion en blockchain, non modifiable
  • Si counter > 0, merge, le compte correspond au script hash, la date est la date de derniere mise à jour de ce compte, et hash(account, counter) devra être utilisé pour dépenser (un partie de) ce compte

Une transaction :

  • a une liste de comptes sources (hashs) et les montants prélevés, accompagnés des paramètres validant le script
    • dans le cas d’un compte merge (script hash), la somme prélevé doit être inférieure ou égale à la somme du compte, et la somme finale du compte doit être supérieure à 1 G1.
    • dans le cas d’un compte non merge (UTXO), la somme prélevé doit être exactement celle de l’UTXO
  • a une liste d’outputs ayant chaqu’un :
    • un montant
    • un script
    • un indicateur merge/non-merge

Liste des termes :

  • Clé/keys : clés cryptographiques
  • Compte/account : unité qui stocke de la monnaie sous la forme d’un hash, peut correspondre à une UTXO hash(tx_id, output_index) (non merge) ou à un script hash (merge)
  • Adresse/address : format unique qui permet de ciblé n’importe quel type de clé ou de compte, qui contient l’id de la monnaie (cross-chain replay protection) et un checksum. Son hash (sans le checksum) peut être utilisé pour créer une identité (uniquement s’il stocke une clé, pas de compte).

Edit : pour rendre toutes ces données vérifiables par les clients, on peut d’abord stocker la liste des comptes dans un document, et à côté chaque document account-> (amount, counter, script, date) dans un binary tree. Ce qui m’inquiète un peu c’est que le nombre de compte risque d’être important à long terme, et que le client ne voudra pas forcement télécharger toute cette liste. Le nœud pourrait alors faire une attaque par omission, mais avec le risque que le client demande la liste qui montre qu’il avait bien l’information, ou que quelqu’un d’autre lui donne cette info. Le risque d’attaque par omission me semble donc largement limité. Sinon, il faudrait trouver une solution pour qu’un client puisse vérifier rapidement qu’un compte est dans la liste des comptes en blockchain sans devoir télécharger toute la liste ni être vulnérable à une attaque par omission.

135

Peux-tu expliquer pourquoi ?

136

Parcequ’ils se basent sur la date d’insertion en block, qui est perdue si plusieurs outputs sont “fusionnés”.

137

OK alors laissons tomber cette idée, conservons le fonctionnement des transactions en mode “source” tel qu’actuellement.

En fait je ne vois même plus pourquoi je trouvais l’idée “géniale”, car autant pour les sources de DU ça a du sens (car c’est le même script de déverrouillage pour l’ensemble des sources d’une clé membre), autant pour les compte TX…

138

Tu as lu ma suggestion au dessus ?

Tout ce qui n’a pas besoin d’informations spécifiques aux entrées indiviudelles peut être regroupé. En plus j’ai proposé un format simple unifié pour ça qui permet de le gérer et de l’expliquer simplement.

139

Non quand tu fais des pavés je lis en diagonale :slight_smile:

Mais comme dit au-dessus, en fait je ne vois plus du tout l’intérêt pour les comptes TX. Je ne le vois que pour les UD, qui par définition n’ont pas de problème de relative time locks.

En vois-tu un ?

140

C’est pas bien, surtout quand je fais l’effort de formater et de faire des listes :stuck_out_tongue:

Comme tu le disais précédement : 99% des transactions seront des “simples” transactions, des <pub_key> CheckSig (ou CheckSigHash), qui n’ont aucun problème à être groupées, et qui actuellement doivent être regroupées dans une transaction pour dépenser plusieurs UTXO de la même clé publique.