Aller au contenu

ETH - Ethereum : ICO et Actes sans notariat


Messages recommandés

Je ne sais pas, j'ai l'impression que c'est plus une révolution technique qu'un changement de paradigme pour le moment. Un peu comme l'invention de l'imprimerie n'était au début qu'une solution technique à un ancien problème. On a donc trouvé un moyen d'envoyer des unités de valeur par internet de façon sécurisée et infalsifiable (à priori), peu chère et rapide. Bon, mais je pouvais déjà envoyer de l"argent par Wetern Union, c'est juste moins fiable, cher et pas très rapide.

 

Mais effectivement, je vois beaucoup de gens qui disent ne pas comprendre Bitcoin, alors ils cherchent de l'information et tombent sur des articles techniques qui expliquent le protocole, la cryptographie et tout le toutim. En général ils ont perdu 90% des lecteurs au bout de trois lignes. Alors que si on disait juste "BTC pour le moment, c'est WU en mieux" ça suffirait probablement comme première approche.

 

La chose qui me paraît révolutionnaire et être un vrai changement de paradigme ce sont les possibilités offertes par le protocole: on commence à implémenter des smart contracts, et à parler d'avoir des programmes autonomes sur le réseaux qui servirait à accomplir des transactions. Là c'est mon imagination qui n'est pas assez grande pour entrevoir les possibilités.

 

https://www.ethereum.org/

 

Applications les plus évidentes: DNS décentralisés, contrats de tout types, crowd funding. Déjà rien qu'un DNS décentralisé, ça serait révolutionnaire pour internet.

Lien vers le commentaire

Applications les plus évidentes: DNS décentralisés, contrats de tout types, crowd funding. Déjà rien qu'un DNS décentralisé, ça serait révolutionnaire pour internet.

Il y a aussi le vote démocratique vérifiable sans briser l'anonymat (en y réfléchissant un peu, je pense que le protocole doit le permettre), le suivi de propriété (immo, contrats par exemple).
Lien vers le commentaire
  • 2 months later...

Apparemment, Ethereum serait encore mieux que Nxt par une approche plus générale, le développement est pour l'instant moins avancé mais il a le soutien de quelques grands noms. On pourrait construire dessus des applications décentralisées de toutes sortes, oů le portefeuille deviendrait un navigateur "Web 3.0". Les perspectives sont gigantesques !

Lien vers le commentaire
  • 1 year later...

Je reste sur Bitcoin. Avec les petites montagnes russes du cours, je réalise des plus values impossible à atteindre avec des actions.

Ethereum, comme Ripple, je m'en méfie comme la peste, je n'ai aucune confiance. Cela dit, avec la disparition probable du cash et la volonté de "réguler" Bitcoin et les autres cryptos libres (entendre "interdire"), Ethereum et Ripple seront sans doute, parmi les rares cryptos à subsister.

Lien vers le commentaire
  • 2 weeks later...

Euh.. une blockchaine décolera justement par l'usage qu'en feront les développeurs, et pour ce qui est d'Ethereum c'est vraiment très très simple à programmer car basé sur du Javascript. La preuve c'est qu'il y a déjà des ateliers sur Meetup. Le jour ou tu verras un workshop NXT ou un autre pour forker Bitcoin fais-moi un signe ;)

:D

 

J'ai participé à un meetup et un hackathon Ethereum... il y a plus d'1 an, quasi 2 ans si ma mémoire est bonne. Pour ne plus jamais y remettre les pieds.

 

À l'époque ce n'était pas du JavaScript: ils avaient réinventé la roue en créant leur propre langage de script. Je m'étais dit que c'était complètement con et que ça ne marcherait jamais s'ils n'utilisaient pas un langage existant (JavaScript, Lua, Python, etc.). Depuis il y a eu beaucoup de drama, plus de la moitié de la communauté s'est barrée, d'autres sont venus. Enfin bref, c'est typiquement le projet open source où les leads souffrent du syndrome NIH, ont un égo qui ne tient pas dans la salle et sont persuadés qu'ils savent tout mieux que tout le monde.

 

Sur le principe, je suis persuadé qu'on aura une blockchain programmable dans un futur proche, mais de là à miser mon argent sur ETH.... :D

 

Je veux bien des détails.

