Code Solidity Ethereum - Possibilités et limites (contraintes)
-
Bonjour à toutes et tous,
J’ouvre cette page de discussion car n’étant pas moi-même développeur, je cherche à mieux comprendre les limites et contraintes technique de cette nouvelle technologie si prometteuse.
Je sais qu’il est possible de coder des smartcontracts standards types ERC20 mais serait il possible d’en créer sans limite de token (possibilité d’en créer au fur et à mesure de la demande) ?
Il est surement aussi possible de créer des smartcontracts plus uniques et adaptés à chaque projets mais comment mettre en relation ce deuxième contrat et un ERC20 crée préalablement (personnel ou déja existant type Bancor ou autre) . Est ce même possible ?
J’ai pas mal d’autres questions, le but final est de créer un projet innovant sur la Blockchain Ethereum mais vous devez vous en douter
Merci à la Cryptocommunauté !!!
-
Bonjour,
oui et oui. Malheureusement l’explication se trouve dans le code … et si tu souhaites faire un projet dans le domaine informatique, sans forcément chercher à devenir expert, tu auras besoin d’apprendre (don’t trust, verify).
Tu peux commencer par lire https://solidity.readthedocs.io/en/v0.4.20/ si tu souhaites attaquer directement par le langage propre à ethereum, mais ce n’est pas vraiment destiné à des novices. Des langages tel que le javascript ou le python, au travers des nombreux tutoriels disponibles sur internet, te permettrons d’acquerir ces bases.
Bonne quête!
-
Bonjour,
Vous devez comprendre que solidity peut permettre de faire énormément de choses, mais sans notion de programmation ça va être difficile pour vous.
Créer un token, c’est simplement garder une liste de gens avec leur solde (nombre de tokens possédés) et des méthodes pour qu’ils puissent se les envoyer. Donc le nombre de tokens peut croître indéfiniment.
Un bon moyen de comprendre les bases :
Les vrais contraintes sont plutôt de l’ordre suivant :
-
l’argent peut seulement être reçu par le contrat, il ne peut jamais aller le chercher. (Je peux faire un contrat qui envoie la moitié de toute somme qu’il reçoit à A et l’autre moitié à B, mais on ne peut pas écrire de contrat qui prenne tout l’argent de celui qui l’appelle).
-
L’exécution du code coûte assez cher et la mémoire aussi.
Il faut essayer de mettre hors ligne tout ce qui peut l’être sans affecter la sécurité. -
Pas de source d’aléa (le mineur peut modifier le résultat). Il vaut mieux utiliser un système de génération hors-ligne - engagement - révélation.
-
Par défaut, une fois déployé, le code n’est pas modifiable.
-