Blockchains / Réseaux peer-to-peer

Proof of Justice

Défilement vers le bas

Whitepaper - Nombre total de pages

Whitepaper - Chiffres totaux

Whitepaper - Auteur(s)

Nathan Trudeau

Whitepaper - Editeur(s)

Nathan Trudeau

Une technologie révolutionnaire

Proof of Justice est un algorithme de consensus révolutionnaire qui résout tous les problèmes majeurs des algorithmes de consensus existants : Il est très écologique, très rapide, sans sensation, sûr et égalitaire (oui, vous avez bien lu tout cela !). Vous voulez faire une CBDC ? Une blockchain complètement décentralisée ? Intégrer complètement l'I.A. à la blockchain ? Tout cela est possible avec Proof of Justice. Oh, et en raison de sa nature fondamentale, PoJ ne fait que devenir plus sûr et plus évolutif au fur et à mesure que le réseau se développe !

Continuez à lire pour connaître le fonctionnement exact en détail, et écoutez cette vidéo pour avoir un aperçu du fonctionnement de Preuve de Justice !

P.S. : Si jamais vous vous perdez en cours de lecture, vous pouvez toujours cliquer sur l'icône (qui apparaîtra et se mettra à jour en bas à gauche de l'écran au fur et à mesure que vous faites défiler la page) pour écouter un résumé vidéo très simple de la section dans laquelle vous vous trouvez !

Introduction

Les blockchains et les réseaux peer-to-peer similaires sont des systèmes comprenant des bases de données qui sont partagées de manière consensuelle entre une pluralité d'entités et sont activement maintenues pour suivre les transactions fournies. Une blockchain décentralisée permet de partager un ou plusieurs types d'activités et d'informations pertinentes entre la pluralité d'entités. Ainsi, pour assurer la légitimité des données, lesdites entités ont besoin de parvenir à un consensus sur l'authenticité de ladite activité et desdites informations pertinentes partagées.

Art antérieur et problèmes

Proof of Work

Une méthode pour atteindre un consensus bien connue dans l'art est un concept appelé "preuve de travail" (PoW) et ses dérivés, qui sont utilisés dans les blockchains telles que BitcoinTM. Le PoW repose généralement sur une première entité qui prouve qu'un certain effort de calcul a été fourni pour valider une pluralité de transactions comprises dans une blockchain PoW. Une ou plusieurs secondes entités sont alors chargées de valider si l'effort produit par la première entité est suffisant, un résultat desdites validations permettant ainsi à la première entité de recevoir une récompense. Pour assurer la sécurité d'un système utilisant le PoW, des algorithmes cryptographiques complexes sont souvent utilisés, et la quantité d'effort de calcul nécessaire pour atteindre un consensus entre les entités participant à la blockchain est souvent importante.

Du point de vue de la sécurité, le PoW repose généralement sur le fait que les entités, telles que la première entité, qui valident les transactions dans la blockchain doivent investir une grande quantité de ressources informatiques afin d'effectuer ladite validation, ce qui entraîne souvent un coût et une consommation d'énergie importants. Comme sous-produit de la quantité desdites ressources informatiques nécessaires pour effectuer ladite validation, une barrière de participation limitative pour les entités moins puissantes prend souvent forme. Ainsi, un système utilisant PoW peut ne pas être attrayant pour diverses raisons, telles qu'une exigence croissante de matériel informatique puissant afin que les entités participant au consensus maintiennent une éligibilité raisonnable à la récompense lors de la validation des transactions, car une augmentation de la puissance de calcul pour valider les transactions est souvent observée en corrélation avec une augmentation d'un ou plusieurs types d'activité de la blockchain, ce qui conduit souvent à une consommation d'énergie importante et à des coûts monétaires croissants.

En outre, du point de vue de la sécurité, le PoW exige généralement que les entités effectuant des transactions dans la blockchain investissent des ressources, telles que des ressources monétaires, lorsqu'elles effectuent lesdites transactions, ce qui peut entraîner des coûts importants, créant souvent une barrière limitant le type, la nature et la portée des transactions que lesdites entités peuvent effectuer.

Proof of Stake

Une autre méthode bien connue pour obtenir un consensus est un concept appelé "preuve d'enjeu" (PoS) et ses dérivés, qui sont utilisés dans les blockchains telles que CardanoTM. Contrairement au PoW, le PoS repose généralement sur la sélection d'un validateur pour fournir un bloc, permettant ainsi l'éligibilité d'une récompense pour ce faire. Le validateur est généralement sélectionné proportionnellement à une quantité de ressources investies, telles que des ressources monétaires. Du point de vue de la sécurité, comme pour le PoW, le PoS repose généralement sur le fait que les entités effectuant des transactions dans la blockchain doivent investir des ressources lors de ces transactions, ce qui peut entraîner des coûts importants, créant souvent une barrière limitant le type, la nature et la portée des transactions que ces entités peuvent effectuer. Un avantage du PoS par rapport au PoW est qu'il nécessite moins d'énergie pour fonctionner. Le PoS, cependant, tend à dépendre des entités qui investissent une quantité importante d'un ou plusieurs types de ressources, ce qui limite souvent les avantages pour les entités moins riches.

Proof of Space

Une autre méthode bien connue pour parvenir à un consensus est un concept appelé "preuve d'espace" (PoSpace) et ses dérivés, qui ressemble au PoW mais tend à s'appuyer davantage sur le stockage que sur de lourds efforts de calcul, et qui est utilisé dans les blockchains telles que ChiaTM. La PoSpace est une technique cryptographique dans laquelle les prouveurs montrent qu'ils allouent l'espace inutilisé du disque dur à l'espace de stockage. Pour fonctionner efficacement, la PoSpace est souvent utilisée avec la preuve de temps. Du point de vue de la sécurité, tout comme le PoW et le PoS, le PoSpace repose généralement sur le fait que les entités effectuant des transactions dans la blockchain doivent investir des ressources lors de ces transactions, ce qui peut entraîner des coûts importants, créant souvent une barrière limitant le type, la nature et la portée des transactions que ces entités peuvent effectuer. Bien que, de la même manière que le PoW nécessite des efforts de calcul importants, le PoSpace exige que le prouveur dispose d'une quantité importante d'espace et de vitesse de lecture dans ses systèmes de stockage de données, tels qu'un disque dur ou un lecteur à semi-conducteurs, ce qui entraîne souvent un investissement important dans le matériel informatique correspondant.

Il existe donc un besoin pour une méthode et un système qui permettent de surmonter les inconvénients identifiés ci-dessus.

Proof of Justice - Aperçu

Les problèmes courants dans le domaine technique liés à la technologie actuelle sont que les algorithmes de consensus nécessitent souvent une quantité importante d'un ou plusieurs types de ressources pour fonctionner et que le pouvoir dans une blockchain connexe est souvent corrélé à la richesse d'une entité donnée, ce qui limite souvent la décentralisation en élargissant le fossé entre les entités plus riches et les entités moins riches.

Proof of Justice fournit, dans une ou plusieurs implémentations, (i) une solution pratique respectueuse de l'environnement, (ii) une solution rapide, (iii) une solution décentralisée, (iv) une solution sans sentiment, et (v) une solution sécurisée à ces problèmes techniques en combinant de multiples stratégies, systèmes et méthodes, y compris l'évaluation de la fiabilité des entités et l'utilisation de nombres pseudo-aléatoires traçables. Travaillant en synchronisation, ces stratégies, systèmes et méthodes fonctionnent ensemble en utilisant peu ou pas d'énergie afin de créer un algorithme de consensus optimisé et écologique.

Architecture de base

Crochets

Les crochets permettent d'exécuter des règles et des scripts en tenant compte des différents états du système. Ils constituent le fondement de la manière dont les règles peuvent s'exécuter et interagir avec les actions et les événements de Proof of Justice. Les crochets sont essentiellement un facteur de définition de l'ordre d'exécution des règles dans un ensemble de règles donné. En outre, les crochets peuvent être enchaînés, de sorte qu'un crochet peut invoquer un autre crochet.

Noeud

Un nœud est un dispositif informatique qui participe au fonctionnement d'un système basé sur la Proof of Justice. Ce dispositif informatique est responsable de la validation et de l'engagement des transactions dans la blockchain. Pour ce faire, l'ordinateur peut soit télécharger l'intégralité du registre distribué, soit déléguer une partie de son stockage sous conditions. Un nœud donné est associé à une paire unique clé privée / clé publique, c'est-à-dire à un portefeuille. Un nœud est associé à une entité. Pour une blockchain mettant en œuvre la Proof of Justice, une entité sera souvent une paire clé publique / clé privée, c'est-à-dire un portefeuille. Il convient de noter que les termes "nœud" et "entité" peuvent être utilisés de manière interchangeable, et il est supposé que le lecteur connaît la différence entre les deux et le contexte dans lequel chaque terme s'applique. Un nœud est également associé à un "pool" de mémoire.

Mempool

Un mempool est un système contenant des transactions à confirmer. Ces transactions ont été récemment soumises par des nœuds et n'ont pas encore été confirmées pour être associées à un bloc. Voici un exemple d'architecture de haut niveau d'un mempool.

Transaction

Une transaction est un ensemble de données représentant des instructions provenant d'un ou plusieurs nœuds et visant un ou plusieurs autres nœuds, des transactions et/ou d'autres données liées à la blockchain. Une transaction dans Proof of Justice doit être effectuée d'une manière spécifique de telle sorte qu'elle respecte un ensemble de règles déterminées. Chaque transaction a au moins un partenaire Peterson et un nonce qui lui est associé. Plusieurs types de transactions peuvent être mis en œuvre, selon l'implémentation de Proof of Justice. Les différents types de transactions peuvent chacun avoir différents ensembles de critères à respecter pour être considérés comme valides.

Bloc

Un bloc est une collection de données d'information sur les transactions. Les blocs sont créés par des entités génératrices qualifiées, qui les ajoutent à la blockchain en vérifiant les nouvelles transactions et en les ajoutant dans lesdits blocs. Un bloc de blockchain comporte plusieurs sections.

Transactions

La première section contient toutes les transactions et est ensuite divisée en plusieurs sous-sections, chaque sous-section étant associée à un ou plusieurs types de transactions, selon l'implémentation de Proof of Justice.

Peterson(s)

La deuxième section contient le Peterson du Générateur associé au bloc au moment de la génération du bloc. Bien que cela soit peu fréquent, dans certaines implémentations de Proof of Justice, il peut y avoir plusieurs Peterson de générateur par bloc.

Système de notation

L'algorithme de consensus Proof of Justice (PoJ) est un système qui encourage les entités à agir de manière juste en pénalisant celles qui ne le font pas. Cela se fait en donnant à chaque entité un score basé sur son comportement, puis en appliquant des règles qui limitent la capacité des entités malveillantes à agir de façon répétée et de mauvaise foi.

Score

Chaque entité dans Proof of Justice est associée à une fiabilité, ladite fiabilité étant établie à la suite de diverses actions et/ou inactions. Le score et la fiabilité d'une entité donnée sont influencés par un ou plusieurs ensembles de règles. Une règle 𝜙 donnée est associée à un poids 𝛾 correspondant, qui peut être fourni sous la forme d'un nombre, et à un indicateur 𝜆 correspondant donné, qui peut être positif ou négatif. On trouvera ci-dessous un exemple d'ensemble de règles, chaque règle 𝜙 étant associée à un poids correspondant 𝛾 et à un indicateur correspondant 𝜆. Il est important de comprendre que Proof of Justice n'est pas destiné à être limité par les règles, poids et indicateurs énumérés ci-dessous et que diverses autres règles, poids et indicateurs peuvent être fournis, influençant éventuellement un score et la fiabilité des entités faisant partie de la blockchain. Étant donné que les mises en œuvre de Proof of Justice varient considérablement, les règles énumérées ci-dessous doivent être adaptées à chaque mise en œuvre pour réaliser le plein potentiel de Proof of Justice.

Tableau 1. Exemple d'ensemble de règles, chaque règle étant accompagnée de son poids et de son indicateur correspondants.

Aperçu des règles	Numéro de règle 𝜙	Poids 𝛾	Indicateur 𝜆
Avoir généré un Peterson différent du partenaire d'une entité (en tant que demandeur)	1	1	+
Avoir passé un temps déterminé (et/ou une quantité d'au moins un bloc généré) dans la blockchain depuis son existence	2	2	+
Avoir généré un Peterson qui n'est pas fréquent dans un bloc nouvellement généré	3	1	+
Génération d'un bloc	4	3	+
Agir en tant qu'agent d'exécution	5	3	+
Avoir généré un Peterson différent du requérant d'une entité (en tant que partenaire)	6	1	+
Avoir généré le même Peterson que le partenaire d'une entité (en tant que demandeur)	7	1	-
Avoir généré le même Peterson que le demandeur d'une entité (en tant que partenaire)	8	2	-
Utilisation fréquente du même partenaire	9	3	-
Être lié à un Peterson qui est fréquent dans les transactions d'un bloc	10	2	-
Avoir des portefeuilles similaires dans les transactions en blocs (comme un générateur)	11	1	-
Avoir un score moyen dans les transactions d'un bloc inférieur ou supérieur à une valeur déterminée (en tant que générateur)	12	1	-
Inclure sa propre transaction dans un bloc (en tant que générateur)	13	2	-
Avoir le même Enforcer dans un nombre déterminé de blocs précédents (comme un générateur)	14	3	-
Avoir le même générateur dans un nombre déterminé de blocs précédent	15	3	-
Avoir un comportement anormal en tant qu'agent d'exécution, générateur, demandeur et/ou partenaire, déterminé par l'apprentissage automatique et/ou tout autre algorithme d'identification pertinent	16	3	-

Attribution des rôles

En référence à la figure 1, une distribution exemplaire des scores d'une pluralité d'entités est présentée sous la forme d'une distribution normale. En fonction du comportement de la pluralité d'entités et de l'ensemble de règles, la distribution peut être fournie sous diverses formes. Un score associé à une entité donnée, dans une mise en œuvre de Proof of Justice, peut être calculé à l'aide de la formule simple suivante : ∑𝜆𝛾𝜙, qui se traduit par une somme de poids et d'indicateurs associés à une pluralité de règles. Une fois le score calculé pour chaque entité, une fiabilité peut être calculée en mettant en correspondance le score avec une distribution probabiliste. Dans une mise en œuvre de Proof of Justice, les entités dont la fiabilité est inférieure à x1 sont considérées comme étant sur liste noire.

Ainsi, selon la figure 1, toutes les entités dont la fiabilité est inférieure à x1 ne seront pas autorisées, ou seront extrêmement limitées, à effectuer une quelconque action dans la blockchain jusqu'à ce qu'une règle, telle que la règle 𝜙=2 du tableau 1, ait augmenté passivement le score au-dessus du seuil de la liste noire. Cela fournit une couche supplémentaire de sécurité car les entités malveillantes ne pourront pas participer et/ou profiter de leurs actions malveillantes.

Dans Proof of Justice, différents seuils de score définissent différents niveaux de permissions et/ou de capacités pour les entités au sein de la blockchain, c'est-à-dire des rôles. Par exemple, un premier seuil x1 peut être utilisé pour mettre des entités sur liste noire, un deuxième seuil x2 peut être utilisé pour déterminer les demandeurs, un troisième seuil x3 peut être utilisé pour déterminer les partenaires, un quatrième seuil x4 peut être utilisé pour déterminer les générateurs et un cinquième seuil x5 peut être utilisé pour déterminer les exécuteurs.

Certaines mises en œuvre de la Proof of Justice peuvent utiliser des règles permettant à une entité donnée de n'être autorisée à jouer un ou plusieurs rôles spécifiques que pendant une période déterminée, avant de perdre l'accès et/ou de devoir relever un défi pour retrouver l'accès. Cela permet d'obtenir un système plus décentralisé et plus sûr, car aucune entité ne peut monopoliser les actions au sein de la blockchain.

Lorsqu'une entité effectue une action qui n'est pas autorisée par son niveau actuel de permissions, l'entité peut être pénalisée en plus de voir sa demande d'effectuer cette action refusée. Les pénalités peuvent prendre diverses formes, telles que, par exemple, la réduction du score, l'inscription sur liste noire, la suppression des autorisations et/ou des capacités, et/ou toute autre forme de punition appropriée.

Figure 1.

Niveaux

Le système de score de Proof of Justice n'est pas lié à un score unique par entité. En effet, une pluralité de scores peut fonctionner ensemble pour obtenir une représentation plus granulaire et plus précise de la fiabilité d'une entité. Comme dans un jeu vidéo, la pluralité de scores peut être représentée sous la forme de "XP" et de "Niveau". Le niveau est un moyen de représenter la performance globale à long terme d'une entité donnée. Les XP (points d'expérience) sont une représentation de la proximité d'une entité par rapport au niveau suivant, c'est-à-dire de la qualité du comportement récent de l'entité.

Les niveaux et les points d'expérience sont utiles pour deux raisons principales :

Il est plus facile pour les entités, telles que les agents d'exécution et les validateurs, d'identifier rapidement les entités qui sont dignes de confiance et celles qui ne le sont pas.
Cela permet au réseau de représenter avec précision la fiabilité d'une entité donnée, par rapport à certaines autres implémentations de Proof of Justice où le score unique d'une entité serait plutôt réduit de manière cyclique pour forcer une rotation des rôles et empêcher la stagnation.

Lorsque l'"XP" d'une entité donnée atteint la valeur maximale autorisée, ladite entité gagne un niveau, c'est-à-dire qu'elle incrémente un second score de 1. Le rythme auquel une entité donnée gagne de l'"XP" est déterminé par les paramètres du système. Lorsqu'une entité gagne un niveau, son XP est remis à 0. Plus le niveau est élevé, plus il est difficile de gagner de l'XP, donc des niveaux, car les récompenses en termes de score de règles ralentissent.

