BitShares French ConneXion  

Performances industrielles et flexibilité


Plus de 100 000 transactions par seconde

De manière à procurer une alternative viable aux plateformes financières existantes, les cryptomonnaies se doivent d’utiliser une technologie Blockchain de haute performance ainsi qu’une plateforme efficace de contrats intelligents. BitShares a été conçu depuis le début pour gérer plus de transactions à la seconde que VISA et MasterCard. Grâce à la Delegated Proof of Stake, le réseau BitShares peut confirmer chaque transaction en 1 seconde en moyenne et n’est limité que par la vitesse de la lumière.


Généralités

Pour atteindre cette performance digne des leaders de l'industrie, BitShares a profité des leçons tirées de la Bourse LMAX, qui est capable de traiter 6 millions de transactions par seconde. Parmi ces leçons nous pouvons en sortir les points clés suivants:

1. Gardez tout en mémoire.
2. Gardez la logique de l’entreprise de base en tant que fil conducteur.
3. Gardez les opérations cryptographiques (hashes et signatures) en dehors de la logique de l’entreprise.
4. Diviser la validation en chèques d’Etat dépendant et indépendant.
5. Utiliser un modèle de données orienté sur l’objet.

En suivant ces règles simples, BitShares est capable de traiter 100 000 transactions par seconde sans avoir fait aucun effort important d’optimisation. Les évolutions futures consacrées à l’optimisation pourront amener BitShares à avoir des performances similaires à LMAX.

Il faut souligner que la performance de BitShares est fortement dépendante d’avoir un protocole de transaction compatible. Il serait impossible d'atteindre un tel niveau de performance dans le cas où le protocole du « Core Business Logic » serait exécuté dans une machine virtuelle qui exécute des opérations cryptographiques et référence tous les objets avec des identificateurs de hachage. Les blockchains sont intrinsèquement mono-sens, et la performance d'un seul noyau de CPU est la ressource la plus limitée et la moins flexible de toutes. BitShares est conçu pour tirer le meilleur parti de ce seul fil d'exécution.


Background

Un blockchain est un registre global qui ordonne des transactions et où chacune de ces dernières modifie de façon déterminante un état global partagé à tous à un instant T. L'ordre dans lequel ces transactions sont traitées peut changer la validité des autres transactions. Par exemple, vous ne pouvez pas retirer de l'argent de votre compte bancaire avant que le dépôt de votre chèque de paie a été validé et crédité sur votre compte. Il devient impossible de savoir si oui ou non une transaction est valide jusqu'à ce que toutes les opérations antérieures qui influent sur ce même compte ont été traitées.

En théorie, les transactions pour deux comptes indépendants peuvent être traitées en même temps, à condition qu'ils ne soient pas tributaires l’un de l’autre. Dans la pratique, le coût d’identifier quelles transactions sont véritablement indépendantes l’une vis à vis de l'autre sur un registre habilité par des contrats intelligents, tout ceci dans des conditions arbitraires est inextricable. La seule façon d'être sûr que deux transactions sont véritablement indépendantes l’une de l’autre est de maintenir des registres complètement séparés, puis périodiquement transférer une valeur entre eux. Une analogie pourrait être faite dans ce cas de figure lorsque nous comparons la « Non Uniform Memory Access » (NUMA) contre « Uniform Memory Access ».

Dans la pratique, la « Uniform Access Memory » est beaucoup plus facile à créer pour les développeurs, et à des coûts inférieurs. Les architectures NUMA, quant à elles, sont généralement adoptées en dernier ressort lors de la construction de supercalculateurs ou des « clusters » géants.

L'industrie informatique s’est développée en réalisant que mesurer l’échelle des performances à travers le parallélisme est loin d'être aussi facile qu’aux premiers jours où il suffisait simplement d'augmenter la vitesse d'horloge du CPU. C’est pour cette raison que les concepteurs de CPU ont poussé les performances mono-filaires à leurs extrêmes limites avant de tenter d'adopter une nouvelle approche multi-filaire cette fois de manière à augmenter les performances. Lorsque le multi-filaire n’est pas suffisant, alors, et alors seulement, le calcul informatique en « cluster » est considéré comme une option.

Beaucoup de personnes dans l'industrie de la crypto-monnaie ont tenté de résoudre le problème d’évolutivité en utilisant une solution en « cluster » sans prendre la peine d’explorer avant ce qui est technologiquement possible sur le seul core d'un ordinateur.


LMAX disruptor

Le LMAX Disruptor fournit, en quelque sorte, une étude de cas sur une architecture qui possède un haut degré d'évolutivité et de performances. Ceci démontre ce qui est réalisable dans un thread d'exécution unique. LMAX est une plate-forme du commerce de détail qui vise à être l'échange le plus rapide du monde. Ils ont été assez généreux pour partager publiquement leur apprentissage.

Voici un bref aperçu de leur architecture:

Le Business Logic Processor est l'endroit où toutes les opérations séquentielles et l'appariement des ordres est traitée. Il est un fil unique qui est capable de traiter des millions d'ordres par seconde. Cette architecture est facilement adaptable dans le domaine des crypto monnaies et leurs blockchains.

Le rôle du « Input Disruptor » est de recueillir des commandes utilisateurs provenant de différentes sources et de les affecter à un ordre déterminé. Après leur avoir assigné un ordre, ils sont répliqués, connectés, et diffusés à de nombreux Business Logic Processor qui vont répéter l’opération. Les tâches du « Input Disruptor » s’effectuent en parallèle et peuvent facilement être affecté à un cluster d'ordinateurs.

Une fois que le Business Logic Processor a traité les entrées, une Output Disruptor prend soin d’avertir toute personne qui souhaite prendre note des résultats. Ceci est également une tâche qui s’effectue en parallèle.

Finalement, LMAX était en mesure de traiter 6 millions de transactions par seconde à travers le Business Logic Processor, tout ceci en utilisant un seul core de CPU de base utilisant une machine virtuelle Java. Si LMAX peut atteindre 6 millions de transactions par seconde, alors il est certain que la crypto-monnaie et ses plates-formes de contrats intelligents n’ont pas besoin des solutions en cluster alors qu’ils ne traitent même pas 10 transactions par seconde.


Blockchain Hautes Performances

Pour mettre en œuvre une blockchain de haute performance, BitShares se doit d’adopter les mêmes techniques utilisées par LMAX. Plusieurs points-clés fondamentaux doivent être respectés:

# Gardez tout en mémoire.
# Évitez les primitives de synchronisation (écluses, opérations atomiques).
# Réduire calcul inutile dans le Business Logic Processor.

La mémoire devient moins cher de jour en jour car elle est extrêmement parallèle dans sa conception. La quantité d'informations qui est nécessaire pour suivre le solde du compte et les autorisations de chaque personne sur l'Internet est moins de 1 téraoctet de RAM. Ceci peut être acheté pour moins de $ 15,000 et installé sur les cartes mères d’un serveur (haut de gamme). Bien avant que 3 milliards de personnes adoptent le système, ce type de matériel sera dans le bureau d’un tout un chacun.

Le véritable problème n’est pas les exigences de mémoire, mais les besoins en bande passante. A 1 million de transactions par seconde et 256 octets par transaction, le réseau nécessiterait 256 mégaoctets par seconde (1 Gbit / s). Ce genre de bande passante n’est pas disponible sur un ordinateur moyen, cependant ce niveau de bande passante est une fraction des 100 Gbit / s que l'Internet 2 fournit à plus de 210 institutions américaines d'enseignement, 70 sociétés et 45 organismes à but non-lucratif.

Par conséquent, la technologie blockchain peut facilement garder tout dans sa RAM et s’organiser pour traiter des millions de transactions par seconde si elle est bien conçue.


Evitez les hashes, identités assignées à la place

Dans un système mono-thread, les cycles CPU sont des ressources rares qui doivent être conservées. Les designs traditionnels de blockchain utilisent des hashs cryptographiques pour générer des identifiants uniques au monde. Ces derniers sont statistiquement garantis de ne jamais produire un identifiant semblable. Le problème avec ces hashes est qu'ils exigent beaucoup plus de mémoire et plus de cycles CPU pour les manipuler. Il faut beaucoup plus de temps CPU pour rechercher un enregistrement de compte par hachage qu'avec un index de tableau direct. Par exemple, les entiers 64 bits sont plus faciles à comparer et manipuler que les identifiants 160+bits. Avoir des identifiants de hachage plus grands signifie qu'il y a moins de place dans la mémoire cache du processeur et que par conséquent plus de mémoire est nécessaire. Sur les systèmes d'exploitation modernes, la RAM rarement utilisée est compressée, mais les identifiants de hachage sont des données aléatoires qui ne sont pas compressibles.

Heureusement, les blockchains nous donnent un moyen à l'échelle mondiale d’attribuer des identifiants uniques qui ne sont pas en conflit avec d’autres. Il est donc possible de supprimer complètement la nécessité d'utiliser des identificateurs par hachage (Bitcoin adresses) pour se référer à un compte, un solde, ou une permission.


Enlevez la vérification par signature pour les Business Logic Processor

Toutes les transactions sur les réseaux de crypto-monnaies dépendent de signatures cryptographiques pour valider les autorisations . Dans le cas général , les autorisations requises peuvent changer à la suite des autres transactions . Cela signifie que les autorisations doivent être définies en des termes qui ne nécessitent pas de calculs cryptographiques dans le Business Logic Processor.

Pour se faire , chaque clé publique doit être attribuée à un identifiant unique et immuable . Après qu’un identifiant a été attribué, le ou les Input Disruptor(s) peut vérifier que la signature prévue correspond à l'ID spécifié. Le temps que la transaction arrive au Business Logic Processor, la dernière étape restante consiste à vérifier les identifiants.

