Le point sur la recherche et le développement concernant les orbes du 16 mai 2019

Après un an et demi de construction de la blockchain Orbs avec l'équipe la plus talentueuse que je puisse espérer, Mainnet a été rendue publique le 28 mars. L’un de mes objectifs non techniques après le lancement est de communiquer directement avec tout le travail que nous effectuons. Préparez-vous - c'est long :)

L'univers des orbes

Depuis le lancement de la plate-forme Orbs prête pour la production et sa publication dans la communauté, l’équipe de développement principale d’Orbs a continué de suivre ses progrès et d’améliorer les améliorations à proposer à la communauté des participants au réseau Orbs. Notre équipe a préparé un article décrivant ce que nous avons appris jusqu’à présent, les problèmes rencontrés par le réseau et les corrections que nous avons proposées aux validateurs qui exécutent le protocole.

Lisez tout a propos de ça ici.

Cas d'utilisation

Les contributeurs Orbs ont manifesté un vif intérêt pour la mise en œuvre de cas d’utilisation sympas au-dessus de la plate-forme, afin de montrer ce dont elle est capable. Certaines de ces idées resteront la preuve de concepts, alors que d’autres pourraient éventuellement évoluer vers des produits fonctionnels à mesure qu’un nombre croissant d’entreprises de l’écosystème s’intéresseraient de passer au niveau supérieur. L’équipe de développement principale d’Orbs estime que cette exploration devrait être axée sur les cas d’utilisation susceptibles de tirer le plus grand avantage d’une blockchain publique, principalement en bénéficiant des diverses garanties proposées par Tal (@talkol). (auditabilité, fourchette, gouvernance). Voir ici [lien] Certains des cas d'utilisation que l'équipe de développement principale d'Orbs estime avoir ce type de potentiel sont les suivants:

MNP décentralisé

Node.js Package Manager (NPM) est un outil très populaire pour partager le code entre des projets de l'écosystème JavaScript. Il héberge plus de 1,2 million de paquets téléchargés plus de 1 milliard de fois par jour. Cette base de données est open source, mais ce qui est intéressant, c’est qu’elle est complètement centralisée et gérée par une société bien connue appelée npm Inc.

Actuellement, il remplit deux rôles importants: 1) l'autorité et 2) le stockage.

Premièrement, npm Inc. authentifie les utilisateurs pouvant publier de nouvelles versions de packages et gère leurs autorisations. Deuxièmement, il héberge et gère le registre dans lequel les packages sont stockés.

Sergey (@ bolshchikov), l'un des principaux contributeurs, est un fan inconditionnel de l'écosystème JavaScript. La validation du concept d'un NPM décentralisé peut répondre aux deux rôles en utilisant des contrats intelligents et une blockchain publique.

Un contrat intelligent permet au npm décentralisé de gérer facilement l’autorité et le rôle de chaque code de publication d’utilisateur de manière transparente. Il permet également de stocker et d’auditer les métadonnées des packages en cours de publication.

App conversation

