sierpe

Sierpe est un serveur auto-hébergé qui surveille le réseau Stellar pour les contrats qu'un utilisateur enregistre et conserve leur historique complet dans la propre base de données Postgres de l'opérateur, exposée via une API REST et une interface de gestion intégrée. Le projet se présente en version v1.5.2, avec une conception décrite comme stable dans docs/DESIGN.md, et précise que les événements, l'état des contrats, les transferts de jetons, les trustlines et les mouvements de jetons sont complets et fonctionnent sur le testnet. Ce qu'il indexe - Les événements émis par les contrats enregistrés, découverts à partir des spécifications on-chain de chaque contrat et récupérés par blocs, puis suivis à la pointe de la chaîne. - L'état du contrat : l'historique des modifications des entrées de stockage plus un instantané actuel. - Les transferts de jetons décodés (décodage SEP-41, muxé CAP-67) et les trustlines classiques des actifs SAC. - Les mouvements de jetons entrant ou sortant d'un contrat, quel que soit le contrat ayant émis le transfert, avec un rapport de couverture par type. - L'historique au-delà de la fenêtre de rétention RPC : les RPC Stellar conservent environ sept jours d'événements, Sierpe effectue donc un rattrapage depuis la genèse lorsque les sources le permettent et est conçu pour rejouer les History Archives publiques pour les plages non servies par RPC ; le rejeu d'archive est fourni via l'image `-full`. Comment il est utilisé Le déploiement consiste en un conteneur à côté d'un Postgres vide. Les contrats sont enregistrés au moment de l'exécution en tant que données, et non comme code, via un appel authentifié tel que POST /v1/contracts avec un ID de contrat et `from: genesis` ; le serveur classifie ensuite le contrat, récupère son historique et continue de le suivre. Les utilisateurs peuvent interroger les événements avec des filtres de style getEvents-v2 (par exemple topic0 et curseurs), l'instantané de stockage actuel pour une clé, et l'historique de toute entrée de stockage. La documentation liste Railway, Docker Compose et les déploiements de conteneurs génériques, et le README suggère que le même binaire fonctionne sur Railway, AWS, GCP ou un petit VPS, avec un coût cible inférieur à 10 $/mois pour un projet typique. Les prérequis sont Docker ou Go 1.25+, avec une configuration via DATABASE_URL, NETWORK et ADMIN_TOKEN. Comportement de l'API et garanties d'honnêteté Le README souligne que la couverture et les lacunes sont des données de premier plan : chaque réponse déclare une `coverage` et un `scanStatus` (HAS_MORE, WAITING_FOR_LEDGERS, OLDEST_REACHED ou COMPLETE), ainsi une page vide indique soit que rien n'existe, soit que l'indexation n'a pas encore atteint cette plage. La pagination repose sur des curseurs opaques qui encodent l'intégralité de la requête, afin d'éviter toute dérive. L'ensemble de la surface de l'API est spécifié dans docs/openapi.yaml et les métriques sont documentées dans docs/METRICS.md ; un tableau de bord Grafana et une page de statut figurent parmi les livrables de l'appliance. Interface et contrôle d'accès Une interface de gestion est intégrée à la racine `/` et il existe un point de terminaison pour la liste des contrats. Un mode Basic Auth optionnel pour l'ensemble de la surface est proposé pour les déploiements sur des domaines publics. Non-objectifs explicites Le README précise que le projet n'est pas un service hébergé, ni une plateforme d'analyse (pas d'agrégations ou de tableaux de bord sur les données utilisateur), ni un indexeur pour l'ensemble de la chaîne (seuls les contrats enregistrés sont indexés), ni un framework — devoir écrire du code pour l'utiliser serait considéré comme un bug. Feuille de route Les jalons achevés couvrent le squelette (config, santé, migrations, boucle de curseur avec vérifications de continuité), les événements de bout en bout, l'état du contrat, une version appliance v1.0.0, les transferts de jetons et les trustlines SAC (v1.1), le rejeu d'archive (v1.2), l'interface intégrée et la liste des contrats (v1.3), le Basic Auth optionnel (v1.4) et les mouvements de jetons avec couverture par type (v1.5). Les travaux prévus incluent la découverte de classes de contrats en v1.6, où l'enregistrement d'un hash wasm indexe chaque contrat déployé à partir de celui-ci, et en v2 la livraison push avec webhooks signés et broker sinks, avec un serveur MCP décrit comme étant à l'étude. Matériel du projet La documentation comprend docs/DESIGN.md (architecture, modèle de données, surface API, configuration, jalons), docs/DEPLOY.md, docs/KNOWLEDGE.md (29 principes distillés d'indexeurs de production, chacun avec sa source), CONTRIBUTING.md et SECURITY.md. Le projet est sous licence Apache-2.0 et invite aux signalements de problèmes et aux retours.