Ce système permet aux entités qui ont été fiables par le passé d'être pardonnées pour les petites erreurs accidentelles. Il incite également les entités à rester actives afin de maintenir leurs privilèges. En effet, un tel système fonctionne bien avec des règles pénalisant les entités qui restent hors ligne pendant de longues périodes.

Les niveaux et les points d'expérience peuvent également être utilisés en conjonction avec d'autres règles, comme la mémoire à long terme et les règles basées sur les défis, pour créer des politiques plus complexes.

Niveaux dépendant du rôle

Comme il sera expliqué ci-dessous, la fiabilité d'une entité donnée, représentée sous la forme d'un ou de plusieurs scores, détermine les actions que ladite entité peut ou ne peut pas faire dans le système basé sur la Proof of Justice, lesdites actions étant déterminées par les rôles accordés par le ou les scores de celle-ci. Ceci est particulièrement important pour les actions liées à la sécurité, telles que l'exécution ou la génération d'un nouveau bloc. Pour garantir que les entités les plus fiables du réseau sont celles qui exécutent ces actions, un système de niveau dépendant du rôle peut être utilisé. Dans un tel système, le niveau d'une entité ne serait pas seulement déterminé par ses performances globales mais aussi par ses performances dans le rôle spécifique qu'elle remplit. Par exemple, si une entité a un niveau élevé en tant qu'agent d'exécution, elle aura plus de chances d'être choisie comme agent d'exécution qu'une autre entité ayant le même niveau global mais un niveau inférieur en tant qu'agent d'exécution. Ce système garantit que seules les entités les plus fiables sont choisies pour les rôles les plus importants et que ces entités sont celles qui ont le plus à perdre si elles agissent de manière malveillante. Le système de niveau dépendant du rôle incite également les entités à participer à une variété de rôles pour avoir plus de chances d'être choisies pour les rôles les plus importants. En effet, si une entité ne participe jamais qu'en tant qu'agent d'exécution, elle aura moins de chances d'être choisie comme validateur qu'une autre entité qui participe à la fois comme agent d'exécution et comme partenaire. Ce système encourage les entités à être bien équilibrées et à participer au réseau de différentes manières, ce qui est bénéfique pour la sécurité et la stabilité globales du réseau.

Inconvénients possibles

Un inconvénient potentiel du système de niveaux et de points d'expérience est qu'il peut être difficile de régler avec précision les paramètres du système afin de garantir sa sécurité et son efficacité. En effet, si les paramètres ne sont pas choisis correctement, il peut être possible pour des entités mal intentionnées d'exploiter le système et d'obtenir un niveau élevé sans être dignes de confiance. De plus, si les paramètres ne sont pas choisis correctement, il est possible que les entités qui sont dignes de confiance soient punies plus sévèrement que celles qui ne le sont pas.

Prévention des exploits

Il existe quelques moyens d'empêcher les entités d'exploiter le système de niveaux et de points d'expérience.

Une façon de le faire est d'implémenter une règle de mémoire à long terme qui garde la trace des actions d'une entité donnée dans le système et d'utiliser ces informations pour réévaluer un ou plusieurs niveaux / XP. Par exemple, si une entité est choisie en tant qu'Enforcer mais qu'elle échoue souvent à faire respecter les blocs, son niveau d'Enforcer sera abaissé.

Une autre façon de procéder consiste à modifier les niveaux dépendant du rôle pour qu'ils soient uniquement à court terme, au lieu d'être permanents. De cette façon, une entité devrait continuellement être performante afin de conserver son niveau élevé.

Une troisième façon de procéder est d'utiliser une règle basée sur un défi qui obligerait les entités à prouver périodiquement leur fiabilité, comme avec une règle basée sur un défi, afin de maintenir leurs niveaux / XPs.

Octroi de l'accès aux ressources

L'un des avantages du système de score dans les systèmes basés sur la Proof of Justice est qu'il peut être utilisé pour accorder aux entités l'accès à différentes ressources et/ou fonctionnalités en fonction de critères. Par exemple, si une entité a un niveau élevé d'application de la loi, elle peut se voir accorder l'accès à des parties spécifiques de la blockchain, comme une DHT plus rapide que la traditionnelle Kademlia avec d'autres inconvénients, comme Koorde, et/ou même un sous-réseau composé uniquement d'entités au-dessus d'un score donné, c'est-à-dire des Enforcers, rendant les communications plus efficaces. Cela est bénéfique car cela permet aux entités qui sont plus dignes de confiance et qui ont prouvé leur fiabilité au fil du temps d'obtenir des privilèges multiples, ce qui incite ces entités à continuer à participer au système.

Système de déclaration des entités

Un système de signalement des entités est un système dans lequel les entités peuvent voter que d'autres entités sont malveillantes afin de réduire leur(s) score(s). Ce système incite les entités à signaler d'autres entités qu'elles estiment malveillantes, car elles seront récompensées si elles ont voté correctement. Ce système est bénéfique car il permet de réduire le niveau de confiance global des entités malveillantes et rend plus difficile leur exploitation du système. En outre, ce système encourage les entités à être vigilantes et à coopérer afin d'assurer la sécurité du réseau.

Pour empêcher une première entité de dénoncer faussement une autre entité afin de réduire son score et de rendre plus difficile sa participation au réseau, on pourrait exiger de la première entité qu'elle fournisse une preuve de malveillance lorsqu'elle dénonce une autre entité et la punir si, selon les autres entités du réseau et/ou une règle non déterministe, elle avait tort. De cette façon, les entités devraient avoir une bonne raison de signaler une autre entité, et elles seraient moins susceptibles de signaler faussement une entité.

Une autre façon de procéder serait de limiter le nombre de rapports qu'une entité peut faire au cours d'une période donnée. De cette façon, les entités devraient être plus sélectives dans les rapports qu'elles font, et elles seraient moins susceptibles de faire des rapports faux ou frivoles.

On pourrait également mettre en place une approche payante pour empêcher le spamming du système de déclaration. De cette façon, les entités devraient payer une petite somme pour faire un rapport, ce qui les découragerait de faire des rapports faux ou frivoles.

On pourrait également utiliser une approche fondée sur la réputation pour donner plus de poids, par exemple sous forme de récompenses en cas de vote correct, aux rapports établis par des entités dont il a été prouvé qu'elles sont dignes de confiance/qui ont une bonne réputation en matière de rapports, et moins de poids aux rapports établis par des entités dont il a été prouvé qu'elles ne sont pas dignes de confiance/qu'elles ont une mauvaise réputation en matière de rapports. De cette façon, les entités légitimes auraient plus de chances de voir leurs rapports pris au sérieux, tandis que les entités qui ont l'habitude de faire des rapports inexacts auraient moins de chances de voir leurs rapports pris au sérieux.

Enfin, on pourrait utiliser une approche fondée sur les garanties pour qu'il soit plus coûteux pour une entité de dénoncer faussement une autre entité. De cette façon, l'entité devrait mettre en place une sorte de garantie, comme une crypto-monnaie native, afin de faire un rapport. Si le rapport s'avère être faux, alors l'entité perdrait son dépôt.

Types de règles

Les règles sont des scripts qui prennent une ou plusieurs entrées données et renvoient un score ajusté pour une ou plusieurs entités. Les règles peuvent prendre différentes formes et sont de différents types. En outre, il est entendu que certaines règles peuvent avoir des limites quant au nombre de points qu'elles peuvent augmenter ou diminuer.

Régulier

Les règles régulières sont des règles qui écoutent un "hook" et qui, lorsqu'un événement est déclenché, calculent le score ajusté d'une ou plusieurs entités en fonction dudit événement. Une règle régulière peut être vue comme une sorte d'instruction "si-alors". Si un certain événement est déclenché, le score d'une entité est augmenté ou diminué d'une certaine quantité en fonction de l'évaluation dudit événement. Par exemple, une règle régulière pourrait être écrite de telle sorte que si une entité génère un nouveau bloc (valide), son score est augmenté de 3 points. Un autre exemple de règle régulière pourrait être rédigé de telle sorte que si une entité tente de générer un bloc considéré comme malveillant selon un ensemble de règles donné, son score est diminué de 10 points. Il existe un nombre infini de façons d'écrire des règles régulières, ce qui les rend très polyvalentes.

Non-déterministe

Les règles non déterministes dans Proof of Justice sont des règles qui écoutent un ou plusieurs "hooks" et qui, lorsqu'un événement est déclenché, tentent de prédire le score ajusté d'une ou plusieurs entités sur la base dudit événement et, dans certains cas, d'événements précédents. Une règle non déterministe est un type spécial de règle qui est autorisée à forcer un ajustement de score pour une entité donnée avec un délai, bien qu'elle puisse être soumise à la supervision d'autres entités, telles que les entités ayant le rôle de Sentinelle. Les règles non déterministes sont sujettes à des changements et des adaptations et sont généralement beaucoup plus gourmandes en espace et en ressources de calcul que les autres types de règles.

Les règles non déterministes sont utilisées pour prédire si le comportement d'une entité est malveillant, et pour suggérer des résultats possibles d'événements, tels qu'un score ajusté, une liste noire, ou toute autre restriction pertinente. Elles peuvent être utilisées pour faire des recommandations ou pour prendre des mesures au nom d'une entité. Les règles non déterministes sont souvent utilisées dans des situations où il est difficile ou impossible de déterminer toutes les informations pertinentes sur un événement ou une situation. Les règles non déterministes peuvent également être particulièrement utiles dans les règles d'opinion.

L'ensemble de données d'un algorithme non déterministe devrait être constitué de données publiques et historiques sur le système basé sur la Proof of Justice ; dans le cas d'une blockchain basée sur la Proof of Justice, les transactions dans les blocs. En tant que tel, la génération d'un algorithme capable d'identifier de manière fiable les actions malveillantes des entités du réseau peut être une tâche difficile en raison de l'absence d'un ensemble de données initial. Il est donc essentiel de garder à l'esprit qu'un maximum d'informations liées au réseau et à la blockchain doivent être enregistrées afin de disposer d'un algorithme non déterministe fiable. Il est également fortement recommandé de créer un prototype fonctionnel capable d'exécuter des simulations de comportements d'entités proches du monde réel, y compris autant de comportements et d'actions malveillants connus que possible. Il serait alors possible de générer un ensemble de données à l'aide desdites simulations et d'entraîner ainsi un algorithme non déterministe.

Il est également recommandé d'inclure, à la sortie, une sorte de phase "d'essai" pour un système basé sur la Proof of Justice mettant en œuvre un algorithme non déterministe du même type, dans lequel ladite phrase "d'essai" permettrait à un ou plusieurs gestionnaires du système de revenir sur des décisions potentiellement cassantes prises par un algorithme non déterministe tout en permettant la collecte de données du monde réel afin d'augmenter les performances de l'algorithme non déterministe.

Il est également recommandé de privilégier à la fois l'efficacité et la précision de l'algorithme. En effet, faire un algorithme qui est précis mais dont l'exécution demande beaucoup de calcul conduirait à la fois à une centralisation du réseau vers des nœuds de calcul plus puissants, mais aussi à l'encontre de la philosophie d'un algorithme de consensus à faible empreinte carbone.

Exigence

Les règles d'exigence sont des règles qui, pour une action de Proof of Justice donnée, doivent être exécutées avec succès et renvoyer une valeur positive avant qu'une ou plusieurs entités puissent exécuter ladite action de Proof of Justice.

Par exemple, une règle d'exigence pour l'action de générer un bloc pourrait être que le générateur doit d'abord soit :

Posséder une certaine quantité de la crypto-monnaie native ; ou
Avoir été actif dans le réseau pendant une période déterminée.

Les règles d'exigence peuvent contribuer à prévenir plusieurs types d'attaques. En exigeant que les nouvelles entités possèdent une certaine quantité de crypto-monnaies avant de pouvoir effectuer des actions spécifiques dans un système de Proof of Justice, il est plus difficile et plus coûteux pour un attaquant de créer de nombreuses nouvelles identités et, dans cet exemple, de récompenser les utilisateurs de longue date en éliminant ces exigences de possession. En tant que telles, les règles d'exigence ajoutent une couche importante de sécurité aux systèmes de Proof of Justice.

Un excellent exemple de règle d'exigence (et de règle basée sur un défi, comme cela sera développé dans la section "Système de notation -> Types de règles -> Basé sur un défi") qui améliorerait grandement un système basé sur la Proof of Justice d'une manière décentralisée serait une règle visant à autoriser une entité donnée à accéder à une ou plusieurs parties du système basé sur la preuve de la justice, dans lequel ladite règle d'exigence comprendrait :

Obtenir un ensemble d'instructions à exécuter par l'entité donnée, l'ensemble d'instructions étant approprié pour autoriser l'entité donnée à obtenir ledit accès ;
Une partie des entités du réseau approuvant le jeu d'instructions obtenu ;
Fournir l'ensemble des instructions approuvées et obtenues à l'entité donnée ;
Obtenir un ou plusieurs résultats d'une exécution de l'ensemble fourni d'instructions par l'entité donnée ; et
Accorder l'accès dans le réseau à l'entité donnée en utilisant lesdits un ou plusieurs résultats.

Il sera compris que l'exécution de l'ensemble d'instructions implique la réception d'une entrée de l'utilisateur étant le propriétaire de l'entité donnée. Dans une ou plusieurs mises en œuvre, l'ensemble d'instructions est adapté pour s'assurer que l'utilisateur n'est pas le propriétaire d'une entité existante dans le réseau. Dans une ou plusieurs mises en œuvre associées, il convient de noter qu'une entité donnée ne peut être associée qu'à un seul, ou un nombre déterminé de, nœuds de calcul.

Dans une ou plusieurs mises en œuvre, une règle d'exigence peut ne pas affecter le(s) score(s) d'une entité donnée, mais permet un accès à un ou plusieurs éléments du système basé sur la Proof of Justice, tels que l'envoi de transactions, l'accès à un algorithme DHT spécialisé, et/ou autres. Ainsi, la règle d'exigence pourrait permettre l'exécution d'une ou plusieurs actions d'un ou plusieurs rôles. Dans une ou plusieurs mises en œuvre, le respect ou le non-respect de la règle d'exigence peut avoir pour conséquence qu'une entité doive fournir des données activées par le traitement d'une ou plusieurs instructions définies.

Il sera entendu qu'une ou plusieurs instructions sont liées à la règle d'exigence, c'est-à-dire que le ou les scores d'une ou plusieurs entités peuvent être affectés par les données activées par le traitement de ladite une ou plusieurs instructions.

Dépendant du score

Les règles dépendantes du score sont des règles qui peuvent être de tout autre type mais qui ne sont activées que lorsque le score de fiabilité d'une entité donnée est supérieur à un seuil donné. Par exemple, une règle dépendante du score pourrait être "Si X a un score supérieur à Y, alors faites Z". De cette manière, différentes conditions peuvent être mises en place en fonction du score d'une entité donnée. Cela permet d'obtenir un système plus souple dans lequel différentes conditions peuvent être appliquées dans différentes situations. Une règle dépendant du score est utilisée pour évaluer les entités de manière plus granulaire.

Par exemple, une règle dépendant du score pourrait réduire le score d'une entité toutes les nième fois que cette entité agit en tant qu'agent d'exécution, forçant une rotation des entités et empêchant la stagnation.

Adaptive

Les règles adaptatives sont des règles qui peuvent être de tout autre type et qui peuvent s'adapter automatiquement en fonction d'une évaluation d'un ou plusieurs aspects de la blockchain. Par exemple, une règle adaptative donnée peut ajuster son propre poids en fonction d'un ou de plusieurs types spécifiques d'activité du réseau ou de tout autre déclencheur pertinent. L'objectif de ces règles est de rendre la blockchain Proof of Justice plus résistante aux actions malveillantes exploitant le poids ou le comportement d'une règle. En outre, les règles adaptatives peuvent aider le réseau à corriger automatiquement certains problèmes sans nécessiter d'intervention manuelle.

Dépendant de l'action

Les règles dépendantes de l'action sont des règles qui peuvent être de tout autre type mais qui ne sont activées que lorsqu'une entité donnée effectue une ou plusieurs actions spécifiques liées à la Proof of Justice. Par exemple, une règle dépendante de l'action pourrait être "Si X essaie de faire Y, alors Z doit se produire d'abord". De cette façon, différentes conditions peuvent être mises en place en fonction des actions entreprises par une entité donnée. Cela permet d'obtenir un système plus souple dans lequel différentes conditions peuvent être appliquées dans différentes situations. Une règle dépendante de l'action peut être utilisée pour empêcher l'exécution de certaines actions si certaines autres conditions ne sont pas d'abord remplies. Par exemple, si une entité a généré un bloc, une règle dépendante de l'action pourrait être utilisée pour s'assurer que le générateur a sélectionné les Enforcers de manière correcte et, dans le cas contraire, le punir et réduire son score.

Mémoire à long terme

Les règles de mémoire à long terme sont des règles qui écoutent un ou plusieurs hooks et qui, lorsqu'un événement est déclenché, en fonction d'un nombre donné (ou de tous) les événements précédents d'un ou plusieurs types pour une ou plusieurs entités données de la blockchain, calculent le score ajusté d'une ou plusieurs entités. Les règles de mémoire à long terme sont importantes car elles contribuent au bon fonctionnement de la blockchain en ajustant les scores des entités en fonction de leur comportement à long terme.

Par exemple, disons que nous avons une règle de mémoire à long terme qui écoute le crochet "enforcement_done". Cette règle pourrait être déclenchée chaque fois qu'une exécution est terminée lorsqu'une entité donnée génère un bloc donné. La règle prendrait alors en compte toutes les applications précédentes de l'entité et, par exemple, si l'entité choisit souvent les mêmes agents d'exécution ou des agents d'exécution ayant des caractéristiques similaires (par exemple des spécifications de machine similaires), alors ladite entité pourrait être punie et son bloc pourrait être considéré comme invalide. Ces événements peuvent également être utilisés par d'autres règles de la blockchain pour déterminer comment cette entité doit être traitée à l'avenir.