Aux Pays-Bas j'ai pu acheter mes premiers BTC en 24 heures: c'est du même niveau de difficulté que de créer un compte Paypal. Je suis allé chez Bitonic et j'ai utilisé iDeal, un système de paiement en ligne utilisable avec toutes les banques néerlandaises. Ça prend 24 heures uniquement parce que la première transaction, comme pour vérifier un compte Paypal, est une fausse transaction de 1 euro qui permet de vérifier le compte en banque: à l'époque c'était fait à la main chez Bitonic, mais ils répondaient dans les 24 heures. Ensuite une fois la première transaction confirmée, il suffit d'aller sur le site, entrer le montant de BTC, son adresse de wallet, payer avec iDeal, et les bitcoins sont livrés dans les 10 minutes.

Lien vers le commentaire
  • 3 months later...

Bah si.

 

Déjà +142% pour TheDAO depuis son plus bas du jour.

Mais je pensais à BTFD Ethereum plutôt (reloadé à $17 et $13 :jaifaim:

S'il y a un hardfork pour revenir au bloc ~1760000, je vois mal comment tu vas conserver ce que tu as acheté.
Lien vers le commentaire

Il y a aussi un "The contract appears "too big to fail". All smart contracts are not equal." :D

Quelqu'un répond assez justement en disant que les mineurs ont le pouvoir d'appliquer ou non les fork

Pour un réseau qui se voudrait PoS, c'est un peu raté :(

et je pense qu'ils ne le feront pas, ou de façon exceptionnelle, au risque de voir la crédibilité du réseau et donc la valeur des coins s'effondrer.

oui ou le contraire... Pour le moment, on ne sait pas ce que ça va donner. Mais c'est clair que s'ils rollback, ça promet quelques jeux de jambes rigolos.
Lien vers le commentaire

Pour un réseau qui se voudrait PoS, c'est un peu raté :(

 

Ethereum est PoW, il faut attendre la sortie de Casper pour les deposit bets et le PoS.

Introducing Casper "the Friendly Ghost"

 

 

oui ou le contraire... Pour le moment, on ne sait pas ce que ça va donner. Mais c'est clair que s'ils rollback, ça promet quelques jeux de jambes rigolos.

 

Disons que les nodes prendront les décisions qui servent leurs intérêts tandis que les developpeurs et les investisseurs tenterons de les influencer.

 

D'ici là il pourrait bien y avoir une alternative* https://www.reddit.com/r/ethereum/comments/4oj7ql/personal_statement_regarding_the_fork/d4d1vir

 

(*) surement ça qui refait plonger Ether

 

BTFD

Lien vers le commentaire

Même le softfork est contestable. Si les devs ont le pouvoir de freezer une adresse alors les flics iront les voir dès qu'il veulent saisir des fonds.

 

Je suis tombé sur ça sur Twitter :

"Apparemment les smarts contracts sont comme les autres contrats, personne ne les lis avant de signer." :D

 

Cette histoire met en question tout l'intérêt des smart contract. A terme il faudra des gens qui étudient les smart contract avant qu'ils soient utilisés et qui attestent de leur sécurité (cela a été fait avec la DAO mais apparemment les gens n'étaient pas assez bons), ce qui revient à faire confiance à ces gens-là. Au final c'est déjà ce qu'il se passe avec les contrats où il faut l'aide d'un avocat pour en avoir un solide.

Mais au moins avec un contrat traditionnel le système judiciaire est là en back up, alors qu'avec un smart contract s'il y a un problème il n'y a plus aucune marge de manoeuvre.

Lien vers le commentaire

Ethereum est PoW, il faut attendre la sortie de Casper pour les deposit bets et le PoS.

Introducing Casper "the Friendly Ghost"

Dans "Pour un réseau qui se voudrait PoS", souligne le verbe au conditionnel et discutes-en avec ton voisin.

 

Disons que les nodes prendront les décisions qui servent leurs intérêts tandis que les developpeurs et les investisseurs tenterons de les influencer.

Ce qui ne change rien à la remarque : en cas de fork, Ethereum perd une bonne partie de sa crédibilité de principe.

 

Ce serait mieux qu'un fork, indubitablement.

A terme il faudra des gens qui étudient les smart contract avant qu'ils soient utilisés et qui attestent de leur sécurité (cela a été fait avec la DAO mais apparemment les gens n'étaient pas assez bons), ce qui revient à faire confiance à ces gens-là. Au final c'est déjà ce qu'il se passe avec les contrats où il faut l'aide d'un avocat pour en avoir un solide.

... et réintroduire des tiers de confiance dans un système construit pour s'en passer au départ. C'est une superbe victoire.
Lien vers le commentaire

Il y avait un avocat qui participait au meetups Ethereum au début, c'était assez marrant de voir le fossé d'incompréhension avec les développeurs. Les smart contract n'ont vraiment rien de "smart" et posent exactement les même problèmes que n'importe quelle implémentation de logique métier dans une application "traditionnelle". À savoir:

 

- il faut un expert métier sous la main pour expliquer les règles métier. Donc dans ce cas, un spécialiste du droit, plus éventuellement un spécialiste du domaine concerné.

- faire coucher sur papier les règles métier à l'expert est loin d'être simple: c'est même tellement compliqué qu'on créé tous les 2 ans des méthodes pour le faire correctement, et il y a des bouquins entier là dessus.

- implémenter ces règles est loin d'être simple: il y a d'abord les problèmes de compréhension, les ambiguïtés, et puis enfin les erreurs d'implémentation.

- ensuite il faut valider que ce qui a été implémenté correspond aux spécifications.

- et enfin il faut valider qu'il n'y a pas de failles de sécurité dans l'implémentation.

 

Je n'ai pas suivi l'affaire mais je viens de lire le  dernier blog d'Ethereum, et voici ce qu'ils disent:

 

The attack is a recursive calling vulnerability,where an attacker called the “split” function, and then calls the split function recursively inside of the split, thereby collecting ether many times over in a single transaction

 

 

Donc visiblement c'est une faille de sécurité dans l'implémentation. D'ailleurs c'est marrant comme faille, ça me rappelle un peu les fork bomb:  https://en.wikipedia.org/wiki/Fork_bomb

 

Techniquement je note deux choses: il n'y a pas de garde-fou contre ce genre d'exploit dans la machine virtuelle Ethereum, et la sécurité repose sur un suivi scrupuleux des bonnes règles de programmation Ethereum de la part des développeurs.

 

Donc ils expliquent ici qu'ils ont créé un outil pour scanner les contrats déjà implémentés, et sans surprise:

 

To cut to the chase, it will turn out that the majority of Ethereum contracts indeed ignore the best-practice recommendations. Clearly, the Ethereum community has yet to solve this problem. At the end, we make some recommendations for how to remedy this situation.

 

 

D'expérience je sais une chose: leur "solution" n'en est pas une et ne fonctionnera pas car tant que la sécurisation des contrats reposera sur les développeurs de contrats il y aura toujours des failles de sécurité. En gros j'ai l'impression que les mecs ne vont pas tarder à redécouvrir pourquoi on a inventé Java pour remplacer le C.

Lien vers le commentaire

En gros j'ai l'impression que les mecs ne vont pas tarder à redécouvrir pourquoi on a inventé Java pour remplacer le C.

... sans succès, du reste. Les failles dans les applis java, y'en a aussi pléthore.

Ontologiquement, il n'existe aucune solution à ce problème.

Lien vers le commentaire

... sans succès, du reste. Les failles dans les applis java, y'en a aussi pléthore.

Ontologiquement, il n'existe aucune solution à ce problème.

Je suis d'accord qu'il n'existe aucune solution, mais pas sur le fait que Java n'est pas un succès: ce langage évite toute une classe de problèmes qui ont fait les beaux jours des personnes malveillantes. Pas de buffer overflow, pas de problèmes de déréférencement de pointeurs qui mènent à des segfault et des possibilités d'exploit, plus le fait que la VM peut-être sandboxée pour limiter l'accès aux fonctions potentiellement dangereuses (lecture de fichiers, etc.).

 

Les failles sont dues aux développeurs d'applications, ce qui milite pour éviter de donner trop de corde pour se pendre aux développeurs.

Lien vers le commentaire

Je suis d'accord qu'il n'existe aucune solution, mais pas sur le fait que Java n'est pas un succès: ce langage évite toute une classe de problèmes

Oui bon certes, mais ce n'est pas tout à fait ce que j'ai écrit. Java résout certains problèmes, en laisse d'autres, et en crée de nouveaux (en terme de complexité, par exemple, d'accès au matériel, etc...) ; des failles de sécu dans la VM Java, y'en a régulièrement par exemple.
Lien vers le commentaire

