ARK Core v2 — Informations supplémentaires avant la sortie du code

Quelques semaines se sont écoulées depuis notre dernière publication technique sur le blog, et à l’approche de la version ARK Core v2 (gardez à l’esprit que “ARK ne donne pas de dates!”) Nous aimerions passer en revue les détails de la Core v2, avant la sortie à venir très prochainement.

Dans cet article, nous aimerions couvrir ce qu’est ARK Core v2 et ce qu’il n’est pas. La dernière phase de test d’ARK Core v2 est en cours sur notre testnet interne et nous sommes sur le point de mettre le code à la disposition du public pour des tests sur Devnet. Ni le temps de test sur Devnet, ni la durée avant de le pousser sur le Mainnet ne peut être prédit. Plusieurs facteurs entrent en jeu, comme les résultats de tests publics et les bugs qui peuvent apparaître. Une fois public, tout le monde est invité à faire des test, à hacker, expérimenter et / ou à coder le noyau, à trouver et rapporter des bugs, suggérer des améliorations ou tout ce qui peut aider à améliorer le code pour le Mainnet.

La première itération de v2 est dédiée à être 100% compatible avec le protocole v1. Afin de passer avec fluidité au nouveau code (avec la possibilité de faire la mise à jour), un hard fork sera nécessaire pour activer le nouveau protocole basé sur AIP11. Nous publierons une API «publique» complètement remaniée qui facilitera grandement la vie des développeurs d’applications clientes. La taille des blocks du hard fork AIP11 ne sera annoncé que lorsque ARK sera prêt à l’annoncer. Avant cela, toute date annoncée par un tiers à n’est que pure spéculation.

ARK Core v2 sera disponible en deux étapes. La première étape de la version v2 inclura la nouvelle structure de frais dynamiques, la mise à niveau multisig (multi-signature) et les transactions par seconde (TPS) mises à jour.
La deuxième étape de la v2 nécessitera un hardfork, intégrant les multi paiements AIP11, les échanges de timelock et de token, et l’expiration de transaction.

Nous aimerions également annoncer que l’intégration d’ARKVM reprendra avec la version core v2 sur devnet. La majorité de l’intégration a été complétée pour v1, maintenant le travail vers la v2 va commencer. Encore une fois, comme nous le disons souvent, “ARK ne donne aucune date”, alors regardez la feuille de route sur le site pour suivre la progression de la VM.

Couvrons maintenant quelques-uns des sujets les plus discutés afin qu’il n’y ait pas de désinformation.

Le temps de Block* (pas de changements) (*Block Time)

Il n’est pas prévu de réduire les délais de création des blocs car il n’y a aucun intérêt stratégique à le faire. Les temps d’attente sont directement liés aux latences du réseau lors de l’établissement d’un consensus. Les temps de bloc inférieurs ne peuvent être réalisés qu’au prix de la centralisation. Cela peut être observé dans certaines crypto-monnaies avec des temps latence plus courts, obtenus en réduisant le nombre de nœuds ou de délégués, et en optimisant (et donc en contrôlant) l’emplacement des serveurs bien connectés. Ces actions ne font pas partie de notre philosophie et sont à l’opposé de notre vision basé sur la décentralisation.

Le nombre de Délégués (aucun changement)

Le nombre de délégués restera à 51. Augmenter le nombre de délégués nécessiterait des tests approfondis et se ferait au prix de latences plus importantes (par exemple en diminuant le TPS et en augmentant le temps de création des bloc) ou en augmentant la centralisation des nœuds.

Frais (pas de fork)

L’une des demandes les plus «anticipées» par la communauté était clairement la réduction des frais, en particulier avec le prix de l’ARK qui a augmenté au cours de l’année écoulée. ARK Core v1 a déjà intégré des frais flexibles, mais cela n’a pas été activé au niveau de la création de clients et de blocs.
ARK Core v2 activera donc cela sans avoir besoin d’un hard fork (ce qui aurait été nécessaire si elle n’avait pas encore été préparée en v1).

Ce que la v2 apportera de + que la v1 :