Les règles de mémoire à long terme sont importantes car elles fournissent un mécanisme permettant à la blockchain d'identifier des modèles de comportement à long terme et de réagir en conséquence. Cela peut aider la blockchain à éviter les situations où des entités sont capables de jouer le système ou d'exploiter d'une autre manière les failles à long terme.

Mémoire à court terme

Les règles de la mémoire à court terme sont très similaires à celles de la mémoire à long terme, mais elles fonctionnent avec un ensemble de données plus limité. Plus précisément, les règles de mémoire à court terme ne prennent en compte que le passé immédiat pour prendre des décisions. Elles s'opposent aux règles de la mémoire à long terme qui peuvent prendre en compte des données historiques.

L'avantage des règles de mémoire à court terme est qu'elles peuvent être évaluées beaucoup plus rapidement que les règles de mémoire à long terme et qu'elles peuvent également identifier des modèles à court terme qui peuvent ne pas être efficaces ou même possibles, selon leurs implémentations, pour les règles de mémoire à long terme. Par exemple, si une entité a un bon historique de comportement juste, mais qu'elle a récemment commencé à envoyer de grandes quantités de fonds à plusieurs autres portefeuilles et qu'elle agit de manière malveillante lorsqu'elle sélectionne les Enforcers lors de la génération d'un bloc, ladite entité pourrait être directement mise sur liste noire, car cela indiquerait probablement un piratage dudit porte-monnaie, ce qui donnerait potentiellement du temps au propriétaire du porte-monnaie pour agir contre l'utilisateur malveillant.

Enchaînement

Les règles chaînées sont des règles qui écoutent une ou plusieurs sorties de règles (et, dans certains cas, un ou plusieurs crochets) et qui, lorsqu'un événement est déclenché, calculent le score ajusté d'une ou plusieurs entités en fonction dudit événement.

L'un des cas d'utilisation courants des règles enchaînées est de donner aux entités une pénalité de score si elles ont été signalées comme malveillantes par une ou plusieurs règles, telles que les règles non déterministes. Pour ce faire, il suffit de configurer une règle qui se déclenche à la sortie d'autres règles et qui pénalise l'entité si elle répond à certains critères. Par exemple, cela peut être réalisé en ayant une règle qui se déclenche sur les sorties de deux règles ou plus, et donne à l'entité une pénalité de score si ces deux règles ont été déclenchées dans une certaine période de temps.

Jeu croisé

Les règles Cross-Set sont des règles qui écoutent un ou plusieurs crochets et se réfèrent à une ou plusieurs règles dans un ensemble de règles différent et, lorsqu'un événement est déclenché, calculent le score ajusté d'une ou plusieurs entités sur la base dudit événement.

Par exemple, vous avez un ensemble de règles A s'appliquant uniquement lorsqu'une entité donnée agit en tant qu'agent d'exécution, et vous voulez prendre le score de l'ensemble A et l'introduire dans une règle Cross-Set. La règle Cross-Set écouterait un événement dans l'ensemble A et, au déclenchement de cet événement, calculerait le score ajusté pour cette entité.
Les règles Cross-Set sont essentiellement utilisées lorsque vous souhaitez gérer deux ou plusieurs ensembles de règles indépendants, mais que vous souhaitez néanmoins pouvoir partager des données entre eux.

Basé sur les défis

Les règles basées sur les défis sont des règles qui écoutent un ou plusieurs crochets et qui, lorsqu'un événement est déclenché, demandent à un sous-ensemble d'une ou plusieurs entités de relever un ou plusieurs défis et, en fonction des résultats, calculent le score ajusté de ladite ou desdites entités. Une règle basée sur les défis est souvent utilisée en conjonction avec d'autres règles, telles que la mémoire à long terme et les règles non déterministes.

Par exemple, si une règle non déterministe donnée prédit qu'une entité donnée agit de manière malveillante, une règle basée sur le défi pourrait prendre cette prédiction en entrée, ainsi que toute autre entrée pertinente, et demander à ladite entité de relever un défi. Si ladite entité ne réussit pas le défi, alors la règle basée sur le défi pourrait ajuster à la baisse le score de ladite entité.

Une règle basée sur des défis peut être utilisée pour mettre en œuvre une grande variété de politiques, telles que la limitation du débit, la rupture de constante, etc. En outre, les règles basées sur des défis peuvent être enchaînées pour créer des politiques plus complexes. Par exemple, une série de règles basées sur des défis pourrait être utilisée pour demander à une entité de relever des défis de plus en plus difficiles afin de continuer à accéder à une ressource donnée si ladite entité demande plusieurs accès sur une période de temps déterminée.

Inaction

Les règles d'inaction sont des règles qui calculent le score ajusté d'une ou plusieurs entités si un ou plusieurs crochets ne sont pas déclenchés selon des critères spécifiques, tels qu'une période de temps.

Il est utile de considérer les règles d'inaction comme une façon d'exprimer "si X ne se produit pas, alors faites Y". Cela peut être utilisé pour inciter les entités à rester actives dans le réseau et potentiellement filtrer les entités anormales.

Par exemple, disons qu'il existe une règle d'inaction qui stipule que si une entité ne participe pas en tant que partenaire ou agent d'exécution au moins une fois sur une période déterminée, son score sera diminué. Si une entité cesse de participer pendant une période prolongée, elle verra son score diminuer de manière significative et devra tout recommencer pour obtenir des privilèges, tels que des rôles, dans le réseau.

Application des règles

Une fois qu'une entité donnée reçoit un nouveau bloc du réseau et qu'elle a fini de valider ledit bloc, elle exécute les règles de tous les ensembles dans l'ordre déterminé, ledit ordre étant déterminé par un ou plusieurs critères, tels qu'un ou plusieurs paramètres de Proof of Justice, l'ordre d'exécution des crochets et/ou d'autres critères similaires. Dans la plupart des implémentations de Proof of Justice, les règles sont associées à un numéro, qui classe l'ordre dans lequel elles doivent être exécutées. Cela vaut également pour l'ensemble de règles lui-même, dans le cas d'une pluralité d'ensembles de règles dans le même système basé sur la Proof of Justice. Une telle mise en œuvre permet de toujours être en mesure de reproduire et de reconstruire le(s) score(s) associé(s) à chaque entité faisant partie du réseau à tout état de bloc donné pour une version de chaîne donnée.

Ajout, modification et suppression de règles

L'ajout, la mise à jour et la suppression dynamiques des règles permettent d'améliorer et de perfectionner constamment un système basé sur la Proof of Justice, ce qui garantit qu'il reste équitable et efficace. En outre, cette flexibilité permet de réagir rapidement aux changements, aux attaques et aux événements, ce qui rend le système plus résilient et plus sûr.

Ajout d'une règle

Lorsque des entités veulent ajouter une nouvelle règle à la blockchain, elles peuvent créer un sondage où les autres entités ayant un score supérieur à un premier seuil peuvent voter s'ils acceptent d'ajouter ladite règle. Si le sondage atteint le quorum nécessaire, la nouvelle règle est ajoutée à la blockchain. L'ajout d'une nouvelle règle de cette manière permet une manière décentralisée et démocratique de gouverner la blockchain, tout en permettant un certain degré de flexibilité et en garantissant que les votes sont effectués par des entités légitimes.

Le processus d'ajout d'une nouvelle règle à la blockchain par sondage peut être le suivant :

Une entité crée un sondage avec la nouvelle règle proposée et le soumet au réseau.
D'autres entités ayant obtenu des scores supérieurs à un deuxième seuil (et/ou déterminées comme des réviseurs de code de règle appropriés par d'autres processus de vote), qui peut être le même que le premier seuil dans certaines mises en œuvre, examinent la nouvelle règle proposée et votent.
Si le scrutin atteint le quorum, la nouvelle règle est ajoutée à la blockchain. Le quorum peut être atteint si un certain pourcentage d'entités vote en faveur de la nouvelle règle (par exemple, 51% ou deux tiers).
La nouvelle règle est maintenant ajoutée à la bibliothèque de règles, les crochets pertinents sont maintenant en place et la règle est maintenant en fonction.

Diverses techniques et stratégies peuvent être mises en œuvre afin d'empêcher d'éventuelles exploitations d'un tel système, par exemple :

Mise en place d'une redevance pour la création d'un tel scrutin
Pénaliser les entités minoritaires à la fin de la période de vote / lors de l'atteinte du quorum (par exemple, par un score réduit).
Le vote pondéré, où les entités ayant un score plus élevé ont plus de poids dans le processus de vote.
Permettre aux entités de disposer d'un certain délai après la création du scrutin pour examiner la règle proposée avant de voter.
Activation d'un mécanisme de signalement où les entités peuvent fournir une ou plusieurs preuves valables que ladite règle est malveillante et être récompensées de manière significative si elles ont raison (et punies si elles ont tort, ce qui évite le gonflement), et pénaliser fortement l'entité qui a créé ledit sondage. En option, un tel mécanisme de rapport pourrait également inclure une "phase de test" pour les règles nouvellement créées, où la règle est activée et active mais ses effets sont (partiellement) réversibles pendant une période de temps donnée.
Permettre uniquement à des entités spécifiques de lancer un sondage sur la création de règles dans le cas d'un système semi-décentralisé.
Permettre uniquement aux entités qui réussissent à résoudre un ou plusieurs défis émis par le réseau / une ou plusieurs entités de créer un scrutin de création de règles.

Voici un exemple de système fonctionnel pour l'ajout de nouvelles règles (où un mécanisme similaire au mécanisme de signalement susmentionné est activé pour les entités identifiant des binaires et des codes sources malveillants) :

Le drapeau "Proposition de règle acceptée" n'étant pas levé, une entité autorisée, telle qu'un gestionnaire de système ou une entité élue, décide qu'il est nécessaire et/ou utile d'introduire une nouvelle règle.
Ladite entité autorisée ouvre un scrutin de création de règle, où d'autres entités qualifiées faisant partie de la blockchain peuvent voter s'ils souhaitent une règle qui fait ce que la nouvelle règle dit qu'elle fera (un résumé de la règle elle-même, en mots).
Si un quorum positif est atteint, le drapeau "Proposition de règle acceptée" est levé, indiquant que le réseau a accepté de mettre en œuvre une telle règle.
Lorsque le script de règle a été développé et si le drapeau "Proposition de règle acceptée" est levé, un sondage "Révision de règle" est créé et contient :
- Le code source du script de règles ;
- Les fichiers binaires pour les différentes plateformes ;
- Les hachages du code source du script et des fichiers binaires ; et
- Un pointeur vers le sondage qui a fait apparaître le drapeau "Proposition de règle acceptée".
Si un quorum positif est atteint, les fichiers binaires appropriés sont placés dans l'ensemble de règles approprié, les entités participantes appropriées sont récompensées et l'indicateur "Proposition de règle acceptée" est réinitialisé.

Modifier une règle

S'il est décidé qu'une règle doit être modifiée, un sondage "Proposition de modification de la règle" peut être créé. Le processus de modification d'une règle serait le suivant :

Le sondage "Proposition de modification des règles" est créé et contient :
- Le code source du script de la nouvelle règle proposée ;
- Les nouveaux fichiers binaires proposés pour différentes plateformes ;
- Les hachages du code source du nouveau script proposé et des fichiers binaires ; et
- Un pointeur vers le sondage qui a levé le drapeau "Proposition de règle acceptée" pour la version originale de la règle en cours de modification.
Si un quorum positif est atteint, le drapeau "Proposition de règle acceptée" est levé, indiquant que le réseau a accepté de mettre en œuvre un tel changement de règle.
Lorsque le nouveau script de règle a été développé et si le drapeau "Proposition de règle acceptée" est levé, un sondage "Révision de règle" est créé et contient :
- Le code source du nouveau script de règles ;
- Les nouveaux fichiers binaires pour les différentes plateformes ;
- Les hachages du code source du nouveau script et des fichiers binaires ; et
- Un pointeur vers le sondage qui a fait apparaître le drapeau "Proposition de règle acceptée".
Si un quorum positif est atteint, les fichiers binaires appropriés sont placés dans l'ensemble de règles approprié, les entités participantes appropriées sont récompensées et l'indicateur "Proposition de règle acceptée" est réinitialisé.

Suppression d'une règle

S'il est décidé qu'une règle doit être supprimée, un sondage "Proposition de suppression de règle" peut être créé. Le processus de suppression d'une règle serait le suivant :

Le sondage "Proposition de suppression de la règle" est créé et contient :
- La raison pour laquelle la règle devrait être supprimée ; et
- Un pointeur vers le sondage qui a levé le drapeau "Proposition de règle acceptée" pour la version originale de la règle à supprimer.
Si un quorum positif est atteint, le drapeau "Proposition de règle acceptée" est levé, indiquant que le réseau a accepté de supprimer une telle règle.
Lorsque le nouveau script de règle a été développé et si le drapeau "Proposition de règle acceptée" est levé, un sondage "Révision de règle" est créé et contient :
- Le code source du nouveau script de règles ;
- Les nouveaux fichiers binaires pour les différentes plateformes ;
- Les hachages du code source du nouveau script et des fichiers binaires ; et
- Un pointeur vers le sondage qui a fait apparaître le drapeau "Proposition de règle acceptée".
Si un quorum positif est atteint, les fichiers binaires appropriés sont placés dans l'ensemble de règles approprié, les entités participantes appropriées sont récompensées et l'indicateur "Proposition de règle acceptée" est réinitialisé.
Si le quorum négatif est atteint, l'indicateur "Proposition de règle acceptée" est réinitialisé.

Peterson

Le cœur des opérations et des actions de Proof of Justice est basé sur des nombres pseudo-aléatoires et traçables appelés Petersons. Un Peterson est, dans la plupart des implémentations, le résultat de la combinaison du Peterson d'un bloc et de l'identifiant d'une entité.

Génération

L'entité obtient P2 ;
L'entité obtient son ID ;
L'entité a divisé son ID en parties égales correspondant à la longueur de P2 ;
L'entité fait correspondre chaque partie de son ID à des valeurs numériques ; et
L'entité effectue un XOR de P1 avec la première partie de l'ID, puis un XOR du résultat avec la deuxième partie, et ainsi de suite jusqu'à ce que la dernière partie de l'ID ait été XORée avec le résultat du XOR précédent.

Dans certaines situations, une 6ème étape où l'entité signe la P1 est nécessaire. Il pourrait également être nécessaire que plusieurs entités la signent, en fonction de la mise en œuvre et de la situation.

Il est entendu que les étapes peuvent varier considérablement en fonction de la mise en œuvre. Par exemple, l'entité peut ne pas avoir besoin de diviser son ID en plusieurs parties. Il se peut que l'entité n'ait besoin de faire un XOR de son ID avec P2 qu'une seule fois, ou même d'utiliser un mécanisme entièrement différent sans faire de XOR. Dans certaines mises en œuvre, l'identifiant peut être fourni et/ou généré par une ou plusieurs autres entités du réseau.

Dans certaines mises en œuvre, au lieu d'utiliser directement l'ID de l'entité, on peut utiliser une génération dynamique basée sur le score de l'entité et son propre ID.

Il est également possible qu'une pluralité de Petersons soit associée à un bloc. Par exemple, le générateur du bloc pourrait générer un Peterson, où n est le nième dernier bloc au moment de la génération dudit bloc. Ensuite, une étape supplémentaire de réduction numérique serait effectuée dans le processus d'obtention afin d'obtenir P2 à partir de ladite pluralité de Petersons.

Une autre mise en œuvre pourrait exiger, dans un processus de génération de bloc ou un processus de génération de transaction, que le générateur de bloc/le demandeur de transaction obtienne un ou plusieurs Petersons d'une ou plusieurs autres entités, puis les inclue dans ledit bloc/transaction.

Il serait également possible, pour une implémentation donnée, de changer dynamiquement l'algorithme de génération de Petersons en fonction d'un ou plusieurs critères, tels qu'un score de l'entité, un nombre déterminé de blocs qui ont été générés depuis l'existence de la blockchain, et/ou des critères similaires.

Suivi du site

Le but d'un Peterson est de pouvoir identifier quand sa génération a été faite, c'est-à-dire ce qu'était P2 à ce moment-là, afin d'avoir une sorte de mesure de temps décentralisée sur laquelle s'appuyer et d'établir la vérité et la confiance dans le système. En effet, c'est la raison pour laquelle la plupart des implémentations de la Proof of Justice choisiront une solution comme celle du XOR mentionnée ci-dessus afin de récupérer P2 en utilisant une variable connue, comme l'ID dans ladite solution mentionnée ci-dessus.

Une entité peut vérifier le temps de génération d'un Peterson en vérifiant si P2 est ce qu'il devrait être à ce moment-là, en fonction de sa connaissance du réseau. Pour la solution mentionnée ci-dessus, le suivi serait le suivant :

L'entité obtient P1 ;
L'entité obtient l'ID qui a été utilisé en P1 ;
L'entité divise l'ID en parties égales correspondant à la longueur d'un Peterson ;
L'entité fait correspondre chaque partie de son ID à des valeurs numériques ; et
L'entité effectue un XOR de P1 avec la dernière partie de l'ID, puis un XOR du résultat avec l'avant-dernière partie, et ainsi de suite jusqu'à ce que la première partie de l'ID ait été XORée avec le résultat du XOR précédent, pour obtenir P2.

Si P2 est ce qu'il devrait être à ce moment-là, selon la situation pour laquelle le suivi a été fait en premier lieu, alors la génération du Peterson peut être considérée comme valide. Dans le cas contraire, la génération de ce Peterson peut être considérée comme invalide.

Il est entendu que les étapes de suivi peuvent varier considérablement en fonction de la mise en œuvre de la génération.

Sélection des entités

