Función fallback

¿Qué es una función fallback?

Una función fallback es una función especial de Solidity que gestiona las llamadas externas que no coinciden con ninguna otra función definida en un contrato inteligente.

Actúa como opción final de enrutamiento de llamadas del contrato cuando Solidity no puede identificar una función normal a partir de los datos de transacción proporcionados.

También puede ejecutarse cuando una llamada no contiene datos y el contrato no dispone de una función receive separada.

Se utiliza ampliamente en aplicaciones de criptomonedas, incluidos los contratos inteligentes actualizables, los sistemas proxy, las carteras modulares, los contratos de pago y los enrutadores de llamadas personalizados.

Según la documentación oficial de Solidity, un contrato puede contener como máximo una función fallback.

La función fallback debe tener visibilidad external, ya que está diseñada para responder a llamadas procedentes del exterior del contrato.

Puede ser payable si el contrato necesita aceptar criptomoneda nativa mediante una llamada no coincidente.

También puede inspeccionar todos los datos de la transacción y devolver datos de respuesta sin procesar si se utiliza su forma avanzada.

Una función fallback no es un gestor general de errores para todas las operaciones fallidas de un contrato inteligente.

Solo se ejecuta en las condiciones específicas de enrutamiento de llamadas definidas por Solidity y la Ethereum Virtual Machine.

¿Por qué se llama función fallback?

La palabra fallback describe una acción alternativa que se utiliza cuando la acción preferida o esperada no está disponible.

Cuando un usuario llama a una función normal de un contrato inteligente, Solidity intenta primero hacer coincidir los datos de transacción proporcionados con una de las funciones declaradas del contrato.

Si no encuentra ninguna coincidencia, el contrato recurre a la función fallback.

Este comportamiento permite a los desarrolladores definir qué debe ocurrir cuando una cartera, un contrato inteligente o una aplicación envía una llamada no compatible.

La función fallback puede rechazar la llamada, aceptar un pago, registrar un evento, devolver datos o reenviar la llamada a otro contrato.

Si el contrato no contiene una función fallback adecuada, la llamada no compatible normalmente se revierte.

¿Cuándo se llama a una función fallback?

Se llama a una función fallback cuando una llamada externa llega a un contrato inteligente y ninguna función normal coincide con el selector proporcionado.

También se llama cuando la llamada contiene datos de entrada vacíos y el contrato no define una función receive.

Una llamada con datos no vacíos puede llegar a la función fallback tanto si transfiere criptomoneda nativa como si no.

La función fallback debe ser payable cuando la llamada incluye un valor distinto de cero en criptomonedas.

Una función fallback no payable rechaza una llamada no coincidente que intenta transferir valor.

Si el contrato define una función receive, una llamada con datos vacíos llega a esta.

Por tanto, la función fallback tiene responsabilidades distintas según si el contrato contiene también una función receive.

Cómo funciona el enrutamiento de funciones en un contrato inteligente

Las llamadas externas a contratos inteligentes suelen incluir datos de transacción codificados, conocidos como calldata.

Los cuatro primeros bytes de una llamada de función estándar contienen un selector de función.

La especificación ABI de Solidity define el selector como los cuatro primeros bytes del hash Keccak-256 de la firma canónica de una función.

Una firma canónica combina el nombre de la función con los tipos de sus parámetros.

Solidity compara el selector entrante con los selectores de las funciones públicas y externas del contrato.

Si existe un selector coincidente, la función correspondiente procesa la llamada.

Si no existe ninguno, Solidity dirige la llamada a la función fallback, si está disponible.

Normalmente, un calldata de menos de cuatro bytes no puede identificar una función Solidity ordinaria, por lo que puede llegar a la función fallback.

Los datos vacíos siguen una regla de enrutamiento distinta, que da prioridad a la función receive.

Función fallback frente a función receive

La función fallback y la función receive son puntos de entrada distintos de Solidity y tienen finalidades diferentes.

La función receive está diseñada específicamente para llamadas con datos de entrada vacíos.

La función fallback se ocupa principalmente de las llamadas con datos que no coinciden con una función declarada.

La función receive siempre es payable, porque su finalidad principal es aceptar criptomoneda nativa.

Una función fallback solo es payable si el desarrollador permite explícitamente que acepte valor.