• ARK-JS activera les frais supplémentaires lorsque vous créez une transaction (custom fees)
• Les délégués seront en mesure de fixer un seuil de frais minimum pour déterminer les blocs qu’ils accepteront lors du forgeage

Ce sera la seule responsabilité des délégués actifs que d’ajuster les frais, de la même manière que les mineurs le font sur le bitcoin. La formule de la nouvelle structure de frais dynamique d’ARK sera proportionnelle à la taille de la transaction. Par exemple, l’ajout de données dans le champ “vendeur” entraînera des frais de transaction plus élevés puisque la taille totale des octets de la transaction est augmentée. Étant donné que certains types de transactions nécessiteront une plus grande consommation de ressources, des frais minimums seront proposés pour ces transactions (c’est à dire pour les “Vote” et les “inscription des délégués”). Théoriquement, cette nouvelle formule de calcul des frais pourrait ramener les frais de transaction à 1 Arktoshi (0.00000001 ARK).

Nous allons travailler sur la capacité des applications clients (ark-desktop, ark-mobile et libraries) à estimer les frais de transaction que vous allez «construire» une fois le marché stabilisé. Il est certain que les frais par défaut existants chez les clients actuels seront supérieurs aux frais du marché quand ils seront activés, donc nous ne nous attendons pas à des frictions de ce côté, ces applications clients continueront à fonctionner comme prévu.

Attention, ça va parler mathématiques.

Voici la répartition de la nouvelle structure de frais dynamiques pour ARK.

Les frais minimums acceptables par le réseau seront :
0.00000001 ARK soit 1 Arktoshi.

La formule de calcul est: TXFee = (T + S) * C

T: octet de décalage minimum en fonction du type de transaction, défini par le réseau (octet). Chaque valeur spécifique sera définie avant la sortie sur devnet (ie: voteTX = 100, multiTX = 5, TX normal = 0)

S: taille de l’octet de transaction sérialisé = 80 octets minimum pour TX normal (47 octets header+ 33 octets TX normal). Les octets Header et TX varieront en fonction de chaque type TX (ex: TX normal = 33 octets + min 47 octets pour header, MultiTX = 29 octets x (nombre de TX) + min 47 octets pour header + 2 octets pour définir le nombre de sorties). Les entrées Vendorfield s’ajoutent au total des octets header.

C: constante (ARK / byte) définie par le délégué incluant la transaction dans son bloc forgé.

C peut avoir plus de 8 décimales, la seule exigence sera que TXFee à la fin doit être plus ou égal à 0.00000001 ARK (1 Arktoshi).

Exemple:

Pour le transfert de base, nous pourrions avoir T = 0 octet, C = 0,0001 ARK / octet.

Pour une transaction de transfert de base avec VendorField empty S = 80 octets, d’où le TXFee = (0 + 80) * 0,0001 qui est 0,008 ARK.

Pour un vote TX, nous pourrions avoir T = 100 octets, C = 0,0001 ARK / octet,
S = 82 octets, TXFee = (100 + 82) * 0,0001 qui est 0,0182 ARK.

Transactions par seconde (pas de fork)

Nous avons vu passer des images et des informations circuler autour du fait que le nouveau noyau d’ARK aurait plus de 14 000 TPS. Mettons ça au clair — ARK core v2 n’aura pas plus de 14 000+ TPS.
Nous ne savons pas d’où proviennent ces chiffres, mais ils sont faux.

Pour mettre ceci en perspective (14 000 TPS), la taille d’une transaction dans le réseau ARK a un minimum de 80 octets (header ou ‘en-tête’ de transaction de 47 octets + 33 octets de transaction, plus de données supplémentaires ou type de transfert différent) les transactions seraient traitées chaque seconde si tous les blocs étaient remplis. La blockchain journalière augmenterait de plus de 95 Go et en un an, la taille de la blockchain dépasserait 34 To.

