Oubliez bitcoin ! Oubliez Ethereum ! Oubliez tous les autres coins ! La révolution blockchain ne portera qu'un nom, celle de PipedPiperCoin

Toutes les infos sont disponibles ici : http://www.piedpiper.com/ et ici : https://twitter.com/piedpipercoin

Ce coin est LE coin qui marquera un tournant dans la révolution blockchain. J'ai déjà revendu tous mes autres coins pour faire un all-in dans $PPC. Ceux qui en auront acheté peuvent être certains d'être cryptogazillionaires dans moins d'un an. TO THE MOOOOOOOOOOON !

Le whitepaper arrive, la team est en train de le finaliser, cependant vous pouvez voir que niveau team c'est du solide sur le site ! Je ne vois pas comment ce coin peut échouer avec de tels talents !

Charlie lee sera surement un des advisors du coin : https://twitter.com/SatoshiLite/status/993895738428936194
Un partenariat avec bitconnect est déjà en négociation, une floppé d'exchanges sont à l'étude ( sauf bittrex )  et le coin pourra bientôt être suivi sur blockfolio ! (https://twitter.com/BlockfolioApp/status/994361624398970880)

Je ne vois pas ce qu'il vous faut de plus pour courir investir dans ce coin qui est assurément le coin du futur !


EDIT : je met le lien vers le thread original : https://bitcointalk.org/index.php?topic=3660872.0



C'est un coin humoristique hein. PiedPiper est une société fictive issue de la série Silicon valley. Le coin est probablement fictif ou s'il existe fera probablement l'objet d'un pseudo airdrop. Par contre je pense qu'on peut dire chapeau aux CMs et marketeux de la série qui reprennent tous les éléments que l'on retrouve dans la communauté. Checkez le compte twitter, ca vaut le coup d'oeil : Tron en prend pour son grade sur les WP, Roger Ver se fait troller sur bcash et le fait de sauver les bébés, Tether sur le pump du prix du coin. Je vous laisse apprécier  

En l'état des choses, je ne pense pas. Dans quelques dizaines d'années, quand les écosystèmes issus de la blockchain auront muris et que tous les acteurs de la société intéragiront avec ces écosystèmes ( parfois sans le savoir ou sans y préter attention ), alors peut-être.

Je pense qu'aujourd'hui, même les plus libertariens tiennent quelque part à la survie du contrat social, et donc à une forme d'existence de l'état. Cela peut paraitre stupide de prime abord, mais je serais curieux de rencontrer quelqu'un qui serait prêt à échanger du titre de propriété mobilier sans l'intervention d'un représentant d'un consensus général de procédure, a.k.a l'état à travers le contrat social.

Aujourd'hui, nos transactions sur blockchain, que ce soit pour des transactions simples, ou des transactions régit par des rêgles dans un smart-contract, ces transactions se font par une simple clé privée, qui, si elle nous appartient, peut nous être dépossédée ( vol des clés ).

Si demain M. Dupont te vole les clés de ta maison et transférer le titre de propriété de ta maison à quelqu'un d'autre, il a fort à parier que tu broncheras, que beaucoup broncheront, libertariens inclus.

Aujourd'hui, et en l'état, pour transférer ce titre de propriété, le notaire qui représente l'état, et donc le contrat social, permet d'assurer par une procédure qu'aucune blockchain n'est aujourd'hui en mesure d'assurer, que cette transaction est légitime et que le propriétaire agréer bien à la transaction. De même, en cas de transaction frauduleuse, la transaction peut être considérée comme annulée, chose impossible sur une blockchain ( si on omet les forks ).

Cette procédure inclus la vérification de l'identité d'un individu avec une garantie telle, qu'un simple jeu de clé et de signatures cryptographiques ne peut pour l'instant pas assurer.

Tu peux te faire voler les clés de ta maison et la copie de ton titre de propriété, tu restes M. Tartampion. Les vecteurs te permettant de prouver que tu es bien toi sont infiniment plus nombreux qu'une transaction disant "le portefeuille 0x02393F9382FD9CD9 à bien signé sa transaction". La preuve, il est plus difficile de te faire passer pour quelqu'un d'autre auprès de services publics que d'avoir 10 wallets sur ta machine

J'ai pris l'exemple tu transfert de propriété car il est le plus parlant je pense. Bien évidemment, on pourra arguer du fait que pour des transactions moins critiques, le notaire n'est pas forcément une nécéssité absolue. Et c'est probablement vrai. D'ailleurs, certains en sont assez persuadés pour avoir tenté de commencer à faire bouger les choses. Je pense au projet mort-né de Notary-Platform qui justement voulait récupérer progressivement une partie des activités notariées ( sur le long terme ).

Enfin, je ne dis pas que ce jour ne viendra pas, mais l'incorporation des technologies blockchains actuelles et futures devra être bien plus poussée qu'elle ne l'est actuellement ou dans un horizon proche afin de pouvoir faire bouger ce pré-carré, hautement représentatif de la notion de structure d'état ( je ne parle pas de gouvernance mais pense plutôt à la notion d'institutions ). Quand ça arrivera, cela voudra dire que quasiment toutes les strates de la société, état et gouvernance compris auront dans leur fonctionnement même implémentés les registres distribués.

EDIT :

Je rajoute un lien en edit de ce post pour partager une URL qui devrait plaire à pas mal de monde ici :
 
https://ethresear.ch

Ce forum est le point central de réfléxion et de recherche des différentes évolutions et perspectives possibles pour Ethereum ( Casper, Abstraction de signatures, etc. ). Des topics y sont régulièrement créés afin de mener des réfléxions sur l'impact du registre distribué d'Ethereum, assez souvent en dehors même de la considération technique. Je pense que c'est une bonne source pour y trouver des idées, des perspectives eventuelles des toutes les ramifications et changements que peut apporter la blockchain dans la société, au dela de la chaine ETH elle-même.

Bonne lecture

EDIT 2 :

A la relecture, je complète un petit point : Cette incorporation et la disparition du métier de notaire ne se fera bien évidemment pas d'un bloc d'un seul. Notary-Platform l'avait bien compris. Ce sera quelque chose de progressif, comme le développement, déploiement et l'évolution des protocoles réseaux l'ont été et le sont toujours. C'est notamment pour cela que ce projet avait pour but de d'abord cibler le c2c ( particulier à particulier ) puis le b2b avant de cibler les contrats exclusifs au notariat.

Effectivemment, scam potentiel. Une rapide recherche sur google donne différents résultats d'annonces douteuses dans différents secteurs :

https://www.competauto.com/annonce-sport-auto-21190.htm&tellafriend=1

https://webcache.googleusercontent.com/search?q=cache:gGM8g6uO7-QJ:https://www.classifiedads.com/financial_services/9dx6x4jd21213+&cd=13&hl=fr&ct=clnk&gl=fr

https://webcache.googleusercontent.com/search?q=cache:6lygzTKhXsIJ:https://www.adpost.com/us/business_opportunities/1112117/+&cd=11&hl=fr&ct=clnk&gl=fr

avec des localisations aux U.S. Douteux, donc, et méfiance, par conséquent.

concernant OVH on parle d'un des plus gros data centers et du 3e hébergeur mondial avec à la clé des dizaines de milliers d'instances VPS, des milliers de serveurs dédiés et mutualisés, des points de relais CDN sur lesquels s'appuient de très grosses entreprises.

En terme d'enjeu, même si Kraken reste un gros player, OVH en est un encore plus gros puisqu'on parle carrément d'infrastructure internet là, pas d'un problème de système localisé. Donc si OVH peut communiquer avec tant de clarté, Kraken aurait pu faire en sorte d'en faire au moins un dixième de ce qu'a fait OVH niveau transparence et communication. Et ce, sans pour autant prendre le risque de compromettre quoi que ce soit, si ce n'est compromettre l'élan de FUD.

De toutes façons, le mal est fait, et ce fail laissera des marques. Esperons que désormais il y ait des têtes qui tombent au niveau management et direction, non pas pour faire plaisir à la foule en colère, mais pour mettre en oeuvre une restructuration de celles-ci afin de mettre à la place des gens compétents, avec une vision de rigueur qui sauront constituer les process nécéssaires pour qu'un tel évenement ne puisse jamais se reproduire.

Certes, mais l'idée etait plus de donner un élément de comparaison. Et bien que Klaba ait 25 ans d'ancienneté, il n'y a pas besoin d'une expérience faramineuse pour être capable d'anticiper les besoin de ce type de déploiement. N'importe quel développeur ayant eu à bosser dans un environnement corpo pendant en un an serait capable de le décrire.

Pour ceux qui ne le savent pas Octave Klaba, PDG d'OVH, avait eu l'intelligence de communiquer avec une transparence sans faille lors d'une panne massive d'un de leurs datacenters. Plusieurs arrivées de courant avaient pété ( indépendant de leur volonté ) et certains fichiers de configuration avaient été perdus.

Il a communiqué sur l'avancement des travaux de restauration, au fil de l'eau, en donnant des informations précises et en fournissant les éléments techniques de chaque aspect de la restauration.

Le résultat c'est qu'il a été salué et qu'il n'y a eu aucune perte de confiance de la part de ses clients.

Ici, avec Kraken, qui certes n'est pas un hébergeur, mais reste quand même un gros player avec des sommes conséquentes en jeu, c'est que nous avons une communication quasi-inexistante.
Bien qu'il soit évident qu'ici les clients, n'étant pas forcément des techos, n'auraient pas besoin de tous les détails techniques, la communication, non contente d'être vague ( délais, problèmes rencontrés ), est trop rare dans un moment comme celui-ci.

Ce problème est la quintessence d'un problème de fond qui traine depuis trop longtemps. La société Kraken n'a que trop peu communiqué sur leurs problemes de scalabilité, leur roadmap et les évolutions à venir.

De même, l'annonce de la MaJ a été faite n'importe comment, annoncée publiquement quelques heures seulement avant le début de celle-ci, et en pleine nuit.

Du pur délire. Déjà rien qu'en externe ca ne me donnerait pas envie de faire partie des associés de cette boite, mais alors en interne ca doit être encore plus inquiétant....

EDIT : oui, il y a une part de frustration dans mon message. Cependant au delà de la frustration de voir mes fonds bloqués, il y a aussi une part d'effarement face à des aspects qui font partie de mon secteur d'activité ( développement logiciel & management de projet ). Cet effarement est dû au manque criant de rigueur dans des process aussi importants mais également dans le fait que pour avoir de tels trous, il doit y avoir un manque d'investissement criant sur ces aspects.

Je te l'échange contre un sandwich au thon périmé, ça te va ?

Effectivemment, 24h de délai pour faire une mise à jour...c'est même plus long, c'est qu'ils ont un vrai problème de structure en interne !

Il n'y a pas très longtemps j'avais tenté d'expliquer en quoi développer et maintenir une telle plateforme n'etait pas forcément ce qu'il y a de plus évident, surtout quand on est pas vraiment un new player, mais là c'est difficilement défendable.

Une mise en prod, dans toute société dont l'existence dépend fortement de ses capacités IT, ne devrait jamais jamais jamais se passer de la façon dont elle s'est passée hier.

Une mise en prod normalement ca devrait être quoi ?

1) Un recettage des évolutions sur un environnement de test
2 ) des tests manuels & automatisés, des tirs de performance sur un environnement de test puis sur un environnement de préprod ( environnement iso à la prod ).
3 )  La création d'une instance de la version actuellement déployée pour rollback en cas d'incident de mise en prod.
4 ) La mise en place de la nouvelle instance de prod, attente que tout soit lancé, commissionnement sur le réseau de prod et décommissionnement de l'ancienne version.

