Je suis retourné aujourd’hui à la section de liquidation du livre blanc, au-delà de ce que j’avais déjà couvert dans cette série.
Ça mérite d’être précis ici. Le propre document de Babylon indique que les liquidations passent par un ensemble « whitelisted » de liquidateurs qui surveillent le prix et l’état du coffre, et non par un ensemble entièrement ouvert.
Ma première lecture de « trustless » m’avait fait penser que cela s’appliquait uniformément à l’ensemble du système, liquidation incluse.
Pas vraiment. La logique de dépense du coffre, unstake, liquidate, slash, est appliquée de façon cryptographique. Mais l’ensemble des liquidateurs qui surveillent la condition de déclenchement est whitelisted. Une garantie différente, même mot pour désigner les deux.
Ainsi, une liquidation ne se limite pas à des baisses de prix, puis à la liquidation. Il y a des baisses de prix, puis un oracle les rapporte ; quelqu’un de la liste whitelisted les remarque et agit, et ce n’est qu’à ce moment-là que le mécanisme de contrainte cryptographique est invoqué.
Le livre blanc le dit clairement lui-même, ce n’est pas caché. Mais la dépendance à l’oracle et la whitelist se trouvent en amont, en silence, de la partie que tout le monde appelle trustless.
Je ne sais pas comment cette whitelist de liquidateurs est réellement décidée ou mise à jour au fil du temps. Je n’ai pas trouvé d’explication clairement formulée.
Lors d’un mouvement de prix suffisamment rapide, la cryptographie du coffre a-t-elle vraiment beaucoup d’importance si les liquidateurs whitelisted qui surveillent le déclencheur sont lents, peu nombreux, ou si l’oracle est en retard ? 👍
#baby $BABY
Ça mérite d’être précis ici. Le propre document de Babylon indique que les liquidations passent par un ensemble « whitelisted » de liquidateurs qui surveillent le prix et l’état du coffre, et non par un ensemble entièrement ouvert.
Ma première lecture de « trustless » m’avait fait penser que cela s’appliquait uniformément à l’ensemble du système, liquidation incluse.
Pas vraiment. La logique de dépense du coffre, unstake, liquidate, slash, est appliquée de façon cryptographique. Mais l’ensemble des liquidateurs qui surveillent la condition de déclenchement est whitelisted. Une garantie différente, même mot pour désigner les deux.
Ainsi, une liquidation ne se limite pas à des baisses de prix, puis à la liquidation. Il y a des baisses de prix, puis un oracle les rapporte ; quelqu’un de la liste whitelisted les remarque et agit, et ce n’est qu’à ce moment-là que le mécanisme de contrainte cryptographique est invoqué.
Le livre blanc le dit clairement lui-même, ce n’est pas caché. Mais la dépendance à l’oracle et la whitelist se trouvent en amont, en silence, de la partie que tout le monde appelle trustless.
Je ne sais pas comment cette whitelist de liquidateurs est réellement décidée ou mise à jour au fil du temps. Je n’ai pas trouvé d’explication clairement formulée.
Lors d’un mouvement de prix suffisamment rapide, la cryptographie du coffre a-t-elle vraiment beaucoup d’importance si les liquidateurs whitelisted qui surveillent le déclencheur sont lents, peu nombreux, ou si l’oracle est en retard ? 👍
#baby $BABY