Pour être clair, toute blockchain décentralisée qui revendiquerait des nombres de TPS aussi élevés mentirait quelque part. Le traitement d’un nombre aussi élevé de transactions se fait au prix d’une centralisation complète des créateurs et des validateurs de blocs. Chaque transaction sur le réseau a une taille d’octet. La gestion de plusieurs Mo par seconde de bande passante avec de faibles latences pour conserver un consensus n’est pas viable actuellement dans un environnement décentralisé. Sans parler de l’espace disque et de la RAM nécessaires pour valider et traiter chaque transaction qui toucherait le nœud.

ARK Core v2 offrira bien sûr une meilleure gestion des transactions (la sérialisation et la dé-sérialisation des transactions réduiront la taille des octets, ce qui augmentera également la vitesse). Cela permettra d’augmenter le TPS et de fournir de meilleures opportunités d’évolution à l’avenir avec des transactions allégées. Le TPS peut facilement être amélioré avec un soft fork (en changeant une valeur dans le fichier de configuration et en mettant à jour les nœuds avec le code le plus récent).

ARK core v2 sera initialement plafonné à environ 150 transactions par bloc (ARK core v1 est actuellement fixé à 50 transactions par bloc). Ceci amène le TPS à environ 19. Des nombres beaucoup plus élevés sont possibles, mais actuellement ce n’est pas un besoin premier que d’atteindre le TPS maximum. Avec des frais réduits, nous devons trouver un moyen efficace pour empêcher les spams de transaction et les engorgements de la blockchain.
Bien sûr, tester les limites maximales du TPS sera très amusant sur Devnet, et des tests approfondis seront nécessaires avant de faire des changements drastiques sur Mainnet.

Ces chiffres ne sont que pour la version Devnet, le nombre de TPS de Mainnet Final v2 seront déterminés après la fin des tests Devnet.

Multi-signatures (Soft fork)

Une transaction à plusieurs signatures est un type de transaction spécial associé à plusieurs clés privées. Le schéma le plus simple est une adresse m-of-n, où n représente le nombre total de clés privées associées à une adresse, et l’envoi de ARK à partir de cette adresse nécessite des signatures d’au moins m clés. Une transaction à plusieurs signatures est une transaction qui envoie des fonds à partir d’une adresse à plusieurs signatures.

L’intérêt principal du multi-signatures est d’augmenter la difficulté d’accès aux coins associés à une clé privée spécifique.
Avec une adresse 2-of-2, vous pouvez garder les deux clés sur des machines totalement séparées, et ainsi le vol nécessitera de compromettre les deux clés privées, ce qui est une tâche beaucoup plus difficile que de mettre la main sur une seule — surtout si les machines sont complètement différentes (par exemple, un PC et un périphérique dédié, ou deux machines hébergées avec un hôte et un système d’exploitation différents).
La seconde signature de l’ARK (2ème mot de passe) sera remplacée par un support multi-signature (la deuxième signature fonctionnera toujours car elle du même type que multisignature 2 sur 2).

Il peut également être utilisé pour la redondance afin de protéger contre la perte — avec une adresse 2 sur 3, non seulement le vol / déplacement de pièces nécessite l’obtention de 2 clés différentes, mais vous pouvez toujours utiliser les pièces (*coins) si vous oubliez une seule clé. Cela permet des options plus flexibles que de simples sauvegardes. Il peut également être utilisé pour des scénarios plus avancés, comme une adresse partagée par plusieurs personnes, lorsqu’un vote majoritaire est requis pour utiliser les fonds (c.-à-d. Portefeuille partagé par exemple).

Multi-paiements (Hard Fork — AIP11)

Afin de réduire les frais de transaction de la blockchain, et en tenant compte de grandes quantités de tx, vous pouvez combiner (par lot) une transaction de plusieurs opérations de paiement. Cela aidera également à réduire les frais par paiement. (ex: envoyer 16 tx dans un paiement groupé à la fois n’engage qu’un seul tarif tx au lieu de 16 frais différents.)

Les transactions de paiement multiple offriront jusqu’à 65546 octets de taille (2 octets pour le nombre de sorties et 29 octets par sortie TX multipaiement = 2260 tx par multipaiement maximum) à inclure dans un type de transaction à paiements multiples. Cela sera certainement utile pour les délégués qui effectuent des paiements quotidiens à un nombre important d’adresses des votants.

