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Ă©rera une 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 logo est 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
λ Interface de création de contrat createcontract
λ Interface de déploiement de contrat deploycontract
λ Interface d'ajout ABI addcontract
λ Interface dâappel des contrats avec lâopĂ©ration des fons sendtocontract
λ Interface de lecture des informations sur les contrats  callcontractfunc
λ 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.