Si el contrato define ambas funciones, una transferencia con datos vacíos llega a receive.

Una llamada con datos que no coinciden llega a fallback.

Si el contrato no tiene función receive, una función fallback payable puede procesar una transferencia con datos vacíos.

La guía actual de Solidity sobre la recepción de criptomonedas recomienda definir una función receive cuando existe una función fallback payable.

Esta separación ayuda a distinguir un pago intencionado de una llamada a una función codificada incorrectamente.

Función fallback frente a función normal

Una función normal de Solidity tiene un nombre declarado y suele disponer de su propio selector.

Las aplicaciones pueden llamar a una función normal mediante una interfaz de contrato conocida.

La función fallback no tiene un nombre al que se pueda llamar de la forma habitual.

No dispone de un selector específico que los usuarios puedan llamar directamente.

En cambio, gestiona las llamadas que no coinciden con la interfaz normal del contrato.

Un contrato puede contener muchas funciones normales, pero solo una función fallback.

Normalmente, la lógica principal de negocio de una aplicación descentralizada debe estar en funciones normales.

La función fallback debe tener una finalidad limitada y claramente documentada, salvo que se utilice intencionadamente como enrutador proxy.

Función fallback frente a gestión de errores

La función fallback no se ejecuta cada vez que falla otra función del contrato inteligente.

Si los datos de entrada coinciden con una función normal y esta se revierte posteriormente, no se llama a fallback.

Si una función coincidente rechaza un pago porque no es payable, Solidity no redirige el pago a fallback.

Si el selector es correcto, pero los argumentos tienen un formato incorrecto, la llamada coincidente normalmente se revierte durante la decodificación.

Una condición fallida, una comprobación aritmética, una regla de control de acceso, una llamada externa o un error personalizado tampoco activa la función fallback.

Los desarrolladores deben gestionar estos fallos mediante la gestión de errores normal, comprobaciones de valores devueltos, errores personalizados o la lógica try-and-catch aplicable.

La función fallback gestiona llamadas no coincidentes, no fallos en llamadas coincidentes.

¿Qué es una función fallback payable?

Una función fallback payable puede aceptar criptomoneda nativa adjunta a una llamada externa no coincidente.

El importe enviado con la llamada está disponible en el campo de valor de la transacción.

La dirección del remitente también está disponible para la función fallback.

Si dispone de suficiente gas, una función fallback payable puede modificar el estado, emitir un evento, reenviar la llamada o realizar otra acción permitida.

Hacer que una función fallback sea payable crea responsabilidades financieras para el contrato.

El contrato puede necesitar una contabilidad fiable de saldos, retiradas controladas, procedimientos de emergencia y protección contra la reentrancia.

Un contrato que no esté destinado a custodiar criptomonedas normalmente debería rechazar los pagos inesperados.

La capacidad de aceptar pagos solo debe incluirse cuando responda a una finalidad definida del protocolo.

¿Qué es una función fallback no payable?

Una función fallback no payable puede procesar llamadas no coincidentes que no transfieran criptomoneda nativa.

Una llamada no coincidente con un valor distinto de cero se revierte si la función fallback no es payable.

Este diseño resulta útil cuando un contrato necesita un enrutamiento o registro personalizado, pero no debe aceptar fondos.

Una función fallback no payable también puede rechazar explícitamente selectores no compatibles.

Rechazar llamadas desconocidas puede ayudar a los usuarios y a las aplicaciones a detectar que están utilizando una interfaz incorrecta.

¿Qué información puede leer una función fallback?

Una función fallback puede acceder a la dirección que inició la llamada actual.

Si es payable, puede acceder al importe de criptomoneda nativa adjunto a la llamada.

Puede inspeccionar todo el calldata proporcionado por quien realiza la llamada.

El calldata completo incluye el posible selector y cualquier otro valor codificado.

La forma parametrizada de la función fallback puede recibir estos datos como una secuencia de bytes.

También puede devolver bytes sin procesar directamente a quien realiza la llamada.

Solidity no aplica automáticamente la codificación ABI normal a los datos sin procesar devueltos por fallback.

Este comportamiento resulta especialmente útil en contratos proxy que necesitan devolver exactamente lo que devolvió un contrato de implementación.

