Dans le post Schéma de release pour Duniter #195 je propose une autre formulation de certaines définitions.
Client
Le client est à la fois la “machine virtuelle” qui exécute le runtime, et le logiciel qui assura la connexion avec l’extérieur (couche p2p, API RPC, oracle de distance, keystore…). Le client inclut un runtime “natif” (mais on ne l’utilise pas sauf exception), plusieurs specs (par exemple duniter --chain=dev, duniter --chain=gdev pour un client compilé avec la feature gdev), cf le super post État des lieux des différentes chaînes.
Runtime
C’est à la fois un élément de l’état (state) en tant que “donnée binaire” et à la fois la fonction de transition d’état (state transition) interprétée en webassembly et exécutée à chaque bloc par le client pour passer d’un état au suivant. Elle peut être modifiée par la méthode system.setCode(runtime), elle-même faisant partie du runtime.
Réseau
C’est la notion qui me manquait au début. C’est à la fois simple car intuitif, et complexe car plein de concepts entrent en jeu.
Un réseau blockchain, c’est un ensemble de machines connectés ensemble qui exécutent le même code (runtime) en même temps. Un réseau peut avoir plusieurs clients différents. Ces clients peuvent être légèrement différents (version différente, architecture différente) ou même radicalement différents (autre implémentation dans un autre langage).
Le runtime d’un réseau peut évoluer au cours du temps (blocs de numéro croissant) lors des runtime upgrades. Ça reste le même réseau, mais toutes les machines se sont mises d’accord en même temps de changer leur fonction de transition d’état.