Là, hier, ils en sont arrivés à faire des tests pendant le déploiement, ce qui est parlant de trous béants dans leur process de production. Ce n'est vraiment, mais vraiment, pas rassurant....d'autant plus que leur communication est très très limitée.

On est loin du professionnalisme d'un Octave Klaba. Quand on sait les sommes en jeu...ils ont de sacrées questions à se poser.

Je ne suis pas là pour shill des coins. Mes investissements sont sur des coins qui ont déjà été shill et pour lesquels j'estime que mon propos n'aurait pas d'apport particulier. Je ne suis pas vraiment là pour dire "ACHETEZ CI ! ACHETEZ CA !".

Je n'ai jamais pensé que seule la techno donnait de la valeur à un produit ou un service et je n'ai en soi rien contre le marketing de produits ou service, si tant est que celui-ci est utilisé à bon escient.

Par contre, ce qui me gonfle un peu, effectivemment, c'est de voir le nombre de coins qui ne se donnent même pas la peine de tenter d'apporter quoi que ce soit à l'écosystème, à l'enrichir et dont la seule existence et le seul interêt est juste un packaging sans rien dedans.

Un bon produit ou service doit répondre à mon sens à un équilibre entre un apport technique et technologique sur une problématique précise et donnée, une roadmap claire et transparente et un marketing construit autour de cela, capable de mettre en avant ces apports, donner envie au "consommateur" sans pour autant trop en faire.