¿Debe una función fallback decodificar el calldata?

Una función fallback puede inspeccionar y decodificar manualmente el calldata.

Los cuatro primeros bytes pueden compararse con los selectores esperados.

Los bytes restantes pueden decodificarse según los tipos de parámetros previstos.

Sin embargo, la documentación de Solidity recomienda recurrir a la decodificación manual en fallback solo como último recurso.

Las funciones normales con nombre ofrecen interfaces más claras, una decodificación automática más segura y una integración más sencilla.

La decodificación manual debe verificar la longitud del calldata, los desplazamientos, los tipos y los selectores compatibles.

Los datos mal formados deben rechazarse antes de realizar cualquier cambio de estado sensible.

Una decodificación incorrecta puede provocar un comportamiento inesperado, transacciones fallidas o vulnerabilidades de seguridad.

Funciones fallback en contratos proxy actualizables

Los contratos proxy actualizables son uno de los usos más importantes de las funciones fallback en aplicaciones de criptomonedas.

Un proxy separa la dirección del contrato y el estado almacenado del código que contiene la lógica de negocio de la aplicación.

Los usuarios envían transacciones a la dirección del proxy.

El proxy almacena la dirección de un contrato de implementación que contiene la lógica activa.

Las llamadas que no coinciden con las funciones definidas directamente por el proxy llegan a su función fallback.

La función fallback reenvía esas llamadas al contrato de implementación mediante delegatecall.

La documentación de Ethereum sobre actualizaciones de proxies explica que esta estructura permite cambiar la lógica de negocio mientras los usuarios siguen interactuando con la misma dirección proxy.

El proxy conserva los saldos y el almacenamiento de la aplicación después de cambiar la implementación.

Este enfoque puede permitir corregir errores y añadir funciones sin trasladar a cada usuario a una nueva dirección de contrato.

¿Qué es delegatecall?

Delegatecall es una operación de la Ethereum Virtual Machine que ejecuta código de otro contrato en el contexto del contrato que realiza la llamada.

En un sistema proxy, el contrato de implementación aporta el código.

El proxy aporta la dirección, el saldo de criptomonedas y el almacenamiento persistente.

Durante la ejecución delegada, siguen estando disponibles el remitente original y el valor de la transacción.

Por tanto, la implementación se comporta como si su lógica formara parte del proxy.

La EIP-7 introdujo delegatecall como operación de bajo nivel para ejecutar código externo preservando el contexto de remitente y valor del llamante.

Delegatecall es potente porque la implementación puede leer y modificar el almacenamiento del proxy.

Por la misma razón, también es peligroso.

Una implementación maliciosa o incompatible puede corromper saldos, permisos, datos de titularidad u otros estados críticos.

Cómo enruta una llamada la función fallback de un proxy

El proxy recibe primero todo el calldata del usuario.

Su función fallback identifica la dirección actual de la implementación.

El proxy reenvía el calldata original a esa implementación mediante delegatecall.

La implementación ejecuta su lógica utilizando el almacenamiento del proxy.

El proxy recoge los datos de respuesta de la implementación.

Si la llamada delegada tiene éxito, el proxy devuelve al llamante original los mismos datos de respuesta.

Si la llamada delegada falla, el proxy debe reenviar al llamante la información original del fallo.

Un reenvío incorrecto puede ocultar errores, modificar los datos devueltos o hacer que las integraciones interpreten mal el resultado.

Ranuras de almacenamiento del proxy

Un proxy debe guardar en algún lugar del almacenamiento persistente del contrato la dirección de su implementación.

La ubicación de almacenamiento no debe coincidir con las variables utilizadas por el contrato de implementación.

La ERC-1967 define ranuras de almacenamiento estandarizadas para la información de implementación, beacon y administrador del proxy.

Estas ubicaciones se eligen para evitar las ranuras de almacenamiento normales que asigna el compilador de Solidity.

Las ranuras estandarizadas también ayudan a los exploradores de blockchain y a las herramientas de desarrollo a identificar las relaciones entre proxies.

Utilizar una ranura de almacenamiento establecida reduce las colisiones accidentales, pero no elimina todos los riesgos de actualización.

Las distintas versiones de la implementación deben seguir manteniendo un diseño de almacenamiento compatible.

