Si l'on compare la blockchain à une immense usine automatisée fonctionnant 24h/24, alors l'oracle en est le capteur le plus essentiel — il détermine si tout le système peut percevoir avec précision le monde extérieur.

À la fin de 2025, les réseaux de seconde couche de l'écosystème Bitcoin sont déjà nombreux. Mais derrière cette apparence de prospérité, j'ai découvert un phénomène intéressant : trouver un véritable partenaire entrepreneurial partageant la même vision n'est plus aussi simple que de faire correspondre des CV. Plus souvent, c'est comme une résonance sous un "phare numérique" — une résonance au niveau du code.

Lors d'une activité communautaire de développeurs l'année dernière, j'ai rencontré mon actuel associé "Lao Mo". À l'époque, nous réfléchissions tous les deux à la même question : lorsque la valeur du Bitcoin est déjà reconnue et que la liquidité continue de se libérer, comment faire entrer les données d'actifs réels hors chaîne de la manière la plus fluide possible dans BTC L2 ? Ce sentiment de trouver un âme sœur, c'est comme dans une jungle enveloppée de brouillard, deux personnes réglant leur fréquence sur la même chaîne qui finissent par se croiser.

Ce que nous faisons maintenant, c'est une toute nouvelle application décentralisée, dont le nom de code interne est "Omni-Anchor". La base repose sur le cadre écologique existant. Le problème central que ce produit veut résoudre est très simple : le retard dans la tarification des actifs dans l'écosystème BTC.

Du point de vue de l'architecture technique, de nombreux schémas d'oracles actuels utilisent une combinaison de consensus multi-nœuds et de preuves à divulgation nulle. Ce mécanisme peut synchroniser les fluctuations des prix des actifs du monde réel hors chaîne sur la blockchain en moins d'une seconde. Cela semble idéal, mais lors du déploiement réel, plusieurs obstacles apparaissent.

Premièrement, la redondance des données. Si chaque chaîne et chaque application doit déployer des nœuds de validation indépendants, le coût devient prohibitif. Deuxièmement, le coût en temps. Plus il y a de tours de consensus dans le processus de validation, plus le délai de confirmation est long. Troisièmement, la flexibilité. Beaucoup de schémas existants ont une architecture relativement fixe, et supporter de nouveaux types d'actifs ou sources de données nécessite des coûts de modification élevés.

Notre approche consiste à travailler sur la modularité. En résumé, il s'agit de transformer la "collecte de données"