Kirill (@ netoneko) a créé Conversation (https://github.com/orbs-network/conversation) - une discussion sans serveur s'exécutant sur la chaîne de blocs Orbs. Il utilise la force des orbes où la finalité est atteinte en quelques secondes et vous pouvez en fait avoir une discussion réactive au-dessus de la blockchain!

Vous avez une idée pour une application utile à développer en utilisant Orbs? Suggérez-le sur le tableau communautaire!

Réseau d'orbes

Github du réseau Orbe

En avril, nous avons beaucoup travaillé sur la surveillance et la stabilisation du réseau Orbs: enregistreur extrait dans une bibliothèque séparée, Scribe: https://github.com/orbs-network/scribe

  • Ajout du support pour les métriques Prometheus exposées via l'API HTTP.
  • Ajout de la validation de configuration pour le nœud qui vérifie que l'adresse du nœud Orbs a été dérivée de la clé publique. Il aborde le problème de mauvaise configuration qu'un de nos partenaires a connu.
  • Le processus de publication simplifié pour le noeud, les versions principales et les versions Gamma et Orbs est maintenant publié sur Docker Hub.
  • Lancement du réseau - enregistre la surveillance et la compréhension de la "pulsation" du réseau:

a) Ethereum Health-Check (github # 1102) - refactored le composant à tester, ajouté un test de cohérence, refactored le code de reporting pour envoyer moins de données ou des données plus concises sur le contrôle de santé

b) Compilateur natif (github # 1106) - ajout de 6 nouvelles métriques pour nous donner une visibilité sur la compilation de contrats

  • Données de surveillance - métriques ajoutées / fixes au compilateur natif et au contrôle de santé Ethereum
  • Rapport de problèmes de synchronisation de bloc - a injecté l'adresse IP homologue de synchronisation dans l'objet de contexte de connexion, afin que nous puissions signaler l'IP homologue et pas uniquement l'adresse de l'homologue (github # 1123)
  • Analyse des nouvelles limitations de transport pour résoudre les communications réseau non valides (github # 1153)
  • Travaillé avec Logz.io pour comprendre nos limites et s’assurer que nous ne sommes pas bloqués et «aveuglés» en ce qui concerne les journaux du système.
  • Ajout d'un vidage de divergence des différences d'état au cas où les validateurs ne soient pas d'accord sur la différence d'état du bloc proposé. C’est un cas intéressant, décrit ici, où les nœuds Orbs n’ont pas atteint un consensus et où l’équipe Orbs a enquêté sur la cause. Une fois que l’équipe a réalisé que c’était à cause d’une exécution non déterministe, nous avons proposé cette fonctionnalité.
  • Suppression de la journalisation des métriques dans les fichiers journaux. La surveillance repose désormais sur l'interrogation des métriques via des requêtes http plutôt que sur l'analyse des journaux
  • Plusieurs numéros: # 1121, # 973
  • Introduit la variable de configuration GOSSIP_RECONNECT_INTERVAL. Auparavant, lorsqu'une connexion ne pouvait pas être établie, nous dormions pour GOSSIP_CONNECTION_KEEP_ALIVE_INTERVAL avant la prochaine tentative. Cette utilisation de keep-alive-interval pour déterminer le temps de repos entre les reconnexions est incorrecte en soi. Le problème est apparu lorsque, dans certains scénarios de test, les messages Keep-Alive sont désactivés en définissant l'intervalle Keep-Alive à une valeur très élevée. Dans ces scénarios, si un écouteur de transport n'est pas initialisé avant la première tentative de connexion, le test s'arrête car l'intervalle de reconnexion a une durée pratiquement infinie.

Gamma

Gamma est un environnement local qui permet aux développeurs de développer, déployer et tester sur la couche Orbs. Vous pouvez lire à ce sujet ici et commencer à jouer avec ici.

  • Nous avons ajouté une option au serveur gamma pour utiliser le consensus LeanHelix. Cela signifie que le serveur Gamma peut maintenant fonctionner avec 2 algorithmes de consensus différents:
  1. Consensus de référence: optimisé pour les temps de blocage les plus rapides et les besoins en ressources les plus faibles, et suppose une confiance entre les nœuds. C'est utile pour le développement de contrats.
  2. Consensus Lean Helix: consensus de leader aléatoire basé sur PBFT, l'hélice maigre est tolérante aux pannes byzantines et constitue l'algorithme de consensus du réseau Orbs en cours de production.
  • Une nouvelle version de Gamma CLI exécute également automatiquement Prism, l'explorateur de blockchain Orbs.

Contrats d'Orbs Ethereum

Github Contrats d'Orbes Ethereum

Ce monorepo contient des projets impliquant les fonctionnalités d'interopérabilité Orbs et Ethereum. Au cours du développement de la V1, l'équipe Orbs a commencé à faire face aux défis liés aux tests, à la création et au déploiement de fonctionnalités couvrant plusieurs chaînes de blocs.

Toutes les sous-références contiennent des contrats Solidity pour le déploiement sur Ethereum. Certains contiennent des contrats Orbs, et d'autres contiennent des processus autonomes supplémentaires destinés à faciliter la communication entre les deux réseaux. En outre, certains sous-ensembles incluent des applications hors chaîne telles que l'interface utilisateur Web.

La pile utilisée dans ces référentiels est diverse:

  1. Les tests unitaires de contrats de solidité sont mis en œuvre dans JS sur Truffle
  2. Les contrats des orbes et leurs tests unitaires sont mis en œuvre à Golang
  3. Les tests d'intégration démontrant les cycles de vie complets de toutes les fonctionnalités sont mis en œuvre à l'aide d'une pile mixte de JS, Truffle, Golang, Gamms et bash

Le monorepo contient actuellement 3 + 1 subrepos:

  1. Abonnement - Contrats de provisioning et de paiement pour les chaînes virtuelles Orbs
  2. ASB - Pont de permutation autonome - permet le transfert de jetons ERC20 entre réseaux Ethereum et Obrs
  3. Vote - Contrats de délégation, de vote, d'enregistrement de gardien et de validateur, de vote d'Ethereum et de contrats de décompte des résultats d'élections et d'exécution de leurs résultats sur des orbes. En outre, il existe un processus externe qui gère le flux de données entre les deux réseaux.
  4. Obsolète - Contrats de fédération. Référence pour le modèle de fédération déconseillé envisagé dans le document de synthèse Orbs original, remplacé depuis par le modèle Orbs PoS.

Refactor / nettoyage

Lors de la sortie de V1, chaque sous-repère avait une structure interne différente, respectant des conventions différentes. En outre, la structure des répertoires était source de confusion, car le référentiel n’était pas initialement conçu comme un monorepo. Le refactor / nettoyage inclus:

  1. Séparation en subrepos - chaque dossier de niveau supérieur représente désormais un seul subrepo correspondant à une seule fonctionnalité
  2. Ajout de lignes shebang dans les scripts bash
  3. Suppression des dossiers non référencés du niveau supérieur du référentiel - répartissez les dossiers du menu fixe dans des sous-dossiers
  4. Arrêtez d'utiliser des liens symboliques NPM
  5. Uniform subrepo structure, avec ces dossiers:
  • Docker - utilisé pour l'automatisation ci
  • Ethereum - chemise à truffes contenant des contrats Ethereum
  • Projet de contrat Orbs - Orbs
  • composants ff-blockchain - tels que les projets d'interface utilisateur Web, les planificateurs, les tâches cron, etc.
  • Construire - générer des artefacts pour tous les projets, en particulier les contrats Ethereum compilés
  • Tester:

a) bout à bout (e2e) - portée indéterminée

b) Test d'intégration - e2e d'intégration teste l'ensemble des fonctionnalités par rapport aux implémentations Ethereum et Orbs: développement local (Gamma / Ganache), testnet (Ropsten / Testnet), production (Mainnets).