Riesgo del diseño de almacenamiento

Un proxy conserva los datos existentes cuando se actualiza el contrato de implementación.

La nueva implementación debe interpretar esos datos del mismo modo que la anterior.

Cambiar el orden de las variables de estado existentes puede hacer que un valor se lea como si fuera otro.

Cambiar el tipo de una variable puede corromper su significado o hacer que deje de ser accesible.

Modificar la herencia también puede alterar el diseño de almacenamiento esperado.

Las nuevas variables de estado deben añadirse según las reglas de almacenamiento de la arquitectura proxy elegida.

Una actualización puede completarse correctamente a nivel de transacción y, aun así, dañar silenciosamente el almacenamiento del contrato.

Por tanto, debe comprobarse la compatibilidad del almacenamiento antes de cada actualización de la implementación.

Colisión de selectores de función

Un selector de función solo contiene cuatro bytes.

En teoría, dos firmas de función diferentes pueden producir el mismo selector.

Esto se conoce como colisión de selectores.

La colisión es especialmente importante cuando un proxy y su implementación definen funciones a las que se puede llamar.

El proxy puede interceptar un selector que el usuario esperaba que llegara a la implementación.

La ERC-1967 explica que las colisiones de selectores pueden producir respuestas inesperadas e incluso ocultar un comportamiento malicioso del proxy.

Los desarrolladores deben probar todos los selectores de las funciones del proxy, de la implementación y de administración, así como de las actualizaciones previstas.

El nombre de una función no basta para demostrar que su selector sea único en varios contratos.

Riesgo de la autoridad de actualización

Normalmente, un proxy actualizable dispone de una cuenta o un mecanismo de gobernanza autorizado para cambiar la dirección de la implementación.

Quien controle esa autoridad puede cambiar el código ejecutado a través de la función fallback.

Una clave de actualización comprometida puede instalar una implementación que transfiera activos o cambie los saldos de las cuentas.

Un administrador malicioso también puede sustituir la lógica legítima por otra perjudicial.

Los usuarios deben revisar la dirección del administrador, el umbral de firmantes, el proceso de gobernanza, el retraso de ejecución, los poderes de emergencia y el historial de actualizaciones.

Verificar el código fuente de la función fallback del proxy no garantiza que todas las implementaciones futuras sean seguras.

La capacidad de actualización introduce una necesidad continua de confianza en la gobernanza y la operativa.

Funciones fallback en contratos Diamond

Un contrato Diamond dirige distintos selectores de función a varios contratos de implementación llamados facets.

La función fallback examina el selector entrante e identifica el facet responsable de esa función.

A continuación, reenvía la llamada al facet seleccionado mediante delegatecall.

La ERC-2535 define una arquitectura proxy multifacet para sistemas modulares de contratos inteligentes.

Este diseño puede facilitar aplicaciones cuya lógica sea demasiado amplia para incluirla cómodamente en un solo contrato de implementación.

También permite añadir, sustituir o eliminar grupos individuales de funciones.

Esta flexibilidad aumenta la complejidad relacionada con selectores, almacenamiento, inicialización, permisos y actualizaciones.

Revisar un solo facet no revela todos los comportamientos accesibles desde la dirección Diamond.

Funciones fallback en cuentas inteligentes modulares

Las cuentas de contratos inteligentes pueden utilizar manejadores fallback para añadir funciones modulares.

Un manejador puede admitir firmas, callbacks de tokens, recuperación de cuentas, permisos de sesión o interfaces específicas de una aplicación.

La ERC-7579 describe los manejadores fallback como módulos que amplían las funciones de una cuenta inteligente.

La cuenta debe controlar qué manejadores pueden instalarse, sustituirse y eliminarse.

Un manejador no autorizado puede crear una vía hacia un comportamiento inesperado de la cuenta.

Los usuarios de carteras deben entender que cambiar un módulo fallback puede modificar la respuesta de la cuenta a las llamadas externas.

Gas y funciones fallback

Una función fallback puede realizar operaciones complejas si quien llama aporta suficiente gas.

No debe presuponer que todas las llamadas dispondrán de la misma cantidad.

Algunos métodos antiguos de transferencia de criptomonedas solo envían a los contratos receptores una pequeña asignación de gas.

