Directrices para la auditoría de los protocolos de participación

Tiempo de lectura: 6 minutos

En este blog, hemos esbozado el concepto de protocolos de participación de liquidez y las pautas de auditoría para protocolos de participación. Las pautas cubren una variedad de puntos vulnerables, como mecanismos de retiro, errores de redondeo, llamadas externas, lógica de tarifas, bucles, estructuras, duración del replanteo, etc. Esta publicación de blog será una referencia útil para auditar los protocolos de replanteo y puede ayudarlo a identificar posibles errores. .

¿Qué es el Stake de Liquidez?

El staking de liquidez permite a los usuarios apostar sus tenencias de criptomonedas y obtener recompensas sin sacrificar la liquidez. En lugar de bloquear sus monedas por un período fijo, los usuarios pueden recibir un token líquido que represente sus activos apostados. Este token se puede intercambiar o usar como cualquier otra criptomoneda, lo que permite a los usuarios usar sus activos como lo deseen mientras obtienen recompensas por apuestas.

Por ejemplo, tiene 100 ETH que desea apostar en la red Ethereum. En lugar de bloquear su ETH por un período fijo, puede usar un servicio de participación de liquidez como Lido para apostar su ETH y recibir un token líquido llamado stETH a cambio. Con stETH, aún puede intercambiar o usar su ETH apostado mientras gana recompensas de apuestas.

Comencemos con la auditoría de contratos de participación:

Examine todas las especificaciones de auditoría disponibles antes de comenzar con el código del contrato. Puede ser en forma de documento técnico, archivos LÉAME o cualquier otra cosa. Estos le darán una idea de lo que contendrá el código del contrato.

Al mirar el documento de especificación de auditoría para el contrato de participación, busque estos puntos:

• Tipos de Tarifas en base y sus cálculos.
• Mecanismo de recompensas para tokens apostados
• Facultades del propietario
• ¿El contrato mantendrá ETH?
• ¿Qué fichas tendrá el contrato?
• Contrato original del que se bifurca

Compruebe que las especificaciones coincidan con el código. Comience con las tarifas y la tokenómica, seguido de la validación de la autoridad del propietario. Verifique que todas las recompensas y los valores de las tarifas estén de acuerdo con la documentación.

¿Puntos vulnerables a buscar?

1. Mecanismo de retiro de recompensas:

Verifique que el mecanismo de recompensas de fichas apostadas se implemente correctamente y que las recompensas se distribuyan de manera justa y proporcional a todos los participantes. Los proyectos pueden distribuir recompensas de dos maneras: ya sea automáticamente, de forma periódica o a pedido de los propios usuarios. Se puede implementar y personalizar una función de retiro de acuerdo con la lógica comercial del protocolo.
A continuación se muestran algunos puntos de control:

• Compruebe si algún usuario puede retirar más de su recompensa + monto apostado.
• Compruebe si hay desbordamiento/subdesbordamiento en el cálculo de la cantidad
• Compruebe si ciertos parámetros pueden tener un impacto negativo en las recompensas durante el cálculo.
• Si se utiliza block.timestamp o block.number en esta función. Compruebe si se puede explotar de alguna manera.

2. Lógica de tarifas:

Si el depósito y el retiro están sujetos a alguna tarifa, verifique que ningún usuario individual pueda eludir la tarifa. Además, esté atento a posibles problemas de desbordamiento o subdesbordamiento. Solo el administrador o propietario debe estar autorizado para modificar la configuración de tarifas. Verificar también que se haya establecido un umbral de cuotas máximas, evitando que el administrador lo fije en un monto excesivamente alto.

3. Mecanismo de acuñación/quema de tokens LP:

Verificar si los mecanismos de acuñación y quema se han implementado correctamente. Una función de grabación debe revertir todos los cambios de estado realizados por una función de menta. Además, es crucial verificar que los usuarios reciban la cantidad adecuada de tokens durante la primera apuesta, cuando el grupo está vacío.

La lógica de las funciones de acuñación y grabación se puede verificar matemáticamente para descubrir cualquier vulnerabilidad oculta. Además, el suministro total de tokens LP acuñados no debe exceder los activos apostados.

4. Errores de redondeo:

Aunque ciertos errores de redondeo menores suelen ser inevitables y no preocupantes, pueden crecer significativamente cuando es posible multiplicarlos. Busque casos extremos en los que uno pueda beneficiarse de los errores de redondeo al apostar y deshacer repetidamente.

