Bitcoin : comprendre et optimiser les fees de vos ...

«Les blockchains ne passent pas à l'échelle» - vraiment?

Il y a une rhétorique dominante parmi les passionnés de monnaie numérique et les «personnalités» qui disent que «les blockchains ne passent pas à l'échelle» ou qu'elles ne le font pas bien. C'est cette rhétorique qui a convaincu un grand nombre de partisans de BTC à se rallier derrière le mantra "offchain" c'est-à-dire «en dehors de la blockchain». Année après année, nous voyons des conférences sur la blockchain discuter des merveilles de la technologie, et dans le même élan, elles déclarent que sortir les données de la chaîne est en quelque sorte une bonne chose.

Pour beaucoup de ces personnalités qui ont passé d'innombrables heures à lutter contre l'écriture des données sur la chaine, Bitcoin SV représente un adversaire qui remet en question toute leur philosophie. C'est pour cette raison que vous entendez des gens comme Adam Back déplorer les réussites atteintes par BSV; ce qui prouve leur hypocrisie un peu plus chaque jour.

Alors que les partisans de BTC estiment que seules les transactions monétaires devraient être écrites sur la blockchain (et que seules ces transactions sont précieuses), Bitcoin SV accueille toutes les données du monde, et les considèrent toutes comme précieuses. Vous ne pourriez pas avoir une opinion plus opposée sur un sujet.

Quelque part entre ces deux façons de penser opposées se trouve la multitude des altcoins, chacune se considérant digne d'enregistrer un certain type de données bien spécifique. Mais aucun autre projet n'englobe l'ensemble de toutes les données en leur accordant de la valeur.

La philosophie d'une blockchain n'est qu'une petite partie du puzzle. L'essentiel est que la philosophie soit entièrement soutenue par des prouesses techniques. De toute évidence, comme nous l'avons vu maintes et maintes fois, BSV continue d'exploser des records historiques en nombre de transactions.

Rien qu'en jetant un oeil aux métriques, BSV apparaît comme le roi de la technologie blockchain. Laissons de côté les promesses de capacités futures (surtout étant donné que l'écosystème blockchain est criblé de fausses promesses) - et concentrons-nous sur le classement actuel.

https://imgur.com/mcFSYat

Le graphique ci-dessus n'est pas basé sur des résultats théoriques de laboratoire. Il s'agit d'une métrique de ce qui a été démontré jusqu'à présent dans le monde réel, sur une blockchain publique, et en direct.

Techniquement, si vous ne regardez que les statistiques de la blockchain, BSV a enregistré plus de 3500 transactions par seconde (TPS). Cela s'est produit avec le record du monde de l'entreprise TAAL établissant un block de 309 Mo. Cependant, ce nombre a été intentionnellement omis du graphique car le traitement par TAAL n'a pas été effectué dans des circonstances habituelles.

Ensuite, il y a le réseau Bitcoin SV STN, qui est un réseau de test spécialement configuré pour tester l'évolutivité de Bitcoin. Celui-ci a récemment culminé à plus de 2400 TPS.

https://imgur.com/3bhqO5l

Mais comme le dit Daniel Connolly, développeur principal du logiciel Bitcoin SV Node, ce ne sont pas les performances de pointe, mais plutôt les performances soutenues qui sont importantes. Examiner les performances de pointe est une fausse mesure de la sécurité, que de nombreux projets utilisent frauduleusement. Mais même ainsi, sur le STN, BSV a atteint une performance soutenue de 1426 TPS pendant 8 heures. Un record.

Sans aucun doute, les opposants qui voient cela ne tarderont pas à sauter dans le train des «promesses». Oui, c’est vrai qu’Ethereum à une future version "Casper" qui prévoit d'augmenter son débit, et Cardano a des améliorations prévues aussi… mais et alors? Pensez-vous que les ingénieurs de nœuds BSV sont assis à se tourner les pouces en attendant? BSV a le projet Teranode en développement qui éclipsera les chiffres actuels avec des blocs de plusieurs TeraOctets. Mais ne nous laissons pas trop emporter par les promesses - je les méprise comme personne.

La philosophie de BSV de passer à l'échelle rapidement signifie que les nœuds ne sont pas des machines pour amateurs. Le refrain de BTC selon lequel «tout le monde a besoin de gérer son propre nœud» est un moyen sûr de s'assurer que votre blockchain ne passera jamais à l'échelle.

BSV est résolu à se retrouver dans des datacenters - et fidèle au livre blanc de Satoshi Nakamoto, il permet aux utilisateurs d'être de simples utilisateurs. BSV n'essaye pas de forcer les utilisateurs quotidiens à devoir tenir un registre de l'historique complet des transactions de la blockchain, comme ça semble être l'obsession de BTC. BSV souhaite que sa blockchain héberge le futur d'Internet, que nous avons baptisé le «Metanet». Personne aujourd'hui ne s'attend à ce que vous ayez l'intégralité d'Internet sur votre ordinateur à la maison, et Bitcoin ne s'attend pas non plus à ce que vous ayez l'intégralité du Metanet chez vous.

Les utilisateurs peuvent alors être de simples utilisateurs - et ils peuvent toujours fonctionner en toute sécurité à l'aide de preuves appelées "SPV". SPV signifie "Vérification de Paiement Simplifiée", c'est une méthode que Satoshi Nakamoto a décrite pour la première fois dans le livre blanc de Bitcoin. À l'échelle mondiale, les portefeuilles SPV sont une nécessité absolue. Le concept est simple, mais les détails de la méthode ont été omis par Satoshi, et l'entreprise nChain détient maintenant le brevet decette méthode. Cela garantit la protection de la technologie SPV au protocole Bitcoin original qui survit sous le nom BSV, et assure son avenir pour le passage à l'échelle.

