Las soluciones para los defectos fatales

MasterChef tiene ciertas fallas que pueden corregirse durante el uso, pero solo si los usuarios son conscientes de ellas y saben lo que pueden hacer. Aquí está la solución, según Gleb Zikov y Vlad Korovnikov de HashEx.

Intercambios descentralizados (DEX) solían ser bastante raros hace solo dos años y, sin embargo, hoy en día parece que están en todas partes. Numerosos proyectos que tienen sus propios DEX personales. Esto sucedió porque, cuando un proyecto de blockchain decide lanzar un DEX, no lo hacen completamente desde cero. En cambio, la base para el código de DEX es a menudo una bifurcación de uno de los dos DEX principales: sushiintercambiar or PancakeSwap.

Contrato inteligente de Masterchef

Estos dos intercambios prácticamente revolucionaron el espacio DEX gracias a un contrato inteligente especial llamado MasterChef. MasterChef aparece en ambos, por lo que también aparece en cualquier DEX que se haya hecho como bifurcación de uno de estos dos. Cada nuevo DEX llega a compartir las mismas características. Pero también significa que comparte las deficiencias y vulnerabilidades de MasterChef. 

Entonces, echemos un vistazo a los problemas que pueden encontrar los usuarios y desarrolladores al tratar con MasterChef. ¿A qué deben prestar atención? ¿Y cómo deben abordarse?

¿Cómo funcionan los DEX?

Lo primero que se debe tener en cuenta es que un contrato de MasterChef es un contrato inteligente escrito en Solidity que controla lo que puede hacer una granja y cómo puede hacerlo. En la mayoría de los proyectos, existen múltiples contratos inteligentes que comparten la responsabilidad y el trabajo. Pero cuando se trata de protocolos basados ​​en MasterChef, es este contrato único el que se encarga de todo lo relacionado con la agricultura.

Los intercambios descentralizados le permiten intercambiar criptomonedas sin tener que depositar dinero en el intercambio. billeteras. En cambio, deposita fondos en contratos inteligentes desde su propia billetera. Usted es la única persona que lo controla y puede acceder a sus propios fondos si los contratos no tienen puertas traseras o vulnerabilidades.

Otra diferencia radica en el hecho de que los CEX utilizan libros de pedidos para comprar y vender. Esto significa que emparejan compradores con vendedores, mientras que los DEX utilizan AMM (Automated Market Fabricante) protocolos de negociación, que calcula el precio de los activos en función de la liquidez invertida.

La liquidez proviene de los fondos de liquidez, que son fondos en los que los usuarios pueden depositar fondos para pares específicos y hacer que los fondos estén disponibles para el protocolo. Luego, cuando alguien intenta comprar activos usando ese par, su pedido se cumple de inmediato usando los fondos del grupo. Mientras tanto, las personas que depositaron fondos en el grupo de liquidez obtienen tokens LP para ese grupo específico. Esto les proporciona el derecho a compartir recompensas.

Y, si alguna vez desean recuperar sus fondos, todo lo que deben hacer es devolver los tokens LP que recibieron.

Como sabrás, existen múltiples formas de generar los rendimientos de las tenencias criptográficas. Las granjas otorgan recompensas adicionales por proporcionar liquidez. Los usuarios agregan liquidez a los DEX, obtienen tokens LP y los apuestan en granjas.

MasterChef: vulnerabilidades y fallas

Hemos cubierto cómo funcionan los DEX y cómo funcionan los fondos de liquidez. Entonces, echemos un vistazo más de cerca a dónde entran las vulnerabilidades de MasterChef, cómo afectan el proceso, así como qué enfoque debe tomar para asegurarse de que las cosas sigan funcionando sin problemas.

Cuentas comprometidas

Uno de los mayores problemas a tener en cuenta gira en torno a las cuentas de los propietarios que se ven comprometidas. Básicamente, SushiSwap inventó un método que le permitió obtener una ventaja frente a Uniswap. Ese método gira en torno a la migración de activos de un intercambio a otro. Esto lo maneja el contrato mediante una función separada a la que solo puede acceder el propietario del contrato.

Sin embargo, esta migración puede terminar sintonizada básicamente con cualquier contrato, sin límites, lo que terminó siendo un gran descuido. Por lo tanto, si la cuenta del propietario se ve comprometida, esto puede resultar en un nuevo contrato de migración que enviaría todos los tokens de LP base en todos los grupos de cultivo a una dirección arbitraria. Esto conduciría a una pérdida masiva de los activos invertidos.