Les failles sont dues aux développeurs d'applications, ce qui milite pour éviter de donner trop de corde pour se pendre aux développeurs.

... ben oui mais à la fin, il faut bien que quelqu'un programme quelque chose quelque part. Pour le moment, les IA ne programment pas tout, et pour en revenir aux smart contracts, ce sont toujours des humains en bout de chaîne.

D'ailleurs, quand on voit les classes de problèmes soulevés dans les smart-contracts (exemples ici : https://www.reddit.com/r/ethereum/comments/4omdlf/to_kickstart_the_building_safer_smart_contracts/) on se dit qu'il n'y aura pas de solution simple, élégante et rapide.

Lien vers le commentaire

Oui bon certes, mais ce n'est pas tout à fait ce que j'ai écrit. Java résout certains problèmes, en laisse d'autres, et en crée de nouveaux (en terme de complexité, par exemple, d'accès au matériel, etc...) ; des failles de sécu dans la VM Java, y'en a régulièrement par exemple.

Oui il y a eu des failles dans la VM mais l'important c'est que ces failles sont corrigées par des experts, testées par une équipe QA professionnelle, et qu'il suffit de mettre à jour la VM pour profiter des correctifs: c'est bien préférable à devoir corriger des milliers de programmes qui sont dans la nature avec des failles car il ne respectent pas les "bonnes pratiques" de programmation.

 

