Discussion autour de la RFC5 (devenue fygg)

Protocols DUBP
1

27 mars 2018 : cette RFC5 à vraiment progressé, et part maintenant sur un protocole généraliste dans lequel sera implémenté Duniter mais qui pourra supporter d’autres usage tout en réglant les problèmes de passage à l’échelle des blockchains actuelles.

La RFC détaillée est sur le gitlab : WIP: RFC 5 : New Scalable Blockchain Protocol (!6) · Merge requests · nodes / common / doc · GitLab

Je laisse l’ancienne proposition ci-dessous pour des raisons historique.

2 fevrier 2018 : ajout d’un paragraphe sur une nouvelle piste pour améliorer le protocole via des arbres de Merkle.

Bonjour à tous !

Je crée ce sujet pour recentrer les discutions et débats autour du futur nouveau protocole, ainsi que de lister les changements et nouvelles fonctionnalités qui semblent faire consensus.

J’ajoute aussi d’autres propositions à débattre, certaines assez triviales comme d’autres qui peuvent amener des changements importants. Elle ne sont pas encore prévues pour cette prochaine version mais pourront l’être si un consensus est établi à leur sujet.

Vous pouvez aussi commenter avec d’autres fonctionnalités, et si elles rencontre un “certain succès” je les rajouterais dans la liste pour avoir une vue d’ensemble.

Cette nouvelle version du protocole n’a pas encore de date précise, mais elle amorcera une phase de consolidation de Duniter avant de partir sur des fonctionnalités beaucoup plus avancées (Lightning Network par exemple).

Enfin, il serait bon de créer ces propositions du protocole en tant qu’issues du dépôt nodes/common/doc car elles ne dépendent pas des projets individuels (duniter-ts, cesium, sakia, duniter-rs, etc).

Je vous remercie d’avance pour votre participation. :slight_smile:

La RFC détaillée est sur le gitlab : WIP: RFC 5 : New Scalable Blockchain Protocol (!6) · Merge requests · nodes / common / doc · GitLab

Fonctionnalités prévues

  • A1 : Nouveau système de script pour la dépense des transactions permettant la création de contrats intéligents compacts, potentiellement complexe, permettant de masquer des conditions non utilisées.

    Note : Les opérateurs de ce nouveau système de script devront seulement proposer des fonctionnalités de base ou qui simplifie la conception et réduise la taille des transactions. Des comportements trop avancées ne devraient être que des combinaisons de ces fonctions simples voir réalisée avec des ensembles de contrats off-chain comme avec un Lightning Network.

  • A3 : Nouveau format des documents en binaire au lieu du texte pour simplifier leur exploitation par les logiciels ainsi que d’économiser de la place dans la blockchain

    Note : Ce nouveau format doit permettre d’accepter les documents de révocation actuels sans devoir resigner, et bien évidement accepter comme sources des transactions de l’ancien protocole.

