Cesium: Transactions référencant un bloc incertain (dont l'age < 6 blocs)

Bonjour ! J’ai besoin de vos avis/idées pour différents points :slight_smile:

Les transactions (TX) qui sont liées à un bloc trop récent (parmi les 6 dernier bloc) peuvent être jugé comme « en attente de validation », du fait que la blockchain peut ecnore forker. Un rollback rend invalide le bloc référencé, et donc la TX…

Du coup, j’envisage plusieurs choses :

  1. Ajouter dans les préférences une option pour choisir la fenetre le délai d’incertitude des blocs (ici, l’exemple est pris pour G1-test) :

  1. Emettre les TX avec comme référence block(t - N) (N étant la valeur des préférences ci-dessus, avec 6 par défaut)

  2. Dans « Mes Opérations », afficher les TX qui référence un bloc trop récents, par exemple dans une nouvelle section « Transactions récentes (fork possibles) » :

Mais je pose les questions suivantes :

  • A. Dans « Mes opérations », dois-je corriger l’heure afficher de la transaction pour ajouter le délai des 6 blocs choisi dans les préférences ? Actuellement c’est l’heure du bloc référencé.
    Sachant que pour les TX recues, l’émetteur à très bien pu, lui, utiliser le dernier bloc (ou tout autre bloc) comme référence… Faut-il que j’applique ce changement recalcul uniquement au TX émises ? Ou bien laisses on l’heure du bloc référencé (qui aura donc un décalage) ?

  • B. Toujours dans « Mes opération », est-ce vraiment judicieux d’avoir une nouvelle section « Transactions récentes » ? Que pensez vous de mettre ces TX également dans « Transaction en attente de traitement » ? D’autres idées ?

EDIT: je suis pas fan non plus du terme « fork » dans l’écran proposé…

  • Transactions en cours de traitement = Pas encore dans la chaine
  • Transaction en cours de validation = Dans une fenêtre < 6 blocks

Pour le blockstamp de la TX, j’aurais tendance à te proposer d’envoyer la transaction à tout les forks connus. Comme ça, tu es certain qu’un des forks l’acceptera. Si tu l’envois qu’à un seul fork, même si tu utilises 6 blocks en arrière, tu as une petite chance de tomber sur un noeud bloqué sur un fork et donc d’avoir quand même une tx invalide (cf l’évènement RML11)

2 Likes

Ce qui ne servira strictement a rien… Dans un autre fil j’avais expliquer qu’il faut que les clients références leur a TX a J-3. Et en tout état de cause a minimum J-1. Lorsque le réseau fork c’est très rarement résolu en moins de 6 blocs, la moyenne c’est plutôt quelques heures. Si on veut un réseau plus stable il faut donc tabler a minima sur du J-1.
Sachant qu’une TX reste une semaine en piscine, en prenant J-1 elle restera 6 jours en piscine, donc il n’y a aucun conséquence néfaste a faire ça (outre le recalcul de l’heure d’émission de la Tx pour un affichage humain).

Et cela me semble n’avoir aucun rapport avec le fait d’annoncer une tx comme “passée” après 6 blocs, ce sont deux aspects totalement différents.

Oui, enfin comme c’est paramétrable, tu mets bien ce que tu veux. tu peux donc mettre 1 jour ou 30 min (6 block pour la G1).

Si la date affichée pour la TX… Tu viens d’en faire une et la date qui s’affiche est “hier”. :slight_smile:

Si, car si l’utilisateur choisi un delta de 1 jour, car il estime que c’est la durée nécessaire pour éviter les conséquence d’un fork, alors il faut l’avertir lorsqu’une TX a un age < 1 jour. Ca me parait logique, non ?

Non car dans un cas on parle d’affichage “en attente de validation” qui vas perturber les utilisateurs lambda et dans l’autre cas d’astuce pour que la tx ne sont pas invalidée en cas de fork, c’est deux besoins totalement différents.
Si tu laisse la tx marquée comme “en attente” pendant 1 jours ça va avoir un effet néfaste, beaucoup d’utilisateurs vont se dire, mais c’est lent c’est toujours pas validé !

En tout les cas, pour le blockstamp des TX je te recommande de prendre a minima la valeur de ForkWindowSize de Duniter, qui est de 100 blocs actuellement, indiquant que Duniter peut roll back jusqu’a 100 blocs :wink:

99% des utilisateurs utilisent les paramètres par défaut, il faut donc penser les paramètres par défaut pour une bonne stabilité du réseau afin d’éviter que les événements type rml11 ne se reproduisent, donc le “tu met bien ce que tu veut” n’est pas un argument. En tant que dev du client le plus utilisé tes choix de config par défaut on un impact énorme sur la grande majorité des utilisateurs, il me semble donc important d’y réfléchir à 2 fois.

1 Like

Je ne suis pas favorable à la solution d’elois. D’après moi, la solution de propager la transaction sur chacun des forks apporte plus de stabilité sans impacter la date d’affichage des transactions.

La solution peut aussi être de la propager sur tous les forks qui ont plus de 5% noeuds synchronisés dessus (pour éviter de propager des transactions à des noeuds complètement désynchronisés du réseau)

1 Like

Et si Cesium ne voit pas tout les forks au moment de la création de la tx ? Typiquement utilisation depuis une connexion pourrie qui ne voit que le nœud Duniter de référence et qui lagge trop a trouver les autres ?
Ta solution est certes plus élégante, mais la mienne est bien plus simple a implémentée et bien plus robuste dans diversités de cas d’usages.

@elois le problème est pour moi la date affichée à l’utilisateur. Comment faire pour être le plus proche possible de la date d’émission, tout en ayant un bloc de référence décalé (peu importe de combien) ?

Ou alors j’affiche plus les dates :slight_smile:

1 Like

Soit le client stocke dans le localStorage un index (HashTx, Date d’émission) ce qui sera plus confort mais demande d’activer l’option “se souvenir de moi”.
Soit dans le cas ou l’option est désactivée, afficher une heure d’émission estimée en considérant qu’il y a en moyenne 1 bloc toutes les 5 minutes. (En se basant sur le décalage paramétré)

C’est galère, car quidd des nouvelles installations, changement de navigateur, changement de compte, etc… j’aime pas trop.

Ben c’est exactement ce que j’ai proposé… :slight_smile: mais en disant que le décalage ne s’applique pas forcément sur les TX recues, car l’émetteur peut avoir une autre conf.
et même d’aiileurs l’utilisateur lui-même pourrait utiliser plusieurs instances paramétrées différemment…

Ca ne règle pas le problème des transactions émises dans le passé (avant le correctif) ceci dit, leur date va être décalée de 3 jours.

Et cette implémentation impacte tout les clients (sakia et silkaj) même si ils ne fonctionnent pas du tout de la même manière en terme de gestion des forks. C’est dommage.

Cesium fait une requêtes sur ws2p/heads avant d’envoyer la transaction tout simplement. Et pour la diffusion à tout les forks, la balle serait alors plutôt dans le camps de Duniter : il faut qu’il accepte de diffuser les documents même si le blockstamp n’est pas dans son fork courant.

En fait je trouve qu’il manque une date d’émission, dans le document de TX…

Voila qui sera top !! on aura donc un date qui serait une date d’émission.

Je ne comprends pas ton truc. Mettons que je détecte les forks. Il me faut ensuite récupérer les sources, sur chaque fork, pour générer le bon document, non ?
Comment faire, sachant que de plus en plus de noeuds n’ont pas BMA d’activé…

Ah, ou alors je garde les sources que j’ai déjà, et j’envoi sur chaque fork un document avec le block head ? (ou head - 6)

Sinon tu peut proposer ce service via Cesium+, tu stocke bien des données de profil. Tu peut aussi stocker les dates d’émissions des tx par hash de tx.

Pour les transactions écrites c’est la date d’écriture en blockchain qui peut etre utilisée dans l’historique affiché a l’utilisateur, çe ne me semble pas déconant :wink:

De toute façon a mon avis tout les clients devrait blockstamper leur document a current_forkWindowsSize pour plus de stabilité.

Le nœud de référence auquel Cesium demande ça n’a pas forcément une vision complète du réseau, mais je suis d’accord ça serait globalement assez efficace, c’est juste plus long a coder comme solution.

Je ne suis pas favorable a cette idée car ça permettrait d’attaquer le réseau par spam.

3 Likes

Non, c’est juste pour le blockstamp. On prend l’hypothèse que les sources sont valides sur tout les forks (si tout les clients se comportent de la même façon, les sources sont consommées sur tous les forks par le broadcast du document)

Je ne sais pas, je ne vois pas en quoi ça permettrait de spammer le réseau de manière plus dense qu’aujourd’hui ?

Je ne sais pas précisement comment cgeek protège BMA du spam, mais perso pour durs je compte bien refuser tout document dont le blockstamp n’est pas dans ma chaîne, ça limitera les spam.
Et puis jusqu’à aujourd’hui on a jamais eu d’attaque par dénis de service, mais tôt ou tard ça viendra, n’ouvrons pas maintenant des failles potentielles.
Duniter n’a pas à relayer des documents dont il ne peut pas vérifier la validité.

2 Likes