Cabe señalar que esta función ahora es familiar para los desarrolladores, por lo que termina siendo eliminada de inmediato en tenedores. Sin embargo, si permanece presente, eso debería tomarse instantáneamente como una bandera roja.

Otra cosa a tener en cuenta es que, en algunas bifurcaciones de MasterChef, el propietario del contrato puede cambiar la tasa de emisión sin ningún límite. Sin embargo, si la cuenta se ve comprometida, un atacante puede establecer una tasa de emisión muy alta, lo que conduciría a la devaluación del token.

Hay una manera bastante fácil de resolver esto simplemente asegurándose de que todas las funciones disponibles para el propietario del contrato requieran una autorización de múltiples firmas. De esa manera, si una sola dirección se ve comprometida, los malos actores no podrían hacer mucho con ella. Otra cosa que debe hacer es agregar un bloque temporal (contrato Timelock) al llamar a la función de migración. De esta manera, el usuario tiene más tiempo para tomar una decisión y el intercambio debería notificarle la migración o cualquier otra transacción sospechosa.

Agregar pools de cultivo idénticos

Otro problema bastante obvio pero que se pasa por alto surge cuando el contrato original no tiene en cuenta el procesamiento de pools de cultivo idénticos, lo que significa que el contrato amenaza con calcular incorrectamente las recompensas de cultivo.

Este no es un gran problema si MasterChef se usa correctamente, ya que el propietario no agregaría grupos idénticos a propósito. De hecho, en los intercambios que funcionan correctamente, estas cosas se verifican y la creación de un grupo duplicado está estrictamente prohibida. Por lo tanto, si inicia la creación del grupo y se dirige hacia la creación de un duplicado del grupo existente, el sistema debería poder informar un error. O bien, sugiera que agregue sus fondos al grupo existente en lugar de crear uno nuevo.

No calcular la cantidad de tokens depositados

Por alguna razón, las personas tienden a olvidarse de considerar lo que podría suceder si se agregan tokens con comisiones por transferencias o tokens de rebase como grupos al contrato de MasterChef. Lo que sucede es un desglose en la forma en que se calculan las recompensas, ya que el código del contrato agrega activos a los grupos solo llamando a ciertas funciones. Esto significa que agregar tokens a la dirección los combinará con los activos que ya están en el grupo. Pero los cálculos de las recompensas de dichos tokens pueden romperse, lo que genera vulnerabilidades.

Las plataformas que funcionan correctamente deben calcular la cantidad de fondos transferidos para la agricultura por separado al verificar la cantidad real transferida que considera las comisiones. De esta manera, los cálculos de recompensa se realizan correctamente.

MasterChef: Conclusión

MasterChef es un contrato inteligente único que se utiliza para el rendimiento agrícola al proporcionar liquidez en DEX. Desafortunadamente, tiene ciertas fallas que pueden corregirse durante el uso, pero solo si los usuarios son conscientes de ellas y saben lo que pueden hacer. 

Arriba hemos cubierto varias cosas que pueden suceder y cómo se pueden evitar estos problemas. Pero debe tenerse en cuenta que hay más, como la dilución de las recompensas si los tokens se envían directamente a la dirección del contrato, problemas con los cambios en el bloque de inicio, optimizaciones de gas y más. 

En otras palabras, hay vulnerabilidades y problemas a tener en cuenta y vigilar. Pero en general, MasterChef es un contrato revolucionario que prácticamente ha permitido intercambios descentralizados. Por lo tanto, mientras siga usándolo con cuidado y sea consciente de sus fallas y cómo solucionarlas, debería estar bien.

Sobre los autores

Gleb Zikov es el cofundador y director de tecnología de una DeFi EN LINEA y empresa de analisis HashEx.

Vlad Koróvnikov es el auditor y desarrollador junior de contratos inteligentes.

Tengo algunost¿Qué decir sobre las soluciones de Masterchef o cualquier otra cosa? Escríbanos o únase a la discusión en nuestro Canal de telegramas. También puedes atraparnos Tik Tok, Facebooko Twitter.

Observación

Toda la información contenida en nuestro sitio web se publica de buena fe y solo con fines de información general. Cualquier acción que el lector realice sobre la información que se encuentra en nuestro sitio web es estrictamente bajo su propio riesgo.