La plupart des processus et des actions dans un système basé sur la Proof of Justice nécessitent de sélectionner une gamme spécifique d'entités afin de communiquer/interagir avec une ou plusieurs d'entre elles. Il s'agit d'une mesure de sécurité, qui limite la possibilité pour une entité donnée de toujours communiquer avec une ou plusieurs autres entités spécifiques pour une ou plusieurs actions d'un ou plusieurs rôles, dans le but d'accomplir des actes potentiellement malveillants. La sélection des entités est souvent effectuée pour sélectionner une ou plusieurs entités ayant droit à un rôle donné (R1).

Obtention des données de présélection

La première étape pour effectuer une sélection d'entités consiste à obtenir les données de présélection. Les données de présélection sont composées de deux éléments :

La ou les distributions de scores actuelles et pertinentes (S1) pour sélectionner la cible ; et
Le Peterson actuel (P1) de l'entité qui doit effectuer la sélection.

Distribution(s) pertinente(s) des scores

S1 peut varier considérablement selon l'implémentation de Proof of Justice. Dans une mise en œuvre utilisant les niveaux et les XP, S1 peut être les niveaux des entités pour R1.

Dans une autre mise en œuvre qui utilise un seul score par entité, la distribution complète des scores est obtenue et déclarée comme S1. Dans ce cas, un sous-ensemble (S2) de S1 serait extrait, où S2 contient toutes les entités qui peuvent être classées comme R1.

Dans une autre mise en œuvre qui utilise une pluralité de scores par entité, chaque score étant associé à un ensemble de règles correspondant, une approche pondérée d'un ou plusieurs de ces sous-ensembles, selon la nature et l'objectif de la sélection, pourrait être compilée et former ainsi S1.

Il est entendu qu'un filtrage supplémentaire sur S1 ou S2 peut être effectué, selon l'implémentation de Proof of Justice. Par exemple, une implémentation pourrait sélectionner les N premières entités dans S2, N étant un paramètre de Proof of Justice ; S2 serait alors utilisé à la place de S1.

Peterson(s)

P1 est obtenu en utilisant le processus Peterson -> procédé de génération mentionné ci-dessus. P1 sera utilisé comme graine de randomisation, permettant le suivi et la validation du processus de sélection des entités.

Traitement des données de présélection

Une fois S1 et P1 obtenus, S1 est séparé en plusieurs morceaux, en fonction du nombre d'entités comprises dans S1. Le nombre (N1) et la taille (Si1) des morceaux peuvent être déterminés de plusieurs façons différentes et selon plusieurs critères, en fonction de la mise en œuvre de Proof of Justice. Dans une mise en œuvre, N1 pourrait être un paramètre de Proof of Justice et Si1 serait calculé en conséquence. Dans une autre implémentation, l'inverse s'appliquerait ; Si1 serait un paramètre de Proof of Justice, tandis que N1 serait calculé en conséquence. De petits ajustements peuvent être faits pour éviter les morceaux vides, en fonction de l'implémentation, de sorte qu'aucun morceau ne puisse avoir un Si1 inférieur à X.

Les morceaux sont ensuite mélangés en utilisant P1 comme graine de randomisation. Ensuite, les n premiers morceaux sont sélectionnés. N peut être déterminé de nombreuses façons. Par exemple, dans une implémentation, il pourrait s'agir d'un paramètre de Proof of Justice, tandis que dans une autre implémentation, il serait calculé en fonction de la raison de la sélection.

Une fois les morceaux mélangés et les n premiers sélectionnés, les entités des morceaux sélectionnés sont rassemblées pour former un ensemble (E1). Selon la mise en œuvre, E1 peut ou non être organisé de manière à pouvoir être suivi, bien que, lorsque cela est possible, une telle organisation soit recommandée pour permettre une meilleure reproductibilité. Par exemple, dans une mise en œuvre, E1 pourrait être mélangé en utilisant P1 comme graine de randomisation. Dans une telle mise en œuvre, il est également recommandé de garder une trace des entités actives et inactives dans le réseau afin que cette reproductibilité soit pertinente et utilisable. Sinon, il serait inexact de supposer que l'entité effectuant la sélection sélectionne réellement une entité dans un ordre séquentiel, de la première à la suivante, comme cela sera décrit ci-dessous.

Effectuer la sélection

Enfin, une entité e est sélectionnée parmi E1 pour effectuer R1. La sélection de e est effectuée par l'entité qui doit effectuer la sélection. Le processus de sélection de e peut être aussi simple que la sélection aléatoire d'une entité de E1 en utilisant P1 comme graine d'aléatoire. Cependant, il pourrait aussi être plus élaboré, selon la mise en oeuvre de la preuve de justice ; par exemple, si plusieurs entités sont nécessaires pour remplir R1 (par exemple, 3 validateurs), alors e pourrait être sélectionné séquentiellement à partir de E1 en utilisant P1 comme graine de randomisation jusqu'à ce que 3 entités distinctes aient été sélectionnées.

Rôles

Le score de Proof of Justice est lié au comportement et à la fiabilité d'une entité donnée au sein du réseau. Atteindre un certain niveau de fiabilité permet à une entité donnée d'accéder à de nouveaux privilèges et responsabilités, ce qui lui permet d'être rémunérée par des récompenses intéressantes en échange de ses services. Les rôles peuvent varier considérablement d'une implémentation de Proof of Justice à une autre.

Types d'octroi

Automatique

Un ou plusieurs critères peuvent être utilisés pour définir quelles entités se trouvent dans le niveau supérieur, ayant ainsi accès à un rôle donné. Par exemple, un critère pourrait être que l'entité se trouve dans le premier X% de toutes les entités ayant le(s) meilleur(s) score(s) (tel que le niveau du rôle de chaque entité). Un autre critère pourrait être que si le score d'une entité donnée est supérieur à un seuil déterminé, alors le rôle est accordé. Par exemple, si une entité a un score de fiabilité globale supérieur à un seuil égal à 50, alors elle débloquera le droit d'agir en tant que, disons, générateur.

Cela permet d'éviter que les entités ayant un mauvais score (et, par conséquent, moins susceptibles d'être méritantes) aient accès auxdits rôles tout en incitant les entités à s'acquitter continuellement, "Grind", d'un rôle donné pour accéder à davantage de récompenses (développé dans la section Rôles -> Types -> Générateur).

Un rôle donné peut avoir des exigences différentes pour chaque mise en œuvre. Par exemple, un rôle de générateur peut avoir besoin d'être dans le top 30% de toutes les entités avec le(s) meilleur(s) score(s) (comme le niveau du rôle de chaque entité) alors qu'un rôle de partenaire peut n'avoir besoin que d'être dans le top 70%, selon une implémentation donnée.

Déterminé

Afin d'accéder à un rôle dans une implémentation donnée de Proof of Justice, une entité doit être approuvée par une ou plusieurs autres entités afin d'accéder à un rôle donné. La ou les entités qui approuvent évalueront si l'entité possède les compétences ou les qualités nécessaires pour occuper ce poste. Par exemple, un rôle de "Réviseur de code" peut devoir être approuvé par X autres entités du réseau sous la forme d'un vote, ou simplement par un ou plusieurs gestionnaires de système, selon la mise en œuvre. Il peut également y avoir des critères spécifiques auxquels l'entité doit répondre afin d'être approuvée, comme prouver qu'elle possède des qualifications pertinentes pour ce rôle, par exemple pour le rôle de "Réviseur de code", en résolvant un défi de programmation généré et proposé par ladite ou lesdites entités d'approbation de manière décentralisée (dans l'exemple de vote, ladite solution audit défi et ledit défi lui-même signé par une ou plusieurs entités d'approbation seraient fournis au réseau au moment de la demande de vote).

Rotation

Afin de s'assurer qu'un rôle donné n'est pas monopolisé par une poignée d'entités, ledit rôle peut faire l'objet d'une rotation (ce qui signifie qu'un sous-ensemble d'entités gagnerait l'accès audit rôle, et qu'un autre sous-ensemble d'entités en perdrait l'accès) périodiquement en fonction d'un ou plusieurs critères, comme par exemple :

Tous les X blocs, faire tourner Y% de toutes les entités ayant un rôle donné ;
Chaque bloc avec une paire Bloc Peterson, rotation Y% de toutes les entités avec un rôle donné ; et/ou

tout autre critère pertinent.

Ce faisant, on s'assure que différentes entités ont la possibilité de remplir lesdits rôles et on évite la stagnation et la centralisation du pouvoir au sein du réseau.

Piquetage

Afin de s'assurer qu'une entité donnée est investie dans le succès de l'action d'un rôle donné, en fonction de l'implémentation et de la nature de l'action dudit rôle, un ou plusieurs actifs de ladite entité seront gelés pendant un temps donné, selon un ou plusieurs critères. Cela signifie que l'entité ne sera pas en mesure d'accéder ou d'utiliser lesdits actifs pendant ladite période de temps, qui peut être déterminée comme une distance de temps entre les blocs (voir Peterson -> Suivi). La nature et/ou la portée du gel peut être déterminée en fonction de diverses conditions, telles qu'un type et/ou une nature donnés de l'action dudit rôle, une quantité et/ou une nature du ou des biens, un score de ladite entité donnée et/ou d'une entité réceptrice/concernée de l'action dudit rôle et/ou d'autres éléments similaires.

Ainsi, il est garanti que les entités sont investies dans le succès de l'action du ou des rôles et sont moins susceptibles d'agir de manière malveillante. En tant que tel, dans une ou plusieurs mises en œuvre, une entité déterminée à avoir agi de manière malveillante verrait :

Un ou plusieurs de ses actifs gelés pour une période prolongée ;
Son/ses score(s), tel(s) que son niveau lié à ladite action, soit (soient) négativement impacté(s) ;
Un ou plusieurs de ses actifs répartis entre un sous-ensemble d'entités du réseau ;
Un ou plusieurs de ses actifs "brûlés", augmentant les récompenses de bloc dans le cas d'une blockchain de Proof of Justice ; et/ou

tout autre élément pénalisant pertinent.

Basé sur l'économie

Dans certaines implémentations de la Proof of Justice, les entités qui veulent prendre part au réseau et/ou effectuer certaines actions liées à celui-ci doivent échanger un ou plusieurs actifs avec le système lui-même afin d'obtenir le droit de le faire. Les actifs peuvent varier considérablement d'une implémentation à l'autre. Par exemple, dans l'une, les actifs peuvent être sous la forme des scores d'une entité, tandis que dans une autre, ils peuvent être sous la forme de jetons ou de pièces. L'échange se fait dans le but d'obtenir l'accès à un rôle et/ou le droit d'effectuer un certain type d'action liée à la blockchain. Par exemple, une entité peut échanger une quantité déterminée d'actifs, sur la base de l'offre et de la demande des autres entités du réseau, pour avoir accès à l'action dudit rôle ou au rôle lui-même. Dans un autre exemple, au lieu d'échanger des actifs, une ou plusieurs entités échangent leur propre score. Par exemple, une entité ayant un score global de 100 pourrait en échanger 40% pour avoir une chance d'agir en tant que rôle d'exécution pour un nombre déterminé de blocs.

Ce système garantit que les entités sont investies dans le succès du réseau et sont moins susceptibles d'agir de manière malveillante. En tant que tel, dans une ou plusieurs mises en œuvre, une entité déterminée à avoir agi de manière malveillante verrait :

Son ou ses scores seront affectés négativement ;
Un ou plusieurs de ses actifs répartis entre un sous-ensemble d'entités du réseau ;
Un ou plusieurs de ses actifs "brûlés", ce qui augmente les récompenses en blocs dans le cas d'une blockchain de Proof of Justice ; et/ou
Tout autre élément pénalisant pertinent.

Ainsi, un système, dans une ou plusieurs mises en œuvre, utilisant la Proof of Justice, peut aider à créer un réseau plus sûr et plus fiable en simulant un système décentralisé, basé sur l'économie.

Types de rôles

Rôle de base

Chaque rôle met en œuvre et est dérivé de la superclasse "Ligne de base". Cette classe fournit la nature fondamentale de chaque rôle dans un système basé sur la Proof of Justice.

Critères et restrictions