Alors oui, quand je vois des coins comme MacronCoin qui ne sont rien d'autre que de simples forks de projets déjà existant avec un beau titre putaclic et que je vois des gens s'étonner de voir le projet finir dans les limbes de l'histoire, je reste plus que circonspect et perplexe.


EDIT : bien évidemment, tout le monde à le droit de spéculer et chacun fait comme il veut. Je n'ai rien contre l'aspect spéculatif du libre marché des crypto-monnaies, mais c'est comme pour tout, point trop n'en faut, et trop de spéculation peut finir par tuer la spéculation. Quand on voit la capitalisation de certains projets qui n'ont rien d'autre qu'un logo, 3 bouts de codes dégueulasses et du spam sur les réseaux sociaux, on se dit que certains vont se manger de sacré retours de baton à vouloir mettre leurs sous dans tout et n'importe quoi sans regarder ce qu'ils achètent.

Tu dois pouvoir le faire sur MeW. Avant d'envoyer une transaction, MeW t'affiche en général le json qui va être envoyé, en regardant dans les champs du json je suis presque persuadé qu'on y trouvera le fameux nonce.

Token Factory spécifie être en alpha, c'est à dire que leur service est encore en développement. L'outil créée probablement des tokens qui sont reconnus comme compliant ERC20, c'est à dire que le token implémente les noms de fonctions attendus pour un token ERC20, mais cela ne veut pas dire que le contenu des fonctions/méthodes soient correct.