La documentación actual de Solidity advierte de que send y transfer están obsoletos y se prevé eliminarlos.

Una asignación pequeña puede no bastar para actualizar el almacenamiento, realizar transferencias adicionales, crear contratos o ejecutar llamadas externas costosas.

Los costes de gas también pueden cambiar con las actualizaciones de la red.

Por tanto, una ruta de pago no debe depender de una lógica fallback compleja.

Los desarrolladores no deben considerar que una pequeña asignación de gas sea la única defensa contra callbacks maliciosos.

Riesgo de reentrancia en funciones fallback

Una función fallback puede llamar a otro contrato si dispone de suficiente gas.

Puede volver a llamar al contrato que envió originalmente criptomonedas o inició la interacción.

Este comportamiento puede provocar reentrancia si el contrato emisor no ha completado su contabilidad antes de la llamada externa.

La guía de seguridad de Solidity sobre reentrancia explica que las llamadas a contratos externos pueden devolver el control antes de que termine la operación original.

Los contratos deben validar las condiciones antes de realizar llamadas externas.

Deben actualizar el estado interno crítico antes de transferir el control a un contrato no fiable.

Una protección adecuada contra la reentrancia puede proporcionar una capa adicional de defensa.

Toda llamada externa debe tratarse como una posible ejecución de código no fiable.

Riesgo de denegación de servicio

Una función fallback puede revertirse de forma deliberada o accidental.

Si otro contrato necesita que un pago se realice correctamente antes de completar una operación mayor, el receptor puede bloquearla.

Una función fallback también puede consumir demasiado gas o realizar llamadas externas costosas.

Esto resulta especialmente peligroso cuando el fallo de un pago hace que se revierta todo un bucle de distribución.

La guía de Solidity sobre el envío de criptomonedas recomienda utilizar diseños basados en retiradas para muchos sistemas de pago.

Un modelo de retirada permite que cada destinatario reclame los fondos por separado.

Así, es menos probable que el comportamiento fallback de un destinatario bloquee los pagos de otros usuarios.

Éxito inesperado de una llamada de bajo nivel

Una llamada de bajo nivel informa de si la ejecución del objetivo tuvo éxito o se revirtió.

Un resultado satisfactorio no demuestra que existiera la función con nombre prevista.

Un selector desconocido puede llegar a una función fallback permisiva y ejecutarse correctamente.

Un contrato que realiza una llamada y solo comprueba su estado de éxito puede suponer erróneamente que se ha realizado la operación solicitada.

Al utilizar llamadas de bajo nivel, los desarrolladores deben validar los datos devueltos y los cambios de estado esperados.

Cuando se conoce la función del contrato objetivo, una interfaz tipada suele ser más segura.

Funciones fallback y criptomoneda nativa

Una función fallback payable puede aceptar criptomoneda nativa mediante llamadas no coincidentes.

Si no existe una función receive, también puede gestionar una transferencia simple con datos de entrada vacíos.

Un contrato sin una función receive o fallback payable normalmente rechaza las transferencias directas ordinarias.

Sin embargo, un contrato no puede garantizar que su saldo vaya a permanecer siempre en cero.

La EVM incluye mecanismos excepcionales que pueden aumentar el saldo de un contrato sin ejecutar su lógica receive o fallback.

La contabilidad interna del contrato no debe presuponer que su saldo real siempre coincide con la suma registrada por las funciones de gestión de pagos.

Funciones fallback y tokens ERC-20

Una transferencia normal de tokens ERC-20 no llama a la función fallback del contrato receptor.

El contrato del token cambia los saldos en su propio almacenamiento.

El contrato receptor puede recibir un saldo de tokens sin ejecutar código alguno.

La ERC-20 define transferencias realizadas mediante el contrato del token, no mediante una función de callback obligatoria en el receptor.

Un contrato no debe depender de que se ejecute fallback para detectar todos los depósitos de tokens.

Las aplicaciones suelen utilizar funciones de depósito explícitas o reglas de contabilidad de saldos separadas.

Funciones fallback y NFT

Algunos métodos seguros de transferencia de NFT llaman a una función receptora específica en el contrato de destino.

Esta función receptora es distinta de la función fallback genérica.

