#newt $NEWT D’après des mesures effectuées sur le Newton Mainnet Beta, je pense que l’engouement aveugle du marché masque une faille d’architecture fatale. Les investisseurs particuliers voient la « limite d’autorisation » comme un bouclier universel, comme si l’on transformait le champ de bataille en coffre-fort. Dans le domaine de l’automatisation de la gestion des risques, le cœur du risk management n’est pas la « limite », mais l’« efficacité » de la validité temporelle des données.
J’ai monté un nœud complet localement et j’ai disséqué en profondeur son mécanisme d’agrégation des signatures BLS. Depuis l’extraction des données sources, la vérification des règles via le moteur Rego, jusqu’à la signature locale du nœud et la diffusion vers la couche de consensus pour prendre la médiane, l’ensemble du flux est extrêmement long. Les paquets que j’ai capturés à l’aide d’une minuterie à haute précision montrent que, de la déclenchement des fluctuations de prix jusqu’à la sortie de la décision finale, le délai physique moyen du système atteint en moyenne 8 à 12 secondes.
Quel ordre de grandeur de catastrophe est-ce ? Prenons l’exemple d’une attaque flash loan ayant eu lieu sur la chaîne : le prix est passé de 1,2 dollar à 0,3 dollar en moins de 4 secondes. Tant que le consensus à médiane de Newton n’a pas terminé sa « finalisation », la valeur réelle du marché externe a déjà été totalement déformée. Le moteur Policy fonde son jugement d’autorisation sur des données expirées datant de 12 secondes : en substance, il utilise les vestiges d’une époque révolue pour couvrir les actifs actuels. Ce n’est pas une malveillance de la part des nœuds, mais un défaut physique inhérent au traitement de données à haute fréquence par un consensus distribué.
À l’heure actuelle, la réalité est la suivante : en cherchant à préserver de force la propriété de non-altérabilité décentralisée, on sacrifie l’exigence la plus critique en matière de latence des transactions à haute fréquence. En couplant étroitement la détection de la falsification et la contrainte temporelle, ce mécanisme produit, en cas d’extrême volatilité, une « île de données » où l’exécution des stratégies accuse rapidement un retard.
La véritable solution industrielle doit découpler entièrement la couche de données et la couche de consensus : les flux de données des oracles doivent emprunter une voie à faible latence pour entrer directement dans le moteur de stratégie ; la couche de consensus doit ensuite effectuer l’audit a posteriori et la confiscation des actifs, et ne doit absolument pas laisser la latence physique devenir un obstacle en amont à la gestion du risque.$BTC
@NewtonProtocol
J’ai monté un nœud complet localement et j’ai disséqué en profondeur son mécanisme d’agrégation des signatures BLS. Depuis l’extraction des données sources, la vérification des règles via le moteur Rego, jusqu’à la signature locale du nœud et la diffusion vers la couche de consensus pour prendre la médiane, l’ensemble du flux est extrêmement long. Les paquets que j’ai capturés à l’aide d’une minuterie à haute précision montrent que, de la déclenchement des fluctuations de prix jusqu’à la sortie de la décision finale, le délai physique moyen du système atteint en moyenne 8 à 12 secondes.
Quel ordre de grandeur de catastrophe est-ce ? Prenons l’exemple d’une attaque flash loan ayant eu lieu sur la chaîne : le prix est passé de 1,2 dollar à 0,3 dollar en moins de 4 secondes. Tant que le consensus à médiane de Newton n’a pas terminé sa « finalisation », la valeur réelle du marché externe a déjà été totalement déformée. Le moteur Policy fonde son jugement d’autorisation sur des données expirées datant de 12 secondes : en substance, il utilise les vestiges d’une époque révolue pour couvrir les actifs actuels. Ce n’est pas une malveillance de la part des nœuds, mais un défaut physique inhérent au traitement de données à haute fréquence par un consensus distribué.
À l’heure actuelle, la réalité est la suivante : en cherchant à préserver de force la propriété de non-altérabilité décentralisée, on sacrifie l’exigence la plus critique en matière de latence des transactions à haute fréquence. En couplant étroitement la détection de la falsification et la contrainte temporelle, ce mécanisme produit, en cas d’extrême volatilité, une « île de données » où l’exécution des stratégies accuse rapidement un retard.
La véritable solution industrielle doit découpler entièrement la couche de données et la couche de consensus : les flux de données des oracles doivent emprunter une voie à faible latence pour entrer directement dans le moteur de stratégie ; la couche de consensus doit ensuite effectuer l’audit a posteriori et la confiscation des actifs, et ne doit absolument pas laisser la latence physique devenir un obstacle en amont à la gestion du risque.$BTC
@NewtonProtocol