Para determinar si los errores de redondeo pueden acumularse en una cantidad sustancial durante un período de tiempo prolongado, podemos calcular matemáticamente el rango de posibles errores de redondeo.

5. Duración de la apuesta:

Asegúrese de que los cálculos de la duración de la participación en el contrato se alineen con la lógica comercial especificada. Verifique que los usuarios no puedan canjear recompensas antes de que finalice la duración de la participación omitiendo las comprobaciones de duración. Además, verifique si un atacante puede aprovechar la duración de la participación para obtener más recompensas.

6. Llamadas externas y manejo de tokens:

La mayoría de las llamadas externas serán a los contratos de token. Por lo tanto, debemos determinar qué tipos de tokens manejará el contrato de participación. Es esencial verificar las llamadas externas en busca de errores y ataques de reingreso. Los tokens deflacionarios o tokens con tarifas de transferencia, como Safemoon, pueden representar un problema si su lógica no se implementa correctamente.

7. Comprobaciones de manipulaciones de precios:

La manipulación de precios a través de un préstamo flash es uno de los hacks más frecuentes en los proyectos DeFi. Puede haber situaciones en las que los actores maliciosos puedan usar préstamos rápidos para manipular los precios durante el staking o el desstake de una gran cantidad de tokens. Revise cuidadosamente las funciones de staking y unstake para evitar escenarios extremos que podrían resultar en ataques de manipulación de precios basados ​​en préstamos instantáneos y la pérdida de fondos de otros usuarios.

8. Algunas comprobaciones adicionales:

• Bucles: Si la lógica del contrato implica hacer un bucle en los arreglos, es importante asegurarse de que no se exceda el límite de gas del bloque. Esto puede ocurrir cuando el tamaño de la matriz es muy grande, por lo que debe investigar qué funciones podrían aumentar el tamaño de la matriz y si algún usuario podría explotarla para provocar un ataque DoS. Mira esto reporte.
• Estructuras: Los contratos de replanteo utilizan el tipo de estructura para almacenar datos de usuarios o grupos. Al declarar o acceder a una estructura dentro de una función, es importante especificar si usar "memoria" o "almacenamiento". Podría ayudarnos a ahorrar algo de gasolina. Para obtener más información, consulte a este artículo.
• Frente corriendo: busque escenarios en los que los actores malintencionados puedan adelantar cualquier transacción en su beneficio.
• Comprobaciones de control de acceso/visibilidad de funciones: Cualquiera puede acceder a cualquier función que se declare como externa o pública. Por lo tanto, es importante asegurarse de que ninguna función pública pueda realizar acciones sensibles. Es crucial verificar que el protocolo de staking haya implementado los controles adecuados para evitar el acceso no autorizado tanto a las monedas staking como a la infraestructura del sistema.
• Riesgos de centralización: Es importante no otorgar poderes excesivos al propietario. Si la dirección del administrador se ve comprometida, podría causar un daño significativo al protocolo. Verifique que los privilegios de propietario o administrador sean apropiados y asegúrese de que el protocolo tenga un plan para manejar situaciones en las que se filtren las claves privadas de un administrador.
• Manejo de ETH/WETH: Los contratos a menudo incluyen una lógica específica para manejar ETH. Por ejemplo, cuando msg.value > 0, un contrato puede convertir ETH en WETH y al mismo tiempo permitir que WETH se reciba directamente. Cuando un usuario especifica WETH como moneda pero envía ETH con la llamada, esto puede romper ciertas invariantes y conducir a un comportamiento incorrecto.

Hasta ahora, hemos discutido los protocolos de participación de liquidez y las pautas de auditoría para dichos protocolos. En pocas palabras, la participación de liquidez permite a los usuarios obtener recompensas de participación sin sacrificar la liquidez. Hemos esbozado los puntos vulnerables en los contratos de participación a los que los auditores deben prestar atención, como los mecanismos de retiro, la lógica de tarifas, el mecanismo de acuñación/quema de tokens LP, errores de redondeo, duración de la participación, llamadas externas y controles de manipulación de precios. 

Recomendamos a los auditores que examinen los documentos de especificaciones de auditoría, cotejen las especificaciones con el código y verifiquen las tarifas y la validación tokenómica. También recomendamos verificaciones adicionales, como bucles sobre arreglos, especificación de memoria o almacenamiento para datos de tipo de estructura y escenarios de ejecución frontal. Estas pautas serán útiles para auditar los protocolos de replanteo y ayudarán a identificar posibles errores.

---

11 Vistas

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://blog.quillhash.com/2023/03/10/guidelines-for-auditing-staking-protocols/