Selon le directeur scientifique de nChain, le Dr Wright: «Les utilisateurs du système sont uniquement tenus de conserver une copie de l'en-tête des blocs auxquels ils peuvent comparer leurs transactions. À l'heure actuelle, l'en-tête d'un bloc a une taille inférieure à 50 Mo. De nombreux fichiers d'image dépassent cette taille. La croissance de ces données est linéaire, alors que le système Bitcoin évolue par la loi de Moore et donc de manière exponentielle.»

En d'autres termes, les portefeuilles Bitcoin de tous les jours, comme celui sur votre smartphone, resteront toujours utilisables quelle que soit la taille de la blockchain, et ce tout en restants sécurisés.

Et comme nChain détient le brevet de cette technologie, si une autre blockchain souhaite évoluer à l'échelle mondiale et éviter d'une manière ou d'une autre que chaque utilisateur doive faire tourner son propre serveur de noeud, elle devra trouver une nouvelle façon de le faire. On leur souhaite bonne chance.

BSV a avancé à pas de géant face à la concurrence, et il ne fait aucun doute que beaucoup d'entreprises dans le monde qui s'intéressent à la blockchain commencent à en prendre conscience. Il n'y a qu'un seul projet blockchain qui a non seulement prouvé sa volonté d'évoluer, mais qui l'a démontré par des records historiques, et a également protégé son avenir avec une série d'inventions et de brevets.

inspiré et traduit de l'article en anglais: https://coingeek.com/blockchains-dont-scale-except-bitcoin-sv/
submitted by zhell_ to BitcoinSVFrance [link] [comments]

Contrats d'exécution consensuels de VDS et processus du téléchargement à la chaîne