Si no existe la función receptora esperada, la llamada puede llegar a fallback porque su selector no coincide con ninguno.

Una función fallback permisiva no debe simular que admite la recepción de NFT, salvo que el contrato implemente intencionadamente el comportamiento requerido.

Una respuesta incorrecta puede hacer que se revierta una transferencia o provocar problemas para recuperar los activos.

¿Puede una función fallback emitir eventos?

Una función fallback puede emitir eventos cuando recibe un pago o una llamada no compatible.

Un evento puede registrar el remitente, el importe transferido, el selector u otro valor útil.

Esta información puede ayudar a los desarrolladores a supervisar integraciones e investigar actividad inesperada.

Emitir un evento consume gas y puede fallar si quien realiza la llamada proporciona una asignación muy limitada.

Los eventos on-chain son públicos y no deben considerarse registros confidenciales.

Registrar todo el calldata también puede generar costes innecesarios, ya que los datos de la transacción ya son visibles públicamente.

¿Puede una función fallback modificar el almacenamiento?

Una función fallback puede modificar el almacenamiento del contrato si dispone de suficiente gas.

Puede actualizar contadores, registros de pagos, permisos, información de enrutamiento u otros datos de estado.

Modificar el almacenamiento aumenta el consumo de gas y amplía el impacto de seguridad de la función.

Una función fallback que modifique datos importantes debe contar con controles de acceso claros y condiciones probadas minuciosamente.

La lógica de recepción de pagos no debe depender de escrituras en el almacenamiento cuando quien llama quizá solo aporte una cantidad limitada de gas.

¿Puede heredarse una función fallback?

Una función fallback puede participar en la herencia de Solidity.

Puede declararse virtual y sustituirse en un contrato derivado.

También puede utilizar modificadores.

La herencia puede dificultar la comprensión del comportamiento final de las llamadas cuando varios contratos aportan lógica relacionada.

Los auditores deben revisar toda la estructura de herencia compilada, no solo un archivo de código fuente.

Cómo probar una función fallback

Los desarrolladores deben probar una llamada que contenga un selector de cuatro bytes desconocido.

Deben probar datos de entrada con menos de cuatro bytes.

Deben probar datos de entrada vacíos sin criptomonedas adjuntas.

Deben probar datos de entrada vacíos con criptomonedas adjuntas.

Deben probar datos no vacíos que no coincidan, tanto con un valor adjunto como sin él.

Deben comprobar la diferencia de enrutamiento cuando hay una función receive.

En un proxy, deben probar que se reenvíen correctamente los datos de retorno y de reversión.

Las pruebas de actualización deben confirmar que todo el almacenamiento existente sigue siendo válido.

Las pruebas de seguridad deben cubrir la reentrancia, las colisiones de selectores, los datos mal formados, las actualizaciones no autorizadas y la falta de gas.

Cómo auditar una función fallback

La auditoría debe identificar primero todos los tipos de llamadas que pueden llegar a la función fallback.

El auditor debe determinar si la función es payable.

Debe comprobarse si el contrato tiene una función receive independiente.

Se deben examinar todas las actualizaciones de almacenamiento, llamadas externas, modificadores, operaciones en ensamblador y comprobaciones de privilegios.

En una auditoría de proxy, debe verificarse cómo se selecciona la dirección de la implementación.

Un usuario no autorizado no debe poder cambiar el destino de delegatecall.

Los datos de retorno y de reversión deben reenviarse correctamente.

Las actualizaciones de la implementación deben mantener la compatibilidad del almacenamiento.

La revisión también debe examinar al administrador, el proceso de gobernanza, el retraso de actualización y los controles de emergencia.

Buenas prácticas para las funciones fallback

Siempre que sea posible, utiliza funciones normales con nombre para el comportamiento habitual de la aplicación.

Define una función receive independiente cuando el contrato acepte intencionadamente transferencias simples de criptomoneda nativa.

Rechaza los selectores no compatibles cuando no sea necesario un enrutamiento personalizado.

Mantén sencilla la lógica fallback relacionada con pagos.

Considera que todos los datos de entrada y todos los llamantes son no fiables.

Valida los selectores y la longitud de los datos antes de decodificarlos manualmente.