Un ou plusieurs critères doivent être remplis pour qu'une entité donnée puisse initier valablement une action liée à un rôle. Ces critères peuvent être de différentes natures, le principal étant que l'entité ait un score valide (tel que le niveau de son rôle dans le cas où le système de niveaux et d'XP est utilisé).

Dans une mise en œuvre, un défi pourrait devoir être relevé par l'entité avant de pouvoir effectuer ladite action liée au rôle.

D'autres techniques peuvent également être utilisées, comme la mise en œuvre d'une règle selon laquelle seul un sous-ensemble d'entités du réseau est autorisé à effectuer ladite action liée au rôle pour une plage donnée de blocs, ledit sous-ensemble étant calculé dynamiquement sur la base du Peterson du bloc actuel. Bien que limitante, cette technique pourrait renforcer la sécurité d'un système basé sur la Proof of Justice.

Des restrictions peuvent également être mises en place pour une entité donnée selon un ou plusieurs critères, variant fortement en fonction du rôle concerné. Par exemple, une quantité maximale d'actions liées à un rôle et/ou une limitation d'un ou plusieurs aspects de ces actions peuvent être imposées en fonction du niveau de rôle de l'entité. Ainsi, un niveau inférieur signifierait des restrictions accrues par rapport à une entité ayant un niveau supérieur.

Dans le cas où une pluralité d'entités dudit rôle sont tenues de coopérer afin de rendre valide une action liée au rôle, alors une combinaison de restrictions telles que celles mentionnées ci-dessus serait, dans une mise en oeuvre, utilisée.

Demandeur et partenaire

Le rôle Demandeur est responsable de la génération et de la diffusion des transactions sur le réseau. Ce rôle permet essentiellement à une entité donnée de créer et de pousser une transaction, en fonction de plusieurs critères. Le rôle Partenaire est chargé de valider des parties d'une transaction et de fournir son Peterson afin de rendre ladite transaction valide ultérieurement.

Critères et restrictions

Outre les critères par défaut, un critère supplémentaire approprié à ce rôle pourrait être que l'entité ne doit pas avoir effectué plus de X transactions d'un ou de plusieurs types spécifiques dans les Y derniers blocs/délai, le délai pouvant être calculé à l'aide du Peterson associé à chaque transaction (qui sera développé ci-dessous). Dans une mise en œuvre, X pourrait être un paramètre de Proof of Justice, tandis que dans une autre, il pourrait être calculé en utilisant la moyenne des transactions de ces types spécifiques effectuées par d'autres entités dans les Z derniers blocs, où Z peut être soit Y, un paramètre de Proof of Justice ou calculé dynamiquement en utilisant une ou plusieurs règles.

Des exemples d'aspects pour lesquels il serait approprié d'imposer des restrictions pour le rôle de demandeur pourraient inclure le nombre d'actifs que le demandeur peut transférer en fonction de son niveau de demandeur, une somme d'actifs transférés dans le temps (établie à l'aide d'un score, ledit score étant déterminé à l'aide d'une règle de mémoire à long terme, par exemple), et/ou des aspects similaires.

Informations préalables à la transaction

Les informations préalables à la transaction sont des données qu'il est nécessaire d'inclure dans une transaction pour que celle-ci soit valide. Ces données sont généralement générées et obtenues avant d'effectuer d'autres processus de génération de transactions. Les informations pré-transaction peuvent comprendre des éléments tels que l'identifiant de l'entité du demandeur (tel qu'une clé publique de portefeuille, si applicable dans la mise en œuvre), les actifs à transférer, l'identifiant de l'entité de destination recevant les actifs (tel qu'une clé publique de portefeuille, si applicable dans la mise en œuvre), un nonce, l'identifiant du type de transaction et/ou des éléments similaires. Les informations préalables à la transaction peuvent varier considérablement en fonction de la mise en œuvre de Proof of Justice.

Dans plusieurs implémentations, une fois que les informations préalables à la transaction ont été rassemblées, elles sont ensuite compilées et signées (PT1). Dans plusieurs implémentations, le demandeur génère également son Peterson (P1) et l'inclut dans PT1 avant de signer PT1.

Frais de transaction

Frais de transaction - Sans coût

Une transaction effectuée dans un système basé sur la Proof of Justice a le potentiel d'être complètement sans sentiment, principalement en raison du mécanisme de Peterson, comme il sera développé dans le rôle du générateur, et de l'évaluation et de l'établissement fiables de la fiabilité des entités au sein du système au fil du temps. Dans une implémentation de Proof of Justice, toutes les transactions seraient sans coût.

Frais de transaction - Adaptatif

Dans une autre mise en œuvre, les frais associés à une transaction sont adaptatifs, ce qui signifie qu'ils sont ressentis uniquement en fonction de critères spécifiques, tels que :

Le(s) score(s) du demandeur, comme son niveau de demandeur ;
Un défi réalisé par le demandeur dans le cadre du processus de collecte d'informations pré-transaction ;
Selon le(s) type(s) de jeton(s) impliqué(s) dans la transaction (par exemple, on pourrait dire que la monnaie native est sans coût, tandis que les jetons peuvent avoir accès aux transactions sans coût sur la base d'un ou plusieurs critères, comme avec une approbation par un gestionnaire de système, permettant à la société qui a fait la blockchain d'accéder potentiellement à des flux de revenus supplémentaires) ; et/ou

tout autre critère qui peut être jugé approprié par le ou les créateurs d'un système basé sur la Proof of Justice.

Frais de transaction - statiques

Dans une autre mise en œuvre encore, la redevance est statique et immuable indépendamment de tout critère. Les frais peuvent être, par exemple, un montant très faible déterminé comme un paramètre de Proof of Justice.

Frais de transaction - basés sur le type

Dans une autre mise en œuvre, les frais sont basés sur le type. Cela signifie qu'il y aurait des frais différents pour chaque type de transaction. Par exemple, dans un système où les jetons peuvent être envoyés sans frais, un type de transaction pourrait être associé à des frais, tandis qu'un autre type de transaction (l'envoi de la pièce native, par exemple) ne serait soumis à aucun frais. Cette mise en œuvre pourrait être utilisée en conjonction avec n'importe quelle autre mise en œuvre. Par exemple, un système pourrait avoir des transactions sans frais pour sa monnaie nationale mais pas pour les jetons, ou il pourrait avoir des transactions sans frais uniquement lorsqu'un défi est relevé avec succès.

Frais de transaction - Dynamique

Enfin, dans une autre mise en œuvre, les frais sont dynamiques et calculés sur la base des frais des X derniers blocs, soit pour toutes les transactions, soit pour un sous-ensemble de transactions déterminé à l'aide d'un ou plusieurs critères (tels que le type de transaction, le(s) score(s) des entités impliquées dans la transaction, un défi réussi par le demandeur, et/ou tout autre critère pouvant être jugé approprié). Cette mise en œuvre pourrait également être utilisée en conjonction avec n'importe laquelle des autres mises en œuvre. Par exemple, un système pourrait avoir des transactions sans coût pour sa pièce native mais pas pour les jetons, ou il pourrait avoir des transactions sans coût seulement quand un défi est complété avec succès.

Il convient de noter qu'il ne s'agit que d'exemples de la manière dont les frais de transaction peuvent être traités dans un système basé sur la Proof of Justice et que toute autre méthode jugée appropriée pourrait également être utilisée.

Sélection des partenaires

Pour qu'une transaction soit considérée comme valide dans un système basé sur la Proof of Justice, un Peterson obtenu d'une entité ayant un rôle de partenaire (Pa1) doit être obtenu et compris dans ladite transaction.

Selon l'étape 202 de la figure 2, tout d'abord, Pa1 est sélectionné à l'aide du processus de sélection d'entités susmentionné. Le Peterson (P1) du demandeur, selon la mise en œuvre de la Proof of Justice, est également introduit dans ledit processus de sélection d'entités.

Selon l'étape 204, une fois que Pa1 a été sélectionné, le demandeur envoie un message (M1) à Pa1, dans lequel M1 contient PT1. Une fois que Pa1 reçoit M1, il génère son propre Peterson (P2) en utilisant le processus Peterson -> procédé de génération mentionné ci-dessus. Pa1 évalue ensuite M1 et détermine la validité de M1 en l'analysant. L'analyse peut varier considérablement en fonction des informations prétransactionnelles qui y sont incluses. Dans la plupart des mises en oeuvre, une partie importante de la validation consiste à évaluer la distance entre P1 et P2. Pour ce faire, Pa1 utiliserait le processus Peterson -> Suivi mentionné ci-dessus pour P1, puis déterminerait la distance en blocs entre P1 et le bloc Peterson utilisé pour générer P2.

Selon l'étape 206, Pa1 inclut ensuite P2 dans un message de réponse (M2). Dans une mise en œuvre donnée de la Proof of Justice, M2 comprendrait également des informations supplémentaires, telles que le hachage d'au moins une partie pertinente de M1. M2 est ensuite signé et renvoyé au demandeur.

Selon l'étape 208, il est déterminé si le Requérant a besoin d'un ou plusieurs autres Partenaires pour la transaction. La nécessité de sélectionner un autre partenaire et le nombre de partenaires à sélectionner peuvent être déterminés par divers moyens, selon la mise en œuvre de Proof of Justice, tels que le niveau du demandeur, un paramètre de Proof of Justice, un ratio d'augmentation de l'activité malveillante détectée dans le réseau établi en analysant le nombre d'entités sanctionnées sur un nombre donné de blocs, une recommandation par un ou plusieurs partenaires, et/ou des moyens similaires. Dans une ou plusieurs mises en œuvre, le besoin d'un ou de plusieurs partenaires est inclus par le demandeur dans M1.

Selon l'étape 210, dans une mise en œuvre donnée, le demandeur sélectionnerait alors, de manière similaire à l'étape 202, un autre partenaire (PaN+1). Dans une autre mise en œuvre, PaN (où Pa1 est pour la première itération) serait celui qui sélectionne PaN+1 à la place du demandeur. Cela peut être fait comme un moyen de résilience supplémentaire contre les activités malveillantes qui pourraient être tentées par les demandeurs dans le réseau et augmenter l'entropie (pseudo)aléatoire pendant le processus de génération de blocs, qui sera décrit ci-dessous.

Selon l'étape 212, une fois que PaN+1 a été sélectionné, PaN envoie un message (MN) à PaN+1, dans lequel MN contient M1 (ou une version signée de PT1, selon la mise en oeuvre). Dans une ou plusieurs mises en oeuvre, MN contiendrait également des informations sur les partenaires précédemment sélectionnés, le nombre de partenaires restant à sélectionner, les informations de chaînage actuelles (l'ordre de sélection des partenaires), et/ou des informations similaires. Une fois que PaN+1 reçoit MN, il génère son propre Peterson (PN+1) en utilisant le processus Peterson -> procédé de génération mentionné ci-dessus. PaN+1 évalue ensuite MN et détermine la validité de MN en l'analysant. L'analyse peut varier considérablement en fonction des informations de pré-transaction qui y sont incluses. Dans la plupart des mises en oeuvre, une partie importante de la validation consiste à évaluer la distance entre P1, PN et PN+1. Pour ce faire, PaN+1 utilise le processus Peterson -> Suivi mentionné ci-dessus pour P1, puis détermine la distance en blocs entre P1 et le bloc Peterson utilisé pour générer PN+1. Il ferait ensuite de même pour PN et PN+1.

Selon l'étape 214, PaN+1 inclut ensuite PN+1 (et/ou PN-X, selon une ou plusieurs mises en oeuvre) (et P1, selon une ou plusieurs mises en oeuvre) dans un message de réponse (MN+1). Dans une mise en œuvre donnée de la Proof of Justice, MN+1 comprendrait également des informations supplémentaires, telles que le hachage d'au moins une partie pertinente de M1 (et/ou MN, selon la mise en œuvre). Le MN+1 est ensuite signé et renvoyé au demandeur (ou à PaN, qui le transmettra ensuite à PaN-1 et PaN-1 compilera les informations avant de les transmettre à PaN-2 et ainsi de suite jusqu'à atteindre Pa1, qui transmettra les informations compilées au demandeur).

Ensuite, l'étape 208 est exécutée à nouveau. S'il est déterminé à l'étape 208 qu'un partenaire supplémentaire est nécessaire, les étapes 210 à 214 sont alors répétées. Sinon, l'étape 216 est traitée.

Selon l'étape 216, le Demandeur compile ensuite les informations reçues par tous les Partenaires.

Figure 2.

Fournisseur

Une fois que les données ont été compilées, elles sont signées par le demandeur et diffusées dans le réseau. La façon dont les entités réceptrices traitent la transaction varie grandement en fonction de la mise en œuvre de la Proof of Justice. Dans une ou plusieurs mises en œuvre, un nœud recevant une transaction jugée malveillante en fournira la preuve au réseau à l'aide d'un mécanisme similaire au "système de notation -> système de déclaration des entités" mentionné ci-dessus. Dans une ou plusieurs mises en œuvre, un mécanisme de mise en cache des transactions est utilisé. Ce mécanisme permettrait essentiellement à des entités spécifiques ayant un rôle de "validateur" de valider une transaction, en fournissant une preuve signée de la validation au réseau et en permettant à d'autres entités du réseau d'utiliser ce verdict de validation au lieu de valider la transaction elle-même avant de l'ajouter aux blocs lors de sa génération ou à leur "mempool" lors de sa réception. Si ladite (une ou plusieurs) desdites autres entités n'ont pas confiance dans le résultat du verdict de la validation mise en cache, elles peuvent la valider manuellement. De plus, si après une validation manuelle le résultat n'est pas le même que celui mis en cache, la preuve peut en être envoyée au réseau avec un système similaire à celui mentionné dans la section "Système de notation -> Système de rapport des entités". Les "Validateurs" se verraient également attribuer des récompenses en bloc pour leur travail, tout comme les Speedsters, les Exécuteurs, les Générateurs et autres. Une "durée de vie" serait également associée à un verdict de transaction donné mis en cache. Dans une ou plusieurs mises en œuvre, la mise en cache est effectuée par le ou les partenaires dans le processus de génération de transaction lui-même s'ils ont le droit de le faire (c'est-à-dire s'ils sont également associés au rôle de "validateur").

Générateur & Exécuteur

Le rôle Générateur est responsable de la génération et de la diffusion des blocs sur le réseau. Ce rôle permet essentiellement à une entité donnée de générer et de pousser le bloc suivant, en fonction de multiples critères. Le rôle Exécuteur est responsable de la validation de certaines parties d'un bloc, en particulier l'organisation de la transaction, et de l'approbation des différences dans l'ordre des transactions afin de rendre le bloc valide.

Critères et restrictions

En plus des critères par défaut, un critère supplémentaire approprié pour ce rôle pourrait être que l'entité doit avoir au moins X transactions pour chaque type donné, ou au total selon l'implémentation, dans son "mempool". Dans une implémentation, X pourrait être un paramètre de Proof of Justice, tandis que dans une autre, il pourrait être calculé en utilisant un système de taille de bloc dynamique, qui sera développé ci-dessous dans la section "Rôles -> Types -> Speedster".

Des exemples d'aspects pour lesquels il serait approprié d'imposer des restrictions pour le rôle de demandeur pourraient inclure le nombre de transactions que le générateur peut inclure dans un bloc et/ou le nombre d'agents d'exécution requis pour ledit bloc et/ou le seuil d'acceptation de chaque agent d'exécution donné pour ledit bloc, qui pourrait être directement lié à son niveau de générateur, à une somme de blocs générés au fil du temps (établie à l'aide d'un score, ledit score étant déterminé à l'aide d'une règle de mémoire à long terme, par exemple), et/ou des éléments similaires.

Informations sur le pré-blocage

Les informations pré-blocs sont des données qu'il est nécessaire d'inclure dans un bloc pour que celui-ci soit valide. Ces données sont générées et/ou obtenues avant d'effectuer d'autres processus de génération de blocs. Les informations pré-blocs comprennent des éléments tels que le Peterson (P1) du générateur, un sous-ensemble (qui peut être la totalité, selon l'implémentation) de transactions dans le "mempool" du générateur, le hachage du bloc précédent et toute autre information pertinente.

Le nombre de transactions sélectionnées pour être placées dans un bloc peut être déterminé par différents moyens. Dans une mise en œuvre donnée, la somme de la taille en octets de chaque transaction par rapport à un seuil unique de taille de bloc maximale statique est le facteur déterminant. Dans une ou plusieurs mises en œuvre, le seuil unique de taille maximale de bloc est dynamique, et un seuil dynamique de taille minimale de bloc est également utilisé, sur la base d'un système de taille de bloc dynamique, ledit système étant développé ci-dessous dans la section "Rôles -> Types -> Speedster". Dans une ou plusieurs mises en œuvre, le niveau de génération de l'entité et/ou le nombre d'agents d'exécution nécessaires pour un bloc donné à générer a également un impact sur le nombre total de transactions pouvant être comprises dans ledit bloc.

Dans Proof of Justice, l'organisation des transactions dans un bloc par leur Peterson partenaire (ou une combinaison/sous-ensemble de ceux-ci, dans le cas où une pluralité de Petersons partenaires sont associés à chaque transaction) est un élément crucial. En effet, c'est en partie la raison pour laquelle les transactions ont le potentiel d'être sans coût en premier lieu. L'ordonnancement peut prendre différentes formes. Par exemple, on peut ordonner les transactions du plus petit Peterson partenaire associé au plus grand Peterson partenaire. Il est recommandé d'utiliser une structure de données auto-équilibrée rapide, efficace et fiable comme composant central du "mempool" de chaque nœud afin d'optimiser ce processus autant que possible. Cependant, plusieurs techniques d'organisation peuvent être utilisées en fonction de l'implémentation.

Il est également possible d'utiliser plusieurs techniques d'organisation et/ou plusieurs structures de données, comme une structure de données pour un ou plusieurs groupes d'un ou plusieurs types de transactions, un peu comme en utilisant plusieurs tables dans une base de données SQL au lieu d'une table avec une colonne "type". L'utilisation de plusieurs structures de données peut conduire à des gains de performance significatifs, selon l'implémentation de Proof of Justice. On comprendra que tant que la méthode d'organisation est connue (et/ou traçable si, par exemple, dans une ou plusieurs implémentations, l'ordonnancement des transactions se fait à l'aide du Peterson du Générateur, bien qu'il soit recommandé de s'en tenir à une ou plusieurs méthodes d'organisation statiques dans tout le système pour des raisons de performance) par les autres entités du réseau, ladite méthode d'organisation devrait être possible à mettre en œuvre. Enfin, il est important de comprendre que toute technique d'organisation devra également prendre en compte le nonce associé à chaque transaction, le cas échéant, en plus du ou des Peterson(s) des partenaires.

Dans plusieurs mises en œuvre, une fois que les informations pré-blocs ont été recueillies, elles sont ensuite compilées et signées (PT1).

Sélection d'Exécuteurs

Pour qu'un bloc soit considéré comme valide dans un système basé sur la Proof of Justice, une ou plusieurs entités ayant un rôle d'exécuteur (Pa1) doivent comparer la liste de transactions (T1) du générateur avec sa propre liste de transactions (T2), comme si Pa1 générait lui-même un bloc, et fournir finalement le résultat de la comparaison (ou sa preuve) (Cr1) au générateur, ledit générateur comprenant alors Cr1 dans ledit bloc.

Il n'est pas recommandé qu'une grande quantité d'Exécuteurs vérifie et signe chaque liste de transactions proposée par chaque Générateur donné, car cela pourrait conduire à de graves problèmes d'évolutivité et de performance à terme. Par conséquent, tout comme le(s) partenaire(s) d'un demandeur, un sous-ensemble d'un ou plusieurs responsables de l'application doit être sélectionné de manière déterminée et traçable pour un générateur donné, en trouvant un équilibre entre la sécurité statistique et la performance.

Selon l'étape 302 de la figure 3, tout d'abord, Pa1 est sélectionné à l'aide du processus de sélection d'entités susmentionné. Le Peterson (P1) du générateur, selon la mise en œuvre de la Proof of Justice, est également introduit dans ledit processus de sélection d'entités.

Selon l'étape 304, une fois que Pa1 a été sélectionné, le générateur envoie un message (M1) à Pa1, dans lequel M1 contient PT1. Une fois que Pa1 reçoit M1, il génère son propre Peterson (P2) en utilisant le processus Peterson -> procédé de génération mentionné ci-dessus. Pa1 évalue ensuite M1 et détermine la validité de M1 en l'analysant. L'analyse peut varier considérablement en fonction des informations de pré-blocage qui y sont incluses, mais elle implique toujours Pa1 :

Générer sa propre liste de transactions (T2) à partir de son propre "mempool" ;
S'assurer que T2 est organisé de la même manière que T1 l'a été ; et
Établir la différence (ou l'indication/la preuve de celle-ci) (D1) entre T1 et T2.

Une partie importante de la validation qui devrait être dans toutes les implémentations de Proof of Justice est de déterminer et d'évaluer la distance entre P1 et P2. Pour ce faire, Pa1 utiliserait le processus Peterson -> Suivi mentionné ci-dessus pour P1, puis déterminerait la distance en blocs entre P1 et le bloc que le Peterson a utilisé pour générer P2.

Selon l'étape 306, Pa1 inclut ensuite P2 et D1 dans un message de réponse (M2). Dans une mise en œuvre donnée de la Proof of Justice, M2 comprendrait également des informations supplémentaires, telles que le hachage d'au moins une partie pertinente de M1. M2 est ensuite signé et renvoyé au générateur.

Dans une ou plusieurs mises en œuvre, un mécanisme où les transactions (ou leurs indications) dans M2 sont considérées comme validées lorsqu'elles sont incluses par le générateur dans le nouveau bloc (car, dans plusieurs mises en œuvre, les transactions dans M2, une fois incluses dans le bloc, seraient utilisées comme référence uniquement et sans être considérées comme validées et confirmées).

Selon l'étape 308, il est déterminé si le générateur (ou son Pa1, dans une ou plusieurs implémentations) a besoin d'un ou plusieurs autres Exécuteurs. En effet, dans une ou plusieurs mises en oeuvre, il pourrait être jugé qu'un Exécuteur aurait besoin de se faire "exécuter" lui-même afin d'augmenter la sécurité. La nécessité de sélectionner un autre Exécuteur et le nombre d'Exécuteurs à sélectionner peuvent être déterminés par divers moyens, selon la mise en œuvre de la Proof of Justice, tels que le niveau du Générateur (ou de l'Exécuteur), un paramètre de Proof of Justice, un ratio d'augmentation de l'activité malveillante détectée dans le réseau établi en analysant le nombre d'entités punies sur un nombre donné de blocs, une recommandation par un ou plusieurs Exécuteur(s), et/ou similaire. Dans une ou plusieurs mises en œuvre, le besoin d'un ou plusieurs Exécuteur(s) est inclus par le Générateur (ou son Exécuteur précédent, si et quand cela est applicable) dans M1.

Selon l'étape 310, dans une mise en œuvre donnée, le générateur sélectionnerait ensuite, de la même manière qu'à l'étape 302, un autre agent d'exécution (PaN+1). Dans une autre mise en œuvre, PaN (où Pa1 est pour la première itération) serait celui qui sélectionne PaN+1 à la place du générateur. Cela peut être fait comme un moyen de résilience supplémentaire contre les activités malveillantes qui pourraient être tentées par les générateurs (ou leur(s) précédent(s) Exécuteur(s)) dans le réseau.

Selon l'étape 312, une fois que PaN+1 a été sélectionné, PaN envoie un message (MN) à PaN+1, dans lequel MN contient M1 (ou une version signée de PT1, selon l'implémentation). Dans une ou plusieurs implémentations, MN contiendrait également des informations sur les Exécuteurs précédemment sélectionnés, le nombre d'Exécuteurs restant à sélectionner pour le Générateur (et/ou l'un de ses Exécuteurs précédents), les informations de chaînage actuelles (l'ordre de sélection des Exécuteurs) et/ou des informations similaires. Lorsque PaN+1 reçoit MN, il génère son propre Peterson (PN+1) en utilisant le processus Peterson -> procédé de génération mentionné ci-dessus. PaN+1 évalue ensuite MN et détermine la validité de MN en l'analysant. L'analyse peut varier considérablement en fonction des informations de pré-blocage incluses, mais elle implique toujours PaN+1 :

Générer sa propre liste de transactions (TN+1) à partir de son propre "mempool" ;
S'assurer que TN+1 est organisée de la même manière que T1 (et TN, le cas échéant, de celle-ci) a été organisée ; et
Établissement de la différence (ou indication/preuve de celle-ci) (DN+1) entre T1 (ou TN de celle-ci) et TN+1. Dans une ou plusieurs mises en oeuvre, au lieu de comparer T1 (ou TN de celle-ci) à TN+1, DN est comparé à TN+1. Dans une ou plusieurs mises en oeuvre, le résultat d'une comparaison entre DN+1 et DN est renvoyé à la place de DN+1.

Dans une ou plusieurs implémentations, si DN+1 contient un nombre de différences supérieur à un seuil déterminé, le bloc est considéré comme invalide, et le processus est donc terminé. Il est recommandé qu'une pluralité d'Exécuteurs doivent arriver à une conclusion similaire avant de mettre fin au processus, afin d'empêcher d'éventuelles attaques sur le réseau par les Exécuteurs. Dans une ou plusieurs implémentations, les Exécuteurs qui arrivent à des conclusions anormales sont éventuellement punis par une ou plusieurs règles.

Dans une ou plusieurs mises en œuvre, la moyenne de chaque conclusion de l'Exécuteur est considérée comme la différence finale selon T1 et TN+X. Dans une ou plusieurs mises en œuvre, les conclusions anormales sont exclues du calcul de la moyenne.

Une partie importante de la validation qui devrait être dans toutes les implémentations de Proof of Justice est de déterminer et d'évaluer la distance entre P1, PN, et PN+1. Pour ce faire, PaN+1 utiliserait le processus Peterson -> Suivi mentionné ci-dessus pour P1, puis déterminerait la distance en blocs entre P1 et le bloc que Peterson a utilisé pour générer PN+1. Il fait ensuite de même pour PN et PN+1. Il est entendu que le temps de latence entre la demande M1 initiale et les demandes ultérieures est destiné à être pris en compte lors de la détermination de DN+1. Ainsi, dans une ou plusieurs mises en œuvre, un seuil de latence d'acceptation est utilisé, ledit seuil pouvant être déterminé par divers moyens. Par exemple, il peut être calculé :

Basé sur le nombre d'Exécuteurs(s) à utiliser pour un bloc donné ;
Basé sur la latence moyenne globale du réseau signalée par une ou plusieurs entités ayant un rôle spécialisé donné ;
Sur la base d'un paramètre de Proof of Justice ; et/ou

tout autre calcul jugé pertinent pour une mise en œuvre donnée de Proof of Justice.

Selon l'étape 314, PaN+1 inclut ensuite DN+1, PN+1 (et/ou PN-X, selon une ou plusieurs mises en œuvre) (et P1, selon une ou plusieurs mises en œuvre) dans un message de réponse (MN+1). Dans une mise en œuvre donnée de la Proof of Justice, MN+1 comprendrait également des informations supplémentaires, telles que le hachage d'au moins une partie pertinente de M1 (et/ou MN, selon la mise en œuvre). Le MN+1 est ensuite signé et renvoyé au générateur (ou à PaN, qui le transmet à PaN-1 et PaN-1 compile les informations avant de les transmettre à PaN-2 et ainsi de suite jusqu'à Pa1, qui transmet les informations compilées au générateur).

Ensuite, l'étape 308 est exécutée à nouveau. S'il est déterminé à l'étape 308 qu'un agent d'exécution supplémentaire est nécessaire, les étapes 310 à 314 sont répétées. Sinon, l'étape 316 est traitée.

Selon l'étape 316, le Générateur compile ensuite les informations reçues par tous les Exécuteurs.

Figure 3.

Fournisseur

En utilisant les informations compilées par les Exécuteurs, le Générateur termine la génération du bloc, formant ainsi le bloc suivant (B1). B1 est ensuite poussé vers le réseau.

Validation croisée

A la réception de B1, une entité réceptrice donnée (R1) validera B1 et son intégrité.

Tout d'abord, R1 vérifiera si l'architecture de base de B1 est valide. Cela implique de vérifier des éléments tels que son en-tête, la structure de chaque section de B1, etc.

Dans une ou plusieurs mises en œuvre où un mécanisme de taille de bloc dynamique est utilisé (expliqué en détail dans la section "Rôles -> Types -> Speedster"), les vérifications impliquent en outre la validation de la taille du bloc.

Ensuite, R1 vérifiera que les transactions de B1 sont valides et qu'il n'y a pas de conflit avec le(s) bloc(s) précédent(s) de la blockchain, que les transactions sont organisées correctement, que toutes les signatures sont valides, que la(les) validation(s) de l'Exécuteur est(sont) valide(s), et ainsi de suite. La validation des transactions peut être effectuée soit intégralement par chaque entité, soit à l'aide d'un système de cache tel que celui mentionné ci-dessus. Seront évalués, dans l'ordre, les éléments suivants :

La chaîne la plus longue sera déclarée comme étant la chaîne actuelle. En cas d'égalité, on passe au critère suivant.
Comparez le score de chaque Générateur(s), trouvez celui ou ceux qui ont le score le plus élevé. En cas d'égalité, passez au critère suivant.
Comparez les Petersons de chaque chaîne, et trouvez laquelle présente la distribution la plus standard de Petersons. En cas d'égalité, passez au critère suivant.
Comparez l'ID de chaque Exécuteur(s), et trouvez celui qui a l'ID absolue la plus petite En cas d'égalité, passez au critère suivant.
Comparez l'ID de chaque générateur et trouvez celui qui a la plus petite ID absolue.

Plusieurs autres critères peuvent être utilisés/changés, selon la mise en œuvre.

Mises à jour de la ou des base(s) de données locale(s)

R1 considérera alors la chaîne de B1 (BC1) comme la chaîne courante et mettra à jour sa chaîne locale en conséquence.

R1 procède ensuite à l'exécution et à l'application des règles sur BC1, conformément à la section "Système de notation -> Application des règles" susmentionnée. Après avoir appliqué ces règles, R1 s'assure que le(s) score(s) de chaque entité du réseau est(sont) à jour dans sa base de données locale.

R1 peut également mettre à jour ses soldes locaux de chaque devise impliquée dans BC1, en fonction des transactions effectuées dans BC1 ainsi que de la distribution des récompenses de bloc (expliquée ci-dessous dans la section Récompenses de bloc dynamiques).

L'objectif final est que toutes les entités maintiennent une version locale de la blockchain et de la base de données qui soit toujours à jour avec l'état global de la blockchain. Toutes les entités utiliseraient alors leur version locale de la blockchain et de la base de données pour s'assurer que tout fonctionne sans problème et comme prévu, et comme référence pour tous les processus pertinents.

Récompenses en blocs dynamiques

Les récompenses du bloc sont attribuées aux entités en fonction des rôles qu'elles ont remplis au sein dudit bloc, chaque rôle ayant un certain poids sur le total des récompenses du bloc.

Le poids attribué à chaque rôle est le suivant : Le storer(s) obtient 15%, l'Enforcer(s) obtient 35%, le Generator(s) obtient 30%, le Speedster(s) obtient 15% et le Partner(s) obtient 5%.

Ces poids peuvent être modifiés par un vote démocratique, par des mécanismes de réduction ou par d'autres moyens, selon la mise en œuvre de Proof of Justice. Un exemple de mécanisme de réduction pourrait être quelque chose du genre : Pour chaque nombre N de blocs, les récompenses des blocs sont divisées par deux par X%, calculé en fonction du nombre de récompenses disponibles. En effet, le nombre de récompenses disponibles peut augmenter si un mécanisme de "brûlage" est utilisé, tel que celui mentionné ci-dessus dans "Rôles -> Types d'octroi -> Jalonnement".

Les récompenses par blocs peuvent changer considérablement de nature en fonction de la mise en œuvre de la Proof of Justice. Dans une ou plusieurs mises en œuvre, les récompenses de bloc consistent uniquement en la pièce centrale de la blockchain. Dans une ou plusieurs autres implémentations, chaque jeton créé sur une blockchain utilisant Proof of Justice serait inclus dans les récompenses de bloc selon un ou plusieurs critères, tels que le nombre de transactions dans un bloc donné impliquant lesdits jetons. Voici un exemple :

Il y a 5 transactions dans un bloc donné. Si le bloc est rempli de :

1 Transaction de la pièce A ;
2 transactions du jeton B ; et
2 transactions du jeton C,

alors les récompenses du bloc seraient :

(1/5 * 10) pièce A ;
(2/5 * 10) jeton B ; et
(2/5 * 10) jeton C,

étant donné que, si les 5 transactions dudit bloc sont constituées de la pièce A, 10 de la pièce A seront attribuées comme récompenses du bloc. Cette technique incite à la concurrence entre les jetons dans une blockchain donnée basée sur la preuve de la justice, incitant ainsi le créateur de chaque jeton à commercialiser ledit jeton afin d'attirer plus d'utilisateurs, créant ainsi de la publicité pour la blockchain basée sur la Proof of Justice. En outre, un tel système permet de retarder, dans le cas où la pièce A aurait une offre maximale (bien que cela ne soit pas recommandé afin de conserver l'aspect sans coût des transactions effectuées dans le cadre de Proof of Justice), le moment où l'offre maximale de la pièce A est atteinte.

Dans une ou plusieurs mises en œuvre, chaque jeton créé sur une blockchain basée sur la Proof of Justice serait utilisé comme récompense de bloc, sans faire le mécanisme de pondération des transactions comme dans l'exemple précédent.

Dans une ou plusieurs mises en œuvre, seuls les jetons seraient soumis au mécanisme de pondération des transactions, tandis que la ou les pièces natives seraient toujours récompensées à pleine capacité.

Dans une ou plusieurs mises en œuvre, la récompense par jeton est définie lors de la création dudit jeton et peut être mise à jour de manière décentralisée, comme un mécanisme de vote similaire au mécanisme de mise à jour des règles mentionné ci-dessus dans "Système de notation -> Ajout, modification et suppression de règles -> Modification d'une règle".

Dans une ou plusieurs mises en œuvre où un ou plusieurs types de transactions dans B1 auraient un ou plusieurs frais attachés, lesdits frais seraient soit :

Ajoutés aux récompenses à distribuer ; ou
Distribués à des entités spécifiques en fonction du type de transaction. En effet, une transaction impliquant une ou plusieurs entités ayant le rôle de Réviseur de code pourrait allouer un grand pourcentage des frais au(x) Réviseur(s) de code concerné(s), indépendamment du pourcentage d'allocation par défaut pour les récompenses de bloc.

Dans une ou plusieurs mises en œuvre où un mécanisme de taille de bloc dynamique est utilisé (développé dans la section "Rôles -> Types -> Speedster"), selon la mise en œuvre de ce mécanisme, l'allocation de récompenses à une ou plusieurs entités peut être affectée.

Speedster

Le rôle de Speedster est responsable du maintien des seuils de taille de bloc idéaux en fonction de l'activité actuelle du réseau et du matériel des nœuds du réseau. Ce rôle permet essentiellement à une entité donnée de créer et de lancer un sondage visant à modifier un ou plusieurs seuils de taille de bloc, ainsi que de voter dans des sondages lancés par d'autres Speedster, selon plusieurs critères.

On comprendra que plus une taille de bloc donnée est grande, plus l'évaluation et/ou la génération et/ou la fourniture et/ou l'obtention et/ou le traitement d'un bloc donné sont souvent exigeants, et que du matériel à haute performance est donc souvent nécessaire pour rendre le processus rapide et efficace. Étant donné que le matériel à haute performance est généralement coûteux et limité, ce qui le rend inaccessible à certains individus, tels que les individus non privilégiés, la taille d'un bloc est souvent directement corrélée à la centralisation de la blockchain vers des nœuds de calcul plus puissants. D'autre part, une taille de bloc plus petite limite souvent l'aspect évolutif d'une blockchain donnée. Souvent, les blockchains de l'art antérieur sélectionnent la taille de bloc pour trouver un équilibre entre la maximisation de la décentralisation et la minimisation de l'évolutivité. Cependant, une telle taille de bloc statique présente des inconvénients, tels que les inconvénients apportés pendant et à la suite des multiples débats passionnés de BitcoinTM sur les tailles de bloc, que les tailles de bloc dynamiques de Proof of Justice peuvent surmonter.

Critères et restrictions

Outre les critères par défaut, un critère supplémentaire approprié pour ce rôle pourrait être que l'entité doit avoir été le plus souvent constamment en ligne et réactive pendant une période déterminée et avoir un matériel de nœuds assez rapide. Un autre critère pourrait être d'avoir un score global moyen supérieur à un seuil déterminé et de ne jamais avoir été mis sur liste noire.

Des exemples d'aspects pour lesquels il serait approprié d'imposer des restrictions pour le rôle d'accélérateur pourraient inclure le nombre de sondages que l'accélérateur peut lancer sur une période de temps déterminée en fonction de son niveau d'accélérateur, le nombre de sondages lancés par l'accélérateur / votés par l'accélérateur au fil du temps (établi en utilisant un score, ledit score étant déterminé en utilisant une règle de mémoire à long terme, par exemple), et/ou similaire.

Seuils

Les seuils définissent le nombre minimum ou maximum de transactions, approximativement, qui peuvent être mises en blocs par les générateurs. Le nombre de seuils peut varier considérablement en fonction de l'implémentation de la Proof of Justice. Un bloc peut comprendre plusieurs seuils. Dans la plupart des implémentations, tous les seuils sont dynamiques. Dans d'autres implémentations, seuls certains seuils sont dynamiques, tandis qu'un ou plusieurs autres sont statiques.

Calcul de la (des) nouvelle(s) valeur(s) seuil(s)

La ou les nouvelles valeurs du ou des seuils de taille de bloc peuvent être calculées et déterminées par divers moyens. Dans une mise en oeuvre donnée, la différence sur une période de temps déterminée des nouvelles transactions d'un ou plusieurs types entrant dans le "mempool" du Speedster (et, dans certaines mises en oeuvre, une pluralité de ceux-ci) est le facteur déterminant. Dans une ou plusieurs mises en oeuvre, le ou les scores associés au demandeur et/ou au partenaire de chaque nouvelle transaction ont un impact sur le calcul. Par exemple, plusieurs nouvelles transactions provenant d'entités non fiables peuvent ne pas être prises en compte dans le calcul. Dans une ou plusieurs mises en œuvre, la quantité de transactions dans un bloc est corrélée à une augmentation des récompenses du bloc, jusqu'à un montant déterminé.

Dans une ou plusieurs mises en œuvre, le niveau de l'entité a également un impact sur la validité et l'acceptabilité d'un sondage de mise à jour du seuil. Par exemple, un Speedster donné avec un niveau de Speedster médiocre prendrait le risque d'être puni plus sévèrement qu'un autre Speedster, plus fiable, si son sondage est rejeté par les autres Speedsters.

Dans les implémentations de la Proof of Justice utilisant les tailles de bloc dynamiques, la taille d'un bloc donné est principalement calculée en utilisant la somme de chaque partenaire Peterson par transaction dans un bloc donné. Dans le cas d'une pluralité de partenaires Petersons par transaction, une combinaison de ceux-ci est effectuée avant le calcul. Dans certaines implémentations où plusieurs sections de différents types de transaction sont présentes dans un bloc donné, un poids est attribué à chaque section, ajustant ainsi la somme résultante des partenaires Petersons.

Dans une ou plusieurs mises en œuvre, une valeur de seuil donnée ne peut être mise à jour que dans les limites des valeurs minimale et maximale déterminées.

Types de mise en œuvre des seuils

Les seuils peuvent être traités de différentes manières.

Dans certaines mises en œuvre, un seuil donné est absolu : un générateur ne peut pas enfreindre un seuil donné et est lié par celui-ci.

Dans d'autres mises en œuvre, un seuil donné est une limite souple : un Générateur peut l'enfreindre, mais selon un ou plusieurs critères. Par exemple, un générateur ne peut le faire que si son niveau de générateur est supérieur à un nombre déterminé. Dans une ou plusieurs mises en œuvre, si un générateur choisit d'enfreindre le seuil, il obtiendra des récompenses en blocs décroissant de manière exponentielle. Ainsi, dans un système utilisant des frais de transaction conditionnels (ou complets), il peut être avantageux pour un générateur de sacrifier un peu de récompenses par bloc pour obtenir davantage de récompenses via les frais de transaction. Il est cependant fortement recommandé, pour les implémentations utilisant quelque chose de ce genre, d'implémenter un seuil dur supplémentaire pour empêcher les blocs anormalement grands. Dans certaines mises en œuvre, un générateur reçoit des récompenses supplémentaires si la taille du bloc est égale ou très proche du seuil souple. En conséquence, dans une ou plusieurs mises en œuvre, un Générateur est puni plus la taille du bloc est éloignée du seuil souple, tel que significativement inférieur à celui-ci.

Dans une ou plusieurs mises en œuvre, un générateur donné peut être autorisé à bénéficier d'une liberté supplémentaire en fonction de la taille du bloc si, par exemple, ledit générateur a mis des actifs en garantie lors de la génération dudit bloc jusqu'à ce que ledit bloc soit validé avec succès par le réseau.

Dans une ou plusieurs implémentations, si un Générateur donné souhaite une plus grande liberté en fonction de la taille du bloc, on pourrait demander à ce Générateur de réaliser au préalable un défi plus ou moins complexe, en fonction de ses demandes.

Seuil supérieur

Un seuil supérieur est le nombre maximum de transactions qu'un générateur est autorisé à mettre dans un bloc. Un seuil supérieur peut être une limite souple ou dure, et il peut y avoir plusieurs seuils selon les implémentations (par exemple, un seuil souple et un seuil dur). Le but d'un seuil supérieur est d'empêcher les blocs extrêmement grands, empêchant ainsi ou limitant sévèrement la plupart des nœuds avec du matériel régulier dans le réseau pour traiter ledit bloc, centralisant le réseau, sans limiter sévèrement les Générateurs dans la taille de bloc qu'ils peuvent choisir.

Seuil inférieur

Un seuil inférieur est le nombre minimum de transactions qu'un générateur est autorisé à mettre dans un bloc. Un seuil inférieur peut être une limite souple ou dure, et il peut y avoir plusieurs seuils selon les implémentations (par exemple, un seuil dur et un seuil souple). L'objectif d'un seuil inférieur est d'empêcher les générateurs d'envoyer des blocs contenant peu ou pas de transactions pour tenter d'attaquer le réseau. De plus, un seuil plus bas permet une décentralisation relative du réseau plus la valeur du seuil est petite, donnant l'opportunité aux nœuds avec un matériel informatique moins puissant de participer au réseau.

Informations préalables au scrutin

Les informations pré-sondage sont des données qu'il est nécessaire d'inclure dans un sondage pour que celui-ci soit valide. Ces données sont générées et/ou obtenues avant d'effectuer d'autres processus de génération de sondage. Les informations de pré-sondage comprennent des éléments tels que le Peterson du Speedster, une indication de la distribution globale du matériel des nœuds dans le réseau, la ou les nouvelles valeurs du ou des seuils de taille de bloc (et, dans certaines mises en œuvre, une preuve du calcul sous-jacent), et toute autre information pertinente.

Création d'un sondage et vote

Une fois qu'un Speedster a généré les informations pré-sondage, il les signe et crée la transaction de sondage. Le Speedster diffuse ensuite le sondage sur le réseau. Dans certaines mises en œuvre, la création d'un tel sondage nécessite que le Speedster avance des frais de transaction (et/ou une garantie qui sera ensuite retournée au Speedster si le sondage est réussi). Il est entendu que, puisque le sondage est une transaction, un ou plusieurs partenaires sont nécessaires, le processus de sélection du partenaire se trouvant dans la section "Rôles -> Types -> Demandeur et partenaire -> Sélection du partenaire".

Dans une ou plusieurs mises en œuvre, si deux ou plusieurs Speedsters essaient de créer un sondage dans une petite période de temps, l'un des deux sondages sera rejeté. Ainsi, il ne peut y avoir qu'un seul sondage par bloc. Plusieurs méthodes peuvent être utilisées pour déterminer quel sondage sera choisi. Par exemple, un sondage donné peut être plus prioritaire qu'un autre si le niveau de Speedster de son créateur est plus élevé que celui de l'autre ou des autres.

Après avoir validé la transaction de création de sondage, les autres Speedsters du réseau voteront s'ils sont favorables ou non à la modification du ou des seuils en analysant les informations pré-sondage spécifiées dans la transaction de création de sondage. Pour chaque Speedster, une fois qu'il a établi son verdict, il créera une transaction de vote l'indiquant comme tel et la diffusera au réseau pour être placée dans un nouveau bloc. Dans une ou plusieurs implémentations, une règle de mémoire à long terme analysant si un Speedster donné décline constamment les changements de la ou des valeurs seuils d'une pluralité de Speedsters fiables verra son ou ses scores impactés négativement.

Dès qu'un Speedster constate que le sondage est clos (c'est-à-dire que suffisamment de votes ont été exprimés et/ou qu'un nombre déterminé de blocs ont été générés depuis la validation de la transaction de création du sondage), il vérifie le résultat du sondage et, s'il est accepté, modifie en conséquence la ou les valeurs seuils dans sa base de données de mise en cache locale.

Dans plusieurs implémentations, si ledit sondage est refusé, le bloc donné déclenchant l'événement de fin dudit sondage, le Speedster qui a créé le sondage est puni. La nature de la punition peut prendre différentes formes. Par exemple, dans le cas où une approche collatérale est utilisée lors de la création de l'interrogation, le Speedster perdrait ainsi sa garantie, dans laquelle ladite perte implique soit la redistribution de la totalité (ou d'une partie de la) garantie aux entités du réseau et/ou sa réaffectation en tant que récompense de bloc. Dans une ou plusieurs mises en œuvre, la punition est proportionnelle au(x) score(s) du Speedster. Dans une ou plusieurs mises en œuvre, les accélérateurs qui ont voté en défaveur du résultat du sondage sont également punis. Il est entendu que la punition peut varier considérablement. Dans une ou plusieurs mises en œuvre, un mécanisme similaire au "système de notation -> système de rapport des entités" serait également utilisé, permettant aux entités de signaler les sondages malveillants même après le fait et punissant / récompensant les entités en conséquence. Par exemple, si le résultat d'un sondage est positif mais qu'une entité prouve par la suite que ce sondage était malveillant, par exemple en identifiant des modèles malveillants avant et/ou pendant le sondage qui n'ont pas été identifiés à l'époque en raison de la limitation des règles, les entités malveillantes pourraient subir des sanctions, comme cela est expliqué dans la section "Rôles -> Types spéciaux -> Liste noire", tandis que les entités non malveillantes qui ont été précédemment punies parce qu'elles n'étaient pas favorables au résultat du sondage seraient ainsi compensées, par exemple en voyant leur(s) score(s) augmenter et en se voyant attribuer un poids supplémentaire lors du calcul des récompenses par bloc pour un nombre déterminé de blocs.

Sentinelle

Le rôle Sentinelle est chargé de surveiller, de modifier ou de mettre fin à une ou plusieurs règles non déterministes (telles que les algorithmes liés à l'IA, les algorithmes d'apprentissage automatique, etc.) Ce rôle consiste essentiellement à déterminer le comportement anormal d'une ou plusieurs règles non déterministes et à agir en conséquence afin de les stabiliser. En effet, bien qu'utile pour identifier et prendre des mesures contre les actions potentiellement malveillantes non prévues d'une ou plusieurs entités, un algorithme non déterministe n'est pas parfait et peut punir des entités qui ne le méritent pas. Une petite marge d'erreur est acceptable dans certaines circonstances, mais si l'algorithme non déterministe commence à agir de manière erratique et à avoir un impact sévère sur le comportement et la sécurité du réseau, des mesures doivent être prises pour maintenir la stabilité.

Critères et restrictions

Des exemples d'aspects pour lesquels il serait approprié d'imposer des restrictions pour le rôle de sentinelle pourraient inclure le nombre de sondages que la sentinelle peut lancer sur une période de temps déterminée en fonction de son niveau de sentinelle, le nombre de sondages lancés par la sentinelle / votés par la sentinelle au fil du temps (établi en utilisant un score, ledit score étant déterminé en utilisant une règle de mémoire à long terme, par exemple), et/ou similaire.

Informations préalables au scrutin

Les informations pré-sondage sont des données qu'il est nécessaire d'inclure dans un sondage pour que celui-ci soit valide. Ces données sont générées et/ou obtenues avant d'effectuer d'autres processus de génération de sondage. Les informations pré-sondage comprennent des éléments tels que le Peterson de la Sentinelle, la ou les actions que la Sentinelle juge nécessaire de prendre concernant l'algorithme non déterministe, le raisonnement derrière cette ou ces actions, et toute autre information pertinente.

Dans une ou plusieurs mises en œuvre, si deux ou plusieurs Sentinelles tentent de créer une interrogation dans un court laps de temps, l'une des deux interrogations sera rejetée. Ainsi, il ne peut y avoir qu'une seule interrogation Sentinelle par bloc. Plusieurs méthodes peuvent être utilisées pour déterminer quel sondage sera choisi. Par exemple, un sondage donné peut être plus prioritaire qu'un autre si le niveau de la Sentinelle de son créateur est plus élevé que celui de l'autre ou des autres.

Afin de déterminer cette ou ces actions, le nœud Sentinelle analysera le comportement de l'algorithme non déterministe et le comparera à un ensemble de paramètres pondérés sous forme de critères. Voici un ensemble exemplaire de critères qui peuvent être utilisés pour diagnostiquer et évaluer rationnellement le comportement erratique d'un algorithme non déterministe :

L'algorithme punit-il des entités pour des actions fiables couvertes par des règles déterministes déjà existantes ?
Étant donné qu'un processus de diagnostic manuel a été effectué en examinant les verdicts précédents rendus par l'algorithme non déterministe, l'algorithme punit-il les entités d'une manière qui n'était pas prévue à l'origine ?
Un deuxième algorithme non déterministe, ou une autre règle déterministe de celui-ci, prédit-il que le premier algorithme non déterministe présente un comportement erratique avec un degré élevé de certitude ?
Le comportement erratique de l'algorithme non déterministe a-t-il un impact important sur le réseau ?

Il est entendu que, dans plusieurs mises en œuvre, la plupart des critères seront déterminés mathématiquement par un processus automatisé. Cependant, dans une ou plusieurs mises en œuvre, comme le suggère le critère exemplaire #2, des processus manuels par des utilisateurs derrière des entités peuvent également être utilisés et jugés pertinents.

Si l'on considère que l'algorithme non déterministe se comporte de manière erratique, la Sentinelle calcule et détermine la ou les actions à entreprendre pour corriger ce comportement erratique. La liste des actions qui peuvent être entreprises est la suivante : suspendre, activer et mettre à jour.

Suspendre: La Sentinelle peut suspendre temporairement l'algorithme non déterministe afin de laisser le temps d'effectuer une analyse des causes profondes et/ou de mettre en place un nouvel algorithme non déterministe.

Activez: Si l'algorithme non déterministe a été précédemment suspendu, la Sentinelle peut le réactiver.

Mise à jour: La Sentinelle peut mettre à jour l'algorithme non déterministe en modifiant ses paramètres, en ajoutant de nouveaux critères, en corrigeant des bogues, et/ou autres. Ceci est similaire à la section "Système de notation -> Ajout, modification et suppression de règles -> Modification d'une règle" mentionnée ci-dessus, mais spécifiquement pour une règle non déterministe. Le but est de limiter les entités qui ne sont pas spécialisées dans ce domaine technique, par exemple, l'apprentissage automatique, dans un cas où des examens manuels / critères manuels sont nécessaires dans une mise en œuvre, d'avoir un impact biaisé sur la décision du réseau, et de laisser la décision aux entités spécialisées dans le réseau. Ceci, cependant, peut ne pas être mis en œuvre, selon l'implémentation.

Création d'un sondage et vote

Une fois qu'une Sentinelle a généré les informations pré-sondage, il les signe et crée la transaction de sondage. La sentinelle diffuse ensuite le sondage sur le réseau. Dans la plupart des cas, la création d'un tel sondage exige de la Sentinelle des frais de transaction (et/ou une garantie qui sera ensuite retournée au Speedster si le sondage est réussi). Il est entendu que, puisque l'enquête est une transaction, un ou plusieurs partenaires sont nécessaires, le processus de sélection du partenaire étant décrit dans la section "Rôles -> Types -> Demandeur et partenaire -> Sélection du partenaire".

Après avoir validé la transaction de création de sondage, les autres Sentinelles du réseau voteront pour ou contre l'exécution de cette ou ces actions sur l'algorithme non déterministe en analysant les informations pré-sondage spécifiées dans la transaction de création de sondage. Pour chaque sentinelle, une fois son verdict établi, elle créera une transaction de vote l'indiquant et la diffusera au réseau pour qu'elle soit placée dans un nouveau bloc. Dans une ou plusieurs mises en œuvre, une règle de mémoire à long terme analysant si une Sentinelle donné refuse systématiquement les changements apportés à un ou plusieurs algorithmes non déterministes de la part d'une pluralité de Sentinelles fiables verra son ou ses scores impactés négativement. Dans une ou plusieurs mises en œuvre, une Sentinelle qui tente constamment d'effectuer une ou plusieurs actions sur un ou plusieurs algorithmes non déterministes qui sont refusées par le réseau verra son ou ses scores affectés négativement.

Dès qu'une Sentinelle constate que le sondage est clos (c'est-à-dire qu'un nombre suffisant de votes a été exprimé et/ou qu'un nombre déterminé de blocs a été généré depuis la validation de la transaction de création du sondage), il vérifie le résultat du sondage et, s'il est accepté, modifie en conséquence la ou les valeurs seuils dans sa base de données de mise en cache locale.

Dans plusieurs implémentations, si ledit sondage est refusé, le bloc donné déclenchant l'événement de fin dudit sondage, la Sentinelle qui a créé le sondage est punie. La nature de la punition peut prendre différentes formes. Par exemple, dans le cas où une approche collatérale est utilisée lors de la création de l'interrogation, la Sentinelle perdrait ainsi sa garantie, dans laquelle ladite perte implique soit la redistribution de la totalité (ou d'une partie de la) garantie aux entités du réseau et/ou sa réaffectation en tant que récompense de bloc. Dans une ou plusieurs mises en œuvre, la punition est proportionnelle au(x) score(s) de la Sentinelle. Dans une ou plusieurs mises en œuvre, les Sentinelles qui ont voté en défaveur du résultat du sondage sont également punies. Il est entendu que la punition peut varier considérablement. Dans une ou plusieurs mises en œuvre, un mécanisme similaire au "Système de notation -> Système de rapport des entités" serait également utilisé, permettant aux entités de signaler les sondages malveillants même après coup et de punir / récompenser les entités en conséquence. Par exemple, si le résultat d'un sondage est positif mais qu'une entité prouve par la suite que ce sondage était malveillant, par exemple en identifiant des modèles malveillants avant et/ou pendant le sondage qui n'ont pas été identifiés à l'époque en raison de la limitation des règles, les entités malveillantes pourraient subir des sanctions, comme cela est expliqué dans la section "Rôles -> Types spéciaux -> Liste noire", tandis que les entités non malveillantes qui ont été précédemment punies parce qu'elles n'étaient pas favorables au résultat du sondage seraient ainsi compensées, par exemple en voyant leur(s) score(s) augmenter et en se voyant attribuer un poids supplémentaire lors du calcul des récompenses par bloc pour un nombre déterminé de blocs.

Types spéciaux

Rôles complets, légers et stockeur

Pour une blockchain basée sur la Proof of Justice, il existe généralement trois types d'entités : Complète, Légère et Stockeur. Une entité complète est une entité où son nœud associé stocke localement l'intégralité de la blockchain (c'est-à-dire ce que les gens associent à "nœud" lorsqu'ils entendent le mot selon la technologie blockchain). Un nœud léger est une entité où son nœud associé ne stocke que les en-têtes de bloc au lieu des données complètes de la blockchain et demandera des données supplémentaires aux autres Stockeurs du réseau si nécessaire. Le nœud Stockeur est une entité dont le nœud associé est un nœud complet mais qui fournira également des données historiques de la blockchain aux nœuds Légers qui en feront la demande. Pour devenir un Stockeur (et, dans certaines mises en œuvre, un Léger), une entité donnée doit répondre à des critères spécifiques. Par exemple, disposer d'un espace de stockage suffisant pour stocker la totalité de la blockchain, avoir un score supérieur à un seuil déterminé, une connexion fiable testée à l'aide d'une règle de type défi, etc.

En rejoignant le réseau pour la première fois, une entité donnée (E1) émettra une transaction pour signaler son intention de devenir un type de nœud donné (Complet, Léger, Stockeur) en disant essentiellement "Hé, je viens de rejoindre le réseau, je veux être X". Les autres entités du réseau valideront alors si E1 peut, en fait, devenir X. E1 ne devra envoyer cette transaction à nouveau que lorsqu'il changera de X. Sinon, chaque fois que E1 effectuera une action dans le réseau, il sera considéré que E1 est X. Dans une ou plusieurs mises en œuvre, les entités qui n'émettent pas ladite transaction sont considérées comme étant de type complet, ce qui permet d'économiser du stockage et de la bande passante en n'envoyant pas de transaction.

E1 émettra, de temps en temps, une transaction Battement de coeur. Si, au bout d'un certain temps, E1 n'émet pas d'autre transaction de Battement de cœur, il sera supposé que E1 est hors ligne. Dans une ou plusieurs mises en œuvre, les entités du réseau interrogeront E1 de temps en temps afin d'établir si E1 est actif. Si E1 reste hors ligne pendant une période déterminée (qui peut être définie comme un paramètre de Proof of Justice), si E1 était un Stockeur, une base de données secondaire (décentralisée) indiquant quel nœud est en ligne et lequel ne l'est pas sera mise à jour, permettant ainsi à d'autres entités du réseau de prendre la place de E1 en tant que Stockeur (si E1 était un Stockeur) si elles remplissent les conditions requises. Dans la plupart des implémentations, un nœud complet deviendra automatiquement un nœud Stockeur s'il remplit les conditions requises, sans qu'il soit nécessaire de créer une transaction l'indiquant.

Si, à tout moment, E1 souhaite changer son statut de type de nœud (c'est-à-dire devenir un nœud complet alors qu'il était auparavant un nœud léger), il peut le faire en émettant une autre transaction avec le nouveau statut souhaité. Les autres entités du réseau valideront à nouveau si E1 peut atteindre le nouveau statut souhaité et mettront à jour leurs états locaux en conséquence.

Relation entre les entités Légères et Stockeurs

Un nœud Léger, lorsqu'il souhaite récupérer des données à partir d'une certaine hauteur de bloc H, choisit aléatoirement N nœuds Stockeurs et envoie une requête à chacun d'eux. Les nœuds Stockeurs répondront aux requêtes avec les données demandées s'ils les ont. Dans le cas contraire, ils répondront par une erreur. Le nœud Légers prend alors les M premières réponses correctes (c'est-à-dire sans erreur) et les compare entre elles. Si les M réponses correspondent, les données sont considérées comme valides et correctes. Sinon, le processus est répété jusqu'à ce que toutes les réponses correspondent ou qu'il n'y ait plus de nœuds Stockeurs à interroger.

Dans certaines implémentations, lorsqu'un nœud complet veut devenir un nœud Stockeur, il doit d'abord prouver qu'il est une source d'information fiable en répondant correctement aux requêtes Y des autres entités du réseau. Dans d'autres implémentations, cela n'est pas nécessaire.

Dans certaines autres mises en œuvre, les Stockeurs se synchroniseront entre eux et signeront les données de la blockchain de manière périodique afin de normaliser les données à fournir éventuellement aux nœuds Légers. Cela permettrait de n'envoyer qu'une seule requête à un nœud Stockeur aléatoire au lieu de plusieurs, puisque les données renvoyées par le nœud Stockeur seraient cosignées, et donc pré-approuvées, par une pluralité de Stockeurs.

Entités légères ou complètes ou stockeur : Différences entre les récompenses en bloc

Les récompenses en bloc qu'une entité donnée reçoit sont proportionnelles au type d'entité qu'elle est. Les entités Complètes recevront toujours plus de récompenses que les entités Légères pour la plupart, sinon la totalité, des actions effectuées dans le réseau pour la plupart, sinon la totalité, des rôles. Par exemple, lorsqu'une entité complète génère un nouveau bloc, agit en tant qu'agent d'exécution ou autre, elle reçoit 90% de la ou des récompenses qui lui sont attribuées. La ou les récompenses restantes pour les entités complètes sont alors distribuées de manière égale entre les entités Stockeur. Par conséquent, lorsqu'un nœud léger génère un nouveau bloc, joue le rôle d'agent d'exécution ou autre, il ne reçoit que 80% de la ou des récompenses qui lui sont attribuées. La ou les récompenses restantes (20%) sont alors distribuées de manière égale entre les entités complètes et/ou les entités Stockeur. Par conséquent, lorsqu'un nœud Stockeur génère un nouveau bloc, agit en tant qu'agent d'exécution et/ou autre, il reçoit 100% de la ou des récompenses qui lui ont été attribuées.

Le raisonnement est que les entités devraient être incitées à prendre plus de responsabilités et à agir de la manière la plus juste possible afin de gagner plus.

Liste noire

Une entité est mise sur liste noire lorsque son ou ses scores tombent en dessous d'un certain seuil. Cela se produit généralement lorsque l'entité présente un comportement suspect. Lorsqu'une entité est inscrite sur une liste noire, il lui est interdit d'effectuer certaines actions liées à la blockchain, telles que générer des blocs, agir en tant qu'Exécuteur, agir en tant que Demandeur, et/ou autres.

Les entités figurant sur la liste noire peuvent faire l'objet d'un slash, qui est une forme de pénalisation. Une sanction peut prendre diverses formes et peut être différente en fonction du critère, de l'événement lié à la blockchain ou de la fonctionnalité liée à la blockchain considérés. Par exemple, un slash peut impliquer l'interdiction ou la limitation de l'utilisation par une entité d'un système lié à un prêt s'il en existe un, l'augmentation des frais d'intérêt liés à un prêt d'un montant déterminé, ou toute autre conséquence pertinente. Dans une ou plusieurs mises en œuvre, un slash peut prendre la forme d'une limitation au lieu d'une interdiction. Par exemple, la quantité de transactions qu'une entité figurant sur la liste noire est autorisée à effectuer pour un nombre donné de blocs. Dans une ou plusieurs mises en œuvre, un slash peut prendre la forme d'un "brûleur", où une partie des actifs d'une entité donnée est réaffectée aux récompenses de bloc et/ou distribuée aux autres entités du réseau.

Dans une ou plusieurs mises en œuvre, il est strictement interdit aux entités figurant sur la liste noire d'effectuer toute action liée à la blockchain jusqu'à ce que leur score repasse au-dessus du seuil. Dans une ou plusieurs mises en œuvre, les entités figurant sur la liste noire sont incapables d'interagir avec et/ou de retirer tout ou partie de leurs actifs jusqu'à ce que leur score repasse au-dessus du seuil. La forme que prend un slash peut varier considérablement en fonction de la mise en œuvre.

Une entité peut également être mise sur liste noire sur une base par rôle/par action. Par exemple, dans une ou plusieurs mises en œuvre, une entité donnée peut être mise sur liste noire spécifiquement pour le rôle d'Exécuteur, influençant ainsi son niveau d'Exécuteur, si un mécanisme de niveau et d'XP est utilisé.

D'autres facteurs peuvent également affecter un slash donné. Par exemple, le nombre de slashs précédent reçus par une entité, le score associé à l'entité, le nombre d'occasions où l'entité a été considérée comme étant sur liste noire, et/ou un vote impliquant au moins une entité faisant partie de la blockchain peuvent tous affecter un slash donné.

Preuve des mécanismes de justice

Paramètres (dynamiques)

Un paramètre est une valeur qui fait partie de la blockchain et qui peut être immuable ou non. Un paramètre peut être mis à jour en fonction de certains critères, événements ou règles. Par exemple, un paramètre peut être mis à jour en fonction d'un processus de vote impliquant une ou plusieurs entités du réseau.

Un paramètre peut être mis à jour sur la base d'un processus de vote impliquant une ou plusieurs entités du réseau. Par exemple, s'il existe une règle qui stipule qu'un paramètre ne peut être mis à jour que si 2/3 des entités du réseau sont d'accord avec la mise à jour, alors le processus de vote implique toutes les entités du réseau. Pour que la mise à jour ait lieu, les 2/3 ou plus des entités doivent voter en faveur de la mise à jour. Le processus de vote peut être initié par toute entité du réseau ayant l'autorité de le faire. Dans une ou plusieurs mises en œuvre, seules les entités ayant le(s) score(s) le(s) plus élevé(s) peuvent voter pour la mise à jour d'un paramètre. Dans une ou plusieurs mises en œuvre, les entités qui souhaitent voter doivent compléter un défi afin de confirmer leur fiabilité. Dans une ou plusieurs mises en œuvre, le degré de la ou des modifications proposées pour un paramètre donné a un impact sur le nombre/les notes des entités requises pour que la modification prenne effet. Si le changement est trop important, certaines implémentations peuvent choisir de permettre uniquement au(x) gestionnaire(s) du système d'autoriser ou de refuser le changement.

Noeud dédié

Un nœud dédié est un dispositif physique qui est utilisé pour générer des blocs et effectuer d'autres actions pour le compte d'une entité du réseau. Un nœud dédié peut être capable de remplir tous les rôles ou une pluralité de rôles, ou seulement des rôles spécifiques. Par exemple, un nœud dédié peut être capable de générer et de faire respecter les blocs, tandis qu'un autre dispositif externe peut être capable de générer et de faire respecter les blocs ainsi que d'agir comme un Stockeur, ayant un disque dur dédié. Dans une ou plusieurs mises en œuvre, il s'agirait également d'une exigence du réseau au lieu d'un élément facultatif. Le dispositif externe est utile car si le téléphone (pour les nœuds Légers) ou l'ordinateur de l'utilisateur est hors ligne, le nœud dédié, s'il reste au domicile de l'utilisateur, par exemple, peut toujours être actif et participer au réseau. Ainsi, un nœud dédié, disposant d'une puissance de traitement dédiée et d'un accès constant à Internet, serait certainement attrayant et pertinent pour les utilisateurs qui voyagent souvent.

Dans une ou plusieurs mises en œuvre, chaque entité du système de Proof of Justice doit utiliser un nœud dédié. Le but est de s'assurer que chaque entité du système apporte sa puissance de traitement et sa connexion Internet au système, et ne se contente pas de dépendre des autres entités. Cela permettrait d'obtenir une distribution plus égalitaire des ressources dans le système et de s'assurer que chaque entité apporte sa juste part.

Dans une ou plusieurs mises en œuvre, une entité peut utiliser plusieurs nœuds dédiés. Par exemple, une entité peut avoir un nœud dédié pour la génération de blocs et un second nœud dédié pour une ou plusieurs autres actions de rôle. Dans une ou plusieurs mises en œuvre, une entité peut utiliser le même nœud dédié à toutes fins.

Une fois que le nœud principal, c'est-à-dire le téléphone ou l'ordinateur, est hors ligne, il ne peut pas recevoir de nouveaux blocs ou transactions et ne peut donc pas valider de données. Lorsque cela se produit, dans une ou plusieurs mises en œuvre, un nœud dédié fonctionne pendant que le nœud principal est hors ligne, et une fois que le nœud principal revient en ligne, le nœud principal se synchronise avec le nœud dédié.

Dans une ou plusieurs mises en œuvre, les entités doivent avoir un ou plusieurs scores supérieurs à un ou plusieurs seuils spécifiques pour pouvoir utiliser un ou plusieurs types de nœuds dédiés.

L'utilisation d'un nœud dédié peut contribuer à améliorer la sécurité et les performances du système dans son ensemble, ainsi qu'à offrir une expérience plus fiable aux utilisateurs. En veillant à ce que toutes les entités du système contribuent à l'apport de leurs ressources, il peut contribuer à uniformiser les règles du jeu et à garantir une participation équitable des utilisateurs. En outre, le fait de disposer d'un dispositif physique toujours en ligne et connecté au réseau peut offrir une expérience plus fiable aux utilisateurs, car ils n'auront pas à craindre que leur nœud soit hors ligne et qu'ils manquent des récompenses potentielles.

Les nœuds dédiés permettent au(x) créateur(s) du système basé sur la Proof of Justice de disposer d'une source de revenus supplémentaire et intéressante. Étant donné qu'un nœud de système de Proof of Justice ne nécessite pas une puissance de calcul importante pour fonctionner, les nœuds dédiés peuvent être fabriqués à un coût minimal, ce qui permet une plus grande accessibilité aux utilisateurs et des marges bénéficiaires potentiellement élevées.

Sous-réseaux spécialisés

Dans une ou plusieurs mises en œuvre, le réseau comprend également plusieurs sous-réseaux, chaque sous-réseau étant associé à un rôle donné (et/ou, dans une ou plusieurs mises en œuvre, à un ou plusieurs scores associés à des entités). Par exemple, il pourrait y avoir un sous-réseau pour tous les Générateurs et un autre sous-réseau pour tous les Exécuteurs, ce qui rendrait beaucoup plus efficace la recherche d'un Générateur / d'un Exécuteur. Cela contribuerait à améliorer la vitesse de propagation des données dans le réseau, ainsi qu'à réduire la quantité de données devant être traitées par chaque nœud.

Preuve de la justice - Avantages

Un premier avantage de Proof of Justice est qu'il permet de traiter efficacement une transaction sans avoir besoin de s'appuyer de manière significative sur des ressources d'investissement comme PoS, PoW, et PoSpace. Au lieu de cela, Proof of Justice utilise un principe d'égalité probabiliste dans lequel les entités ont une chance égale de générer le bloc suivant, à condition que lesdites entités respectent et adhèrent à un ensemble de règles déterminées.

Un deuxième avantage de la Proof of Justice est qu'elle permet de détecter des événements potentiellement indésirables et/ou de contrer des événements potentiellement indésirables en déterminant un modèle potentiellement suspect et ainsi de créer une règle pour punir une entité liée au modèle potentiellement suspect. Par exemple, une attaque Sybil, qui consiste à attaquer une blockchain en créant un grand nombre d'entités pour prendre le pouvoir décisionnel d'une blockchain, peut être contrée en utilisant une ou plusieurs règles établissant qu'une entité donnée doit avoir un certain score pour agir en tant qu'Exécuteur, Générateur et/ou tout autre rôle pertinent. Ainsi, même si une entité effectue une attaque Sybil sans permettre la détection de l'événement potentiellement indésirable lié à la blockchain et/ou la neutralisation du modèle potentiellement suspect, le modèle suspect pourrait toujours être déterminable et pénalisable. Il sera entendu que les modèles potentiellement suspects peuvent être fournis sous diverses formes. Pour une ou plusieurs implémentations d'une blockchain utilisant PoJ, ladite blockchain pourrait détecter un modèle potentiellement suspect sélectionné dans un groupe comprenant une rotation et/ou une alternance d'entités pour un Exécuteur, un Générateur, et/ou tout autre rôle pertinent, ignorant et/ou priorisant les transactions d'une entité similaire lors de la génération d'un bloc, la sélection d'un contrôleur et/ou d'un partenaire qui a été déterminé dans le même laps de temps qu'un Générateur, et/ou d'un demandeur et/ou de tout autre rôle pertinent, la détermination d'une transaction d'une entité déterminée dans le même laps de temps qu'un Générateur lors de la génération d'un bloc, la détermination d'une transaction d'une entité déterminée dans le même laps de temps que la majorité des autres entités lors de la génération d'un bloc et/ou similaire. Par conséquent, le score associé à une entité effectuant les activités susmentionnées pourrait subir un impact négatif lorsqu'il est détecté, et l'entité pourrait être pénalisée et/ou figurer sur une liste noire.

Un troisième avantage de la Proof of Justice est que, puisqu'elle permet d'évaluer les entités et de détecter et/ou de contrer les schémas potentiellement suspects, les attaques telles qu'une attaque 51%, c'est-à-dire lorsqu'une majorité d'entités tente de prendre un pouvoir décisionnel dans le réseau pour effectuer des actions malveillantes telles que la mise à jour malveillante d'un bloc et/ou la génération d'un bloc malveillant dans une blockchain et/ou la génération et/ou le traitement d'une transaction malveillante dans une blockchain, peuvent être détectables et il est possible de les combattre en mettant en œuvre des stratégies telles que :

Règle visant à empêcher une entité donnée d'agir en tant qu'agent d'exécution, générateur et/ou tout autre rôle pertinent en réduisant son score lorsqu'elle exécute un modèle reconnaissable et potentiellement suspect, réduisant ainsi le score lié à ladite entité donnée en dessous d'une région déterminée dans une distribution de score, telle qu'une région d'agent d'exécution ou une région de liste noire ;
Stratégie visant à permettre le partitionnement, où un Générateur et/ou Demandeur et/ou tout autre rôle pertinent donné n'est autorisé à interagir avec un Exécuteur et/ou un Partenaire et/ou tout autre rôle pertinent respectif que si ledit Exécuteur et/ou Partenaire et/ou tout autre rôle pertinent respectif est compris dans un partitionnement différent dudit Générateur et/ou Demandeur et/ou tout autre rôle pertinent donné, le Générateur et/ou Demandeur et/ou tout autre rôle pertinent donné étant associé audit partitionnement sur la base d'un événement donné lié à la blockchain, l'événement donné lié à la blockchain étant déclenché lorsqu'une condition donnée est remplie, telle qu'un nombre déterminé de blocs, une quantité déterminée de temps écoulé, et/ou similaire ;
Stratégie visant à limiter une entité donnée à produire de manière répétée des transactions d'un type donné vers un portefeuille donné et/ou une autre entité donnée sur une période de temps déterminée, limitant ainsi ladite entité à interagir de manière répétée avec une ou plusieurs entités spécifiques et/ou à produire des transactions d'un type donné vers un ou plusieurs portefeuilles spécifiques. Pour une mise en œuvre donnée de Proof of Justice, la stratégie peut en outre consister à exiger qu'un montant d'un ou plusieurs actifs compris dans un portefeuille associé à ladite entité donnée soit compris dans une plage déterminée pour pouvoir agir en tant qu'Exécuteur, Générateur et/ou tout autre rôle pertinent, limitant ainsi une création massive d'entités malveillantes. Pour une mise en œuvre donnée de la Proof of Justice, la stratégie peut également comprendre la limitation de ladite entité à interagir avec d'autres entités associées à des portefeuilles comprenant un nombre d'actifs inférieur à un seuil minimum, ledit seuil minimum étant soit statique, soit déterminé sur la base d'une pluralité de portefeuilles ; et/ou
Stratégie visant à mettre à jour, après un nombre déterminé de blocs, le score associé à une entité donnée si ledit score est au-dessus d'une limite supérieure dans une distribution de scores par rapport à un score moyen, ledit score moyen étant basé sur une pluralité d'entités, limitant ainsi ladite entité donnée à interagir de manière répétée avec un Exécuteur, un Générateur spécifique et/ou tout autre rôle pertinent. Pour une mise en oeuvre donnée de la Proof of Justice, la stratégie peut comprendre la demande temporaire à ladite entité donnée d'agir en tant qu'Exécuteur, Générateur, et/ou tout autre rôle pertinent en relation avec un événement lié à la fiabilité, tel que ladite mise à jour de score l'indique après le nombre déterminé de blocs, jusqu'à ce qu'une ou plusieurs entités puissent agir en tant qu'Exécuteur, Générateur et/ou tout autre rôle pertinent.

On comprendra que parce que les Exécuteurs sont, par défaut, choisis dans une fourchette de score spécifique variant en fonction du nombre de Générateurs, et parce que les schémas suspects sont détectables et punissables, les attaques 51% sont possibles mais extrêmement difficiles à exécuter et les entités malveillantes seraient pénalisées par les règles déterminées rapidement. De même que PoW, PoS et PoSpace, Proof of Justice n'est pas infaillible contre les attaques 51%, et ces dernières peuvent réussir à traiter des transactions frauduleuses.

Retour : Page d'accueil

Suivant : DataLok