On en discutait hier avec @kimamila , je ne sais pas encore quelle est la meilleure manière de designer ça, je suis en pleine réflexion sur le sujet. La piste que j’aimerais creuser c’est publier les hash des données libres dans la blockchain et les données correspondantes dans un DHT kademlia qui serait gérée par les mêmes nœuds et exposée via la même API RPC (en définissant des customs rpc).
Je ne vois pas bien ce qui est commun à ethereum ? je travaille justement pour un projet qui réimplémente ethereum dans substrate, donc je vois au quotidien que c’est très différent !
@poka avait la même impression, dans l’idée on peut le voir comme ça, mais ça n’a rien à voir avec ce que l’on appelle smart contract dans l’usage.
Le runtime doit à minima implémenter une API de base permettant de créer un bloc et de l’exécuter. On peut étendre son API autant qu’on veut, on peut y définir des offchain worker pour faire des calculs plus couteux. Le point le plus crucial est de différencier le code qui fait partie de l’exécution d’un bloc, du reste. On parle de code onchain vs offchain.
La principale contrainte du runtime est que le temps d’exécution d’un bloc ne doit pas dépasser un temps cible permis par le consensus: 2 secondes pour un bloc toutes les 6 secondes avec BABE.
Pour s’en assurer, un “poids” est associé à chaque extrinsic, et seul les extrinsics dont le poids est inférieur au poids encore disponible sont exécutés, les autres restent en mempool pour un futur bloc.
Non l’impératif d’exécution déterministe des blocs n’a pas de rapport avce le consensus. C’est pour avoir un seul code qui génère et vérifie le bloc. Pour vérifier un bloc, il suffit de le générer avec une mempool virtuelle qui contient exactement les extrinsic dans le bloc, et vérifier qu’on obtient exactement le même bloc au bit près. Comme chaque bloc contient le nouveau merkel root du storage, on est alors certain que le nouvel état de storage on-chain est strictement identique.
La syntaxe, si tu utilises FRAME c’est celle de FRAME, sinon je sais pas. Je connais pas de projet qui utilise substrate sans FRAME, même si c’est théoriquement possible.
Je ne comprends pas la question. La gouvernance c’est au métier de la définir, mais son implémentation est une problématique technique.
Si c’est forker en 2 réseaux différents appliquant des règles différentes en cas de désaccord, ce n’est ni facilité ni rendu plus compliqué, et je ne vois pas comment ça pourrait l’être.
Sachant que dans la conf de polkadot le poid maximal d’un bloc est 2000 milliard de poids et qu’une transaction monétaire à un poid de 68885000. La limiti théorique maximale est de 14516 transactions monétaires par bloc, soit 2419 transactions par seconde soit environ 209 millions de transactions par jour.
On parle bien de limite onchain et mono-blockchain, il est possible de scaler bien plus avec un layer 2 offchain pour les paiements (par exemple les lightning network) ou/et des parachains (sorte de sidechain mais customisables pour se spécialiser dans une tache, pas encore mature mais c’est pour bientôt, polkadot va lancer ses premières parachain dans quelques mois, l’une d’entre elle est d’ailleurs développée par ma boite).
Non c’est un artefact de polkascan, l’auteur est bien celui qui génère le bloc 