Si tu n'as pas écrit une ligne de code de ces smart-contracts, et que le code que j'ai inspecté plus tôt est intégralement généré par tokenfactory, alors ca veut dire que l'outil pour l'instant ne génére que des tokens inamovibles, sans aucune instruction de transaction dans les méthodes générées.

Pour faire plus clair : ton outil ne sert à rien pour l'instant si ce n'est faire mumuse et générer des tokens dans le vent. L'utilité viendra peut-être plus tard, mais il est clair que ce service en est encore à l'état de R&D.

En même temps vous vous attendiez à quoi ?
Je sais pas si ça a financé sa campagne, et à vrai dire j'en doute. Je pense surtout que ça à permis au dev de se faire la main et/ou étudier du code pour créer sa propre instance de blockchain pour pas cher en vendant son test aux couillons qui y ont encore vu une poule aux oeufs d'or.

Il s'agissait probablement de surfer sur un phénomène d'actualité combiné : blockchain, elections, ICO, Macron, et d'en tirer tout le profit possible.

A ceux a qui il reste de cette bouse entre les mains, faites une croix sur le fait de voir ce truc fonctionnel un jour, de voir des implémentations interessantes.

Au moins ca vous rappelera un truc : à force d'investir et d'acheter tout et n'importe quoi, vous finirez par y perdre des plumes.

N'oubliez jamais : DYOR, ce n'est pas parce que ça brille que c'est de l'or.

A bon entendeur.

Il me semble que pour ça il faut que tu donnes le même nonce que la transaction précédente.

Ce qu'il va se passer en faisant cela c'est que les noeuds lorsqu'ils vont enregistrer la transaction 2 en premier, enregistreront normalement le nonce de la transaction. Lorsque la transaction 1 sera traitée à son tour, le nonce ayant déjà utilisée, la transaction 1 sera rejetée automatiquement.

Que quelqu'un me corrige si j'ai tort, mais il me semble que c'est la logique qui est derrière cela.

Si le statut de la transaction apparait en success ca veut dire que la méthode appelée a bien pu être traitée.

En regardant le contrat à cette adresse je trouve les fonctions suivantes sur ton token :


et



Tes fonctions sont tout simplement vides. C'est à dire que quand on les appelle, elle ne font....rien. D'ou le fait qu'il n'y ait pas de tokens qui bougent.

Il faut remplir tes fonctions avec les instruction de traitement afin de bouger les tokens d'une variable de mapping à une autre :


et



Je te copie/colle un contract standard ERC20 avec son intérfance dépendante ici  :

ERC20TokenInterface.sol

GRPToken.sol

j'ai copié/collé ce contrat depuis le token ERC20 de wetrust ( très beau projet au passage avec des devs solides, j'ai eu la joie de me voir fournir un peu d'aide et d'apprentissage de la part de shine2lay ).

