On peut les fournir à l’exécution, avec l’option --raw-spec, cf notre discussion Quel genesis une nouvelle version du client doit-il incorporer?. Ça permet de remplacer les raw specs incorporées par une version externe sans changer de binaire.
Oui, l’intérêt d’intégrer le genesis au binaire est qu’on n’a pas à la fournir en dehors. L’inconvénient est que pour changer de genesis, il faut livrer un nouveau binaire (ou utilise --raw-spec). Idem pour les bootnodes.
Ça dépend. Ce n’est pas immédiat d’établir si une version du client est compatible avec un runtime différent. En général ça fonctionne, d’où la possibilité de faire des runtime upgrade sans changer de client, mais si un runtime requiert des api client non présentes dans le client, ça peut ne pas fonctionner. Le versionnage du runtime est indépendant de celui du client. Il me semble que chez purestake, @elois avait travaillé à déterminer si un runtime et un client était compatibles (apparemment il travaille chez moonsong maintenant, d’ailleurs).
Donc en gros, si on reboot une blockchain, on commence par démarrer avec une chaîne “live”, puis on fait build-spec pour passer les raw chainspecs aux autres premiers forgerons. Ces derniers démarrent leur noeud avec un client compatible et l’option --raw-spec pour utiliser les specs du réseau. Enfin, une fois qu’on a un ensemble de bootnodes stables et de confiance, on les inclut dans des client specs et on publie un binaire “tout en un” pour les forgerons qui veulent juste lancer leur nœud mais pas configurer de chaîne custom et de bootnodes.