Résumé des contrats d’exécution consensuels
Le concept de base du contrat d’exécution consensuels
Contrats d’exécution consensuels, connu sous le nom de contrat intelligent dans l'industrie de la blockchain, mais l'équipe de VDS estime que ce terme est trop marketing, car nous n'avons pas trouvé à quel point la technologie de programmation contractuelle est intelligente jusqu'à présent, il s'agit simplement d'un système décentralisé dans le réseau distribué, la procédure prédéfinie de comportement consensuel formée par l'édition de code. Dans l'esprit de rechercher la vérité à partir des faits, nous pensons qu'il est plus approprié de renommer le contrat intelligent en tant que contrat d'exécution de consensus. Lorsque les humains combineront la technologie blockchain avec la technologie d'intelligence artificielle de AI à l'avenir, les obstacles à la compréhension des noms sont éliminés.
Le contrat d'exécution consensuel peut être appliqué à de nombreuses industries, telles que la finance, l'éducation, les systèmes administratifs, l'Internet des objets, le divertissement en ligne, etc. Grâce à la technologie de la blockchain, dans un réseau distribué spécifique, un script d'exécution qui est formé par l'édition de pré-code sans aucune intervention de tiers et le comportement de consensus des deux parties ou de plusieurs parties impliquées dans le protocole. Il garantit l’exécution sûre, stable et équitable des droits et intérêts de tous les participants au contrat.
Le contrat d'exécution consensuel a joué un rôle dans l'accélération de l'atterrissage de diverses applications pour le développement de l'industrie de la blockchain et a incité davantage de développeurs à y participer activement, révolutionnant l'expérience réelle des produits de la technologie de la blockchain. Tout découle des contributions exceptionnelles de l'équipe Ethereum, ouvrant une nouvelle porte à l'ensemble de l'industrie.
Structure de base et jonction
L’intégration de EVM
La machine virtuelle Ethereum (EVM) utilise un code machine 256 bits et est une machine virtuelle basée sur la pile utilisée pour exécuter les contrats d'exécution consensuels d'Ethereum. Étant donné que l'EVM est conçu pour le système Ethereum, le modèle de compte Ethereum (Account Model) est utilisé pour la transmission de valeurs. La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La raison de cette conception est, d'une part, c'est en raison de la nécessité de réaliser la fonction d'échange de résonance de VDS et la fonction d'échange inter-chaîne unidirectionnelle de bitcoin à chaîne VDS, qui peuvent réaliser la génération de deux adresses différentes de bitcoin et VDS avec une clé privée. D'autre part, l'équipe VDS estime que la structure sous-jacente des transactions Bitcoin est plus stable et fiable grâce à 10 ans de pratique sociale. Par conséquent, VDS utilise une couche d'abstraction de compte (Account Abstraction Layer) pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par EVM. De plus, VDS a ajouté une interface basée sur le modèle de compte, afin qu'EVM puisse lire directement les informations sur la chaîne VDS. Il convient de noter que la couche d'abstraction de compte peut masquer les détails de déploiement de certaines fonctions spécifiques et établir une division des préoccupations pour améliorer l'interopérabilité et l'indépendance de la plate-forme.
Dans le système Bitcoin, ce n'est qu'après la vérification du script de déverrouillage (Script Sig) et du script de verrouillage (Script Pub Key) que la sortie de transaction correspondante peut être dépensée.
Par exemple, le script de verrouillage verrouille généralement une sortie de transaction sur une adresse bitcoin (la valeur de hachage de la clé publique). Ce n'est que lorsque les conditions de configuration du script de déverrouillage et du script de verrouillage correspondent, que l'exécution du script combiné affiche le résultat sous la forme True (la valeur de retour de système est 1), de sorte que la sortie de transaction correspondante sera dépensée.
Dans le système distribué de VDS, nous soulignons l'opportunité de l'exécution du contrat d'exécution consensuel. Par conséquent, nous avons ajouté les opérateurs OP_CREATE et OP_CALL au script de verrouillage. Lorsque le système de VDS détecte cet opérateur, les nœuds de l'ensemble du réseau exécuteront la transaction. De cette façon, le rôle joué par le script Bitcoin est plus de transférer les données pertinentes vers EVM, pas seulement en tant que langage de codage. Tout comme Ethereum exécute un contrat d'exécution de consensus, le contrat déclenché par les opérateurs OP_CREATE et OP_CALL, EVM changera son état dans sa propre base de données d'état.
Compte tenu de la facilité d'utilisation du contrat d'exécution du consensus de la chaîne VDS, il est nécessaire de vérifier les données qui déclenchent le contrat et la valeur de hachage de la clé publique de la source de données.
Afin d'éviter que la proportion d'UTXO sur la chaîne de VDS ne soit trop importante, la sortie de transaction de OP_CREATE et OP_CALL est t conçue pour être dépensée. La sortie de OP_CALL peut envoyer des fonds pour d'autres contrats ou adresses de hachage de clé publique.
Tout d’abord, pour le contrat d'exécution consensuel créé sur la chaîne VDS, le système généreraune valeur de hachage de transaction pour l'appel de contrat.Le contrat nouvellement libéré a un solde initial de 0 (les contrats avec un solde initial ne sont pas 0 ne sont pas pris en charge). Afin de répondre aux besoins du contrat d'envoi de fonds, VDS utilise l'opérateur OP_CALL pour créer une sortie de transaction. Le script de sortie du contrat d'envoi de fonds est similaire à :
1: the version of the VM
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
Ce script n'est pas compliqué et OP_CALL effectue la plupart du travail requis. VDS définit le coût spécifique de la transaction (sans tenir compte de la situation de out-of-gas) comme Output Value, qui est Gas Limit. Le mécanisme spécifique du Gas sera discuté dans les chapitres suivants. Lorsque le script de sortie ci-dessus est ajouté à la blockchain, la sortie établit une relation correspondante avec le compte du contrat et se reflète dans le solde du contrat. Le solde peut être compris comme la somme des coûts contractuels disponibles.
La sortie d'adresse de hachage de clé publique standard est utilisée pour le processus de base des transactions de contrat, et le processus de transaction entre les contrats est également généralement cohérent. En outre, vous pouvez effectuer des transactions par P2SH et des transactions non standard (non-standard transactions). Lorsque le contrat actuel doit être échangé avec un autre contrat ou une adresse de hachage de clé publique, la sortie disponible dans le compte du contrat sera consommée. Cette partie de la sortie consommée doit être présente pour la vérification des transactions dans le réseau de VDS, que nous appelons la transaction attendue du contrat (Expected Contract Transactions). Étant donné que la transaction attendue du contrat est générée lorsque le mineur vérifie et exécute la transaction, plutôt que d'être générée par l'utilisateur de la transaction, elle ne sera pas diffusée sur l'ensemble du réseau.
Le principe de fonctionnement principal de la transaction attendue du contrat est réalisé par le code OP_SPEND. OP_CREATE et OP_CALL ont deux modes de fonctionnement. Lorsque l'opérateur est utilisé comme script de sortie, EVM l'exécute, lorsque l'opérateur est utilisé comme script d'entrée, EVM ne sera pas exécuté (sinon il provoquera une exécution répétée). Dans ce cas, OP_CREATE et OP_CALL peuvent être utilisés comme Opération sans commandement. OP_CREATE et OP_CALL reçoivent la valeur de hachage de transaction transmise par OP_SPEND et renvoient 1 ou 0 (c'est-à-dire il peut être dépensé ou pas). Il montre l'importance de OP_SPEND dans la transaction attendue de l'intégralité du contrat. Plus précisément, lorsque OP_SPEND transmet la valeur de hachage de transaction à OP_CREATE et OP_CALL, OP_CREATE et OP_CALL comparent si la valeur de hachage existe dans la liste des transactions attendues du contrat. S'il existe, renvoyez 1 pour dépenser, sinon retournez 0, ce n'est pas pour dépenser. Cette logique fournit indirectement un moyen complet et sûr de garantir que les fonds du contrat ne peuvent être utilisés que par le contrat, ce qui est cohérent avec le résultat des transactions UTXO ordinaires.
Lorsque le contrat EVM envoie des fonds à l'adresse de hachage de clé publique ou à un autre contrat, une nouvelle transaction sera établie. À l'aide de l'algorithme de Consensus-critical coin picking, la sortie de transaction la plus appropriée peut être sélectionnée dans le pool de sortie disponible du contrat. La sortie de transaction sélectionnée sera utilisée comme script d'entrée pour exécuter un seul OP_SPEND, et la sortie est l'adresse cible des fonds, et les fonds restants seront renvoyés au contrat, tout en modifiant la sortie disponible pour la consommation. Ensuite, la valeur de hachage de cette transaction sera ajoutée à la liste des transactions attendues du contrat. Lorsque la transaction est exécutée, la transaction sera immédiatement ajoutée au bloc. Une fois que les mineurs de la chaîne ont vérifié et exécuté la transaction, la liste des transactions attendues du contrat est à nouveau parcourue. Une fois la vérification correcte, la valeur de hachage est supprimée de la table. De cette façon, l'utilisation de OP_SPEND peut effectivement empêcher l'utilisation de valeurs de hachage codées en dur pour modifier le coût de la sortie.
La couche d'abstraction des comptes VDS élimine la nécessité pour l'EVM d'accorder trop d'attention à coin-picking. Il lui suffit de connaître le solde du contrat et peut échanger des fonds avec d'autres contrats ou même des adresses de hachage de clé publique. De cette façon, seule une légère modification du contrat d'exécution du consensus Ethereum peut répondre aux exigences de fonctionnement du contrat VDS.
En d'autres termes, tant que le contrat d'exécution consensuel peut être exécuté sur la chaîne Ethereum, il peut s'exécuter sur la chaîne VDS.
Achèvement de AAL
La conception de la chaîne VDS est basée sur le modèle Bitcoin UTXO. La plate-forme générale de contrat d'exécution de consensus utilise le modèle de compte. Étant donné que le contrat en tant qu'entité nécessite un logo de réseau, ce logoest l'adresse du contrat, de sorte que le fonctionnement et la gestion du contrat d'exécution consensuel peuvent être effectués par cette adresse. La couche d'abstraction de compte est ajoutée à la conception du modèle (Account Abstraction Layer, AAL) de chaîne de VDS, qui est utilisée pour convertir le modèle UTXO en un modèle de compte qui peut être exécuté par le contrat.
Pour les développeurs qui exécutent des contrats par consensus, le modèle de compte de la machine virtuelle est relativement simple. Il prend en charge l'interrogation des soldes des contrats et peut également envoyer des fonds pour d'autres contrats. Bien que ces opérations semblent très simples et basiques, toutes les transactions de la chaîne VDS utilisent le langage de script Bitcoin, et il est plus compliqué que prévu d'être implémenté dans la couche d'abstraction de compte de la chaîne VDS basée sur le modèle Bitcoin UTXO. AAL a donc élargi sa base en ajoutant trois nouveaux opérateurs :
OP_CREATE est utilisé pour effectuer la création de contrats intelligents, transmettre le code d'octet transmis via la transaction à la base de données de stockage de contrats de la machine virtuelle et générer un compte de contrat.
OP_CALL est utilisé pour transférer les données pertinentes et les informations d'adresse nécessaires pour appeler le contrat et exécuter le contenu du code dans le contrat. (Cet opérateur peut également envoyer des fonds pour des contrats d'exécution consensuels).
OP_SPEND utilise la valeur de hachage de ID de contrat actuel comme transaction d'entrée HASH ou transaction HASH envoyée à l'UTXO du contrat, puis utilise OP_SPEND comme instruction de dépense pour créer un script de transaction.
Utilisation des Contrats et processus du téléchargement à la chaîne
Rédiger les contrats
Il est actuellement possible d'utiliser le langage Solidity pour rédiger des contrats d'exécution de consensus.
Utilisez Solidity Remix ou un autre Solidity IDE pour l'écriture et la compilation de code.
solidity remix(https://remix.ethereum.org/
Il est recommandé d'utiliser le mode homestead pour compiler.
Il est recommandé d'utiliser la version solidité 0.4.24 (si d'autres versions sont utilisées, cela peut provoquer des erreurs ou des échecs).
La syntaxe Solidity peut être référencée(https://solidity.readthedocs.io/en)
Compiler et déployer les contrats
Fonctionnement du contrat intelligent de vdsd
Examiner les variables de fonctionnement de l'environnement
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
> Les tests sous contrat sont effectués dans l'environnement de test. Il est recommandé de tester après avoir atteint une hauteur de 440 blocs.
440 blocs hautement achevés l'opération de retour de fonds après les événements anormaux du contrat (refund) et (revert).
La commande de contrat de déploiement est :
```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
Cette fonction est utilisée pour l'exécution du constructeur du contrat avec les paramètres entrants pour obtenir le ByteCode qui est finalement utilisé pour le déploiement.
(Cette méthode consiste à associer le bytecode à ABI et à le stocker localement pour l'enregistrement. Il peut appeler des méthodes internes localement et renvoyer le bytecode approprié)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
La valeur de retour est : txid, éxpéditeur, hachage de l'expéditeur160, adresse du contrat
Consulter si la commande a été exécutée avec succès :
```vds-cli gettransactionreceipt txid```
La valeur de retour de txid pour les transactions non contractuelles est vide
La valeur de retour est : Les informations pertinentes de txid sur la BlockHash Hachage du bloc
- blockNumber Hauteur de bloc
- transactionHash Hachage de transaction
- transactionIndex La position de l'échange dans le bloc
- from Hachage de l’adresse de l’expéditeur 160
- to Le destinataire est l'adresse du contrat, le lieu de création de la transaction contractuelle est 00000000000000000000000000000
- cumulativeGasUsed Gas accumulé
- gasUsed Gaz réellement utilisé
- contractAddress Adresse du contrat
- excepted Y a-t-il des erreurs
- exceptedMessage Message d'erreur
-
Il convient de noter que le champ excepted n'est pas None, ce qui indique que l'exécution du contrat a échoué. Bien que la transaction puisse être vérifiée sur la chaîne, cela ne signifie pas que le contrat a été exécuté avec succès, c'est-à-dire que les frais de traitement pour l'exécution de ce contrat ne sont pas remboursables. Les frais de traitement ne seront remboursés que si la méthode revert est entrée dans le contrat, et les frais de méthode ne seront pas remboursés pour la méthode assert.
Appel des contrats
```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
Cette fonction est utilisée pour ajouter le contrat ABI à la base de données locale.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
Cette fonction est utilisée pour obtenir les informations du contrat ajouté.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
Cette fonction renverra le résultat de l'exécution lors de l'appel de la méthode constante ordinaire, comme l'appel de la méthode d'opération de données de contrat retournera la chaîne de format hexadécimal du script d'opération.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
Cette fonction est utilisée pour envoyer le script d'opération de contrat au contrat spécifié et le faire enregistrer sur la blockchain.
Consultation des résultats d’exécution des contrats
```vds-cli gettransaction txid```
Cette commande est utilisée pour afficher les heures de confirmation de la transaction de portefeuille actuelle.
```vds-cli gettransactionreceipt txid```
Cette commande est utilisée pour vérifier les résultats d'exécution de la création de contrat et des transactions d'appel, s'il y a des exceptions levées et des consommations réelles de GAS.
`${datadir}/vmExecLogs.json` enregistrera les appels de contrat sur la blockchain. Ce fichier servira d'interface externe pour les événements de contrat.
Interface d'appel des contrats
l Interface de création de contrat createcontract
l Interface de déploiement de contrat deploycontract
l Interface d'ajout ABI addcontract
l Interface d’appel des contrats avec l’opération des fons sendtocontract
l Interface de lecture des informations sur les contrats callcontractfunc
l Interface d'acquisition d'informations sur l'exécution des transactions contractuelles gettransactionreceipt
L’expliquation des coûts d’expoitation des contrats
Les coûts de fonctionnement de la création d'un contrat sont toutes des méthodes estimées, et un succès d'exécution à 100% ne peut pas être garanti, car gas limit a une limite supérieure de 50000000, et les contrats dépassant cette limite entraîneront un échec. La chaîne de VDS utilise une méthode de rendre la monnaie, ce qui signifie que même si beaucoup de gaz est envoyé, le mineur n'utilisera pas tout le gas et restituera le gas restant. Alors ne vous inquiétez pas de dépenser trop de gas.
Le coût de création d'un contrat est approximativement de la taille du Byte Code * 300 comme gas limit, le gas price minimum est de 0.0000004, gas price * gas limit est le coût de création d'un contrat.
En ce qui concerne l'exécution de la méthode dans un contrat, le gas requis est estimé. En raison de la congestion du réseau, l'estimation ne garantit pas que 100% peuvent être téléchargés avec succès dans la chaîne. Par conséquent, je crains de tromper et de demander au développeur de vérifier les résultats.
submitted by YvanMay to u/YvanMay [link] [comments]

[Résumé] White paper de Ethereum

tl;dr : Même résumé, ce white-paper est vraiment énorme. Les plus faignants devraient lire uniquement Pourquoi une nouvelle chaîne ? et Les contrats. L'un décrit la philosophie générale du projet, l'autre est l'innovation la plus impressionnante.
Pourquoi une nouvelle chaîne ?
Le protocole Bitcoin est très bien pour gérer une monnaie. Quand on a voulu implémenter d'autres concepts tels que "colored coins" et "smart property" de façon décentralisée, on a d'abord essayé de le faire en s'appuyant sur la blockchain Bitcoin. C'est la meilleure façon de faire, en informatique et surtout en cryptographie que de réutiliser un maximum de composants éprouvés.
Seulement si le protocole Bitcoin est très bien pour gérer une monnaie, il n'est pas prévu pour être générique. Du coup, implémenter des choses différentes dans la blockchain peut relever du casse-tête et demander de faire des choix discutables pour tout faire fonctionner.
Ethereum propose donc une blockchain prévue pour être générique. Léger en fonctionnalité, l'accent est mit sur la souplesse du protocole. Ainsi, si au départ Ethereum ne fait pas grand chose, il évoluera avec le temps et les idées de chacun.
La blockchain Ethereum
Dans cette partie, nous verront les principales différences entre la blockchain Ethereum et la blockchain Bitcoin.
** Version modifiée de GHOST **
Dans la blockchain Bitcoin, un bloc en suit toujours un et un seul autre. Si deux blocs valides suivent le même bloc, un seul des deux sera retenu dans la chaîne officielle, l'autre sera déclaré orphelin.
Le problème de cette approche est que la puissance de calcul qui a servi à générer le bloc orphelin est purement et simplement perdue. Cela a un impact considérable lorsqu'il y a beaucoup d'orphelins. Hors augmenter la vitesse de création des blocs (un bloc toute les dix minutes pour Bitcoin) augmente le nombre de blocs orphelins, cette augmentation est donc dangereuse pour la sécurité de la chaîne.
GHOST permet de palier à ce problème de puissance de calcul perdu. Ceci en faisant en sorte qu'un bloc référence non seulement son parent, mais aussi les blocs orphelins. Ainsi les orphelins ne sont plus perdus et renforcent, par leur proof of work, la difficulté pour un attaquant de créer une chaine parallèle.
Note : une description plus détaillée de GHOST est disponible en français ici.
La version de GHOST proposée par Etherneum est très légèrement modifiée. Principalement un bloc ne peut plus référencer n'importe quel orphelin de la chaîne, mais seulement les frères de son bloc parent. Ça réduit le rattrapage d'orphelins à un seul niveau, mais ça permet d'éviter que des petits malins s'amusent à miner des orphelins à côté du Genesis bloc là où la difficulté est moindre.
Avec ça l'intervalle entre les blocs sera de 60 secondes et la sécurité devrait être comparable à celle de Litecoin qui propose des blocs espacés de 2 minutes 30.
** La monnaie du réseau **
La monnaie du réseau sera l'ether. Son nom n'est pas le même que celui du protocole pour éviter les confusions comparables à celles qui existent entre le bitcoin (unité de compte) et le Bitcoin (protocole). Toujours pour éviter les polémiques qui remplissent le forum, les sous-unité de l'ether sont déjà nommées (ou presque) 1 ether = 1 000 finney = 1 000 000 szabo = ... = 1 000 000 000 000 000 000 wei. Les noms compris dans le "..." ne sont pas encore définits.
Cette monnaie reste sommaire. Il n'y a pas d'histoire de double signatures, de transactions dans le futur,... Toutes ces choses-là pourront être implémentées dans les contrats que nous verrons plus bas. L'utilité première de cette monnaie est de pouvoir payer les frais de transaction et servir de récompense pour les mineurs assurant la sécurité du réseau.
Dans Bitcoin, il n'y a pas de notion directe de solde à une adresse. Les transactions génèrent des "sorties" qui peuvent être utilisées pour créer de nouvelles transactions. Le solde d'une adresse est donc la somme de la valeur des sorties non dépensées associées à une adresse. Ethereum élimine ce concept que personne ne comprend. Ethereum tient à jour une association "adresse = solde" pour toutes les adresses qui ont plus de zéro ether.
D'un point de vue financier, le projet Ethereum sera crowdfundé (euh... il y a un verbe équivalent en français ?). Ce n'est pas technique comme information, mais ça à son importance pour la répartition des premiers ether. En effet, les investisseurs et le projet lui-même se partageront une somme initiale en ether. Ensuite les mineurs prendront le relais comme créateurs de valeur. Les blocs généreront toujours la même quantité d'ether, ayant deux effets. Premier effet, la valeur initiale acquise par les investisseurs va s'amenuiser peu à peu, il n'y a pas de nombre maximum d'ether jamais créé. L'inflation sera tout de même réduite au fil du temps, si produire 50 pièces quand il y a 50 pièces en circulation crée une inflation de 100%, produire 50 pièces sur 5000 pièces en circulation crée une inflation d'1%.
** Algorithme de Minage **
Bitcoin utilise des hash sha256 pour son proof of work. Demandant au mineur de trouver une valeur d'un champ libre de son bloc telle que le hash du bloc soit suffisamment prêt de zéro. Ce qui est "suffisamment" prêt est réglé par la difficulté. Cette façon de faire pose un problème : les ASIC. Ces machines qui coûtent un bras et rendent n'importe quelle carte graphique as-been on une vilaine tendance à concentrer la puissance de calcul dans les bras des plus riches. Et une puissance de calcul concentrée est mauvaise pour la sécurité.
Une autre façon de faire est d'utiliser Scrypt à la place de sha256 comme algorithme de hash. Scrypt est plus gourmand en mémoire, rendant les ASIC moins efficace comparés aux systèmes généralistes. Seulement Scrypt ne demande que 128 kilo octets de mémoire et les fabricants d'ASIC commencent à arriver à trouver des designs qui valent le coup. On ne peux pas simplement augmenter la mémoire consommée par Scrypt, car c'est une lame a double tranchant. Il faut beaucoup de mémoire pour calculer le proof of work, mais il en faut autant pour vérifier le proof of work. Demander a tous les noeuds du réseau de disposer autant de mémoire qu'un laptop moderne pourrait faire sauter beaucoup de raspberry-pi.
Pour pallier aux problèmes de Scrypt, Ethereum utilisera un autre algorithme de minage (pas basé sur du brute forçage de hash) nommé Dagger qui devrait prendre 100 Mega octets de mémoire pour générer le proof of work, mais seulement 100 Kilo octets pour le vérifier.
** Transactions **
Une transaction contient l'adresse du receveur, le nombre d'ether transférée, des données arbitraires et une signature. L'adresse de l'expéditeur peut-être déterminée depuis la signature.
La partie la plus intéressante c'est la présence de données arbitraires. On peut y metre ce qu'on veut (si j'ai bien compris). Le protocole définit son utilisation pour créer les contrats... Que nous verrons très vite.
Une autre chose à noter, il n'y a aucun moyen de préciser les frais de transactions. Ceux-ci sont déduit automatiquement et la transaction ne sera valide que si l'adresse source a assez de fond pour payer la valeur et les frais. Les frais de transactions auront le droit a leur propre paragraphe.
Les contrats
Les contrats sont des agents virtuels dans le réseau. Ils ont une adresse avec laquelle ils peuvent emmètre et recevoir des ether, un programme qui est activé quand le contrat reçoit une transaction, un espace mémoire volatile pour faire ses calculs (une espèce de mémoire vive) et un espace mémoire persistant pour y stocker des données entre deux activations.
Le programme est écrit dans un langage spécifique, étudié pour les spécificités d'Ethereum. Ce langage est Turing-complet, c'est-à-dire qu'il dispose d'une entrée, d'une sortie et permet de résoudre à peu près n'importe quel problème. Ses entrées sont principalement les fameuses données arbitraires des transactions qu'il reçoit et sa sortie est l'espace mémoire persistant. En plus de ça, le langage permet d'envoyer des transactions et d'inspecter la blockchain.
Pour illustrer ce que les contrats peuvent faire, dans le white-paper vous pourrez trouver plein d'exemples d'implémentations simplistes de problèmes courrants. Il y a une monnaie alternative, un produit dérivé financier, une émulation de Namecoin (pas simpliste, vraiment minimaliste) et plein d'autres embryons d'idées.
Pour créer un contrat, on doit envoyer une transaction sans adresse de destination, contenant le code du programme. L'adresse du contrat est déterminée à partir du hash de la transaction qui l'a créé. C'est à cette adresse qu'il faut envoyer des transactions quand on veut activer le programme.
Les frais de transaction
Dans Bitcoin les frais de transaction sont optionnels, au pire la transaction est rejetée ou délayée longtemps. Dans Ethereum, autoriser de ne pas mettre de frais de transaction serait infaisable. Les agents exécutent des programmes Turing-complet, si un de ces programmes faisait une boucle infini gratuitement, il mettrait a genoux le réseau en un rien de temps.
Bilan, des frais de transaction en dur et non-négociables. Il y a des frais différents pour à peu prêt tout, de l'envoie d'une transaction a l'exécution d'une ligne de code par un agent. Pour que ces frais s'ajustent avec le temps ils se basent sur un frai de base qui change en fonction de la difficulté. Plus la difficulté est grande, plus le frai de base est petit. Ainsi, si le court (en bourse) de l'ether augmente, les mineurs sont incités à ajouter plus de puissance de calcul et les frais diminuent pour compenser l'augmentation de la valeur de l'ether. Au contraire si le court diminue et que des mineurs se retirent, les frais augmentent puisque l'ether à moins de valeur.
Quelques références :
Elles sont toutes en anglais.
submitted by JeanBono to BitcoinFrance [link] [comments]

[Traduction] New paper: Accelerating Bitcoin's Trasaction Processing

Au milieu de toutes ces agitations entre les légiférant, les économistes, les traders et autres gens qui de toutes façons ils y connaissent rien au code, un petit article technique est paru !
D'abord un post sur bitcointalk, puis un lien sur reddit anglophone nous permettent de discutter de tout ça en anglais.
Mais ce soir j'était d'humeur a m'essayer au métier de traducteur, donc voici la traduction du post bitcointalk (seulement la partie qui résume le papier, le reste c'est du blabla).
Scalabilité, délais et sécurité :
Nous commençons notre recherche par l'examination des effets d'un grand volume de transactions sur la sécurité de Bitcoin (suivant les travaux de Decker et Wattenhofer). Le nombre de transactions par seconde (TPS) que Bitcoin peut supporter est limité par deux principaux facteurs : 1) La vitesse de création des blocs (d'un bloc toutes les dix minutes) et 2) la taille maximum d'un bloc (actuellement d'un méga octet). Ces deux paramètres réunis limitent le nombre de transactions par seconde que Bitcoin peut gérer. La façon la plus évidente d'augmenter le TPS est d'augmenter soit la taille des blocs, soit la vitesse de création des blocs. Chacune de ces modifications est controversée, et pour une bonne raison : chacune pourrait affecter la sécurité du protocole. D'abord, considérons une augmentation de la vitesse de création des blocs (comme par exemple la génération de blocs de Litecoin toute les deux minutes et demie, ou même Fastcoin et son extrême douze secondes par bloc). La création rapide de blocs entraine un nombre important de blocs concurrents. La plupart finiront orphelins. Le même symptôme apparaît si on augmente la taille des blocs : les gros blocs mettent plus longtemps à se propager sur le réseau (à cause des limitations de bande passante) et les blocs créés pendant cette propagation finiront certainement orphelins, c'est-à-dire, ils seront perdus.
Perdre un bon nombre de blocs affaiblit la sécurité du réseau et le rend plus vulnérable aux attaques de type 50%. Par exemple, si la moitié des blocs sont perdus de cette manière, le réseau gâche effectivement la moitié de sa puissance de hash à construire des blocs qui ne contribuent pas à la confirmation des transactions. Un attaquant qui possède des ressources centralisées et ne souffre pas de délais peut mettre en oeuvre une attaque de type 50% avec à peine plus de 33% de la puissance de hash. Ceci parce qu'il peut facilement créer des chaînes plus longues que le reste du réseau (les botnets, qui souffrent de délais internes, sont moins efficaces que les attaquand centralisé).
En utilisant différentes techniques, nous analysons la quantité de blocs qui finissent dans la chaîne et combien en sont écartés, nous utilisons ceci pour estimer les différences de sécurité entre différents paramétrages. Entre autres résultats, nous montrons que transmettre des blocs ne contenant que des hashs de transactions (au lieu de transactions entières) améliorerai grandement la scalabilité (et ce n'est pas simplement une amélioration des performances par deux, mais nous obtenons plutôt une capacité de seize fois plus de transactions par secondes !).
Les modifications du protocole que nous proposons (qui sont au chapitre huit de notre publication) :
Puisqu'un grand volume de transactions impliquent un grand nombre de blocs concurrents, il serait appropriés que les blocs orphelins ne soient pas réellement gâchés. En fait, chaque bloc pourrait être vu comme ne garantissant pas seulement les transactions qu'il contient, mais aussi celles des blocs qui le précèdent. Même si un bloc n'est pas dans la chaîne principale, nous pouvons prendre en compte la confirmation qu'il apporte aux blocs précédents. C'est la base de la modification que nous proposons, nous l'appelons règle de sélection de chaîne "Greedy Heaviest-Observed Sub-Tree" (GHOST).
Grossièrement, puisque chaque bloc contient un hash de son prédécesseur, l'ensemble des blocs forment un arbre ayant pour racine le Genesis Block. Actuellement, Bitcoin choisit l'historique correct comme étant la plus longue (ou plutôt la plus grosse) chaîne de l'arbre. Nous suggérons une autre approche : à chaque séparation, choisir le sous-arbre qui contient le plus de blocks (ou, plus exactement, les blocks présentant la plus grande difficulté combinée). Répéter jusqu'à trouver une feuille. Le chemin traversé est la chaîne que les noeuds devront accepter. Mais en quoi est-ce utile ? Maintenant, un attaquant qui veut changer la chaîne choisit par l'algorithme doit nous faire changer de sous-arbre. Pour ce faire, il doit construire plus de blocs que ceux présent dans le sous-arbre légitime (et pas juste plus de blocs que dans la plus grande chaîne !).
Voici le pseudo-code de la règle de sélection de chaîne GHOST :
1. SET B <- Genesis Block 2. IF B est une feuille : RETURN(B) ELSE : SET B <- fils de B qui a le sous-arbre le plus lourd 3. GOTO 2 
Coût de la modification : Tant que la vitesse de création des blocs est lente et leur taille est petite, il n'y a quasiment pas de différence entre la méthode de la plus grande chaîne et la règle GHOST. Il n'y a pas de coût. Les deux sont quasiment identiques, car dans ce cas, la plus grande chaîne est aussi le plus lourd des sous-arbres. Lorsque les volumes de transactions sont élevés, GHOST construit un peu moins de blocs dans sa chaîne principale (car un nouveau bloc n'étend pas toujours la plus longue chaîne), réduisant ainsi légèrement le nombre de transactions acceptées par seconde, mais il le fait de manière bien plus sécurisée ! Les délais et un grand nombre de blocs orphelins n'augmentent plus la vulnérabilité contre une attaque de type 50%. Cela implique que nous pouvons augmenter la vitesse de création des blocs et la taille des blocs à des niveaux qui étaient auparavant trop risqués et largement compenser la réduction de volume de transactions supporté. À vrai dire, nous estimons que la génération d'un bloc par seconde pourrait mener à des volumes de plus de 200 TPS. Ça permet des temps de validation rapide et, plus important, une amélioration de la granularité des confirmations. Même une seule confirmation donne un certain niveau de confiance quant à la légitimité d'une transaction, ce qui est quasiment instantané quand les blocs sont générés chaque seconde.
submitted by JeanBono to BitcoinFrance [link] [comments]

[Résumé] Sortie de bitcoin-qt 0.8.6

Voici le lien en anglais pour tous les détails : https://bitcointalk.org/index.php?topic=364353.0
Il y a tout un tas d'amélioration techniques, optimisations et bug fix qui feront plaisir à ceux d'entre nous qui font tourner un full-node. Je m'attarderai seulement sur les trois modifications de comportement, qui impactent tout le monde même ceux qui n'utilisent que ds web wallets.
Ces modifications sont décrites un peu plus en détail en anglais ici : https://gist.github.com/gavinandresen/7670433#proposed-086-changes
Fin de la règle des 0.01 BTC minimum pour les transactions gratuites
Avant 0.8.6, lorsqu'on emmettait une transaction avec une sortie de moins de 0.01 BTC, les noeuds bitcoin-qt refusaient de la relayer s'il n'y avait pas de frais de transaction associé. Ça permettait d'éviter qu'un attaquant puisse flooder le réseau en evoyant des milliers de transactions de quelques satoshis.
Le truc c'est que depuis la version 0.8.2, il y a un autre mécanisme pour protéger contre ce type d'attaque, essentiellement les noeuds refusent de relayer les transactions qui comportent des sorties de moins de 5430 satoshis. Et puis 0.01 BTC ça commence à valoir de la thune de nos jours.
Bilans, si vous déplacez quelques vieux mBTC, vous ne serez plus forcés d'y ajouter des frais de transaction pour voir votre transaction se propager dans le réseau.
Augmentation de la taille des blocs minés
La taille des blocs minés par défaut sera plus grande qu'avant. Ce qui devrait permettre plus de transactions par seconde. Bon, la taille des blocs n'est pas beaucoup augmentée et à vrai dire, ce n'est qu'un changement de valeur par défaut, l'option est toujours configurable. Si j'ai bien compris c'est un coup d'essai pour observer l'impact sur le réseau plus que pour changer nos vies.
Ajout systématique de frais de transaction pour les transactions de plus de 1000 octets
Ce n'est une fonctionnalité que du porte-monnaie proposé par bitcoin-qt, pas de changement de comportement du noeud.
Le protocole spécifie que pour pouvoir être gratuite, une transaction doit faire moins de 10 000 octets. 10 000 octets c'est beaucoup, j'ai personnellement pu faire des choses pas conventionelles du tout en moins de 10 000 octets :) Du coup, on va tendre a baisser ce nombre pour 1 000 octets. Maintenant, quand vous enverrez des bitcoins depuis bitcoin-qt, si la transaction créée fait plus de 1 000 octets, l'ajout de frais de transaction sera forcé.
Une transaction gratuite de 10 000 octets devrait donc se propager aussi bien qu'avant, mais ça ne viendra pas d'un utilisateur de bitcoin-qt 0.8.6 ou supérieur. L'idée étant d'éviter qu'un utilisateur ne squat accidentellement une grande partie de la place réservée aux transactions gratuites dans son bloc.
Conclusion
C'était mieux dans le bon vieux temps ou bien bitcoin-qt 0.8.6 c'est l'avenir ? Faites votre choix et upgradez... ou pas :)
submitted by JeanBono to BitcoinFrance [link] [comments]

83jeanluc - YouTube [Tuto informatique#Vidéo N°16] Utiliser la sauvegarde via le cloud Mega LE BITCOIN, C'EST QUOI ? COMMENT EN OBTENIR ? Explication ... VI. 2nde - Solutions et concentration massique Les Périphériques de Stockage Mentent !  Le Stockage de données

Dans le cas du bitcoin, ce sont l’identité (via une adresse mail) du donneur, du receveur et la quantité. Le blockchain fonctionne par validation des blocs , un à un, formant ... Cela se comporte comme des pièces (d’où le terme “coin” de bitcoin) : vous devez donner 5 BTC et indiquer que vous souhaitez que l’on vous rende la monnaie, en précisant sur quelle adresse. Le Bitcoin est une nouvelle génération de monnaie numérique (crypto-monnaie), dont le créateur, selon la version officielle, est Satoshi Nakamoto. Bitcoin est un système de paiement mondial à travers lequel vous pouvez effectuer des transactions avec des frais très bas par rapport à d'autres systèmes de paiement mondiaux et sans intermédiaires sous forme de banques. Cette monnaie est ... Le cours du bitcoin depuis 2009, date de sa création, a connu de nombreux rebondissements. Très volatile, le prix du bitcoin a déjà connu plusieurs pics et corrections. En l’espace de quelques années, le bitcoin est passé de 0,01 à 20,000 dollars. Cet article décrit les grandes étapes du bitcoin depuis sa naissance jusqu’à aujourd ... Le portefeuille Bitcoin contient des clés privées et des adresses publiques et vous donne un accès complet à vos fonds. Si vous souhaitez en savoir plus sur les portefeuilles de crypto-monnaie, consultez ce guide détaillé. Atomic est un portefeuille de bureau et mobile, disponible pour tous les principaux systèmes d’exploitation: Windows, macOS, Linux, Android et iOS.

[index] [4265] [12228] [4269] [32206] [1808] [38573] [18722] [10374] [42551] [6225]

83jeanluc - YouTube

But how does bitcoin actually work? - Duration: 26:21. 3Blue1Brown Recommended for you. 26:21. Solutions et concentrations massiques - Physique-Chimie - Seconde - Les Bons Profs - Duration: 4:46 ... Avoir accès à moins de mémoire que prévu, cela arrive sur n'importe quels supports de stockage : clé USB, disque dur, carte SD ... Mais alors est-ce que les ... Acheter du Bitcoin : https: ... 01netTV est la chaîne vidéo du site 01net.com, leader en France sur la High-tech. Elle est animée par les journalistes François Sorel et Jérôme Colombain ... Révision pour le cours de science et technologie de 4e secondaire pour le chapitre 2 : molécules, règle de l'octet, charge électrique, dissociation électrolytique, solutions, pH. Qu'est-ce que le bitcoin, pourquoi faut-il s'y intéresser ? 🤔 L'ACTUALITÉ, TOUS LES JOURS SUR INSTAGRAM : http://instagram.com/hugodecrypte/ L'ACTUALITÉ TOUS...

#