Tu feras attention, au survol du code j'ai constaté que d'autres fonctions de ton contrat avaient l'air vide.

Avant d'aller plus loin , je te conseille vraiment de passer par un outil de test type remix IDE : https://remix.ethereum.org/

Ca te permettra de tester le déploiement de tes tokens, les fonctions, etc. sur du réseau simulé, sur les testsnets. Ca t'évitera de te ruiner pour déployer des contrats sur un main net sans être certain que ceux-ci soient carrés.

Je t'ai mis les deux contrats également dans des gists sur github : https://gist.github.com/anonymous/6e552ade5cb6e6377dd66d570649882f

Tu as juste à ouvrir RemixIDE, reconstruire les fichiers et go !


EDIT :

J'INSISTE ! quitte à passer pour un gros relou, mais arrête de tenter de déployer tes contrats sur le mainnet pour le moment, ca te coûte une foutue fortune pour pas grand chose. Utilise Remix IDE, creuse un peu le fonctionnement de tout le bousin, lis sur les différents outils que je t'ai linké, apprends à déployer sur ganache-cli/testrpc, puis à déployer & tester sur un testnet . Une fois que tu auras fait cela et que tu seras certain que tes contrats ne sont pas buggués et qu'ils sont construits correctement alors ET SEULEMENT ALORS tu pourras déployer sur le main net.

Sans ça, tu te ruines pour rien.

No offense hein, après tout ç'est pas mon argent qui part pour rien, mais ca m'embête un peu de te voir claquer de l'argent pour rien.

Hello !

Alors, je vais reprendre quelques points :

- Tes tokens ils sont créés dans ton contrat normalement. Si tu regardes la structure d'un smart-contract de token ERC20, tu verras qu'il y a normalement une variable de mapping nommé balances qui sert à savoir qui dispose de quels montants de tokens :



Si tu ne connais pas les mappings, je te conseille d'aller voir par là bas : http://solidity.readthedocs.io/en/develop/types.html#mappings

Pour expliquer un peu, imaginons que mon addresse de wallet soit 0x123456789, mon solde de ton token sera stocké dans balances[0x123456789]. Pour connaitre mon solde, il y a une fonction dans le smart-contract ERC20 :


Cette fonction, vu qu'elle renvoie une constante, et donc n'altère pas l'état du smart-contract ( pas de calcul et pas d'écriture, juste de la lecture dans l'EVM ), ne coûte rien. Il faut donc appeler la fonction balanceOf avec mon addresse pour récuperer mon solde de token :


Je te conseille de lire un peu de doc sur le fonctionnement et le principe des tokens ERC20 avant d'approfondir et de te lancer dans la distribution de tokens, ca te permettra de savoir ce que tu fais et être sur de pas semer chaos, désordre et malaria.

Voir ici : https://theethereum.wiki/w/index.php/ERC20_Token_Standard


Ensuite, en ce qui concerne la distribution, si tu as lu un peu les docs que je t'ai fourni ainsi que le code, tu verras qu'il y a des fonctions qui servent à gérer les aspects transactionnels du mapping de variables des balances. Du coup c'est simple, pour faire une distribution il suffit d'appeler ces fonctions.

Exemple, je créer un token avec 10000. Comme je suis un beau gosse je vais t'en filer 2000, toi  dont ton adresse est 0x987654321. Je vais donc appeler la méthode


du smart-contract.

L'EVM traitera la transaction, et mettra à jour la variable mappée : balances[0x987654321] . Vu qu'elle etait à 0 elle passera à 2000. Bim ! Je t'ai distribué des tokens de mon cru !


Après, tu peux automatiser en créant un smart-contract qui appelera le smart-contract ERC20 selon des règles que tu aura codé toi afin de distribuer régulièrement/équitablement/nimportecomment les tokens du contrat.


Enfin quelques pistes pour le développement :

- Pour ce qui est déploiement, compilation et création d'ABI pour tes smart-contracts tu peux regarder du côté de Truffle qui est très bien même si le compilateur est assez cryptique en ce qui concerne les bugs de compilation.  https://github.com/trufflesuite/truffle
- Une alternative est Embark, mais je n'en suis pas très fan personnellement, en dépit d'une console de suivi pas trop mal foutue. https://embark.readthedocs.io/en/2.5.2/