Ensuite je ne pense pas que Java crée de la complexité: c'est juste que les problèmes d'aujourd'hui sont plus complexes que les problèmes d'il y a 20 ans. Parmi les premières applications que j'ai écrit, il en avait une qui était un jeu concours où les gens pouvaient entrer leur email, nom et prénom dans un formulaire, le formulaire était envoyé à un CGI en Perl qui sauvegardait la liste dans un fichier CSV en clair, puis il y avait un Cron en Bash qui envoyait la liste au responsable tous les matins. C'était ça, le genre de problème à résoudre à l'époque. Aujourd'hui c'est... un peu plus compliqué et le niveau d'exigence à changé :)  Donc forcément on a besoin d'outils plus complexes à maîtriser.

 

... ben oui mais à la fin, il faut bien que quelqu'un programme quelque chose quelque part. Pour le moment, les IA ne programment pas tout, et pour en revenir aux smart contracts, ce sont toujours des humains en bout de chaîne.

D'ailleurs, quand on voit les classes de problèmes soulevés dans les smart-contracts (exemples ici : https://www.reddit.com/r/ethereum/comments/4omdlf/to_kickstart_the_building_safer_smart_contracts/) on se dit qu'il n'y aura pas de solution simple, élégante et rapide.

Non il n'y pas de solution simple et élégante, mais ce n'est pas une raison pour partir sur une "solution" qui a déjà été un échec par le passé: faire une liste de tous les problèmes et définir une liste de bonnes pratiques pour éviter ces problèmes a un gros air de déjà-vu. Il y a une littérature abondante sur ce qu'il ne faut pas faire en C, pourtant les mêmes erreurs ont été commises encore et encore. En Java aussi on a notre top 10: https://www.owasp.org/index.php/Top_10_2013-Top_10, pourtant ces erreurs sont commises encore et encore...

 

Ensuite quand je vois ceci, j'ai vraiment envie d'insérer une image de petit chat qui se facepalm:

https://www.reddit.com/r/ethereum/comments/4omdlf/to_kickstart_the_building_safer_smart_contracts/d4e3nzq

 

Laisser les développeurs gérer eux-même les cas limite sur des transactions et espérer que ça va bien se passer, c'est juste ne tenir aucun compte de 40 ans de retour d'expérience en ingénierie logicielle. Alors oui c'est vrai que les solutions des serveurs applicatifs pour gérer des rollbacks sur des transactions sont complexes, mais c'est parce que c'est un problème intrinsèquement compliqué (quoique de nos jours avec de l'event sourcing c'est plus simple). Ces problèmes de balance de compte ne devraient pas être de la responsabilité du développeur mais gérés automatiquement par la VM Ethereum, c'est ça la bonne pratique validée.

 

Parce qu'on sait d'expérience que si on laisse les développeurs gérer cette complexité "à la main", il y aura des failles, et ces failles seront exploitées tôt ou tard.

Lien vers le commentaire