Au départ, nous limiterons cela à 16 sorties possibles (16 paiements par transaction) et augmenterons selon les besoins et selon les tests supplémentaires.

Timelocks et Token Swaps (Hard fork — AIP11)

Notez que cette fonctionnalité est encore en cours de révision et de nombreux détails vont probablement changer selon les spécifications AIP11.

Il y a eu des discussions sur le fait que les Bridgechains / ARKchains doivent nécessairement exécuter des nœuds de relais ARK, afin de réaliser des échanges au sein même de l’écosystème ARK et ainsi de disposer d’une certaine quantité de pièces ARK pour ces chaînes. Nous ne voulons pas que le bridgechain soient obligés de compter sur la chaîne principale ARK pour fonctionner. La réalisation de swaps (*échanges) au sein de l’écosystème ARK se fera avec un Timelock combinant des transactions de types Tx multisignature. Nous allons développer des capacités de conversion facilement compréhensibles et utilisables directement dans le portefeuille de bureau ARK (plus tard sur mobile et sur le Web). L’échange devrait être aussi facile que d’entrer quelques valeurs et d’attendre des deux parties qu’elles acceptent les termes (c.-à-d. Échanger 5 ARK pour 100 jetons Persona ou vice versa de manière simple). Nous concentrerons notre développement sur ceci après la version initiale de la v2.

Les transactions en Timelocked combinées avec le support multi-signature fournissent une base stable pour les capacités de permutation ARKchain et les canaux de paiement offchain. Afin de fournir cette fonctionnalité, un hard fork sera nécessaire. Les transactions Timelock introduiront deux nouveaux champs dans la structure de la transaction:

Le type Timelock définit différents types pour le champ de valeur de timelock. Les types actuellement pris en charge seront:

• 0 — pour timelock de type timestamp (si timelock type = 0, la valeur du timelock doit être spécifiée avec horodatage).
• 1 — pour la valeur de type timelock de type blockheight (si timelock type = 1, la valeur du timelock doit être spécifiée avec blockheight).
• TimeLockType = 0, valeur de timelock = horodatage: la transaction sera forgée lors de la transmission de l’horodatage.
• TimeLockType = 1, valeur de timelock = blockHeight: la transaction sera forgée lorsque la blockchain atteint la largeur spécifiée à la valeur du timelock pour blockHeight.

Expiration (Hard Fork— AIP11)

Pour atténuer les attaques de double dépense lorsque le signataire de la transaction ne contrôle pas le canal de communication pour envoyer / vérifier la transaction sur la blockchain, nous devons garantir que le tiers ne peut pas détenir les transactions car la durée de validité est actuellement infinie dans v1. C’est le but du champ d’expiration. (*expiration field)

L’expiration sera également un nouveau point important dans la structure des transactions. L’expiration est l’horodatage, ou le délai après lequel la transaction ne peut pas être incluse dans un bloc. En d’autres termes, si l’horodatage du bloc est strictement supérieur à l’horodatage d’expiration de la transaction, le bloc est considéré invalide. En pratique, cela signifie que les transactions expirées ne seront pas forgées et seront supprimées du pool de transactions. La transaction devra donc être envoyée à nouveau.

Résumé

Pour résumer tout — ARK Core v2 apportera beaucoup de nouvelles fonctionnalités, en reprenant l’essentiel des meilleures fonctions déjà opérationnelles. La v2 sera également compatible à 100% avec la v1 pour faciliter la transition vers la nouvelle base de code, modulaire, plus rapide, plus facile à comprendre et à enrichir pour les développeurs.

ARK Core v2 sera un tout nouveau chapitre dans la vision d’ARK et nous sommes très excités de vous le faire savoir. Avec V2, nous rompons complètement avec notre ancien code Crypti / Lisk et nous nous affirmons en même temps comme des pionniers, des innovateurs et des leaders dans l’espace blockchain.

Article original de BoldNinja & ArkEcosystem
Traduit par Antoine Breuil pour Ark & ARK.io Espace Francophone