Test public : une solution pour la confidentialité et la scalabilité sur Ethereum

Blockchain est une technologie innovante qui promet d'améliorer de nombreux aspects de la vie humaine. Elle transfère des processus et des produits réels dans l'espace numérique, assurant la rapidité et la fiabilité des transactions financières, réduisant leur coût, et permettant également de créer des applications DAPP modernes utilisant des contrats intelligents dans des réseaux décentralisés.

Étant donné les nombreux avantages et les différentes applications de la blockchain, il peut sembler étrange que cette technologie prometteuse ne soit pas encore présente dans tous les secteurs. Le problème est que les blockchains décentralisées modernes manquent d'évolutivité. Ethereum traite environ 20 transactions par seconde, ce qui est insuffisant pour répondre aux besoins du business dynamique moderne. Dans le même temps, les entreprises utilisant la technologie blockchain n'osent pas abandonner Ethereum en raison de sa haute résistance au piratage et aux pannes de réseau.

Pour assurer la décentralisation, la sécurité et la scalabilité dans la blockchain, répondant ainsi à la Trillemme de la Scalabilité, l'équipe de développeurs Opporty a créé Plasma Cash — une chaîne latérale, composée d'un contrat intelligent et d'un réseau privé basé sur Node.js, transmettant périodiquement son état à la chaîne principale (Ethereum).

Les processus clés dans Plasma Cash

1. L'utilisateur appelle la fonction du contrat intelligent `deposit`, lui transmettant le montant en ETH qu'il souhaite déposer dans le token Plasma Cash. La fonction du contrat intelligent crée le token et génère un événement à ce sujet.

2. Les nœuds Plasma Cash, abonnés aux événements du contrat intelligent, reçoivent l'événement de création du dépôt et ajoutent à la pool la transaction de création du token.

3. Périodiquement, des nœuds spéciaux Plasma Cash prennent toutes les transactions du pool (jusqu'à 1 million) et en forment un bloc, calculent l'arbre de Merkle et, par conséquent, le hash. Ce bloc est envoyé à d'autres nœuds pour vérification. Les nœuds vérifient si le hash Merkle est valide, si les transactions sont valides (par exemple, si l'expéditeur du jeton est bien le propriétaire). Après la vérification du bloc, le nœud appelle la fonction `submitBlock` du smart contract, qui enregistre dans la chaîne principale le numéro et le hash Merkle du bloc. Le smart contract génère un événement sur l'ajout réussi d'un bloc. Les transactions sont supprimées du pool.

4. Les nœuds ayant reçu l'événement de soumission de bloc commencent à appliquer les transactions qui ont été ajoutées au bloc.

5. À un moment donné, le propriétaire (ou non-propriétaire) du jeton souhaite le retirer de Plasma Cash. Pour cela, il appelle la fonction `startExit`, en fournissant les informations sur les deux dernières transactions concernant le jeton, qui prouvent qu'il est le propriétaire du jeton. Le smart contract, utilisant le hash Merkle, vérifie la présence des transactions dans les blocs et envoie le jeton pour retrait, qui aura lieu dans deux semaines.

6. Si l'opération de retrait du jeton a été effectuée de manière irrégulière (le jeton a été dépensé après le début de la procédure de retrait ou le jeton avait déjà été pris par un tiers avant le retrait), le propriétaire du jeton peut contester le retrait dans un délai de deux semaines.

La confidentialité est atteinte de deux manières.

1. La chaîne principale ne sait rien des transactions qui se forment et se transmettent à l'intérieur de la chaîne secondaire. L'information concernant qui a déposé et retiré de l'ETH dans/sout Plasma Cash reste publique.

2. La chaîne secondaire permet d'organiser des transactions anonymes en utilisant des zk-SNARKs.

Environnement technologique

• NodeJS
• Redis
• Etherium
• Soild

Test

En développant Plasma Cash, nous avons testé la vitesse du système et obtenu les résultats suivants :