Utiliza estándares de proxy revisados en lugar de crear una lógica de reenvío no probada.

Protege las ubicaciones de almacenamiento de la implementación, el administrador y el beacon.

Mantén el diseño de almacenamiento entre actualizaciones.

Aplica controles de acceso claros a todas las funciones de actualización.

Al reenviar llamadas, devuelve correctamente tanto los datos de éxito como los de fallo.

Utiliza un orden seguro para actualizar el estado y una protección adecuada contra la reentrancia.

Prueba llamadas inusuales que quizá nunca generen las interfaces habituales de carteras.

Utiliza una versión estable actual del compilador de Solidity y consulta la lista oficial de errores conocidos del compilador.

Errores habituales con funciones fallback

Un error frecuente es suponer que fallback se ejecuta después de que se revierta una función coincidente.

Otro es hacer que la función sea payable sin disponer de un sistema de retirada seguro.

Algunos contratos aceptan pagos simples mediante fallback sin definir una función receive más clara.

La decodificación manual del calldata puede realizarse sin comprobar la longitud de los datos.

Quien realiza una llamada de bajo nivel puede confundir la ejecución satisfactoria de fallback con la ejecución satisfactoria de la función solicitada.

Un proxy puede guardar la dirección de la implementación en una ubicación que colisione con el estado de la aplicación.

Una actualización puede reordenar las variables y corromper saldos o permisos.

Un destino delegatecall sin restricciones puede permitir la ejecución de código arbitrario en el contexto del proxy.

Una función fallback compleja puede fallar si recibe menos gas del previsto.

Un desarrollador puede esperar equivocadamente que una transferencia ERC-20 active la función fallback.

Ideas equivocadas habituales sobre las funciones fallback

Una función fallback no es un gestor universal de errores de contratos inteligentes.

No se llama después de todas las transacciones fallidas.

No es payable automáticamente.

No siempre es la función adecuada para recibir pagos ordinarios en criptomonedas.

Un contrato solo puede contener una función fallback.

Una función fallback no tiene un selector normal de función.

Puede procesar calldata no coincidente aunque no se transfieran criptomonedas.

Una ejecución satisfactoria de fallback no demuestra que el llamante utilizara la interfaz de contrato correcta.

La función fallback de un proxy puede exponer a los usuarios a código que no está almacenado en la dirección del proxy.

Verificar únicamente el código fuente del proxy no demuestra que su implementación actual sea segura.

Preguntas frecuentes

¿Qué es una función fallback en Solidity?

Es una función externa especial que gestiona las llamadas que no coinciden con ninguna otra función del contrato inteligente.

¿Cuándo se ejecuta la función fallback?

Se ejecuta cuando ningún selector coincide con una función declarada o cuando los datos de entrada están vacíos y no existe una función receive.

¿Puede un contrato tener varias funciones fallback?

No. Un contrato Solidity puede tener como máximo una función fallback.

¿Tiene nombre una función fallback?

No. Se declara mediante la palabra clave fallback, no con un nombre de función normal.

¿Debe ser external una función fallback?

Sí. Una función fallback debe tener visibilidad external.

¿Una función fallback es payable automáticamente?

No. Solo acepta criptomoneda nativa si se marca explícitamente como payable.

¿Qué ocurre si se envía valor a una función fallback no payable?

La llamada no coincidente se revierte si intenta transferir una cantidad distinta de cero.

¿Cuál es la diferencia entre fallback y receive?

Receive gestiona datos de entrada vacíos, mientras que fallback se ocupa principalmente de llamadas que no coinciden con una función declarada.

¿Qué función gestiona una transferencia simple de criptomonedas?

Si existe, la gestiona receive; fallback payable solo lo hace cuando no existe una función receive.

¿Se ejecuta fallback después de que falle otra función?

No. Un fallo dentro de una función coincidente no redirige la ejecución a fallback.

¿Puede fallback inspeccionar los datos de transacción?

Sí. Puede acceder a todo el calldata proporcionado por quien realiza la llamada.

¿Puede fallback devolver datos?

Sí. Su forma avanzada puede devolver bytes sin procesar directamente al llamante.

¿Por qué utilizan fallback los contratos proxy?

La utilizan para reenviar las llamadas de los usuarios a un contrato de implementación mediante delegatecall.