Questions ouvertes

  1. Le projet ABS fait encore une distinction entre les réseaux cibles Ganache et Ropsten dans le code de test. C'est une dette technique
  2. Les dépendances entre subrepos ne sont pas encore résolues. Actuellement, les contrats Ethereum doivent être compilés et publiés à l'aide du script ./deploy.sh situé dans le dossier du projet truffle, ou manuellement.
  3. La pile de test d'intégration est trop complexe.

Suivi de la performance

Dans les semaines qui ont précédé notre lancement prévu, l'équipe principale d'Orbs a effectué des tests de stabilité sur diverses configurations de réseau. L'objectif était double: identifier les bogues qui se manifestent seulement après une longue période de mise en ligne du système et tester les limites de charge du système.

Lorsqu'un nouveau système logiciel passe en production, il est essentiel de mettre en place un système de surveillance. Son objectif principal est d'identifier les anomalies, c'est-à-dire les écarts par rapport aux indicateurs de performance clés définis pour le système. Ces informations doivent être présentées de manière optimale dans un format clair, de sorte qu’un simple coup d’œil sur un tableau de bord des performances permette aux utilisateurs d’identifier l’état «Tout OK» ou «Pas tout OK».

Lisez tout a propos de ça ici.

Prisme

Prism est une implémentation de référence d'un explorateur de blocs Orbs. Comme chaque élément d'Orbs, Prism est un projet open source. Si vous voulez revoir le code ou contribuer, jetez un coup d'oeil ici:

https://github.com/orbs-network/prism

Nouvelles fonctionnalités

  • Ajout d'un lien vers la page du contrat à partir de la page des transactions.
  • Détecter les contrats du système et l'indiquer sur le client (sans le code)
  • BlockHeight a été remplacé par un nombre (dans la base de données) au lieu de chaîne pour pouvoir trier l'historique des transactions de la page du contrat. Le client doit toujours utiliser la chaîne car elle ne supporte pas bigint.
  • Ajout du contrat surlignant la syntaxe Golang.

Améliorations côté serveur

  • Ajout de quelques utilitaires basiques et additifs d’ajout / soustraction pour les calculs bigint sur le client, car ils ne sont pas pris en charge par certains navigateurs.
  • Ajouté release.js qui va bouger la version de package.json, commit et push. Ajout de la publication aux scripts npm pour une publication simple et rapide.
  • Ajout de la version de Prism (extraite de package.json) en bas à gauche du client Prism.
  • Arrêt de l'utilisation de IS_PRODUCTION / IS_STAGING extraite de NODE_ENV et simplification de ceux-ci en paramètres plus spécifiques tels que FORCE_HTTPS, MINIFY_JS, LOG_TO_CONSOLE, LOG_TO_FILE et LOG_TO_ROLLBAR.
  • Ajout de valeurs par défaut à .env au lieu de config.js. Utiliser également .staging.env et .testnet.env pour pouvoir déboguer d'autres environnements (ignoré sur git)
  • Déplacé du port webpack 8080 vers le port 8085 pour permettre à gamma d'utiliser son port par défaut
  • Correction de README.md pour refléter l'état actuel du projet
  • Suppression de tout ce qui concerne postgres
  • Tests unitaires fixes et e2e tests de collusion de bases de données, en effaçant la base de données après chaque test
  • Cloudinary ajouté pour le téléchargement des captures d'écran des tests e2e ayant échoué
  • E2E a échoué à cause du minutage de l’animation, donc nous avons ajouté la variable d’environnement DISABLE_ANIMATIONS qui est activée pendant les tests e2e. Cela désactivera les animations et empêchera les échecs dans les tests e2e
  • Utilisation de func au lieu de méthode dans les journaux spécifiques à l’arceau de sécurité et ayant généré un rapport d’erreur erroné
  • Toute la liste d'arguments de transactions a été repensée pour mieux afficher les valeurs longues
  • Disposition des blocs fixes (qui se chevauchent)
  • Nouvelle tentative de chargement du bloc et de l'émetteur après une erreur d'extraction au lieu d'afficher systématiquement les journaux avec erreur lors de la réponse à getBlock avec blockHeight = 0
  • Utiliser process.cwd au lieu du chemin relatif pour accéder aux fichiers sur le serveur
  • Capper ajouté (pour éviter le débordement de mémoire du client), pas encore utilisé
  • Ajout de la possibilité de déboguer les tests client
  • Protection supplémentaire contre l'échec d'initialisation du serveur
  • Les blocs avec plus d'un émetteur sont maintenant mieux disposés
  • Arrêter le démarrage de l'application si la base de données n'a pas pu s'initialiser
  • Utilisation de l'enregistreur injecté au lieu de console.log
  • Éviter les besoins, en utilisant es6 import quand c'est possible
  • Ajout d'informations supplémentaires sur les journaux relatifs aux demandes de blocage incorrect
  • Ajout d'un arceau de sécurité comme enregistreur dans Winston
  • Utilisation de Winston Logger sur le serveur. (Journaux à la console, au fichier et à distance)
  • Empêcher l'animation lorsque l'application démarre pour la première fois
  • Correction d'un bug d'animation en arrière-plan
  • Implémentation des blocs prev et next
  • Correction de la génération de signatairePublicKey dans les tests
  • Ajout de l'adresse du signataire aux transactions