- Pour ce qui est du développement de smart-contracts je te conseille remix IDE qui te permettra de suivre toutes les recommandations, avoir les warnings et de bonnes indications sur les bugs de tes contracts.

Tu peux utiliser l'outil directement en ligne :  https://remix.ethereum.org
ou en installer une instance directement chez toi ou sur un serveur : https://github.com/ethereum/remix


Voilà de quoi démarrer. Courage et hésite pas à me solliciter ou à poser des questions sur http://ethereum.stackexchange.com si tu bloques sur certains points techniques. Dernière petite chose : patience ! L'apprentissage est long, demande pas mal de lecture, mais est clairement passionnant !

EDIT :

quelques outils complémentaires/nécéssaires :

TestRPC/Ganache-CLI pour simuler un réseau ethereum, très utile quand on développe et avant de déployer sur un testnet ou sur main net: https://github.com/trufflesuite/ganache-cli. Si tu veux tester tes smart-contracts sans que ca te coute un rond, à faire tourner absolument ! Les déploiements de contrats sur testnets et main net se font après que tes contrats soient bien développés et testés sur ce simulateur !

la doc Web3, qui sert à l'intéraction offchain-onchain : https://web3js.readthedocs.io/en/latest/

Attention, ces outils sont encore en développement pour la plupart, il faut donc régulièrement regarder les docs, fouiller les repos github. Avoir des connaissances solides en développement et notamment en P.O.O est loin d'être optionnel.

Je pense qu'il y a confusion ici, on ne parle pas de mettre un avatar mais d'associer un logo a un jeton.

@Ceric35 : c'est dépendant de chaque service.

Si tu fais référence à MeW, c'est probablement un élément à fournir à travers une Pull Request pour ajouter tes éléments de configuration au fichier dans lequel sont listés les différents tokens ERC20.

Si tu fais référence a etherscan il faut passer par là : https://etherscan.io/token-search