¿Qué conserva delegatecall?

Conserva el remitente y el valor originales y ejecuta el código de implementación sobre el almacenamiento y el saldo del proxy.

¿Delegatecall modifica el almacenamiento de la implementación?

No. El código de implementación ejecutado de forma delegada normalmente lee y escribe el almacenamiento del proxy que realiza la llamada.

¿Qué es un contrato de implementación?

Es el contrato que contiene la lógica de negocio ejecutada mediante un proxy actualizable.

¿Qué es una colisión de selectores?

Se produce cuando firmas de función distintas generan el mismo selector de cuatro bytes.

¿Por qué es importante el diseño de almacenamiento?

Un diseño de almacenamiento incompatible puede hacer que una implementación actualizada lea o sobrescriba incorrectamente los datos existentes del proxy.

¿Puede una función fallback causar reentrancia?

Sí. Puede volver a llamar a otro contrato si dispone de suficiente gas.

¿Puede fallback rechazar un pago?

Sí. Una función fallback no payable o una que se revierta explícitamente puede rechazar un pago normal realizado mediante una llamada de mensaje.

¿Puede un contrato impedir cualquier aumento posible de su saldo?

No. Algunos mecanismos de la EVM pueden aumentar el saldo de un contrato sin ejecutar la lógica receive o fallback.

¿Una transferencia ERC-20 activa fallback?

Normalmente no, porque el contrato del token actualiza los saldos sin llamar al receptor.

¿Puede fallback emitir un evento?

Sí, siempre que la llamada proporcione suficiente gas para esa operación.

¿Puede fallback actualizar el almacenamiento?

Sí, pero las actualizaciones de almacenamiento aumentan el coste y pueden fallar si el gas disponible es limitado.

¿Puede fallback utilizar modificadores?

Sí. Una función fallback puede utilizar modificadores de Solidity.

¿Puede heredarse fallback?

Sí. Puede ser virtual y redefinirse en un contrato derivado.

¿Una llamada de bajo nivel satisfactoria demuestra que existe la función solicitada?

No. Es posible que la función fallback haya aceptado un selector desconocido.

¿Todos los contratos inteligentes deberían tener una función fallback?

No. Un contrato solo debe definirla cuando necesite gestionar de forma personalizada las llamadas no coincidentes.

¿Es segura una función fallback en un contrato actualizable?

Puede serlo si la lógica de reenvío, el diseño de almacenamiento, la implementación y la autoridad de actualización están diseñados y auditados correctamente.

¿Cuál es el mayor riesgo de una función fallback?

Depende de su finalidad, pero la delegación de un proxy, las llamadas externas sin restricciones, las actualizaciones inseguras y el comportamiento inesperado ante pagos pueden ser riesgos críticos.

Conclusión

Una función fallback es un punto de entrada especial de Solidity para llamadas externas que no coinciden con otra función declarada del contrato inteligente.

También puede gestionar datos de entrada vacíos cuando el contrato no define una función receive.

Una función fallback payable puede aceptar criptomoneda nativa, mientras que una no payable rechaza las llamadas no coincidentes que incluyen valor.

Para las transferencias intencionadas y simples de criptomonedas, normalmente es más clara la función receive.

Las funciones fallback son esenciales para los proxies actualizables, ya que pueden reenviar llamadas a contratos de implementación mediante delegatecall.

Este proceso conserva el remitente y el valor originales mientras ejecuta el código de implementación sobre el almacenamiento del proxy.

El enrutamiento mediante fallback en proxies introduce riesgos relacionados con el diseño de almacenamiento, las colisiones de selectores, la autoridad de actualización y delegatecall.

Las funciones fallback también pueden provocar problemas de reentrancia, denegación de servicio, gas, decodificación y éxito inesperado de llamadas.

Los desarrolladores deben limitar el comportamiento de fallback, rechazar las llamadas no compatibles cuando corresponda y utilizar funciones normales con nombre para la lógica habitual de la aplicación.

Entender la función fallback es esencial para evaluar contratos inteligentes de criptomonedas, porque este punto de entrada sin nombre puede controlar los pagos, el enrutamiento de proxies, el comportamiento de cuentas modulares y la ejecución de una aplicación descentralizada completa.