Cette même technique peut être utilisée pour supprimer les conditions préalables de contrôle sur un objet immuable avec un identifiant statique.


Transactions étudiées pour les validation statiques

Beaucoup de propriétés de transaction peuvent être vérifiées de façon statique, sans la nécessité de faire référence à l'état global actuel.

Ces contrôles incluent la vérification de l’éventail des paramètres, la déduplication des saisies, l'ordre de tri de tableaux etc… De manière générale, de nombreux contrôles peuvent être effectués si la transaction comprend les données qu'ils " estiment " appartenir de l'état global. Une fois que ces contrôles sont effectués , la seule chose qu’il reste à faire pour le Business Logic Processor est de s’assurer que les " hypothèses " sont toujours vraies, ce qui peut généralement se résumer à la vérification d'un timestamp de modification sur les objets référencés par rapport au moment où la transaction a été signée.


Contrats intelligents

Beaucoup de blockchains adoptent un langage de script d'usage général pour définir toutes leurs opérations. Ces designs définissent le « Business Logic Processor » comme une machine virtuelle et toutes les transactions sont définies comme des scripts à exécuter par la machine virtuelle. Cette approche prend les limitations monothread d'un CPU réel et les compile en forçant le tout à traverser un processeur virtuel. Un processeur virtuel, même avec une compilation des données à la volée, sera toujours plus lent qu'un CPU réel, mais la vitesse pure de calcul n’est pas le seul problème avec une approche "tout est un script".

Lorsque les transactions sont définies à un niveau si bas, cela signifie que la plupart des contrôles statiques et des opérations cryptographiques sont aspirées dans le Business Logic Processing et la capacité de traitement globale baisse. Un moteur de script ne devrait jamais exiger qu’une vérification de signature cryptographique soit faite, même si elle est faite par un appel natif.

Sur la base des leçons que nous tirons de LMAX, nous savons qu’une machine virtuelle pour une blockchain devrait être conçue en gardant à l’esprit les performances monothread. Cela signifie qu’elle doit être optimisée pour pouvoir effectuer une compilation à la volée depuis le début, et que les contrats intelligents les plus fréquemment utilisés doivent être supportés nativement par la blockchain. Cela ne laissera donc que les contrats personnalisés rarement utilisés à être effectués sur une machine virtuelle. Ces contrats personnalisés devraient être conçus autour de la performance, ce qui signifie que la machine virtuelle devrait limiter la mémoire adressable à quelque chose qui va tenir dans le cache d’un processeur.


Modèle de données orienté objet

L'un des avantages de garder tout en mémoire est que le logiciel peut être conçu pour imiter les relations réelles des données. Cela signifie que le Business Logic Processor peut suivre rapidement les pointeurs se situant dans la mémoire jusqu’aux données dont il a besoin, plutôt que d'être obligé d'effectuer des requêtes de base de données coûteuses en ressources. Cela signifie également que les données peuvent être accessibles sans les copier, et que les données peuvent être modifiées sur place. Cette optimisation unique offre un énorme gain de performances comparé à l’utilisation d’une approche fondée sur la base de données.


Taille des transactions

Une blockchain qui traite 100 000 transactions par seconde génère beaucoup de données. La taille moyenne d'une transaction sur les réseaux concurrents, comme Ripple et Bitcoin, est d'environ 250 octets. Une opération similaire sur BitShares est en moyenne de seulement 100 octets. En d'autres termes, les systèmes concurrents nécessitent 2,5 fois la largeur de bande passante pour le même nombre de transactions. En supposant une connexion en Gigabit à l'Internet, il faudrait seulement environ 0,1 secondes pour transférer un bloc contenant 100.000 transactions. Les réseaux concurrents exigeraient 0,25 secondes. Après que la latence et d’autres soubresauts sur un réseau peer-to-peer soient pris en compte, il devient clair que la taille de la transaction a un impact direct sur l'intervalle de bloc, et donc la latence de confirmation.

Les tailles de transaction sont souvent une indication de la quantité de données que la CPU doit traiter dans son cheminement. Par conséquent, ils servent comme une indication de combien de temps sera nécessaire pour que la performance monothread d'un CPU soit frappé.

Certaines optimisations sont possibles dans tous les protocoles si ils supposent que tous les nœuds ont une connaissance préalable de toutes les transactions de diffusion et ne nécessitent que la liste ordonnée des identifiants de transaction pour diffuser chaque bloc. Ce serait une possibilité d’évolution pour le système d'implémentation.


Conclusion

Concevoir une blockchain de haute performance n’est pas quelque chose de sorcier, cela ne nécessite pas de protocoles complexes et difficiles à comprendre. De la même manière cela ne nécessite pas de diviser le traitement des données entre tous les nœuds du réseau. Au lieu de cela, tout ce qui est nécessaire pour construire une blockchain haute performance est de supprimer tous les calculs qui ne sont pas vitaux et indépendant du Core Business Logic, et de concevoir un protocole qui facilite ces différents optimisations. Voila ce que BitShares a fait.