• jusqu'à 35 000 transactions par seconde ajoutées au pool ;
• jusqu'à 1 000 000 transactions peuvent être stockées dans un bloc.

Les tests ont été réalisés sur 3 serveurs suivants :

1. Intel Core i7-6700 Quad-Core Skylake avec NVMe SSD — 512 Go, 64 Go DDR4 RAM
3 nœuds valides Plasma Cash ont été mis en place.

2. AMD Ryzen 7 1700X Octa-Core « Summit Ridge » (Zen), SATA SSD — 500 Go, 64 Go DDR4 RAM
Un nœud ETH de testnet Ropsten a été mis en place.
3 nœuds valides Plasma Cash ont été mis en place.

3. Intel Core i9-9900K Octa-Core avec NVMe SSD — 1 To, 64 Go DDR4 RAM
Un nœud de soumission Plasma Cash a été mis en place.
3 nœuds valides Plasma Cash ont été mis en place.
Un test a été lancé pour ajouter des transactions dans le réseau Plasma Cash.

Total : 10 nœuds Plasma Cash dans un réseau privé.

Test 1

La limite est de 1 million de transactions par bloc. Ainsi, 1 million de transactions se retrouvent dans 2 blocs (puisque le système parvient à traiter une partie des transactions et à les soumettre pendant qu'elles sont envoyées).

État initial : dernier bloc #7 ; 1 million de transactions et de jetons sont enregistrés dans la base.

00:00 — lancement du script de génération de transactions
01:37 — 1 million de transactions créées et l'envoi vers le nœud a commencé
01:46 — le nœud de soumission a pris 240k transactions du pool et commence à former le bloc #8. Nous voyons également que 320k transactions sont ajoutées au pool en 10 secondes
01:58 — le bloc #8 a été signé et envoyé pour validation
02:03 — le bloc #8 a été validé et la fonction `submitBlock` du contrat intelligent avec le hachage Merkle et le numéro du bloc a été appelée
02:10 — le script de démonstration a terminé son travail, ayant envoyé 1 million de transactions en 32 secondes
02:33 — les nœuds ont commencé à recevoir des informations indiquant que le bloc #8 a été ajouté à la chaîne principale et ont commencé à traiter 240k transactions
02:40 — 240k transactions ont été retirées du pool, qui sont déjà dans le bloc #8
02:56 — le nœud de soumission a pris les 760k transactions restantes du pool et a commencé à calculer le hachage Merkle et à signer le bloc #9
03:20 — tous les nœuds contiennent 1 million 240k transactions et jetons
03:35 — le bloc #9 a été signé et est envoyé pour validation à d'autres nœuds
03:41 — erreur réseau survenue
04:40 — l'attente de validation du bloc #9 a été interrompue par un timeout
04:54 — le nœud de soumission a pris les 760k transactions restantes du pool et a commencé à calculer le hachage Merkle et à signer le bloc #9
05:32 — le bloc #9 a été signé et envoyé pour validation à d'autres nœuds
05:53 — le bloc #9 a été validé et envoyé dans la chaîne principale
06:17 — les nœuds ont commencé à recevoir des informations indiquant que le bloc #9 a été ajouté à la chaîne principale et ont commencé à traiter 760k transactions
06:47 — le pool a été nettoyé des transactions contenues dans le bloc #9
09:06 — tous les nœuds contiennent 2 millions de transactions et jetons

Test 2

La limite est de 350k par bloc. Nous avons donc 3 blocs.

État initial : dernier bloc #9 ; 2 millions de transactions et jetons sont enregistrés dans la base

00:00 — le script de génération de transactions est déjà en cours d'exécution
00:44 — 1 million de transactions créées et l'envoi vers le nœud a commencé
00:56 — le nœud de soumission a pris 320k transactions du pool et commence à former le bloc #10. Nous voyons également que 320k transactions sont ajoutées au pool en 10 secondes
01:12 — le bloc #10 a été signé et envoyé à d'autres nœuds pour validation
01:18 — le script de démonstration a terminé son travail, ayant envoyé 1 million de transactions en 34 secondes
01:20 — le bloc #10 a été validé et envoyé dans la chaîne racine
01:51 — tous les nœuds ont reçu de la chaîne racine l'information que le bloc #10 a été ajouté, et commencent à appliquer 320k transactions
02:01 — le pool s'est vidé de 320k transactions qui ont été ajoutées au bloc #10
02:15 — le nœud de soumission a pris 350k transactions du pool et forme le bloc #11
02:34 — le bloc #11 est signé et envoyé aux autres nœuds pour validation
02:51 — le bloc #11 a été validé et envoyé dans la chaîne racine
02:55 — le dernier nœud a exécuté les transactions du bloc #10
10:59 — une transaction avec la soumission du bloc #9 a pris beaucoup de temps dans la chaîne racine, mais elle a été exécutée et tous les nœuds ont reçu l'information et ont commencé à exécuter 350k transactions
11:05 — le pool s'est vidé de 320k transactions qui ont été ajoutées au bloc #11
12:10 — tous les nœuds contiennent 1 million 670k transactions et tokens
12:17 — le nœud de soumission a pris 330k transactions du pool et forme le bloc #12
12:32 — le bloc #12 est signé et envoyé aux autres nœuds pour validation
12:39 — le bloc #12 a été validé et envoyé dans la chaîne racine
13:44 — tous les nœuds ont reçu de la chaîne racine l'information que le bloc #12 a été ajouté et commencent à appliquer 330k transactions
14:50 — tous les nœuds contiennent 2 millions de transactions et tokens

Test 3

Dans le premier et le deuxième serveurs, un nœud validant a été remplacé par un nœud de soumission.

État initial : dernier bloc #84 ; 0 transactions et tokens sont conservés dans la base

00:00 — 3 scripts ont été lancés, générant et envoyant chacun 1 million de transactions
01:38 — 1 million de transactions a été créé et l'envoi vers le nœud de soumission #3 a commencé
01:50 — le nœud de soumission #3 a pris 330k transactions du pool et forme le bloc #85 (f21). Nous voyons aussi que 350k transactions sont ajoutées au pool en 10 secondes
01:53 — 1 million de transactions a été créé et l'envoi vers le nœud de soumission #1 a commencé
01:50 — le nœud de soumission #3 a pris 330k transactions du pool et forme le bloc #85 (f21). Nous voyons aussi que 350k transactions sont ajoutées au pool en 10 secondes
02:01 — le nœud de soumission #1 a pris 250k transactions du pool et forme le bloc #85 (65e)
02:06 — le bloc #85 (f21) est signé et envoyé aux autres nœuds pour validation
02:08 — le script de démonstration du serveur #3 a terminé son travail, ayant envoyé 1 million de transactions en 30 secondes
02:14 — le bloc #85 (f21) a été validé et envoyé dans la chaîne racine
02:19 — le bloc #85 (65e) est signé et envoyé aux autres nœuds pour validation
02:22 — 1 million de transactions a été créé et l'envoi vers le nœud de soumission #2 a commencé
02:27 — le bloc #85 (65e) a été validé et envoyé dans la chaîne racine
02:29 — le nœud de soumission #2 a pris 111855 transactions du pool et forme le bloc #85 (256).
02:36 — le bloc #85 (256) est signé et envoyé à d'autres nœuds pour validation.
02:36 — le script de démon du serveur #1 a terminé son travail, ayant envoyé 1 million de transactions en 42,5 secondes.
02:38 — le bloc #85 (256) a été validé et envoyé à la chaîne racine.
03:08 — le script de démon du serveur #2 a terminé son travail, ayant envoyé 1 million de transactions en 47 secondes.
03:38 — tous les nœuds ont reçu de la chaîne racine l'information que les blocs #85 (f21), #86(65e), #87(256) ont été ajoutés et commencent à appliquer 330k, 250k, 111855 transactions.
03:49 — le pool a été vidé de 330k, 250k, 111855 transactions, qui ont été ajoutées aux blocs #85 (f21), #86(65e), #87(256).
03:59 — le nœud de soumission #1 a pris 888145 transactions du pool et forme le bloc #88 (214), le nœud de soumission #2 a pris 750k transactions du pool et forme le bloc #88 (50a), le nœud de soumission #3 a pris 670k transactions du pool et forme le bloc #88 (d3b).
04:44 — le bloc #88 (d3b) est signé et envoyé à d'autres nœuds pour validation.
04:58 — le bloc #88 (214) est signé et envoyé à d'autres nœuds pour validation.
05:11 — le bloc #88 (50a) est signé et envoyé à d'autres nœuds pour validation.
05:11 — le bloc #85 (d3b) a été validé et envoyé à la chaîne racine.
05:36 — le bloc #85 (214) a été validé et envoyé à la chaîne racine.
05:43 — tous les nœuds ont reçu de la chaîne racine l'information que les blocs #88 (d3b), #89(214) ont été ajoutés et commencent à appliquer 670k, 750k transactions.
06:50 — en raison de la perte de connexion, le bloc #85 (50a) n'a pas été validé.
06:55 — le nœud de soumission #2 a pris 888145 transactions du pool et forme le bloc #90 (50a).
08:14 — le bloc #90 (50a) est signé et envoyé à d'autres nœuds pour validation.
09:04 — le bloc #90 (50a) a été validé et envoyé à la chaîne racine.
11:23 — tous les nœuds du serveur #3 ont reçu de la chaîne racine l'information que le bloc #90 (50a) a été ajouté, et commencent à appliquer 888145 transactions. Pendant ce temps, le serveur #3 a déjà appliqué les transactions des blocs #88 (d3b), #89(214).
12:11 — tous les pools sont vides.
13:41 — tous les nœuds du serveur #3 contiennent 3 millions de transactions et de jetons.
14:35 — tous les nœuds du serveur #1 contiennent 3 millions de transactions et de jetons.
19:24 — tous les nœuds du serveur #2 contiennent 3 millions de transactions et de jetons.

Obstacles

Lors du développement de Plasma Cash, nous avons rencontré les problèmes suivants, que nous avons résolus et continuons de résoudre :

1. Conflit d'interaction entre différentes fonctions du système. Par exemple, la fonctionnalité d'ajout de transactions dans le pool bloquait le fonctionnement du soumission et de la validation des blocs, et vice versa, ce qui entraînait une baisse de la vitesse.

2. Il n'était pas clair comment envoyer un grand nombre de transactions tout en minimisant les coûts de transmission des données.

3. On ne savait pas comment et où stocker les données pour obtenir de bons résultats.

4. Il n'était pas clair comment organiser le réseau entre les nœuds, car la taille d'un bloc avec 1 million de transactions occupe environ 100 Mo.

5. Le fonctionnement en mode monothread interrompt la connexion entre les nœuds lorsque des calculs longs se produisent (par exemple, la construction de l'arbre de Merkle et le calcul de son hachage).

Comment avons-nous géré tout cela ?

La première version du nœud Plasma Cash était une sorte de combine qui pouvait tout faire en même temps : accepter des transactions, soumettre et valider des blocs, fournir une API pour accéder aux données. Étant donné que NodeJS est initialement monothread, la lourde fonction de calcul de l'arbre de Merkle bloquait la fonction d'ajout de transactions. Nous avons vu deux options pour résoudre ce problème :

1. Lancer plusieurs processus NodeJS, chacun exécutant certaines fonctions.

2. Utiliser worker_threads et déplacer l'exécution d'une partie du code dans des threads.

En fin de compte, nous avons utilisé les deux options en même temps : nous avons logiquement séparé un nœud en 3 parties, qui peuvent fonctionner séparément, mais en même temps de manière synchronisée.

1. Nœud de soumission, qui accepte les transactions dans le pool et s'occupe de la création de blocs.

2. Nœud de validation, qui vérifie la validité des nœuds.

3. Nœud API — fournit une API pour accéder aux données.

Chaque nœud peut être connecté via un socket unix par le biais de cli.

Les opérations lourdes, telles que le calcul de l'arbre de Merkle, ont été transférées dans un thread séparé.

Ainsi, nous avons réussi à faire fonctionner toutes les fonctions de Plasma Cash en même temps et sans pannes.

Une fois que le système a fonctionné fonctionnellement, nous avons commencé à tester la vitesse et, malheureusement, nous avons obtenu des résultats insatisfaisants : 5 000 transactions par seconde et jusqu'à 50 000 transactions dans un bloc. Il a fallu comprendre ce qui avait été mal mis en œuvre.

Pour commencer, nous avons commencé à tester le mécanisme de communication avec Plasma Cash pour connaître la capacité maximale du système. Auparavant, nous avons écrit que le nœud Plasma Cash fournit une interface de socket Unix. Initialement, il était textuel. Les objets JSON étaient transférés en utilisant `JSON.parse()` et `JSON.stringify()`.

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

Nous avons mesuré la vitesse de transfert de tels objets et avons obtenu environ 130 000 par seconde. Nous avons essayé de remplacer les fonctions standard travaillant avec JSON, mais la performance ne s'est pas améliorée. Le moteur V8 doit être bien optimisé pour ces opérations.

La gestion des transactions, des jetons et des blocs se faisait via des classes. Lors de la création de telles classes, la performance a chuté de moitié, ce qui indique que la POO ne nous convient pas. Nous avons dû tout réécrire en utilisant une approche fonctionnelle.

Écriture dans la base de données

Au départ, Redis a été choisi pour le stockage des données comme l'une des solutions les plus performantes répondant à nos exigences : stockage clé-valeur, travail avec des tables de hachage, ensembles. Nous avons lancé redis-benchmark et obtenu environ 80 000 opérations par seconde en mode de 1 pipelining.

Pour une performance élevée, nous avons configuré Redis de manière plus fine :

• Nous avons établi une connexion de socket Unix.
• Nous avons désactivé la sauvegarde d'état sur disque (pour la fiabilité, il est possible de configurer une réplique et de faire des sauvegardes sur disque dans un autre Redis).

Dans Redis, un pool est une table de hachage, car nous avons besoin de la possibilité d'obtenir toutes les transactions en une seule requête et de supprimer les transactions une par une. Nous avons essayé d'utiliser une liste ordinaire, mais elle fonctionne plus lentement lors du déchargement de la liste entière.

Lors de l'utilisation de la bibliothèque Redis standard de NodeJS, nous avons obtenu une performance de 18 000 transactions par seconde. La vitesse a chuté de 9 fois.

Étant donné que le benchmark nous a montré des capacités clairement cinq fois supérieures, nous avons commencé à optimiser. Nous avons changé la bibliothèque pour ioredis et avons obtenu des performances de 25k par seconde. Nous ajoutions des transactions individuellement, en utilisant la commande `hset`. Ainsi, nous générions de nombreuses requêtes vers Redis. L'idée est née de regrouper les transactions en lots et de les envoyer avec une seule commande `hmset`. Le résultat — 32k par seconde.

Pour plusieurs raisons, que nous allons décrire ci-dessous, nous travaillons avec les données en utilisant `Buffer` et, comme il s'est avéré, si cela est converti en texte (`buffer.toString(‘hex’)`) avant l'écriture, nous pouvons obtenir un gain de performance supplémentaire. Ainsi, la vitesse a pu être augmentée à 35k par seconde. À ce stade, nous avons décidé de suspendre l'optimisation supplémentaire.

Nous avons dû passer à un protocole binaire car :

1. Le système calcule souvent des hachages, des signatures, etc., et pour cela, il a besoin de données sous forme de `Buffer`.

2. Lors de la transmission entre services, les données binaires pèsent moins que les données textuelles. Par exemple, lors de l'envoi d'un bloc de 1 million de transactions, les données en texte peuvent occuper plus de 300 mégaoctets.

3. La conversion constante des données affecte la performance.

C'est pourquoi nous avons basé notre propre protocole binaire de stockage et de transmission de données, développé sur la base de la bibliothèque remarquable `binary-data`.

En conséquence, nous avons obtenu les structures de données suivantes :

— Transaction

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

— Token

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

— Bloc

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

Avec les commandes habituelles `BD.encode(block, Protocol).slice();` et ` BD.decode(buffer, Protocol)`, nous convertissons les données en `Buffer` pour les stocker dans Redis ou les transmettre à un autre nœud et récupérer les données.

Nous avons également 2 protocoles binaires pour la transmission de données entre services :

— Protocole pour l'interaction avec le Plasma Node via un socket unix

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

où :

• `type` — une action à exécuter, par exemple 1 — sendTransaction, 2 — getTransaction ;
• `payload` — les données à transmettre à la fonction correspondante ;
• `messageId` — l'identifiant du message, permettant d'identifier la réponse.

— Le protocole d'interaction entre les nœuds

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

où :

• `code` — le code du message, par exemple 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT ;
• `versionProtocol` — la version du protocole, car il peut y avoir des nœuds dans le réseau avec différentes versions qui peuvent fonctionner différemment ;
• `seq` — identifiant du message ;
• `countChunk` et `chunkNumber` nécessaires pour diviser les gros messages ;
• `length` et `payload` la longueur et les données elles-mêmes.

Étant donné que nous avons préalablement typé les données, le système final fonctionne beaucoup plus rapidement que la bibliothèque `rlp` d'Ethereum. Malheureusement, nous n'avons pas encore pu nous en passer, car il est nécessaire de retravailler le contrat intelligent, ce que nous prévoyons de faire à l'avenir.

Si nous avons réussi à atteindre la vitesse 35 000 des transactions par seconde, nous devons également les traiter dans un délai optimal. Comme le temps moyen de formation d'un bloc est d'environ 30 secondes, nous devons inclure dans le bloc 1 000 000 des transactions, ce qui signifie transférer plus de 100 Mo de données.

Au départ, nous avons utilisé la bibliothèque `ethereumjs-devp2p` pour la communication entre les nœuds, mais elle ne gérait pas une telle quantité de données. En conséquence, nous avons utilisé la bibliothèque `ws` et configuré le transfert de données binaires via websocket. Bien sûr, nous avons également rencontré des problèmes lors du transfert de gros paquets de données, mais nous les avons divisés en chunks et ces problèmes n'existent plus maintenant.

La formation de l'arbre de Merkle et le calcul du hachage 1 000 000 des transactions prend environ 10 secondes de calcul continu. Pendant ce temps, la connexion avec tous les nœuds peut être interrompue. Il a été décidé de déplacer ce calcul dans un thread séparé.

Conclusions :

En réalité, nos conclusions ne sont pas nouvelles, mais pour une raison quelconque, de nombreux spécialistes les oublient lors du développement.

• L'utilisation de la programmation fonctionnelle plutôt que de la programmation orientée objet augmente les performances.
• Le monolithe est moins performant qu'une architecture de services pour un système performant sur NodeJS.
• L'utilisation de `worker_threads` pour les calculs lourds améliore la réactivité du système, en particulier lors des opérations i/o.
• Les sockets UNIX sont plus stables et plus rapides que les requêtes HTTP.
• Si vous devez transmettre rapidement de grandes quantités de données sur le réseau, il est préférable d'utiliser des websockets et d'envoyer des données binaires divisées en morceaux, qui peuvent être retransmises si elles ne réussissent pas à arriver, puis regroupées en un seul message.

Nous vous invitons à visiter GitHub le projet : https://github.com/opporty-com/Plasma-Cash/tree/new-version

Cet article a été coécrit avec Alexandre Nashivan, développeur senior Clever Solution Inc.

Source : habr.com