Je suis d'accord qu'il n'existe aucune solution, mais pas sur le fait que Java n'est pas un succès: ce langage évite toute une classe de problèmes

L’existence même de java est un problème en soit :lol:

Et il est bien plus susceptible que le C a certaines classes de problèmes (deserialisation par exemple, récemment illustré dans jboss, weblogic etc.).

La seul protection efficace de java c'est que c'est tellement pénible a lire que personne ne veut aller y chercher des bugs (je profite que neuneu2k soit parti pour taper sur java  :ninja: ).

 

Quand a la VM java elle même, c'est probablement le software qui a eut le plus de trou de sécurité de l'histoire (avec flash peut etre), au point qu'une 0day java ne vaut plus rien tellement tout le monde en a tout le tour du ventre.

Pour Ethereum on savait qu'il y aurait des bugs dans les contrats, si on veut un minimum de flexibilité dans le langage qui les décrit c'est inévitable.

  • Yea 1
Lien vers le commentaire

Oui il y a eu des failles dans la VM mais l'important c'est que ces failles sont corrigées par des experts, testées par une équipe QA professionnelle, et qu'il suffit de mettre à jour la VM pour profiter des correctifs: c'est bien préférable à devoir corriger des milliers de programmes qui sont dans la nature avec des failles car il ne respectent pas les "bonnes pratiques" de programmation.

Si tu utilise java, tu sais que tu es vulnérable au gazillion de 0day qu'il y a dessus.

Si tu utilise apache ou openssh, tu utilise un programme battle-tested écrit par des gens avec un cerveau, et tu as l'esprit plus tranquille.

  • Yea 1
Lien vers le commentaire
Side Chains are Superior

A side chain is nothing more than a smart contract with a proper governance model. One or more people are selected to evaluate inputs to the contract and generate signed messages that cause the desired effect within other chains.

If The DAO were a Side-chain, then the DAO token holders would elect curators who would interpret the rules of The DAO and then sign messages to initiate payments to the desired contractors. If a bug were found in the implementation of The DAO’s interface, then the curators could update their code.

Assuming the rules of The DAO Sidechain allowed ample time to review the outputs for potential bugs, then everyone could rest assured that no money would escape without adhering to the intent of the DAO.

 

 

Par le créateur de Bitshares (qui s'y connait en DAO)

 

https://steemit.com/ethereum/@dantheman/ethereums-not-so-smart-contracts

Lien vers le commentaire

:D Jubal arrête de me troller: c'est trop gros ça passera pas. À moins que tu ne cherches à faire revenir neuneu2k.

 

Mais revenons au sujet.

Pour Ethereum on savait qu'il y aurait des bugs dans les contrats, si on veut un minimum de flexibilité dans le langage qui les décrit c'est inévitable.

Je me demande bien qui est ce "on" : les concepteurs? Les gens qui ont investi de l'argent dans Ethereum? Les utilisateurs du réseau?

 

Est-ce que du coup ils ont fait faire des audits du code par des tiers?

 

Moi je maintiens tout ça pue le défaut de conception à 100km, le genre de problème qui ne sera pas corrigé sans un changement majeur du langage et de la VM Ethereum.

Lien vers le commentaire

A lire : https://www.reddit.com/r/ethereum/comments/4opjov/the_bug_which_the_dao_hacker_exploited_was_not/

Complexity and "Turing completeness" are not the real culprit here - those are all good things that we can have someday. The real culprit is poor language design. Specifically, I would recommend using "functional" (rather than "procedural") languages for mission-critical code which will be driving "smart contracts" - and even better if a high-level "specification" language could be used, allowing formal derivation of a (verifiably correct) program in a low-level "implementation" language (ie, providing mathematical proof that the implementation satisfies the specification - and mitigating the problem where the high-level human-readable "description" is different from the low-level machine-runnable "code"). I suspect many people (raised in a world where JavaScript is the "assembly language of the web") might not know about some of the history and possibly related work. So take this as a stern lecture telling you to take a good look at the history of functional languages (and specification vs implementation languages) as used in mission-critical projects, including finance - which, even when using such tools, are still very hard to get right - as we can see from the decades-long history of failures of major projects in defense, healthcare, aerospace, etc.

Ça rejoint les remarques d'autres ci-dessus (notamment Jubal et moi).

Lien vers le commentaire

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...