Después de un gran aumento de CAP, los usuarios comenzaron a informar dos problemas relacionados con su propiedad de liquidez. El equipo profundizó en el problema, identificó el problema y preparó una solución.
https://gitlab.com/thorchain/bepswap/bepswap-web-ui/-/issues/1057r = runa en estaca;
a = activo apostado
R = Rune Balance (después)
A = Saldo de activos (después)
unidades = ((R + A) (r A + R a)) / (4 R A)Asigne las primeras unidades de proveedores de liquidez iguales a la cantidad de RUNE aportada. Asigne unidades de proveedores de liquidez posteriores iguales a la siguiente ecuación: r = runas apostadas;
a = activo apostado
R = Rune Balance (antes)
A = Saldo de activos (antes)
P = Unidades de piscina existentes
Ajuste de deslizamiento = (1 – ABS ((R a – r A) / ((2 r + R) (a + A))))
unidades = ((P (a R + A r)) / (2 A R)) * ajuste de deslizamiento
El algoritmo de Uniswap calcula la propiedad del grupo en función de la proporción de ETH depositado, en comparación con la profundidad existente, multiplicada por la cantidad existente de tokens del grupo.
El equipo descubrió que este algoritmo no causa ningún problema de bonificación y, debido a que solo se permite la provisión de liquidez simétrica, la erosión no se aplicó.
El algoritmo de Uniswap calcula la propiedad del grupo según la media geométrica de los dos activos depositados.
El equipo descubrió que este algoritmo es susceptible al problema de la "bonificación" cuando el precio cambia radicalmente en el transcurso de la adición de liquidez.
En este escenario, tres LP agregan liquidez con un precio variable (1,00 a 1,32). El LP final puede agregar y eliminar liquidez inmediatamente, pero reclamar más de lo que aportan. No se sabe si el equipo de Uniswap está al tanto de este problema. Es posible que un atacante pueda usar un préstamo flash para agregar y eliminar inmediatamente liquidez con fines de lucro, en un grupo que ha experimentado una divergencia de precios. El equipo dejará la comunidad para investigar más este problema.
Problema de bonificación
THORChain tiene que tolerar la provisión de liquidez asimétrica ya que no puede sacar fondos de las billeteras, por lo que debe lidiar con todo lo que se le envíe, y la provisión de liquidez asimétrica es una estrategia de arbitraje válida. El algoritmo original tomó la media de los activos depositados para encontrar la parte del grupo, luego multiplicó cada lado y luego tomó la media de eso. Este método funciona bien si no hay cambio de precio.
Después del mismo escenario que el anterior, se puede ver que el LP final gana una "bonificación" injusta. Este bono es más notable cuanto más drásticos sean los cambios de precio de un grupo durante el transcurso de la liquidez que se agrega.
Bono de reparación
Para abordar el problema encontrado, el algoritmo para asignar la propiedad del grupo se modifica de la siguiente manera:
Al primer acuñador se le asignan unidades de grupo simplemente iguales a la cantidad de RUNE depositada. Esto crea P. Los siguientes minters son los siguientes: El LP final ya no tiene una bonificación
Erosión de capital
El segundo problema es el de la erosión del capital de los proveedores de liquidez existentes. La causa fundamental es que el algoritmo original no tuvo en cuenta el deslizamiento generado por los grandes proveedores de liquidez asimétrica.
En este escenario, el segundo LP realiza dos grandes apuestas asimétricas.
Entonces pueden reclamar más de lo que aportaron, en detrimento de los LP existentes.
Arreglando la erosión del capital
Para solucionar este problema, el deslizamiento debe contabilizarse y "virtualizarse". La intención es transferir una cantidad equivalente de activos del proveedor de liquidez asimétrico a todos los proveedores de liquidez anteriores para que sea equivalente a las tarifas que se habrían retenido si el proveedor de liquidez entrante hubiera realizado un swap. A continuación, se modifica el algoritmo de propiedad del grupo para incluir este ajuste de deslizamiento.
Ejecutando el escenario nuevamente, el problema ahora está solucionado. Los proveedores existentes ahora * se benefician * a expensas de un proveedor de liquidez que realiza una gran participación asimétrica. Los honorarios acumulados que habrían acumulado si el LP hubiera hecho un intercambio y participación primero.
El equipo descubrió dos problemas relacionados con la propiedad del grupo, lo que provocó una "bonificación" y erosión de la liquidez. Los problemas estaban separados y las causas fundamentales de ellos se debían a diferentes razones. La bonificación fue causada por derivar incorrectamente la propiedad del grupo durante los cambios dinámicos de precio, y la erosión fue causada por no tener en cuenta el deslizamiento durante una participación asimétrica. El equipo derivó una ecuación de propiedad de la piscina final que ha abordado ambos problemas y debería evitar que la bonificación y la erosión vuelvan a ocurrir.
El equipo también nota que Uniswap V2 tiende a exhibir el problema de la "bonificación" y el equipo de Uniswap debería investigar esto.
Reporte completo:
https://github.com/thorchain/Resources/blob/master/Audits/BEPSwap-PoolOwnershipIssueAndFix-Sep2020.pdf
Reparar:
El equipo actualizará la máquina de estado con la nueva lógica y la implementará en la red esta semana como Versión 0.14.0. Una vez que se actualiza la red, el CAP se puede aumentar nuevamente.