VT2020-BFT-Fiche - Revision history

Alexandre.Salmon: /* Sources */

2021-01-10T20:26:25Z

Sources

← Older revision		Revision as of 20:26, 10 January 2021
Line 77:		Line 77:
	==Sources==		==Sources==
	<references />		<references />
	* [https://dl.acm.org/doi/10.1145/357172.357176, The Byzantine Generals Problem, Leslie Lamport, Robert Shostak, ~~Marshall~~ Pease]		* [https://dl.acm.org/doi/10.1145/357172.357176, The Byzantine Generals Problem, Leslie Lamport, Robert Shostak, Marshall Pease]
	* [https://dl.acm.org/doi/10.1145/1067629.806523, Some constraints and tradeoffs in the design of network communications, E. A. Akkoyunlu, K. Ekanadham, R. V. Huber]		* [https://dl.acm.org/doi/10.1145/1067629.806523, Some constraints and tradeoffs in the design of network communications, E. A. Akkoyunlu, K. Ekanadham, R. V. Huber]
	* [http://pmg.csail.mit.edu/papers/osdi99.pdf, Practical Byzantine Fault Tolerance, Miguel Castro and Barbara Liskov]		* [http://pmg.csail.mit.edu/papers/osdi99.pdf, Practical Byzantine Fault Tolerance, Miguel Castro and Barbara Liskov]
	* [http://www.di.fc.ul.pt/~bessani/publications/dsn14-bftsmart.pdf, State Machine Replication for the Masses with BFT-SMART, Alysson Bessani, João Sousa Eduardo, E.P. Alchieri]		* [http://www.di.fc.ul.pt/~bessani/publications/dsn14-bftsmart.pdf, State Machine Replication for the Masses with BFT-SMART, Alysson Bessani, João Sousa Eduardo, E.P. Alchieri]
			* [http://www.ee.surrey.ac.uk/, Illustration du problème des deux généraux]
			* [https://bitcoin.fr/le-probleme-des-generaux-byzantins/, Illustration du problème des généraux byzantins]
			* [https://viresinnumeris.fr/probleme-generaux-byzantins/, Illustration du problème des généraux byzantins: Défaite, Victoire]
			* [https://cia.news/comprendre-la-technologie-blockchain/, Illustration BlockChain]
			* [https://www.youtube.com/watch?v=bBC-nXj3Ng4&ab_channel=3Blue1Brown, Vous êtes-vous déjà demandé comment les Bitcoins (et autres crypto-monnaies) marchaient en réalité ?, 3Blue1Brown]

	== VT2020 ==		== VT2020 ==

Alexandre.Salmon: /* Sources */

2021-01-10T20:21:20Z

Sources

← Older revision		Revision as of 20:21, 10 January 2021
Line 76:		Line 76:

	==Sources==		==Sources==
			<references />
			* [https://dl.acm.org/doi/10.1145/357172.357176, The Byzantine Generals Problem, Leslie Lamport, Robert Shostak, Marshall Pease]
			* [https://dl.acm.org/doi/10.1145/1067629.806523, Some constraints and tradeoffs in the design of network communications, E. A. Akkoyunlu, K. Ekanadham, R. V. Huber]
			* [http://pmg.csail.mit.edu/papers/osdi99.pdf, Practical Byzantine Fault Tolerance, Miguel Castro and Barbara Liskov]
			* [http://www.di.fc.ul.pt/~bessani/publications/dsn14-bftsmart.pdf, State Machine Replication for the Masses with BFT-SMART, Alysson Bessani, João Sousa Eduardo, E.P. Alchieri]

	== VT2020 ==		== VT2020 ==

Alexandre.Salmon: /* BFT-SMART */

2021-01-10T20:12:43Z

BFT-SMART

← Older revision		Revision as of 20:12, 10 January 2021
Line 63:		Line 63:
	BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.		BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.

	[[File:bft_smart_comparison.png \| thumb ~~\| left~~ \| comparaison entre BFT-SMaRt, PBFT et UpRight]]		[[File:bft_smart_comparison.png \|400px\| thumb \| comparaison entre BFT-SMaRt, PBFT et UpRight]]

	BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.		BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.

Alexandre.Salmon: /* BFT-SMART */

2021-01-10T20:11:47Z

BFT-SMART

← Older revision		Revision as of 20:11, 10 January 2021
Line 63:		Line 63:
	BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.		BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.

	[[File:bft_smart_comparison.png]]		[[File:bft_smart_comparison.png \| thumb \| left \| comparaison entre BFT-SMaRt, PBFT et UpRight]]

	BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.		BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.

Alexandre.Salmon: /* BFT-SMART */

2021-01-10T20:10:56Z

BFT-SMART

← Older revision		Revision as of 20:10, 10 January 2021
Line 63:		Line 63:
	BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.		BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.

	[[File:bft_smart_comparison.~~jpg~~]]		[[File:bft_smart_comparison.png]]

	BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.		BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.

Alexandre.Salmon: /* BFT-SMART */

2021-01-10T20:10:15Z

BFT-SMART

← Older revision		Revision as of 20:10, 10 January 2021
Line 62:		Line 62:

	BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.		BFT-SMaRt est une librairie Java open source. Elle facilite la réplication de données dans un réseau et propose une alternative robuste, multicore et modulaire à PBFT et UpRight.

			[[File:bft_smart_comparison.jpg]]

			BFT-SMaRt arrive en effet à afficher des performances supérieures à PBFT et significativement supérieures à UpRight. La valeur "Throughput" étant la vitesse de point en octet/sec, "Clients" le nombre de client utilisés pour atteindre cette valeur et "Throughput 200" le débit avec 200 clients.

	===Proof of Work===		===Proof of Work===

Alexandre.Salmon: /* Impossibilité */

2021-01-10T19:58:29Z

Impossibilité

← Older revision		Revision as of 19:58, 10 January 2021
Line 14:		Line 14:
	Si on considère un protocole inspiré de TCP et notamment des messages échangés lors de l'ouverture d'un connexion (SYN, SYN-ACK, ACK), on obtient un protocole qui se déroule comme suit:		Si on considère un protocole inspiré de TCP et notamment des messages échangés lors de l'ouverture d'un connexion (SYN, SYN-ACK, ACK), on obtient un protocole qui se déroule comme suit:

			* A -> B: On Attaque, en attente d'acquittement
			* B -> A: Acquittement, On Attaque, en attente d'acquittement
			* A -> B: Acquitement

	Si lors du premier message A n'attends pas acquittement, il sera seul face à l'ennemi si son message est perdu. On trouve la situation inverse si A attends un acquittement mais pas B, si le deuxième message se perd, A continuera d'attendre pendent que B perd la bataille. En fait on peu continuer d'ajouter des message à ce dialogue pour acquitter les acquittements, l'engagement d'une armée ou de l'autre à rentrer dans la bataille repose toujours sur le dernier message de la conversation, et ce dernier peut toujours être perdu. Il n'y a pas de solution déterministe à ce problème.		Si lors du premier message A n'attends pas acquittement, il sera seul face à l'ennemi si son message est perdu. On trouve la situation inverse si A attends un acquittement mais pas B, si le deuxième message se perd, A continuera d'attendre pendent que B perd la bataille. En fait on peu continuer d'ajouter des message à ce dialogue pour acquitter les acquittements, l'engagement d'une armée ou de l'autre à rentrer dans la bataille repose toujours sur le dernier message de la conversation, et ce dernier peut toujours être perdu. Il n'y a pas de solution déterministe à ce problème.

Alexandre.Salmon at 19:57, 10 January 2021

2021-01-10T19:57:03Z

← Older revision		Revision as of 19:57, 10 January 2021
Line 67:		Line 67:

	Chaque utilisateur sur le réseau est à l'écoute de nouveau bloc créé par les mineurs pour pouvoir l'ajouter à sa propre copie de la blockchain. Dans le cas d'une tentative de fraude, un utilisateur donnée captera deux blocs contradictoires pour savoir lequel des deux blocs est frauduleux, il lui suffit d'attendre que plus de blocs soient "minés". Si une majorité des acteurs du réseau sont loyaux, des blocs s'ajouteront plus rapidement au bloc valide qu'au bloc contrefait, il suffira donc à l'utilisateur de considérer la chaîne la plus longue comme étant la chaîne valide. Pour que le faussaire puisse intégrer durablement un bloc contrefait à la blockchain, il faut qu'il soit capable de miner les blocs au moins aussi vite que tout les autres mineurs réunis.		Chaque utilisateur sur le réseau est à l'écoute de nouveau bloc créé par les mineurs pour pouvoir l'ajouter à sa propre copie de la blockchain. Dans le cas d'une tentative de fraude, un utilisateur donnée captera deux blocs contradictoires pour savoir lequel des deux blocs est frauduleux, il lui suffit d'attendre que plus de blocs soient "minés". Si une majorité des acteurs du réseau sont loyaux, des blocs s'ajouteront plus rapidement au bloc valide qu'au bloc contrefait, il suffira donc à l'utilisateur de considérer la chaîne la plus longue comme étant la chaîne valide. Pour que le faussaire puisse intégrer durablement un bloc contrefait à la blockchain, il faut qu'il soit capable de miner les blocs au moins aussi vite que tout les autres mineurs réunis.

			==Sources==

	== VT2020 ==		== VT2020 ==

Alexandre.Salmon: /* Proof of Work */

2021-01-10T19:56:24Z

Proof of Work

← Older revision		Revision as of 19:56, 10 January 2021
Line 64:		Line 64:
	La BlockChain du bitCoin fonctionne de la manière suivante, chaque bloc contient une liste de transactions et le hash du bloc précédent. De ce fait on ne peut pas falsifier un bloc sans devoir falsifier les suivant. Pour rendre difficile la création et la modification d'un bloc, le bloc contient aussi une preuve de travail, il s'agit d'une valeur que le "mineur" doit trouver pour que le hash du bloc commence par un nombre donné de zéros (par exemple 30). Cette pratique rends très difficile la production de bloc (il faut en moyenne 10 minutes pour qu'un bloc soit ajouté à la blockchain). Il est cependant très facile de vérifier que la preuve de travail est bonne et ainsi valider le bloc.		La BlockChain du bitCoin fonctionne de la manière suivante, chaque bloc contient une liste de transactions et le hash du bloc précédent. De ce fait on ne peut pas falsifier un bloc sans devoir falsifier les suivant. Pour rendre difficile la création et la modification d'un bloc, le bloc contient aussi une preuve de travail, il s'agit d'une valeur que le "mineur" doit trouver pour que le hash du bloc commence par un nombre donné de zéros (par exemple 30). Cette pratique rends très difficile la production de bloc (il faut en moyenne 10 minutes pour qu'un bloc soit ajouté à la blockchain). Il est cependant très facile de vérifier que la preuve de travail est bonne et ainsi valider le bloc.

	[[File:~~blockChain~~.~~png~~\|500px\|right\|thumb\|Représentation de la blockchain bitcoin]]		[[File:BlockChain.jpg\|500px\|right\|thumb\|Représentation de la blockchain bitcoin]]

	Chaque utilisateur sur le réseau est à l'écoute de nouveau bloc créé par les mineurs pour pouvoir l'ajouter à sa propre copie de la blockchain. Dans le cas d'une tentative de fraude, un utilisateur donnée captera deux blocs contradictoires pour savoir lequel des deux blocs est frauduleux, il lui suffit d'attendre que plus de blocs soient "minés". Si une majorité des acteurs du réseau sont loyaux, des blocs s'ajouteront plus rapidement au bloc valide qu'au bloc contrefait, il suffira donc à l'utilisateur de considérer la chaîne la plus longue comme étant la chaîne valide. Pour que le faussaire puisse intégrer durablement un bloc contrefait à la blockchain, il faut qu'il soit capable de miner les blocs au moins aussi vite que tout les autres mineurs réunis.		Chaque utilisateur sur le réseau est à l'écoute de nouveau bloc créé par les mineurs pour pouvoir l'ajouter à sa propre copie de la blockchain. Dans le cas d'une tentative de fraude, un utilisateur donnée captera deux blocs contradictoires pour savoir lequel des deux blocs est frauduleux, il lui suffit d'attendre que plus de blocs soient "minés". Si une majorité des acteurs du réseau sont loyaux, des blocs s'ajouteront plus rapidement au bloc valide qu'au bloc contrefait, il suffira donc à l'utilisateur de considérer la chaîne la plus longue comme étant la chaîne valide. Pour que le faussaire puisse intégrer durablement un bloc contrefait à la blockchain, il faut qu'il soit capable de miner les blocs au moins aussi vite que tout les autres mineurs réunis.

Alexandre.Salmon: /* Practical Byzantine Fault Tolerance */

2021-01-10T19:53:56Z

Practical Byzantine Fault Tolerance

← Older revision		Revision as of 19:53, 10 January 2021
Line 42:		Line 42:
	===Practical Byzantine Fault Tolerance===		===Practical Byzantine Fault Tolerance===

	[[File:~~pbft~~.png\|500px\|right\|thumb\|Schéma des message lors de l’exécution de PBFT]]		[[File:Pbft.png\|500px\|right\|thumb\|Schéma des message lors de l’exécution de PBFT]]

	'''f''': nombre maximal de fautes tolérées		'''f''': nombre maximal de fautes tolérées