Propositions

  • B1 : Les dates entrées dans les en-têtes de blocs sont déterminées par ceux qui forgent les blocs. Il pourrait être possible d’influencer le temps moyen calculé et poser des problèmes avec certains types de contrats sensible au temps (Time Locked Contracts utilisés dans un possible Lightning Network). Un proposition est de définir les intervalles de temps en nombre de blocs/id de blocs, ce qui avec un intervalle entre 2 blocs de 5 mins ne poseraient pas de problèmes pour les durées des documents en mois (certifications, identités) et qui permettrait d’avoir un compteur entier discret (le numéro du bloc).

  • B2 : Un solutions pour limiter le risque de spam sur le réseau. Pour l’instant le nombre d’utilisateurs est faible, tout comme le nombre de transactions. Cependant avec l’expension de la communauté il y a risque d’augmentation importante du nombre de transactions, voir même d’attaques purement malveillantes.
    Il me semble aussi important de garder un protocole simple et de ne pas gérer des quotas pour plein de petits éléments.
    Une idée qui vient de temps en temps sur ce forum est l’utilisation de frais comme dans d’autres cryptomonnaies, qui peuvent bien sûr être nuls tant qu’il n’y a pas de congestion. Il faudrait étudier s’ils sont compatibles avec la TRM, même s’ils ne sont pas de la création monétaire. Ils ne peuvent pas amener à une course à la puissance car celle-ci ne détermine pas le nombre de transactions possibles dans un bloc, et donc les frais récoltés. Ils ne seraient utilisés qu’en cas de congestion pour éviter un spam massif de transactions (qui pourraient là aussi poser problèmes pour un Lightning Network qui doit pouvoir fermer les channels en cas de conflit en un temps limité).
    Beaucoup de personnes ne sont pas pour rajouter cette possibilité, mais j’aimerais réunir les différents arguments pour voir quels sont les désavantages de cette solution par rapport à d’autres plus complexes impliquant des quotas et des limitations pour tous les utilisateurs, même honnêtes.

  • B3 : Possibilité de pouvoir désigner une clé déléguée au calcul des blocs, qui permet de ne pas exposer sa clé privée de membre en cas d’attaque (qui peut permettre de certifier des membres sans l’accord du possesseur de la clé). Cette clé pourrait être changée au bout d’une certaine période avec la signature de la clé membre, et pourrait permettre de révoquer le compte (ce qui incite le membre à sécuriser sa machine, ainsi que de ne pas donner sa clé à un tier de confiance qui calculerait à sa place). Cette clé ne pourrait pas déplacés les fonds du compte membre. (issue #1208)

  • B4 : Changement de l’algorithme de difficulté personnalisé et d’exclusion temporaire. (issue ?)

  • B5 : Changement de l’algorithme de preuve de travail pour être plus ASIC-resistent (issue #1239)

  • B6 : Examiner les différentes règles appliquées, et voir celles qui vraiment utiles et celles qui le sont moins dans le but de simplifier le protocole qui devrait rester simple mais efficace (Keep It Simple, Stupid)

Autre piste

Une autre piste utilisant quasi exclusivement des arbres de Merkle est étudiée. Elle permettrait de “stocker” l’état complet de la monnaie au moment de chaque bloc, de prouver l’existence d’informations dans cet etat via un nombre limité de requêtes, ainsi que de permettre l’oublie d’un grand nombre d’informations d’anciens blocs tout en restant certain que toutes les règles ont été respectées depuis le bloc/arbre genesis. Plus d’informations seront ajoutées au fil des recherches sur ce sujet, et une RFC dédiée la définira précisément et de manière beaucoup plus technique.

2 Likes
2

A1 : Oui
A2 : Pas bien compris. Quelle différence avec WS2P ?
A3 : Oui
B1 : Ok pour les éléments longue durée, mais quid des time locks etc sur les transactions, qui peuvent être beaucoup plus courts ?
B2 : Contre. Les arguments sont toujours dans l’ancien post. En cas de congestion, la priorisation par l’age des sources me parait suffisamment efficace. La plus grande justification derrière les fees ce sont des fausses raisons économiques. Regarde par exemple Steem, qui n’a pas de fees, et qui rémunère les mineurs par l’inflation de monnaie : https://steemit.com/steem/@chitty/steem-has-no-fees-repeat-no-fees
Dans Duniter, l’economic insentive, c’est seulement le fait de faire valoir son droit de décision sur le réseau, et de participer à la sécurisation de la monnaie commune. C’est différent de la théorie des jeux…
B3 : Oui
B4 : Même issue que B5 : https://git.duniter.org/nodes/typescript/duniter/issues/1239
B5 : Oui, attention à avoir un algo qui soit raspberry pi - compatible
B6 : Oui (mais ya du boulot là)

2 Likes
3

Ce sera simplement le standard utilisé par A3, et même si d’autres protocoles existent il serait bien d’avoir au moins un ensemble assez harmonisé.

Donc quelqu’un qui spam le réseau verra toutes ses transactions passer avant celles des utilisateurs normaux ? Le spam est donc une attaque concluante, car il empêche les échanges des autres membres.

Il me semble avoir lu vouloir passer à une plage de 2/3 d’exclusion. Le changement de preuve de travail consiste à faire plus que du SHA256 + Ed25519 + SHA256. Ça me semble donc être 2 choses distinctes :slight_smile:

4

Bof, pour combien de temps est-ce qu’il arrive à empêcher les échanges avec les autres membres ?

5

Heu j’ai loupé un épisode ? A ma connaissance, ceci est une nouvelle proposition, pas une fonctionnalité prévue !

De plus, comme je l’ai déjà dit par le passé j’aimerais que l’on dissocie entièrement le protocole blockchain du protocole réseau. Si vous le souhaitez j’ouvrirai une RFC sur les futurs spec de WS2P ou l’on pourra discuter de tout ça :slight_smile:

2 Likes
6

En phase. Concentrons cette RFC sur le fonctionnement de la chaine. Il faudra toutefois s’assurer que le nouveau format s’intègre bien aux transfert par WS2P.

1 Like
7

Si rien ne l’empêche de publier des transactions (qui passeront dans l’ordre) il peux en poster autant qu’il veut, et donc empêcher tout transactions.

C’est le nouveau format des données en blockchain, qui pourrait être utiliser pour les autres API.

8

Ben non ? Des qu’elle est consommée, la transaction génère des sources d’age “0” … Ces sources passeront donc derrière toutes les transactions des autres utilisateurs ?

9

En fait je ne pense pas que ce soit gênant, WS2P peut envoyer des documents sous n’importe-quel format, du moment qu’il sont récupérés et lus de la bonne façon. Et de toute façon il y aura besoin de faire une nouvelle version de WS2P qui correspondra a ce nouveau protocole donc ou fera les changements nécessaire dans la foulée, bref ce n’est pas une contrainte :wink:

2 Likes
10

D’accord, je vois maintenant ce que tu veux dire, et en effet ça fonctionne. Il me semblait que dans le protocole actuel on pouvait consommer “partiellement” une source (vu qu’on précise le montant en input), et que du coup une source pouvait être utilisée plusieurs fois.

Ce que j’ai défini dans le nouveau protocole (et qui doit donc être actuellement en vigueur) c’est que toute la source est consommée et que la part qui n’est pas utilisée dans l’échange doit être explicitement listée comme sortie. La somme en input et en output doit aussi être égale.

1 Like
11

On consomme déja toujours totalement une source en fait, surement pour ça qu’on se comprenait pas :slight_smile: Une source de 100 est nécessairement totalement dépensée. Et génère par exemple 30 et 70.
Je pense que le montant de la source est précisé uniquement pour simplifier le processing dans le code de Duniter… Mais @cgeek pourra surement nous préciser ça.

1 Like
12

Ok très bien, ça me semble beaucoup plus logique que ce que j’avais compris à premier abord. La sortie de 70 (le reste) est donc implicitement une sortie avec le même verrou que l’entrée ? Comment on fait s’il y en a plusieurs ?

13

Celui qui créé la transaction la reverouille avec sa clé, oui.

Si il y a plusieurs source, il faudrait effectivement choisir si on prend en compte la plus ancienne, la plus récente, une moyenne, une moyenne pondérée par le montant de chaque source…

14

Ou elle doit simplement être explicite. C’est ce que j’ai prévu dans la RFC2 en tout cas.

1 Like
15

J’ai pas compris ce dernier élément, qu’est-ce qui doit être explicite ? Inso parlait du fait qu’en cas de transaction qui consomme plusieurs sources à la fois, il fallait définir quelle était la date retenue.

Et aussi, on reste quand même assez embêté au cas où une personne s’amuse à splitter toutes ses unités Ğ1 sur des comptes différents (minimum 1Ğ1, pour rappel). Dans ce cas il peut quand même placer plusieurs milliers de transactions de façon récurrente et avoir le même poids qu’une grosse transaction. À mon avis il y a un truc à faire avec le montant aussi, mais on en avait déjà parlé sur un autre sujet.

Du reste, je réponds la même chose qu’Inso aux différents points A1…B6.

16

En fait non, je pense @nanocryk que tu faisais allusion a ça : Change handicap formula : replace the median by second tiercile (#1169) · Issues · nodes / typescript / duniter · GitLab

1 Like
17

Y a-t-il la notion de “dust output” avec Duniter ?
Quel est le montant minimum autorisé pour un output ?
Quel est le nombre maximum d’outputs autorisés pour une transaction ? Limite de taille de la tx ?
Il serait intéressant d’essayer de décrire les éventuels scénari possibles d’une attaque de type spam.

18

Tu peux définir “dust output” ?

Je dirais 0.01 g1, et une “adresse” doit contenir au minimum, mais je n’en suis pas certain.

255 inputs, 255 outputs. Quand à la taille actuellement c’est un nombre de ligne qui est défini dans le protocole. Là tout de suite je ne le trouve pas, mais je l’ai vu dedans et sinon quelqu’un d’autre pourra sûrement le préciser.

Il me semble bien qu’il y a plusieurs sujets qui en parlent sur ce forum, avec des propositions pour les limiter.

19

0.01 par output, oui.
Une adresse ne doit pas contenir moins de 0.1 DU.

1 Like
20

D’accord, je ne savais pas que c’était en fonction du DU.