Le gas ne se génère pas, il se paie. Tu détermines à quel prix en Ether ( en unités GWei qui est une sous division de l'ether ) tu veux payer ton gas. Tu spécifies par exemple que tu es disposé à payer 20GWei par unité de gas consommée pour une transaction.

Il me semble que normalement non, etant donné que tu n'as pas encaissé les sommes sur un compte bancaire qui t'appartient nominativement tu n'as rien à payer pour le moment. L'argent en question, quelle que soit sa valeur, est toujours considérée comme étant dans le circuit d'investissement.

Tu ne payes tes plus-values que lorsqu'il s'agit de sommes qui arrivent à un endroit ( compte bancaire nominatif ) qui te permet de t'approvisionner directement.

Le BTC n'etant pas considéré légalement comme une monnaie, bien que tu puisses les dépenser pour consommer, le portefeuille individuel qui les stocke n'est pas considéré comme te permettant un approvisionnement direct.

Personne ne peut le dire avec précision.

La semaine dernière il y avait environ 20 000 transactions en attente. Au début de la semaine il y en avait 16 000, et depuis quelques jours ca semble se stabiliser autour de 13 000. La demande reste donc constante.

Le seul moyen de savoir quand est ce que les fees à mettre pourront redescendre c'est de suivre régulièrement la queue de transactions en attente que tu peux visualiser ici : https://etherscan.io/txsPending

Je ne dédouane pas Kraken de ses problèmes, il est clair qu'il y a des erreurs inacceptables de leur côté, qui en plus de ça fait perdre des sommes parfois conséquentes à leurs clients.

Mon propos était plutôt de nuancer car on a souvent partir dans une vue simpliste "saitoumal" ou "saitoubien" sans prendre en considération les points de complexité qui peuvent se cacher derrière ( le fameux "yakafokon" ). Ayant la (mal)chance de faire du dev dans des grosses corpos je vois aussi la machine titanesque à l'oeuvre. Je ne l'aime pas pour autant, mais je vois que ce n'est pas aussi simple que ce que le grand public peut imaginer. Je cherchais à mettre en exergue cette complexité que l'on peut retrouver dans des structures à croissance très forte ou ayant un poid déjà certain.

Le marché fera de toute façon son oeuvre. J'ai les boules contre Kraken comme toi, mais me dis que s'ils ne réussissent pas à remonter la barre ils finiront par couler. Après, pour le fait qu'ils brassent des millions ca ne veut pas forcément dire qu'ils ont les moyens adaptés. On peut faire un CA de 4 milliards et être en déficit. Si c'est le cas pour eux, c'est que là aussi ils ont un problème.

J'aimerais bien être une petite souris et me glisser dans leurs locaux, voir comment ca se passe, parce que quelque chose me dit que ca doit être pas mal le foutoir niveau gouvernance, structure et prise de décision.

Il faut aussi réaliser la complexité de la tâche. Attention, je ne cherche pas à décharger les plateformes en question de leurs responsabilités, apporter un peu d'éclairage sur le sujet.

Construire une plateforme de trading c'est quoi ? Globalement c'est :

[1]
- Construire un moteur de traitement de requêtes efficace. On ne parle pas ici d'une simple base mySQL ou MongoDB avec quelques millions de lignes. On parle ici d'un système de traitement, réparti sur plusieurs machines, qui doivent se coordonner et avoir la capacité à engranger des milliers d'ordres à la seconde, avec une synchronisation entre chaque machine traitant les requêtes pour garder une cohérence entre les mouvements enregistrés par les machines. Ca implique également du coup une stratégie de déploiement d'infrastructure conséquente avec des devops à la hauteur de la tâche.

Un moteur de ce type là, ca ne se pond pas en un jour. Et une fois que l'on a un moteur taillé pour une certaine scalabilité, selon comment le processus de suivi, de qualité, la documentation réalisée en interne ont été réalisé, ca peut être plus ou moins compliqué de dépasser certains jalons.

Prenons le cas de Kraken. Kraken est une des plateformes les plus connues mais également les plus anciennes. Quand Kraken à commencé, ils ont probablement créée un moteur d'API et de traitement des requêtes taillé pour être capable d'emmagasiner un volume maximum de données préalablement établi, pensant avoir de la marge de manoeuvre pour le jour où ils devraient scaler pour encaisser des volumétries plus grandes.

Pour précision, il convient de garder en tête qu'on parle de requêtage humain mais également automatisé. Vu la quantité de robots qui doivent se connecter et leur capacité à émettre du volume, avec la croissance actuel ca doit être franchement conséquent.

Kraken n'avait peut-être tout simplement pas anticipé une croissance de la demande aussi rapide. Le résultat c'est qu'ils ont probablement un moteur de traitement de requête qui atteint ses limites actuellement en terme de capacité.

Deux réponses que l'on voit souvent à cela c'est :

- "Ils n'ont qu'à changer !"  : Ben oui, mais changer un moteur dans un écosystème IT n'est pas forcément quelque chose de simple et de rapide. On ne change pas une pièce de moteur en 2-2, c'est le travail d'une équipe complète, qui va passer par un processus qui est censé apporter une qualité et un suivi à ce remplacement. Cela veut dire de multiples intervenants, chacun avec sa propre problématique à gérer ( specs, developpements, tests, infra, suivi qualitatif, doc, maintenance ) .

- "Ils n'ont qu'a rajouter des serveurs" : Aussi, mais encore une fois, ce n'est pas qu'une question de rajouter des serveurs. En fonction d'une architecture et d'un écosystème IT que vous aurez déployé, arrivé à une certaine taille vous pourrez rajouter autant de serveurs que vous voudrez, votre ensemble ne pourra avoir des gains de performance qu'à la marge. De même, si vous disposez d'une architecture avec des pièces complexes, si l'équipe ou la personne qui etai(en)t à l'origine de cette partie là ne sont plus sur le sujet ( partis vers d'autres horizons par exemple ) le remplacement des personnes peut être non seulement compliqué ( compétences spécialisées précises ) mais également prendre du temps ( montée en compétence sur le sujet en question, la prise de connaissance peut prendre des mois parfois ).

[2]
En ce qui concerne l'interface, c'est un peu pareil. Il faut du monde, qu'ils prennent connaissance de ce qui a été fait, de comment ça marche, et si lors du développement de ce qui a été mis en place la documentation n'a pas été bien faite, ca peut être un point de ralentissement conséquent.

Dans le cas de plateformes d'échanges il y a 2 publics à viser :

- Madame cryptomichu, qui n'y connait pas grand chose mais voudrait bien acheter du bitcoin et de "l'ethium" () et qui a donc besoin d'une interface légère, simple et intuitive

- Jean-Michel forencrypto qui lui passe ses journées à passer des ordres, a besoin de voir des graphiques dans tous les sens, a besoin d'outils particulièrement poussés, capable de rendre en temps réel toute une série d'indicateurs.

Ce sont deux démarches d'UX très différentes, chacun avec son lot de problématiques : pour la première une réflexion de design graphique poussée, l'autre une nécéssité d'embarquer beaucoup de fonctionnalité en limitant la consommation de ressources côté client ( navigateur ).

[3]
En ce qui concerne les processus de KYC, ca peut également être un sujet épineux. je releverais 3 points :

- L'arrivée des régulateurs s'est faite cette année, et les plateformes pensaient peut-être disposer de plus de temps pour pouvoir mettre en place ces processus. Du coup, la tête dans le guidon, ils n'ont pas anticipé qu'il faudrait développer cet aspect et se sont focalisé sur d'autres choses.

- On a pas envie que nos informations personnelles sensibles de ce type arrivent dans les mains de n'importe qui. Il faut sécuriser le process et les outils. Que ce soit fait de façon interne ou externe. En interne il faut convenir de la façon dont ce sera fait et étudier comment limiter au maximum la fuite potentiel d'informations, trouver les personnes que l'on estime viable pour faire le job et en qui on peut avoir confiance. En externe c'est un peu pareil, il faut trouver le bon partenaire, vérifier sa réputation, sa viabilité, s'assurer que les données qui lui seront transmises ne fuiteront pas, et que si jamais ca arrivait, il y aurait des mécanismes de responsabilité mis en place ( par les contrats ). On est donc loin ici de l'embauche d'une personne pour tenir une caisse de supermarché.

- Il y a également la prise en compte du cadre régulatoire, qui fait intervenir des juristes, des avocats...etc, et pareil, ce boulot là ne se fait pas en un jour.

De surcroit, il faut souvent faire tenir tout cela dans le cadre d'un plan d'investissement et de business development. Mettre en place un package complet de ce type là peut coûter cher, et si à l'étude préalable, qui elle aussi peut prendre du temps, on se rend compte que ca va bouffer la marge nette de l'entreprise des 3 prochaines années, il peut être décidé que ce sera fait de façon ventilée, et tant pis pour l'image. Il ne faut pas oublier qu'une partie de ces entreprises ont des investisseurs qui les regardent de près et attendent un ROI certain. Pareil, peut être que certaines de ces entreprises ne disposent pas des fonds nécéssaires. Du coup il faut alors emprunter, et ca aussi c'est pas forcément une sinécure.

Ajoutons à cela le facteur humain interne, à savoir les éventuels turn-over de ressources humaines, les conflits et enjeux internes ( #macarriere ) et on commence à avoir une bonne idée de l'ensemble des embuches que ces plateformes peuvent rencontrer.

N'oublions pas que ces plateformes sont jeunes pour la plupart, qu'elles vivotent dans un environnement extrêmement dynamique, avec des attentes élevées, et où pour elles le jeu peut s'arrêter quasiment du jour au lendemain si elles ne prennent pas les précautions nécéssaires.

J'entends parfois une incompréhension par rapport au fait que les exchanges traditionnels eux arrivent à tenir sans problème. Sauf que les exchanges traditionnels eux ont une existence bien plus longue, une expérience et un savoir qu'ils ont eu le temps d'accumuler depuis belle lurette et qu'ils ont eu le temps de cadrer l'intégralité des processus, des connaissances et des besoins matériels et immatériels nécéssaires pour offrir une certaine stabilité.

les exchanges crypto y viendront, patience.

----

Note 1 : Certaines entreprises peuvent acheter des outils auprès d'autres entreprises. Ca a été le cas de kraken avec cryptowatch. Ici pareil, ca ne s'intègre pas en 2-2. Il faut avant l'achat auditer l'outil pour vérifier ce que l'on achète, puis incorporer tout le savoir nécéssaire, constituer une équipe eventuellement autour de l'outil pour pouvoir l'intégrer dans le nouvel écosystème.

Note 2 : Je réitère concernant le fait que je ne cherche pas à dédouaner complètement les exchanges. Il s'agit ici d'apporter une vision sur ce que comporte la création et l'évolution d'outils ayant des besoins industriels. Je suis le premier à souffrir des lacunes de certaines plateformes, et ca me fait rager autant que vous, néanmoins quand je pense à ce qui se joue derrière, je me dis que ca doit pas être très reposant et ça, on a souvent tendance à l'oublier.