Boyar

Boyar sur Github

Boyar est probablement le seul système d’approvisionnement en chaînes de blocs à faire l’allocation de ressources dynamique en temps réel. Cela signifie que lorsqu'une nouvelle chaîne virtuelle est créée, de nouveaux conteneurs sont automatiquement générés sur tous les nœuds Orbs par ce système (un nœud Orbs est un cluster de machines, pas un seul ordinateur).

  • Ajout de la journalisation via Scribe (https://github.com/orbs-network/scribe)
  • Ajout de la surveillance pour les conteneurs de virtual-chain. L'état des conteneurs est maintenant signalé aux journaux
  • Condition de concurrence fixe qui s'est produite lorsque plusieurs chaînes virtuelles ont été provisionnées à la fois
  • Ajout de la prise en charge des chaînes virtuelles 10 et 100 s'exécutant en parallèle sur le même cluster (plus de 300 vérifiées pour fonctionner sur le matériel actuel, m4.xlarge x 3)
  • Ajout de la prise en charge de NFS en tant que persistance de volume de chaîne virtuelle pour l'un des validateurs, Tenta, leur permettant d'exécuter le nœud Orbs sur leur propre matériel (non-AWS) sans modification de code et avec un effort minimal
  • Prise en charge SSL facultative ajoutée: l'API publique du nœud Orbs est désormais disponible via HTTPS, ce qui permet de créer des applications client dans le navigateur. Le chiffrement se produit dans le proxy inverse Nginx qui envoie des demandes de proxy à des conteneurs de chaîne virtuelle individuels

Nébuleuse

Nébuleuse sur Github

Nebula est un outil de déploiement de nœud Orbs pour les validateurs qui fournit toutes les ressources nécessaires sur AWS et crée le nœud Orbs.

  • Ajout d'une option pour activer HTTPS dans l'API publique du nœud Orbs implémentée dans Boyar.
  • Supprimez la configuration automatisée d'un nœud Ethereum de notre outil de déploiement de nœud, Nebula.

Depuis la dernière mise à jour, Nebula ne crée plus de nœud Ethereum dans le cadre du nœud Orbs. Il incombe désormais au responsable de la validation de configurer un nœud Ethereum dans un processus séparé (avant de créer le nœud Orbs avec Nebula) et de s’assurer qu’il est synchronisé et prêt à prendre la route avant d’utiliser Nebula pour déployer son nœud Orbs. Puisque l'écosystème Orbs POS est basé sur Ethereum, Boyar & Nebula doit avoir un état à jour d'Ethereum pour pouvoir fonctionner. Certains des changements récents apportés à Nebula, qui prennent également en charge ce même objectif, incluent dans les arguments de Nebula un point d'extrémité Ethereum que le nœud Orbs utilisera pour l'accès réseau principal Ethereum.

En outre, Nébuleuse a été refondue pour être plus concise et facile à contribuer. La charpie a également été ajoutée au projet pour rechercher davantage d’erreurs lors de l’écriture de code, en particulier lors de l’utilisation d’un éditeur open source basé sur Atom (par exemple, VS Code et ses amis).

Lancement de la communauté Orbs

Nous avons lancé Orbs Community en utilisant la plate-forme Discourse. et visez à ce qu'il devienne un environnement ouvert pour la discussion et la collaboration sur les orbes avec la communauté de tous les participants de l'univers des orbes - développeurs, mandants, gardiens et validateurs. Orbs étant un projet décentralisé et à source ouverte, tout membre constructif de la communauté peut devenir modérateur. Consultez ce billet de blog pour plus d'informations sur la communauté.

Ensemble avec l'établissement de la communauté, nous avons relancé notre guide de contributeurs orbes. Nous apprécions la bonne communauté autour du projet, nous avons donc ajouté un code de conduite qui s’applique à tous les projets du réseau Orb. Si vous êtes prêt à contribuer au code, veuillez consulter le guide de contribution, il devrait suffire à vous aider à démarrer.

Hackathon

Les orbes auront un hackathon les 22 et 23 mai. Son objectif est que l'équipe de recherche et développement d'Orbs explore plus avant les capacités de la plate-forme Orbs, dans le but de découvrir et de partager de nouvelles idées de cas d'utilisation et de produits pouvant être développés sur la plate-forme Orbs. Nous sommes enthousiastes à l'idée de recevoir des idées de la communauté sur des produits spécifiques qu'il serait intéressant de développer. Rejoignez la conversation sur: https://community.orbs.network/t/ideas-for-r-d-hackathon/90

Recherche

L'équipe d'Orbs est également engagée dans des recherches théoriques que la communauté des développeurs pourrait trouver utiles dans le développement futur du réseau Orbs. Vous trouverez ci-dessous une synthèse de ce à quoi nous avons réfléchi et sur laquelle nous avons travaillé récemment.

Aucune preuve de connaissance

L’adoption d’applications classiques dépend en grande partie de la capacité à fournir aux utilisateurs la confidentialité requise. La capacité à atteindre la confidentialité avec la capacité de maintenir un état consensuel et de fournir les garanties d'auditabilité et de possibilité de fractionnement est difficile. Plusieurs technologies cryptographiques pour les solutions de protection de la vie privée font actuellement l'objet de recherches, telles que les preuves à zéro connaissance, les pare-balles, le calcul multipartite, etc. Nous avons choisi de centrer notre recherche sur les preuves à zéro connaissance.

Les preuves à zéro connaissance sont un outil cryptographique de pointe. Ils permettent à une entité de fournir la preuve d'une réclamation sans révéler aucune information autre que la validité de la réclamation elle-même. Un cas d'utilisation courant lié à Blockchain est la pièce de confidentialité Zcash, où les preuves à zéro connaissance sont utilisées de la manière suivante: Un payeur, plutôt que de télécharger une transaction, télécharge une «preuve» de la transaction correcte. Tous les nœuds de vérification du système peuvent alors vérifier que la transaction sous-jacente est valide, sans savoir qui est le payeur, quel est le montant payé et à qui. En outre, ils sont en mesure de mettre à jour le pool de transactions en conséquence, remplissant ainsi leur rôle de maintenance du système sans compromettre la confidentialité des utilisateurs.

L’équipe de recherche Orbs explore continuellement tous les aspects des preuves à zéro connaissance, de la théorie à la mise en œuvre. Nous étudions les protocoles de pointe pour les preuves à zéro connaissance et nous nous demandons s’il est possible d’amorcer l’architecture réseau unique Orbs afin d’obtenir de nouvelles améliorations. Parallèlement, nous recherchons des cas d'utilisation où les preuves à zéro connaissance se présentent comme un outil clé. Un exemple sur lequel nous nous sommes récemment concentrés est l'identification numérique, un problème aux implications immenses. Lors du prochain Hackathon, nous espérons montrer une preuve de concept pour un système d'identification de chaînes de blocs, dont l'outil principal est la preuve zéro connaissance.

ZKProof.org est une initiative ouverte de l’industrie et du monde universitaire visant à normaliser la sécurité, la mise en œuvre et l’application de preuves à l’absence de connaissances. Début avril, un atelier de normalisation s'est tenu à Berkeley. Il a rassemblé des experts du monde entier, issus du secteur et du monde universitaire. L'équipe principale d'Orbs était représentée par son cryptographe en chef, Idan Perl.

Exécution non déterministe

L'équipe Orbs étudie activement le sujet du support à l'exécution non déterministe dans les contrats intelligents, afin d'étendre les capacités de notre plate-forme. L'exécution non déterministe fournit deux capacités importantes. Le premier est la possibilité de parvenir à un consensus sur des données externes au système, qui peuvent varier par nature (telles que l'emplacement ou le cours d'une action). Le second est la capacité d'identifier et de supprimer les transactions qui entraînent une exécution non déterministe non intentionnelle permettant au bloc d'atteindre un consensus. Par exemple, les écritures d'ordre d'ordre non déterministes survenues dans le contrat d'élections en raison de l'utilisation de cartes de Golang.

La plupart des solutions blockchains existantes suivent l'approche de réplication de machine à états active, dans laquelle les opérations des clients sont ordonnées puis exécutées. Ici, le service backend distribue l'application sur plusieurs serveurs afin d'améliorer la résilience d'une application client-serveur en matière de tolérance aux erreurs arbitraires et de comportements incorrects (sous certaines hypothèses, telles que la majorité absolue). Dans cette approche, si tous les serveurs partent du même état, traitent et exécutent la même séquence d'opérations, ils conservent tous un seul état cohérent.

Cette conception nécessite que l'exécution d'une opération soit déterministe. Si les serveurs traitent un contrat intelligent qui inclut une source de non-déterminisme, tel qu'aléatoire, ou en dehors des données système, le résultat de l'opération sera différent d'un serveur à l'autre, ce qui entraînera leur divergence et empêchera la progression de l'état.

L'approche commune dans les systèmes à chaînes de blocs pour traiter l'exécution non déterministe est la suppression. Ethereum a développé son propre environnement d'exécution (EVM) ainsi que le langage de programmation Solidity, qui permet d'éliminer toutes les traces de non-déterminisme (par exemple, l'allocation de variables en mémoire à des adresses connues).

Cette approche empêche l'adoption, par exemple par les développeurs habitués à différents langages à usage général, et empêche des fonctionnalités robustes et intéressantes dans l'application qui s'exécute par dessus.

Il existe plusieurs approches traditionnelles dans la recherche sur les systèmes distribués pour soutenir une exécution non déterministe - reposant sur une source aléatoire de confiance - ou même sur la conception de la plate-forme blockchain de la structure Hyperledger, qui ont modifié la séquence de traitement des opérations - exécution en premier lieu, phase de commande et validation finale.

Nous continuons à rechercher des approches possibles pour intégrer le soutien à une exécution non déterministe dans la plate-forme Orbs.

Le hasard

L’équipe de recherche Orbs travaille à la rédaction d’un article sur le thème de la génération aléatoire.

Les applications qui nécessitent de l’aléatoire sont confrontées à un dilemme. S'ils deviennent transparents, ils perdent leur capacité à générer facilement du hasard. S'ils restent obscurs, les utilisateurs n'ont pas de bonne raison de faire confiance à l'application (autre que la réputation, celle-ci ne peut pas être basée sur beaucoup). Étant donné que le caractère aléatoire peut avoir de grandes implications économiques (en déterminant les gagnants de précieux prix), il pourrait s'avérer très rentable de modifier le caractère aléatoire, de le prédire ou de bloquer sa publication. Comment une application peut-elle garantir (et non promettre!) L'intégrité du processus de génération de hasard qu'elle utilise?

Notre article présente un service de génération de hasard dans un environnement de jeu théorique pouvant être utilisé par une application. Intuitivement, cela peut être vu comme une solution de type «hasard en tant que service». Le caractère aléatoire est produit à la demande (plutôt que sous forme de balise), instantanément (sans délai inhérent intégré) et neutralise la collusion.

Un processus de génération aléatoire fiable pourrait s'avérer utile pour le réseau Orbs un jour - en sélectionnant les transactions de manière équitable pendant les périodes de forte charge, en sélectionnant les comités de manière équitable (parmi un vaste réseau de validateurs).

Aller en tournée

Notre propre Shai Yallin a passé les trois premières semaines d’avril en tournée avec son groupe Subterranean Masquerade. Il vivait dans une nuit de nuit et jouait de la musique au quotidien!

Impliquez-vous avec les orbes

  • Visitez le site Web pour en savoir plus sur la chaîne de chaînes publique Orbs
  • Orbs est open-source! Passez en revue le code sur Github et contribuez
  • Commencez à développer des applications sur Orbs, consultez la documentation

Publié à l'origine à l'adresse https://www.orbs.com le 16 mai 2019.