Pi Network est bien plus qu’un fork de Stellar. Pi hérite de la technologie de base de Stellar (le registre, le protocole de consensus SCP et le modèle de transaction) et y ajoute ses propres couches : le Pi SDK, le Pi Browser, le Pi Desktop, un flux d’approbation de paiement en deux étapes via la plateforme Pi App et un système d’identité KYC. Une différence notable réside dans le graphe de confiance : selon la documentation de Pi, les Cercles de Sécurité des utilisateurs aident les nœuds Pi à former des groupes de confiance pour le consensus. Avec ces couches, Pi est un produit destiné aux utilisateurs finaux, avec une expérience et un modèle opérationnel différents de ceux de Stellar. OPINION PERSONNELLE : À un certain stade de son développement, Pi Network pourrait totalement se détacher de la technologie de Stellar. ----- Pi Network et Stellar : Similitudes et différences I. Vision et approche Les deux projets partagent l’objectif d’élargir l’accès mondial à la finance, mais ils partent de points de départ différents. Stellar : départ depuis l’infrastructure et les institutions - Mission : infrastructure financière open source permettant aux particuliers et aux institutions de transférer de l’argent rapidement et à très faible coût. - Modèle de développement : construction à partir du niveau infrastructure, puis expansion du réseau via des partenaires stratégiques tels que le PNUD, MoneyGram et le HCR. - Focus stratégique : paiements transfrontaliers et tokenisation d’actifs réels (RWA). Pi Network : départ depuis les utilisateurs finaux et un écosystème peer-to-peer - Mission : une monnaie numérique universelle aussi accessible que possible aux particuliers, avec moins de dépendance aux intermédiaires financiers traditionnels. - Modèle de développement : construction d’une communauté d’utilisateurs et d’une économie peer-to-peer (P2P) autour d’applications concrètes en premier lieu. Combinaison de la blockchain avec l’IA. - Institutions et RWA : Pi n’exclut pas les connexions institutionnelles ni la tokenisation des RWA, mais les considère comme une étape ultérieure ; toute telle intégration doit servir les utilisateurs et la croissance de l’écosystème Pi. II. Différences techniques et produit 1. Consensus et graphe de confiance - Stellar : les validateurs configurant leurs propres groupes de confiance (quorum slices). Une étude académique datant d’environ 2019 a révélé que la structure des quorums de Stellar était fortement concentrée et influencée par quelques nœuds clés ; elle peut donc ne plus refléter le réseau actuel. - Pi Network : Pi utilise SCP mais modifie la source de la confiance. Selon Pi, les Cercles de Sécurité des utilisateurs depuis l’application mobile forment un graphe mondial de confiance qui aide les nœuds Pi à former des quorum slices. Pi a indiqué que son testnet comportait initialement une couche centralisée au niveau de la blockchain pour accélérer les tests ; le rôle réel des Cercles de Sécurité sur le mainnet ne peut donc pas encore être vérifié indépendamment. 2. Identité et distribution - Stellar : protocole blockchain pur, sans minage ni KYC au niveau du réseau. - Pi Network : modèle produit intégré, avec une application mobile pour le minage via les Cercles de Sécurité, un système KYC étendu et un logiciel Pi Desktop pour ordinateur (incluant le nœud Pi, l’application Pi, Solohost...). Le passage du KYC est obligatoire pour transférer les Pi minés depuis le solde du téléphone vers le wallet mainnet. 3. Flux de paiement - Stellar : les paiements sont directs. L’utilisateur signe une transaction et la soumet au réseau. Les applications tierces peuvent ajouter leurs propres serveurs, mais le protocole ne l’exige pas. - Pi Network : les paiements passent par la plateforme Pi App avec un flux de vérification en deux étapes : 1. L’interface frontale appelle `Pi.createPayment`. 2. Le backend appelle l’API `/approve` et reçoit un `paymentDTO`. 3. Le Pionnier confirme la transaction dans le wallet Pi. 4. La blockchain la traite et envoie un retour à la plateforme Pi App. 5. Le backend appelle l’API `/complete` avec l’ID de transaction (txID) et reçoit à nouveau un `paymentDTO`.